Ich habe also einen Laptop, der derzeit im Dual-Boot-Modus von Windows und Linux läuft. Ich verwende hauptsächlich die Linux-Installation, aber ich habe bestimmte Dinge, die unter Windows laufen müssen. Derzeit habe ich Bitlocker unter Windows eingerichtet, was ich auch bevorzuge, aber manchmal lösen Änderungen, die Linux am System vornimmt, Bitlocker aus und führen dazu, dass der Wiederherstellungsschlüssel benötigt wird. Das ist jetzt schon ein paar Mal passiert und es ist ziemlich nervig, den Schlüssel eingeben zu müssen. Ist es möglich, das System über eine auf einem USB-Stick gespeicherte Datei zu entsperren? Und damit meine ich nicht nur, den Schlüssel auf einen Stick zu stecken und ihn von dort aus einzutippen. Ich habe Zugriff auf den Schlüssel, aber ihn einzugeben ist wirklich nervig.
Wenn nicht, werde ich Bitlocker wahrscheinlich einfach ganz ausschalten, denn alles, was ich verschlüsseln möchte, befindet sich sowieso auf meiner Linux-Installation, die verschlüsselt ist. Aber es wäre schön, wenn ich Bitlocker bei Bedarf einfach schneller entsperren könnte.
Randbemerkung: Gibt es eine Möglichkeit, irgendwo die Protokolle durchzusehen und herauszufinden, was genau den Auslöser dafür war, dass Bitlocker den Wiederherstellungsschlüssel benötigt? Ich glaube, ich weiß, was es dieses Mal war, aber ich möchte gerne sicher sein.
Antwort1
Derzeit habe ich Bitlocker unter Windows eingerichtet, was ich auch bevorzuge, aber manchmal lösen Änderungen, die Linux am System vornimmt, Bitlocker aus und führen dazu, dass der Wiederherstellungsschlüssel benötigt wird.
Vermeiden Sie das Booten von Windows aus Linux GRUB heraus, da der Systemstatus, den BitLocker zum Versiegeln des Schlüssels mit Ihrem TPM verwendet, von der gesamten Bootkette abhängt. Wenn Sie über GRUB booten, wird der Schlüssel bei jedem Upgrade von grubx64.efi nicht mehr versiegelbar sein.
Verwenden Sie stattdessen entweder das F8-Menü Ihrer Firmware (oder F11 oder F12...), um Windows BOOTMGR auszuwählen, ohne den Umweg über GRUB zu nehmen,oderVerwenden Sie efibootmgrunter Linux, um die Firmware aufzufordern, "das nächste Mal direkt in Windows neu zu starten" (sieheHierUndHier).
Darüber hinaus würde die Aktivierung von Secure Boot BitLocker ermöglichen, sich an PCR7 zu binden, das auch bei Windows BOOTMGR-Updates weniger anfällig ist. (Das Vermeiden von GRUB ist eine Voraussetzung für die Nutzung der PCR7-Versiegelung; BitLocker wird die Verwendung verweigern, wenn es etwas in der Kette erkennt, das nicht von Microsoft signiert ist.)
Ist es möglich, den Schlüssel über eine Datei auf einem USB-Stick zu entsperren? Und damit meine ich nicht nur, den Schlüssel auf einen Stick zu stecken und ihn von dort aus einzutippen.
Wahrscheinlich ja, es ist eine integrierte Funktion von BitLocker, aber soweit ich mich erinnere, wird ein anders formatierter Schlüssel erwartet. Das heißt, Sie können den numerischen Wiederherstellungsschlüssel nicht einfach in die Textdatei einfügen. Dazu müssen Sie einen neuen Schlüsselslot („Schlüsselschutz“) hinzufügen.
Versuchen Sie manage-bde -protectors -add -RecoveryKey, die Schlüsseldatei auf Ihrem USB-Stick zu erstellen (vorausgesetzt, dieser ist unter H:\ gemountet):
manage-bde -protectors -add C: -rk H:\
Hinweis: Sie benötigen hierfür die Vollversion von BitLocker (die „Geräteverschlüsselung“ von Windows Home reicht also nicht aus). Ich weiß eigentlich nicht, ob BitLocker diese Kombination zulässt – obwohl es keinen guten Grund gibt, warum es das nicht tun sollte, aber ich erinnere mich, dass es manchmal wählerisch ist.
Randbemerkung: Gibt es eine Möglichkeit, irgendwo die Protokolle durchzusehen und herauszufinden, was genau den Auslöser dafür war, dass Bitlocker den Wiederherstellungsschlüssel benötigt? Ich glaube, ich weiß, was es dieses Mal war, aber ich möchte gerne sicher sein.
Technisch ist das möglich, aber es werden keine BitLocker-Protokolle sein – Sie würden sich das „TCG-Ereignisprotokoll“ des TPM ansehen und müsstenvergleichenes mit einem früheren Protokoll aus einem „bekanntermaßen funktionierenden“ Protokoll. (Das liegt daran, dass es sich nicht um ein „Dinge sind schiefgelaufen“-Protokoll handelt – es ist eher ein „Systemstatus-Audit“-Protokoll, aus dem die TPM-PCRs berechnet werden;Änderungenin diesem Protokoll beeinflussen, ob das TPM der Entsiegelung des BitLocker-Schlüssels oder anderer Daten zustimmt.)
Die Protokolldatei liegt in einem standardmäßigen, von TCG definierten Binärformat vor und wird im RAM der Firmware gespeichert. Windows speichert sie hilfreicherweise in einer .log-Datei unter C:\Windows\Logs\MeasuredBoot(Protokolle früherer Systemstarts werden dort gesammelt, sodass Sie sie vergleichen können), Linux ermöglicht das Lesen über /sys und es gibt Tools, um sie vom Binärformat in eine Art Textprotokoll zu dekodieren (ich habe selbst eines geschrieben, als ich diese Art von BitLocker-Problem untersuchte); beginnend mitdie von Microsoft empfohlenekönnte eine gute Idee sein, aber es gibt auch einePowerShell-Modul, tpm2_eventlogunter Linux,tcglog-parser, usw.
(Das Ereignisprotokoll von Windows selbst gibt Aufschluss darüber, ob BitLocker seinen Schlüssel mit PCR7 oder PCR4+usw. versiegelt – ohne Secure Boot ist es Letzteres – und ich bin zu 80 % sicher, dass Änderungen an für PCR4 markierten Ereignissen die Ursache sind, da es bei PCR4-Ereignissen in erster Linie darum geht, die genauen SHA-Hashes aller am Prozess beteiligten Bootloader aufzuzeichnen, wie z. B. grubx64.efi aus Ihrer Linux-Installation.)