B
Bob.Dig
Gast
Habe den Startpost entsprechend angepasst. Noch ein paar mehr Erfolgsmeldungen könnten nicht schaden und hoffentlich zieht MS für Win10 nach...
Update: Das Verkleinern der Bitlocker-Partition und die Erstellung einer separaten Daten-Partition hat ebenfalls einwandfrei geklappt.
Mann muss lediglich daran denken dass man die Hardwareverschlüsselungs-GPO nochmal explizit für Festplattenlaufwerke aktiviert, in der Regel macht man es im ersten Schritt oft nur für das Betriebssystemlaufwerk.
Hierbei kann man nochmal die Feststellung von @tox1c90 bestätigen, dass ohne dieses Setting (deaktivieren der Checkbox) von der UI sonst nur Softwareverschlüsselung angeboten wird.
Mann muss lediglich daran denken dass man die Hardwareverschlüsselungs-GPO nochmal explizit für Festplattenlaufwerke aktiviert, in der Regel macht man es im ersten Schritt oft nur für das Betriebssystemlaufwerk.
Hierbei kann man nochmal die Feststellung von @tox1c90 bestätigen, dass ohne dieses Setting (deaktivieren der Checkbox) von der UI sonst nur Softwareverschlüsselung angeboten wird.
Zuletzt bearbeitet:
Falls irgendwer gerade ein hardwareverschlüsseltes sekundäres, d.h. Nicht-Boot-Laufwerk unter Windows 11 am Laufen hat (mit automatischem Unlock aktiviert) und das hier liest, würde ich mich über Input zu folgendem Problem freuen:
Probiert mal, ob das Laufwerk nach Aufwachen aus dem S4 Ruhezustand/Hibernation ansprechbar ist. Bei mir klappt das nur aus normalem S3 Standby, aus dem S4 Ruhezustand meint Windows zwar, dass Laufwerk sei unlocked, es hängt aber und ist nicht ansprechbar. Sobald man darauf zugreifen will springt im Task Manager die Disk usage auf permanent 100% und Antwortzeit auf 2 Sek. und das halbe System hängt sich auf. Das ist bei der SATA so, bei der NVMe kommt einfach nur eine Fehlermeldung bei jedem Versuch mit dem Explorer in die Partition zu gehen.
Nach einem Neustart ist alles wieder gut. Mit Software-Bitlocker passiert das nicht. Offenbar kriegen sekundäre Datenlaufwerke ihren Unlock-Befehl nicht korrekt bei Hardware-Bitlocker und Aufwachen aus dem Ruhezustand, gleiches passiert auch beim Schnellstart leider.
Wenn ich auf der Windows-SSD (d.h. dem Bootlaufwerk) weitere Partitionen erstelle und für diese Hardware-Bitlocker aktiviere, passt auch alles. Das Bootlaufwerk wird offenbar immer korrekt entsperrt (muss ja, sonst könnte man gar nicht booten).
Hatte ich früher unter Windows 10 nicht, darum würde mich interessieren ob das ein Windows 11 - Schnitzer ist. Leider hab ich seitdem auch das Mainboard ja gewechselt und weiß dadurch nicht, ob es nicht auch daran liegen könnte.
Wenn es also bei wem anders unter W11 nicht auftritt, würde ich mal bei MSI deshalb anklopfen
Oder ich geb es wieder ganz auf…. Offenbar ist es eine Never ending Story aus verschiedensten, nicht immer gleich offensichtlichen Problemen.
Am meisten nervt mich, dass es ein Problem ist, das eigtl 2016 schonmal gefixt wurde:
https://social.technet.microsoft.co...ake-from-sleep-issue?forum=win10itprosecurity
Probiert mal, ob das Laufwerk nach Aufwachen aus dem S4 Ruhezustand/Hibernation ansprechbar ist. Bei mir klappt das nur aus normalem S3 Standby, aus dem S4 Ruhezustand meint Windows zwar, dass Laufwerk sei unlocked, es hängt aber und ist nicht ansprechbar. Sobald man darauf zugreifen will springt im Task Manager die Disk usage auf permanent 100% und Antwortzeit auf 2 Sek. und das halbe System hängt sich auf. Das ist bei der SATA so, bei der NVMe kommt einfach nur eine Fehlermeldung bei jedem Versuch mit dem Explorer in die Partition zu gehen.
Nach einem Neustart ist alles wieder gut. Mit Software-Bitlocker passiert das nicht. Offenbar kriegen sekundäre Datenlaufwerke ihren Unlock-Befehl nicht korrekt bei Hardware-Bitlocker und Aufwachen aus dem Ruhezustand, gleiches passiert auch beim Schnellstart leider.
Wenn ich auf der Windows-SSD (d.h. dem Bootlaufwerk) weitere Partitionen erstelle und für diese Hardware-Bitlocker aktiviere, passt auch alles. Das Bootlaufwerk wird offenbar immer korrekt entsperrt (muss ja, sonst könnte man gar nicht booten).
Hatte ich früher unter Windows 10 nicht, darum würde mich interessieren ob das ein Windows 11 - Schnitzer ist. Leider hab ich seitdem auch das Mainboard ja gewechselt und weiß dadurch nicht, ob es nicht auch daran liegen könnte.
Wenn es also bei wem anders unter W11 nicht auftritt, würde ich mal bei MSI deshalb anklopfen
Oder ich geb es wieder ganz auf…. Offenbar ist es eine Never ending Story aus verschiedensten, nicht immer gleich offensichtlichen Problemen.
Am meisten nervt mich, dass es ein Problem ist, das eigtl 2016 schonmal gefixt wurde:
https://social.technet.microsoft.co...ake-from-sleep-issue?forum=win10itprosecurity
Hallo,
Vielen Dank für eure interessanten Beiträge über die letzten 3 Jahre
! Ich nutze Truecrypt seit 2008, aber Bitlocker und HW-Encryption ist neu für mich (naja 12+ Stunden Recherche habe ich hinter mir). Der Installationsprozess ist mir klar, aber die allgemeinen Erfahrungen nach der Installation scheinen stark auseinander zu gehen?
Es klingt nämlich fast so, wie wenn das ganze Thema nachwievor relativ unstable ist? Wie schätzt ihr das ein (so als Resümee, bevorzugt unter Windows 11 Pro)?
Mal angenommen die eDrive HW-Encryption läuft. Gab es bei euch Situationen bei denen das ganze durch Windows Updates, BIOS/UEFI Updates oder Intel ME Firmwareupdates (=TPM bei Intel) zu Problemen geführt hat?
Ich stelle mir nämlich die Frage ob sich der Neuinstallations-Aufwand und der mögliche zukünftige Ärger auszahlt?
Danke!
ps. Für ein SED-Laufwerk und meinen Einsatzzweck (und wohl 95% der Anwender) wäre die Lösung per ATA-Passwort die einfachste Möglichkeit die zumal auch OS-unabhängig wäre. Aber warum auch immer, wird das bei den Consumer Mainboards leider nicht unterstützt! Stattdessen implementiert man einen overengineered Prozess, an den sich nicht alle halten und der scheinbar bis heute nicht richtig funktioniert?
Vielen Dank für eure interessanten Beiträge über die letzten 3 Jahre
! Ich nutze Truecrypt seit 2008, aber Bitlocker und HW-Encryption ist neu für mich (naja 12+ Stunden Recherche habe ich hinter mir). Der Installationsprozess ist mir klar, aber die allgemeinen Erfahrungen nach der Installation scheinen stark auseinander zu gehen?Es klingt nämlich fast so, wie wenn das ganze Thema nachwievor relativ unstable ist? Wie schätzt ihr das ein (so als Resümee, bevorzugt unter Windows 11 Pro)?
Mal angenommen die eDrive HW-Encryption läuft. Gab es bei euch Situationen bei denen das ganze durch Windows Updates, BIOS/UEFI Updates oder Intel ME Firmwareupdates (=TPM bei Intel) zu Problemen geführt hat?
- Falls ja, in welcher Situation genau und hat euch dann der Bitlocker-Recovery-Key geholfen? System oder Datenlaufwerke?
- Ich habe auch immer wieder davon gelesen, dass HW-Bitlocker für Updates (welche?) pausiert werden musste und anschließend garnicht oder nur noch SW-Bitlocker ging? Was ist, wenn ich auf das pausieren vergesse?
- Kann ich ein HW-Encrypted Bitlocker Laufwerk in einen anderen PC stecken und per Recovery-Key dort nutzen?
Ich stelle mir nämlich die Frage ob sich der Neuinstallations-Aufwand und der mögliche zukünftige Ärger auszahlt?
Danke!
ps. Für ein SED-Laufwerk und meinen Einsatzzweck (und wohl 95% der Anwender) wäre die Lösung per ATA-Passwort die einfachste Möglichkeit die zumal auch OS-unabhängig wäre. Aber warum auch immer, wird das bei den Consumer Mainboards leider nicht unterstützt! Stattdessen implementiert man einen overengineered Prozess, an den sich nicht alle halten und der scheinbar bis heute nicht richtig funktioniert?
B
Bob.Dig
Gast
@hm1 Zu Win11 kann ich nichts sagen. Was "unangenehme Situationen" betrifft, diese rühren vor allem an der Verwendung mit einem TPM, das hat aber nix mit der hardwarebasierten Verschlüsselung zu tun sondern betrifft genauso SW-BitLocker. Mein Tipp also, auf TPM verzichten, wobei das bei Win11 natürlich wieder nicht sonderlich sinnvoll ist. Daher den Recovery Key gut absichern.
Was das Pausieren der Verschlüsselung betrifft, auch das ist ein allgemeines BitLocker Feature und erlaubt dir einfach, nach z.B. dem obligatorischen Neustart nach einem Patchday, das Passwort oder die PIN nicht eingeben zu müssen, ist aber völlig optional.
Was das Pausieren der Verschlüsselung betrifft, auch das ist ein allgemeines BitLocker Feature und erlaubt dir einfach, nach z.B. dem obligatorischen Neustart nach einem Patchday, das Passwort oder die PIN nicht eingeben zu müssen, ist aber völlig optional.
Zuletzt bearbeitet von einem Moderator:
hm1 schrieb:
Da stimme ich dir absolut zu.
Beim Thema Verschlüsselung würde ich mir langsam wirklich eine Kopie von Apple Filevault wünschen. Es ist unglaublich wie leicht die Benutzung eine Verschlüsselung sein kann, wenn sie wirklich gut integriert ist.
Die meisten, nein eigentlich jeder, braucht Verschlüsselung als einfachen Schutz, wie Laptop in die Reperatur bringen, Festplatten Garantie, Laptop verloren.
Dafür eigenen sich Bitlocker und Filevault sehr gut und es kommt vor allem auf Performance, Freiheit von Fehlern und Einfachheit in der Benutzung an. Ich finde Bitlocker immer noch sehr kompliziert. Apple nutzt auch eigene Chips zu Verschlüsselung, d.h. es gibt keinen Unterschied in der Performance. Auch wenn SW schnell, ist es nervt doch dass man Performance verliert.
Zuletzt bearbeitet:
Läuft bei mir einwandfrei. Haswell-Notebook mit Samsung 860 EVO, Windows 11.
Vermutlich auch ne recht gute Kombi dafür: Abgehangene Intel-Plattform mit mSATA Samsung SSD.
Finde die Kombi aus transparenter, aller Wahrscheinlichkeit nach sicherer Implementierung und 100 % Performance nach wie vor sehr attraktiv.
Vermutlich auch ne recht gute Kombi dafür: Abgehangene Intel-Plattform mit mSATA Samsung SSD.
Finde die Kombi aus transparenter, aller Wahrscheinlichkeit nach sicherer Implementierung und 100 % Performance nach wie vor sehr attraktiv.
@hm1
Ich habe tatsächlich Alles, was du ansprichst, schon rauf und runter durch und kann dir daher aus eigener Erfahrung sagen, wie das läuft
Zu den einzelnen Punkten:
0. (fett): Windows Updates lösen normalerweise keine Bitlocker-Recovery aus, haben sie bei mir auch nie. Bezüglich BIOS/UEFI-Updates kommt es darauf an, ob du das Firmware-TPM (fTPM) von Intel/AMD nutzt, oder ein diskretes Modul. BIOS/UEFI-Updates, unabhängig davon ob die Intel-ME dabei auch aktualisiert wird oder nicht, lösen meiner Erfahrung nach (MSI-Board) jedes Mal einen Reset des fTPM aus, dabei geht der Bitlocker-Key im fTPM verloren und die Recovery muss benutzt werden. Einfaches "Reset to default" oder sogar ein CMOS-Clear hingegen erhält den Inhalt des fTPM (bei meinem MSI-Board ist es jedenfalls so, das kann je nach Hersteller auch anders sein).
Vorteil diskretes TPM: Dem ist es völlig egal, was mit dem BIOS/UEFI passiert. Wenn man möglichst komfortabel dahingehend sein will, lohnt sich daher ein diskretes TPM.
1.: Wann immer der primäre Bitlocker-Key (TPM oder USB-Startupkey) verloren ist, braucht man den Recovery Key. Unabhängig davon ob System- oder Datenlaufwerk. Und der funktioniert vor allem immer. Wenn man z.B. TPM+PIN hat als primären Key und hat einfach die PIN vergessen, kann man auch selber im Bitlocker-Screen auf Wunsch in die Recovery und den langen Recovery-Key stattdessen eingeben. Dann kommt man rein als wär nix gewesen und kann dann in Windows den TPM-Key ändern. Muss man in die Recovery weil TPM gecleart wurde (z.B. durch BIOS-Update) erfolgt sogar eine automatische Wiederherstellung des TPM-Keys + PIN, und ab dem nächsten Reboot geht es wieder ganz normal ohne Recovery. Für z.B. den Auto-Unlock der Datenlaufwerke spielt es auch keine Rolle, ob man das Systemlaufwerk mittels primärem Key (TPM+PIN) oder Recovery-Key unlocked.
Das ist im Übrigen meine Prozedur beim BIOS/UEFI-Update: Ich kümmer mich um nix, das fTPM ist dann halt leer und ich geb beim ersten Booten nach dem Update den Recovery-Key ein. Nach dem Boot krallt sich Windows automatisch das leere TPM und beschreibt es wieder mit allem Nötigen.
2.: Einmal eingerichtet, verhält sich HW- und Software-Bitlocker meiner Erfahrung nach 100% gleich, auch bei Updates. Pausieren muss man für Updates auch nicht. Bei größeren Feature-Upgrades pausiert Windows automatisch, damit die Installation mit den mehrfachen Reboots unbeaufsichtigt durchlaufen kann (sonst würde der PC jedesmal im Bitlocker-Screen hängen). Außerdem ist pausieren keine Entschlüsselung, sondern gibt nur den Key temporär ohne Authentifizierung frei. D.h., dass dabei konzeptionell die Verschlüsselung nicht entfernt wird, und logischerweise die Art der Verschlüsselung (HW oder SW) zwangsläufig erhalten bleibt.
3.: Ja! Bezüglich Recovery-Key muss man einmal prinzipiell verstanden haben, dass das einfach nur ein Passwort ist, das wie jede andere Authentifizierungs-Form zum Unlocken genutzt werden kann! Der ganze Kram mit "Recovery-Modus" und was diesen auslöst klingt nach viel mehr, als es technisch eigtl. ist. Der Recovery-Key ist nicht mehr als ein zwangsweise zusätzlich eingerichtetes sehr langes Passwort, das technisch nicht mehr ist als das Passwort, dass du selber bei Bitlocker für Datenlaufwerke zum Unlock einrichten kannst. Wenn du lustig drauf bist, könntest du zum Unlocken generell einfach immer nur den Recovery-Key nehmen ohne irgendwelche Nachteile zu haben (außer dass das Eintippen lange dauert).
Aus diesem Grund kannst du die verschlüsselte Partition auch auf jedem beliebigen PC mit dem Key unlocken. Der primäre TPM-Unlock bedeutet z.B. auch nur, dass ein Key mit ähnlicher Länge wie der Recovery-Key im TPM abgelegt wird. Könnte sogar exakt der gleiche sein (ist es aber glaub ich nicht). Recovery-Key statt TPM-Unlock bedeutet dann du gibst ihn selber ein (und nicht das TPM für dich).
Einziger Punkt ist, dass nicht jedes Board von einem HW-verschlüsselten Laufwerk booten kann. Und das manche Boards (z.B. mein altes Asrock) sich beim Post aufhängen, wenn ein gesperrtes HW-verschlüsseltes Laufwerk dran hängt.
Letzte Frage: Du musst nicht mal unbedingt komplett neuinstallieren. Es reicht eine "Dummy"-Installation. Du ziehst ein Image von der bisherigen C:-Partition. Dann installierst du auf eine eDrive-enabled SSD ein neues Windows. Alles wichtige für HW-Verschlüsselung ist nämlich nicht auf C:, sondern auf der EFI-Systempartition sowie der MSR-Partition. Der Witz ist, nach dem ersten Boot der frischen Dummy-Installation dann das alte C:-Image auf die neue SSD zurückzuspielen und damit das neue C: der frischen Installation zu überschreiben, und zwar wirklich nur C:, damit die drumherum-Partitionen die aus der neuen Installation bleiben. In der so zusammengestellten Installation lässt sich dann HW-Verschlüsselung nachträglich aktivieren (hab ich immer so gemacht, wenn ich auf ne neue SSD umgezogen bin).
Ist jetzt sehr lang geworden die Antwort, aber ich hoffe dafür verständlich
Ich habe tatsächlich Alles, was du ansprichst, schon rauf und runter durch und kann dir daher aus eigener Erfahrung sagen, wie das läuft
hm1 schrieb:
Zu den einzelnen Punkten:
0. (fett): Windows Updates lösen normalerweise keine Bitlocker-Recovery aus, haben sie bei mir auch nie. Bezüglich BIOS/UEFI-Updates kommt es darauf an, ob du das Firmware-TPM (fTPM) von Intel/AMD nutzt, oder ein diskretes Modul. BIOS/UEFI-Updates, unabhängig davon ob die Intel-ME dabei auch aktualisiert wird oder nicht, lösen meiner Erfahrung nach (MSI-Board) jedes Mal einen Reset des fTPM aus, dabei geht der Bitlocker-Key im fTPM verloren und die Recovery muss benutzt werden. Einfaches "Reset to default" oder sogar ein CMOS-Clear hingegen erhält den Inhalt des fTPM (bei meinem MSI-Board ist es jedenfalls so, das kann je nach Hersteller auch anders sein).
Vorteil diskretes TPM: Dem ist es völlig egal, was mit dem BIOS/UEFI passiert. Wenn man möglichst komfortabel dahingehend sein will, lohnt sich daher ein diskretes TPM.
1.: Wann immer der primäre Bitlocker-Key (TPM oder USB-Startupkey) verloren ist, braucht man den Recovery Key. Unabhängig davon ob System- oder Datenlaufwerk. Und der funktioniert vor allem immer. Wenn man z.B. TPM+PIN hat als primären Key und hat einfach die PIN vergessen, kann man auch selber im Bitlocker-Screen auf Wunsch in die Recovery und den langen Recovery-Key stattdessen eingeben. Dann kommt man rein als wär nix gewesen und kann dann in Windows den TPM-Key ändern. Muss man in die Recovery weil TPM gecleart wurde (z.B. durch BIOS-Update) erfolgt sogar eine automatische Wiederherstellung des TPM-Keys + PIN, und ab dem nächsten Reboot geht es wieder ganz normal ohne Recovery. Für z.B. den Auto-Unlock der Datenlaufwerke spielt es auch keine Rolle, ob man das Systemlaufwerk mittels primärem Key (TPM+PIN) oder Recovery-Key unlocked.
Das ist im Übrigen meine Prozedur beim BIOS/UEFI-Update: Ich kümmer mich um nix, das fTPM ist dann halt leer und ich geb beim ersten Booten nach dem Update den Recovery-Key ein. Nach dem Boot krallt sich Windows automatisch das leere TPM und beschreibt es wieder mit allem Nötigen.
2.: Einmal eingerichtet, verhält sich HW- und Software-Bitlocker meiner Erfahrung nach 100% gleich, auch bei Updates. Pausieren muss man für Updates auch nicht. Bei größeren Feature-Upgrades pausiert Windows automatisch, damit die Installation mit den mehrfachen Reboots unbeaufsichtigt durchlaufen kann (sonst würde der PC jedesmal im Bitlocker-Screen hängen). Außerdem ist pausieren keine Entschlüsselung, sondern gibt nur den Key temporär ohne Authentifizierung frei. D.h., dass dabei konzeptionell die Verschlüsselung nicht entfernt wird, und logischerweise die Art der Verschlüsselung (HW oder SW) zwangsläufig erhalten bleibt.
3.: Ja! Bezüglich Recovery-Key muss man einmal prinzipiell verstanden haben, dass das einfach nur ein Passwort ist, das wie jede andere Authentifizierungs-Form zum Unlocken genutzt werden kann! Der ganze Kram mit "Recovery-Modus" und was diesen auslöst klingt nach viel mehr, als es technisch eigtl. ist. Der Recovery-Key ist nicht mehr als ein zwangsweise zusätzlich eingerichtetes sehr langes Passwort, das technisch nicht mehr ist als das Passwort, dass du selber bei Bitlocker für Datenlaufwerke zum Unlock einrichten kannst. Wenn du lustig drauf bist, könntest du zum Unlocken generell einfach immer nur den Recovery-Key nehmen ohne irgendwelche Nachteile zu haben (außer dass das Eintippen lange dauert).
Aus diesem Grund kannst du die verschlüsselte Partition auch auf jedem beliebigen PC mit dem Key unlocken. Der primäre TPM-Unlock bedeutet z.B. auch nur, dass ein Key mit ähnlicher Länge wie der Recovery-Key im TPM abgelegt wird. Könnte sogar exakt der gleiche sein (ist es aber glaub ich nicht). Recovery-Key statt TPM-Unlock bedeutet dann du gibst ihn selber ein (und nicht das TPM für dich).
Einziger Punkt ist, dass nicht jedes Board von einem HW-verschlüsselten Laufwerk booten kann. Und das manche Boards (z.B. mein altes Asrock) sich beim Post aufhängen, wenn ein gesperrtes HW-verschlüsseltes Laufwerk dran hängt.
Letzte Frage: Du musst nicht mal unbedingt komplett neuinstallieren. Es reicht eine "Dummy"-Installation. Du ziehst ein Image von der bisherigen C:-Partition. Dann installierst du auf eine eDrive-enabled SSD ein neues Windows. Alles wichtige für HW-Verschlüsselung ist nämlich nicht auf C:, sondern auf der EFI-Systempartition sowie der MSR-Partition. Der Witz ist, nach dem ersten Boot der frischen Dummy-Installation dann das alte C:-Image auf die neue SSD zurückzuspielen und damit das neue C: der frischen Installation zu überschreiben, und zwar wirklich nur C:, damit die drumherum-Partitionen die aus der neuen Installation bleiben. In der so zusammengestellten Installation lässt sich dann HW-Verschlüsselung nachträglich aktivieren (hab ich immer so gemacht, wenn ich auf ne neue SSD umgezogen bin).
Ist jetzt sehr lang geworden die Antwort, aber ich hoffe dafür verständlich
Vielen lieben Dank für eure Erfahrungsberichte! Insbesonderer Dank geht an @tox1c90 ! Dein Beitrag wird wohl in den nächsten Jahren für viele Leute extrem wertvoll sein .
Ich werde nächste Woche versuchen bei meinem alten Laptop (Thinkpad T450 + SATA Samsung 850 Evo) eDrive zu aktivieren und testen. Der ist zwar von 2014, eignet sich aber schön als Spielwiese, weil ich den sowieso Neuinstallieren wollte...
In den nächsten Monaten werde ich dann mein Hauptsystem angehen: Windows 11 Pro, ASUS B660i Board + i7-12700k (inkl. fTPM), UEFI-only, Secureboot on, CSM off, System-NVMe Samsung 980 Pro und eine Daten-NVMe Samsung 970 Evo Plus. Aktuell gibt es aber leider keine Erfahrungen, ob mein Board von eDrive NVMe Disks booten kann. Das ist eine gewisse Unsicherheit, aber leider habe ich auch kein Foto vom NVMe-Systemlaufwerk-PSID-Code-Label gemacht.
DH. wenn ich den PSID-Code brauche, dann müsste ich den PC zur Hälfte zerlegen (und dabei gehen möglicherweise die NMVe-Wärmepads vom Board kaputt). Sehr ärgerlich, dass ich zwar vom Baufortschritt Fotos gemacht habe, aber leider nicht von den Labels der Laufwerke
...
Im Grunde ist für mich nur der Schutz des Datenlaufwerks notwendig. Am Systemlaufwerk habe ich nichts bis auf ein paar Browser-Cookies und Steam.
Daher noch zwei Fragen:
ps. ITX-Systeme sind schön und toll, aber genauso schnell eingesteckt wie ein Laptop... das wurde mir erst nach zwei Monaten wärend einem Urlaub bewusst, sonst hätte ich mich vorher informiert.
. Ich werde nächste Woche versuchen bei meinem alten Laptop (Thinkpad T450 + SATA Samsung 850 Evo) eDrive zu aktivieren und testen. Der ist zwar von 2014, eignet sich aber schön als Spielwiese, weil ich den sowieso Neuinstallieren wollte...
In den nächsten Monaten werde ich dann mein Hauptsystem angehen: Windows 11 Pro, ASUS B660i Board + i7-12700k (inkl. fTPM), UEFI-only, Secureboot on, CSM off, System-NVMe Samsung 980 Pro und eine Daten-NVMe Samsung 970 Evo Plus. Aktuell gibt es aber leider keine Erfahrungen, ob mein Board von eDrive NVMe Disks booten kann. Das ist eine gewisse Unsicherheit, aber leider habe ich auch kein Foto vom NVMe-Systemlaufwerk-PSID-Code-Label gemacht.
DH. wenn ich den PSID-Code brauche, dann müsste ich den PC zur Hälfte zerlegen (und dabei gehen möglicherweise die NMVe-Wärmepads vom Board kaputt). Sehr ärgerlich, dass ich zwar vom Baufortschritt Fotos gemacht habe, aber leider nicht von den Labels der Laufwerke
... Im Grunde ist für mich nur der Schutz des Datenlaufwerks notwendig. Am Systemlaufwerk habe ich nichts bis auf ein paar Browser-Cookies und Steam.
Daher noch zwei Fragen
: - Da ich den PSID-Code vom Datenlaufwerk ohne Aufwand ablesen kann, könnte ich dort versuchen eDrive zu aktivieren. Wenn ich nun das Datenlaufwerk neuinitialisiere (entweder per Secure-Erase oder diskpart), dann müsste es doch ohne Windowsneuinstallation (also auf einem unverschlüsselten System) als reines Datenlaufwerk Hardware-Bitlocker-verschlüsselbar sein, oder?
- Als zweiten Schritt könnte ich dann irgendwann in ferner Zukunft das Systemlaufwerk-eDrive aktivieren und Neuinstallieren (falls ich den PC mal soweit zerlegen sollte, dass ich an den PSID-Code komme). Ich frage mich aber, warum hier überhaupt zwischen eDrive an und aus unterschieden wird? Ich meine der PSID-Code schützt mich doch nur vor dem Reset des Laufwerks und dabei gehen so oder so die Daten verloren... Daher ist es doch völlig egal ob ich physisch Zugriff auf das Laufwerk habe? Nicht nur das, denn laut mancher Berichte müsste ich bei einem Misserfolg, den PC nochmals zerlegen, das Laufwerk ausbauen und auf einem Zweitsystem (was ich nicht besitze) den PSID-Revert durchführen...
ps. ITX-Systeme sind schön und toll, aber genauso schnell eingesteckt wie ein Laptop... das wurde mir erst nach zwei Monaten wärend einem Urlaub bewusst, sonst hätte ich mich vorher informiert
.Also in dem Zusammenhang ist wichtig zu wissen, dass der Auto-Unlock der Datenlaufwerke nur geht, wenn das Systemlaufwerk ebenfalls Bitlocker-verschlüsselt ist. Der Grund ist, dass beim Auto-Unlock die Schlüssel für die zu entsperrenden Partitionen auf C: abgelegt werden, sodass es wichtig ist, dass C: ebenfalls verschlüsselt ist (sonst könnte jemand die vom unverschlüsselten C: einfach auslesen und damit alle anderen entsperren).
Es ist also auch allein für mehr Komfort sinnvoll, das Systemlaufwerk zu verschlüsseln.
Bezüglich PSID, Secure Erase, etc.: Im eDrive-Modus geht kein Secure Erase mehr, die SSD wird nachdem sie geswitched wurde melden, dass sie zum SE-Kommando nicht kompatibel ist. Komplettes Leeren und Neuinitialisieren geht dann nur noch mit diskpart->clean.
Was uns zur PSID bringt: Die dient nur dazu, das Laufwerk wieder vom eDrive- in den normalen Modus zurückzuschalten (wonach SE dann wieder gehen würde). Für was anderes braucht man die nicht. Selbst wenn man alle Möglichkeiten zum Unlock (TPM, PIN, Recoverykey) verloren hat und das LW nicht mehr entschlüsseln kann, kann man das LW einfach per diskpart cleanen und braucht dafür die PSID nicht. Letztlich ist sie imho also gar nicht so wichtig.
Es ist also auch allein für mehr Komfort sinnvoll, das Systemlaufwerk zu verschlüsseln.
Bezüglich PSID, Secure Erase, etc.: Im eDrive-Modus geht kein Secure Erase mehr, die SSD wird nachdem sie geswitched wurde melden, dass sie zum SE-Kommando nicht kompatibel ist. Komplettes Leeren und Neuinitialisieren geht dann nur noch mit diskpart->clean.
Was uns zur PSID bringt: Die dient nur dazu, das Laufwerk wieder vom eDrive- in den normalen Modus zurückzuschalten (wonach SE dann wieder gehen würde). Für was anderes braucht man die nicht. Selbst wenn man alle Möglichkeiten zum Unlock (TPM, PIN, Recoverykey) verloren hat und das LW nicht mehr entschlüsseln kann, kann man das LW einfach per diskpart cleanen und braucht dafür die PSID nicht. Letztlich ist sie imho also gar nicht so wichtig.
Vielen Dank an alle,
Der Versuch eDrive auf dem Laptop (Thinkpad T450) zu aktivieren ist gescheitert... Das lag aber nicht am Laptop oder Windows, sondern der etwas älteren Sandisk X300s die OPAL unterstützt (aber scheinbar nicht über das Sandisk Tool, sondern laut einem Review über eine Drittherstellersoftware) ... Problem: die Drittherstellerseite führt zu Malware ("...sie haben ein iPhone gewonnen!"). Wenn ich wollte, könnte ich aber im Lenovo BIOS jederzeit die SED-Funktion über das ATA-Passwort aktivieren (ohne eDrive). Möglicherweise teste ich HW-Bitlocker mal irgendwann mit der SATA Samsung 850 Evo...
Heute habe ich das Datenlaufwerk meines Desktops SW-verschlüsselt. Backup erstellt, rund 137.000 Dateien / 1,42 TB per md5sum vorab geprüft (ca. 40min Laufzeit) und Software-Bitlocker aktiviert. Erste Performancetests zeigen definitiv einen Impact auf die Performance (siehe unten). - Aber das wirklich überraschende war, dass die Real-Life-Performance des gleichen md5sum Checks über alle Dateien ebenfalls nur 40 Minuten dauerte.
Eigentlich wollte ich SW-Bitlocker nur im vorbeigehen mittesten und dann eDrive aktivieren und HW-Bitlocker nutzen... Aber das Ergebnis scheint mir aktuell gut genug zu sein! Das Thema HW-Bitlocker werde ich daher erst weiterverfolgen, wenn es einen Neuinstallationsgrund und Erfahrungen gibt ob ich von einem NVMe eDrive überhaupt booten kann... (das Thema schlägt im ASUS Forum nur ein paar Mal im Jahr auf...)
Frage @ alle Ich finde im Netz unterschiedliche Aussagen zum Thema TRIM und SW-Bitlocker. Tendenziell eher in Richtung "funktioniert". Wie ist eure Erfahrung hierzu? Danke! (dass das bei HW-Bitlocker funktioniert ist mir klar)
Hier meine Software-Bitlocker Performancemessungen... Zwar nicht das Thema, aber vielleicht nützlich für die Entscheidung zwischen keinem und SW-Bitlocker (i7-12700K, Samsung NVMe 970 Evo Plus 2TB)
Samsung Magician (unverschlüsselt): Das System lief vorher 1 1/2 Stunden im idle... Die Werte waren konstant zu vorherigen Tests.
Samsung Magician (SW-verschlüsselt): Nach ersten Tests recht rasch nach dem Reboot hatte ich einen Abfall von -1.000MB/s bei Seq.Read und -50.000 IOPS bei Rnd.Read! Rund eine Stunde nach dem ersten Reboot nach der SW-Bitlocker Aktivierung hat sich Seq.Read verbessert, aber Rnd.Read bleibt "schwach". Interessant sind die Rnd. Write IOPS die wesentlich höher sind als unverschlüsselt! Die waren aber unverschlüsselt vor 2 Monaten auch über 400.000... Also ok.
CrystalDiskMark8 (unverschlüsselt): Die CPU-Last unverschlüsselt war ca. 1% und im Taskmanager kaum sichtbar. Ergebnis vergleichbar mit früheren Tests.
CrystalDiskMark8 (SW-verschlüsselt): Performance Impact bei den ersten Tests beim Read definitiv sichtbar… aber nicht so schlimm für ein Datengrab. Write ist beim RND4KQ1T1 halbiert. Mit SW-Verschlüsselung habe ich eine CPU-Last von irgendwas zwischen 3-8% und im Taskmanager gut erkennbar! Die Performance hat sich nach ca. 2 Stunden gebessert (SEQ1MQ8T1 war kurz nach der Aktivierung bei 3200MB/s). RND4KQ1T1 blieb jedoch halbiert... Das ist scheinbar der einzige wunde Punkt
Der Versuch eDrive auf dem Laptop (Thinkpad T450) zu aktivieren ist gescheitert... Das lag aber nicht am Laptop oder Windows, sondern der etwas älteren Sandisk X300s die OPAL unterstützt (aber scheinbar nicht über das Sandisk Tool, sondern laut einem Review über eine Drittherstellersoftware) ... Problem: die Drittherstellerseite führt zu Malware ("...sie haben ein iPhone gewonnen!")
. Wenn ich wollte, könnte ich aber im Lenovo BIOS jederzeit die SED-Funktion über das ATA-Passwort aktivieren (ohne eDrive). Möglicherweise teste ich HW-Bitlocker mal irgendwann mit der SATA Samsung 850 Evo...Heute habe ich das Datenlaufwerk meines Desktops SW-verschlüsselt. Backup erstellt, rund 137.000 Dateien / 1,42 TB per md5sum vorab geprüft (ca. 40min Laufzeit) und Software-Bitlocker aktiviert. Erste Performancetests zeigen definitiv einen Impact auf die Performance (siehe unten). - Aber das wirklich überraschende war, dass die Real-Life-Performance des gleichen md5sum Checks über alle Dateien ebenfalls nur 40 Minuten dauerte
.Eigentlich wollte ich SW-Bitlocker nur im vorbeigehen mittesten und dann eDrive aktivieren und HW-Bitlocker nutzen... Aber das Ergebnis scheint mir aktuell gut genug zu sein! Das Thema HW-Bitlocker werde ich daher erst weiterverfolgen, wenn es einen Neuinstallationsgrund und Erfahrungen gibt ob ich von einem NVMe eDrive überhaupt booten kann... (das Thema schlägt im ASUS Forum nur ein paar Mal im Jahr auf...)
Frage @ alle Ich finde im Netz unterschiedliche Aussagen zum Thema TRIM und SW-Bitlocker. Tendenziell eher in Richtung "funktioniert". Wie ist eure Erfahrung hierzu? Danke! (dass das bei HW-Bitlocker funktioniert ist mir klar)
Hier meine Software-Bitlocker Performancemessungen... Zwar nicht das Thema, aber vielleicht nützlich für die Entscheidung zwischen keinem und SW-Bitlocker
(i7-12700K, Samsung NVMe 970 Evo Plus 2TB)Samsung Magician (unverschlüsselt): Das System lief vorher 1 1/2 Stunden im idle... Die Werte waren konstant zu vorherigen Tests.
Samsung Magician (SW-verschlüsselt): Nach ersten Tests recht rasch nach dem Reboot hatte ich einen Abfall von -1.000MB/s bei Seq.Read und -50.000 IOPS bei Rnd.Read! Rund eine Stunde nach dem ersten Reboot nach der SW-Bitlocker Aktivierung hat sich Seq.Read verbessert, aber Rnd.Read bleibt "schwach". Interessant sind die Rnd. Write IOPS die wesentlich höher sind als unverschlüsselt! Die waren aber unverschlüsselt vor 2 Monaten auch über 400.000... Also ok.
CrystalDiskMark8 (unverschlüsselt): Die CPU-Last unverschlüsselt war ca. 1% und im Taskmanager kaum sichtbar. Ergebnis vergleichbar mit früheren Tests.
CrystalDiskMark8 (SW-verschlüsselt): Performance Impact bei den ersten Tests beim Read definitiv sichtbar… aber nicht so schlimm für ein Datengrab. Write ist beim RND4KQ1T1 halbiert. Mit SW-Verschlüsselung habe ich eine CPU-Last von irgendwas zwischen 3-8% und im Taskmanager gut erkennbar! Die Performance hat sich nach ca. 2 Stunden gebessert (SEQ1MQ8T1 war kurz nach der Aktivierung bei 3200MB/s). RND4KQ1T1 blieb jedoch halbiert... Das ist scheinbar der einzige wunde Punkt
Starbuck80
Newbie
- Registriert
- Feb. 2022
- Beiträge
- 6
Hallo Zusammen,
nach Monaten der Recherche und immer wieder rumprobieren bin ich unter anderem auch über diesen Thread gestoßen. Nach dem ich zwischenzeitlich aufgegeben hatte, konnte ich nun mit einer älteren Win10 1903er Version das eDrive zum laufen bekommen. Also erstmal ein Danke an alle Beteiligten für das letzte Teil des Puzzles
Allerdings ist mir bei meinem letzten Setup etwas aufgefallen und vielleicht kann das ja mal jemand testen und eventuell bestätigen:
Ich habe die Theorie dass die Hardware-Encryption auch mit Versionen >1903 möglich ist, allerdings "verhält" sich die Grundinstallation bei Versionen ab 1909 anders. Folgendes war mir aufgefallen:
Vielleicht kann das ja mal jemand testen bei Gelegenheit.
Gruß
Starbuck
nach Monaten der Recherche und immer wieder rumprobieren bin ich unter anderem auch über diesen Thread gestoßen. Nach dem ich zwischenzeitlich aufgegeben hatte, konnte ich nun mit einer älteren Win10 1903er Version das eDrive zum laufen bekommen. Also erstmal ein Danke an alle Beteiligten für das letzte Teil des Puzzles
Allerdings ist mir bei meinem letzten Setup etwas aufgefallen und vielleicht kann das ja mal jemand testen und eventuell bestätigen:
Ich habe die Theorie dass die Hardware-Encryption auch mit Versionen >1903 möglich ist, allerdings "verhält" sich die Grundinstallation bei Versionen ab 1909 anders. Folgendes war mir aufgefallen:
- Grundsetup Win10 21h2 (oder jede andere > 1903)
- Im Explorer wird das C:\ Drive wie üblich angezeigt, man könnte nun über das Kontext-Menü Bitlocker aktivieren, ABER: Wenn man über CMD den Status mit "manage-bde -status" abfragt, sieht man das Bitlocker irgendwie schon "vorbereitet" ist. Aber mit einer Software-Cipher!
- Also anstatt die GPO für die Hardware-Encryption zu setzten, wird Bitlocker normal aktiviert. Das sollte nicht lang dauern.
- Danach Bitlocker wieder deaktivieren, das dauert dann einen Moment.
- Nachdem deaktivieren mit "manage-bde -status" prüfen das Bitlocker wirklich deaktiviert ist.
- Die GPO setzten, reboot (ggf. vorher "Schnell Start" in den Energie Optionen deaktivieren, oder mit "gpupdate /force" nachhelfen)
- Bitlocker aktivieren, Hardware Encryption funktioniert.
Vielleicht kann das ja mal jemand testen bei Gelegenheit.
Gruß
Starbuck
B
Bob.Dig
Gast
Also wer solche Theorien aufstellt, darf sie auch gerne selbst testen.Starbuck80 schrieb:
Irgendeine "Vorbereitung" deutet auf einen Laptop mit TPM hin, ändert aber an den bekannten Gegebenheiten nichts.
Starbuck80
Newbie
- Registriert
- Feb. 2022
- Beiträge
- 6
Bei mir hat es ja so funktioniert. Nur hab ich nur dieses eine System zum testen.
Ja TPM war aktiv. Die übrigen Vorrausetzungen sind natürlich dieselben.
Ja TPM war aktiv. Die übrigen Vorrausetzungen sind natürlich dieselben.
Zuletzt bearbeitet:
Das „vorbereitet“ kenne ich auch nur von Laptops sowie Surface-Tablets, die ab Werk mit Verschlüsselung ausgeliefert werden. Bei denen ist irgendwas im UEFI hinterlegt, das Windows anweist die Verschlüsselung nach Neuinstallation automatisch wieder zu aktivieren, bzw mit einer Verzögerung um die Einrichtung nicht zu stören (d.h. vorbereitet). Diese Geräte haben in der modernen Systemsteuerung einen Unterpunkt „Geräteverschlüsselung“. Dort steht zwar nix von Bitlocker, aber im Hintergrund ist es natürlich Bitlocker.
Da standardmäßig ohne Gruppenrichtlinie nur Software-Bitlocker läuft, wird dann zunächst natürlich nur dieses aktiviert.
Da standardmäßig ohne Gruppenrichtlinie nur Software-Bitlocker läuft, wird dann zunächst natürlich nur dieses aktiviert.
Starbuck80
Newbie
- Registriert
- Feb. 2022
- Beiträge
- 6
Ich denke die Vorberreitung geschieht durch das Setup, bei Installation wird erkannt das alle eDrive-Vorrausetztungen gegeben sind und Bitlocker aktiviert/vorbereitet. Dies würde auch der Microsoft Doku entsprechen. Der Knackpunkt ist nur das Microsoft ja irgendwann die Hardware-Verschlüsselung standardmäßig deaktiviert hat. Daher wird dann Software-Cipher verwendet. (Was ja streng genommen dann kein eDrive mehr ist) Und dies wiederum könnte dann im Konflikt mit der zu aktivierenden GPO stehen und bei Versionen >1903 dazu führen, dass sich Bitlocker nicht aktivieren lässt.
Quelle: https://docs.microsoft.com/en-us/wi...uring-encrypted-hard-drives-as-startup-drives
Quelle: https://docs.microsoft.com/en-us/wi...onfiguration-disableencrypteddiskprovisioning
B
Bob.Dig
Gast
@Starbuck80 Du liegst hier, wie schon die ganze, kurze Zeit, die Du hier angemeldet bist, falsch und deine Theorien sind daher wertlos. Wir brauchen hier auch keine weiteren deiner Theorien, eher solides Testen ist gefragt, welche Konfigurationen funktionieren. Und vielleicht kommt auch eDrive irgendwann wieder zurück zu Win10, es wird vermutlich nicht von MS angekündigt werden.
Deine Zitate sind zwar nett, aber uns hier längst bekannt, sie beziehen sich auf das ursprüngliche eDrive, bevor MS es verbannt hat oder im Falle der jüngeren Win11 Builds weiterhin gut versteckt hält.
Das Verhalten, was Du beschreibst, ist mit jedem aktuelleren Laptop zu beobachten, da MS dort standardmäßig das "normale" BitLocker aktivieren möchte, das hat aber nichts mit eDrive zu tun!
Deine Zitate sind zwar nett, aber uns hier längst bekannt, sie beziehen sich auf das ursprüngliche eDrive, bevor MS es verbannt hat oder im Falle der jüngeren Win11 Builds weiterhin gut versteckt hält.
Das Verhalten, was Du beschreibst, ist mit jedem aktuelleren Laptop zu beobachten, da MS dort standardmäßig das "normale" BitLocker aktivieren möchte, das hat aber nichts mit eDrive zu tun!
Zuletzt bearbeitet von einem Moderator:
