BitLocker – Überprüfung nach Firmwareupdate
Dieser Test bestimmt, ob das Gerät während des Firmwareupdatevorgangs die Wiederherstellung ausgelöst wurde. BitLocker muss vor einem Firmwareupdate aktiviert werden, und der Test sollte nach einem Update ausgeführt werden.
Testdetails
| Spezifikationen |
|
| Plattformen |
|
| Unterstützte Versionen |
|
| Voraussichtliche Laufzeit (in Minuten) | 5 |
| Kategorie | Szenario |
| Zeitüberschreitung (in Minuten) | 300 |
| Neustart erforderlich | false |
| Erfordert eine spezielle Konfiguration | false |
| Typ | automatic |
Zusätzliche Dokumentation
Tests in diesem Funktionsbereich enthalten möglicherweise zusätzliche Dokumentation, einschließlich Informationen zu Voraussetzungen, Einrichtung und Fehlerbehebung, die in den folgenden Themen zu finden sind:
Ausführen des Tests
Dieser Test gibt „Pass“ oder „Fail“ zurück.
Problembehandlung
Allgemeine Informationen zur Problembehandlung von HLK-Testfehlern finden Sie unter Problembehandlung bei Windows HLK-Testfehlern.
Wenn der Test nicht erfolgreich ist, bedeutet das, dass dieses System die BitLocker-Wiederherstellung ausgelöst hat. Rufen Sie die BitLocker-Ereignisprotokolle aus zwei Stellen der Ereignisanzeige ab:
Anwendungs- und Dienstprotokolle > Microsoft > Windows > BitLocker-API > Verwaltung
Filtern Sie unter Windows-Protokolle > System nach Ereignisquellen, die mit BitLocker gestartet wurden.
Die Ereignisse sollten detaillierte Gründe dafür liefern, warum die Wiederherstellung ausgelöst wurde. Nachdem die Ursache der BitLocker-Wiederherstellung ermittelt und behoben wurde, führen Sie den Test auf einem System aus, das nie eine BitLocker-Wiederherstellung ausgelöst hat, damit dieser erfolgreich ist.
Wenn das System den sicheren Start für die Integritätsprüfung (PCR[7]) verwendet, finden Sie in den folgenden Schritten weitere Diagnoseinformationen.
Die Wiederherstellung kann durch das Firmwareupdatepaket ausgelöst werden.
Wenn das System TPM 2.0 aufweist, ist PCR[7]-Unterstützung erforderlich. Andernfalls ist die PCR[7]-Unterstützung optional. Die EFI-Protokollspezifikation enthält Details zur PCR[7]-Unterstützung.
Überprüfen Sie, ob dieses System PCR[7] unterstützt und von BitLocker oder der Geräteverschlüsselung verwendet wird, indem Sie den folgenden Befehl über eine Eingabeaufforderung mit erhöhten Rechten ausführen:
Manage-bde -protectors -get %systemdrive%Wenn das PCR-Validierungsprofil PCR[7, 11] (verwendet den sicheren Start für die Integritätsprüfung) angibt, ist das System ordnungsgemäß konfiguriert.
Wenn das PCR-Validierungsprofil nicht angibt, dass BitLocker den sicheren Start für die Integritätsprüfung verwendet (z. B. bei PCR[0, 2, 4, 11]), bedeutet das, dass BitLocker PCR[7] nicht verwenden kann. In diesem Fall ist möglicherweise eines der folgenden Ereignisse im Ereignisprotokoll unter Anwendungs- und Dienstprotokolle > Microsoft > Windows > BitLocker-API > Verwaltung vorhanden.
BitLocker kann den sicheren Start nicht für die Integritätsprüfung verwenden, da dieser deaktiviert ist.
BitLocker kann den sicheren Start nicht für die Integritätsprüfung nicht verwenden, da die erforderliche UEFI-Variable X nicht vorhanden ist.
BitLocker kann den sicheren Start nicht für die Integritätsprüfung verwenden, da die UEFI-Variable X nicht gelesen werden konnte. Fehlermeldung: X.
BitLocker kann den sicheren Start nicht für die Integritätsprüfung verwenden, da der erwartete TCG-Protokolleintrag für die Variable X fehlt oder ungültig ist.
BitLocker kann den sicheren Start nicht für die Integritätsprüfung verwenden, da der erwartete TCG-Protokolleintrag für die Betriebssystem-Ladeautorität fehlt oder ungültig ist.
BitLocker kann den sicheren Start nicht für die Integritätsprüfung verwenden, da der erwartete TCG-Protokolleintrag für die Betriebssystem-Ladeautorität eine ungültige Struktur aufweist. Es wird ein EV_EFI_VARIABLE_AUTHORITY-Ereignis erwartet. Die Ereignisdaten müssen als EFI_VARIABLE_DATA-Struktur formatiert sein. Dabei muss „VariableName“ auf „EFI_IMAGE_SECURITY_DATABASEGUID“ und UnicodeName auf „db“ festgelegt sein.
BitLocker kann den sicheren Start nicht für die Integritätsprüfung verwenden, da der erwartete TCG-Protokolleintrag für die Betriebssystem-Ladeautorität ungültig ist. Der Inhalt des Felds EFI_VARIABLE_DATA.VariableData sollte eine EFI_SIGNATURE_DATA-Struktur aufweisen, bei der „SignatureOwner“ auf die GUID {77fa9abd-0359-4d32-bd60-28f4e78f784b} (Microsoft) festgelegt ist.
BitLocker kann den sicheren Start nicht für die Integritätsprüfung verwenden, da der erwartete TCG-Protokolleintrag für die Betriebssystem-Ladeautorität ungültig ist. Die in der Betriebssystemautorität enthaltene EFI_SIGNATURE_DATA-Struktur konnte nicht in der Signaturdatenbank „db“ für den sicheren Start gefunden werden.
BitLocker kann den sicheren Start nicht für die Integritätsprüfung verwenden, da die Signatur des Startladers nicht als Microsoft-Signatur bestätigt werden konnte, die mit einem vertrauenswürdigen Microsoft-Stammzertifikat verbunden ist.
BitLocker kann den sicheren Start nicht für die Integritätsprüfung verwenden, da der TCG-Protokolleintrag für die Betriebssystem-Ladeautorität ungültig ist. Die Signatur, die in der EFI_SIGNATURE_DATA-Struktur des Betriebssystem-Autoritätsereignisses enthalten ist, konnte nicht in der bestätigten Zertifikatkette für den Startlader gefunden werden.
BitLocker kann den sicheren Start nicht für die Integritätsprüfung verwenden, da die erwartete Trennlinie im TCG-Protokoll fehlt oder ungültig ist.
BitLocker kann den sicheren Start nicht für die Integritätsprüfung verwenden, da das TCG-Protokoll für PCR[7] ungültige Einträge enthält.
Wenn BitLocker oder die Geräteverschlüsselung PCR[7] verwendet, wie in Schritt 3 vom Befehl „manage-bde“ zurückgegeben wurde, und das System die Wiederherstellung auslöst, ist ein BitLocker-Driver-Ereignis mit der Ereignis-ID 24658 unter Windows-Protokolle > System vorhanden, das angibt, dass die Konfiguration für den sicheren Start unerwartet geändert wurde. Um das Problem zu diagnostizieren, suchen Sie unter Anwendungs- und Dienstprotokolle > Microsoft > Windows > BitLocker-API > Verwaltung nach den zwei aktuellsten BitLocker-API-Ereignissen (Ereignis-ID 817). Der Zeitstempel eines der Ereignisse mit der ID 817 sollte früher als der des Ereignisses 24658 sein. Der Zeitstempel des anderen Ereignisses mit der ID 817 sollte später sein. Das Ereignis 817 wird protokolliert, wenn BitLocker einen Schlüssel mithilfe von PCR[7] im TPM versiegelt. Auf der Registerkarte Details finden Sie den PCR[7]-Wert für die Startsitzung, in der dieses Ereignis protokolliert wurde. Da das System während eines Neustarts eine Wiederherstellung ausgelöst hat, sollten die PCR[7]-Werte in diesen beiden Startsitzungen unterschiedlich sein. Der Unterschied ist an den PCR[7]-Werten ersichtlich, die in diesen beiden 817-Ereignissen protokolliert wurden. In Ereignis 817 wird ebenfalls das TCG-Protokoll für diese Startsitzung protokolliert. Wenn Sie ein Tool zum Analysieren des TCG-Protokolls besitzen, können Sie detaillierte Informationen zur PCR-Erweiterung ermitteln. Wenn Sie kein solches Tool besitzen, haben Sie die folgende Möglichkeit:
Kopieren Sie TBSLogGenerator.exe vom Windows HLK-Controller auf Ihren Testcomputer. Diese finden Sie unter %systemdrive%\Programme (x86)\Windows Kits\8.1\Hardware Certification Kit\Tests\<Architektur>\NTTEST\BASETEST\ngscb. Hierbei entspricht <Architektur> der Architektur Ihres Testcomputers. Diese kann „amd64“, „x86“ oder „Arm“ lauten.
TBSLogGenerator.exe sichert bei der Ausführung die PCR-Werte und das TCG-Protokoll der Startsitzung in einem für Menschen lesbaren Format.
Wiederholen Sie die Schritte, die die BitLocker-Wiederherstellung auslösen. Verwenden Sie für beide Startsitzungen in der BitLocker-Wiederherstellung TBSLogGenerator.exe, um die PCR-Werte und TCG-Protokolle zu sichern.
Analysieren Sie die PCR-Werte und TCG-Protokolle beider Sitzungen, um den Unterschied zu ermitteln.