BitLocker check after firmware update
This test determines whether the device has hit recovery during the firmware update process. BitLocker must be enabled before a firmware update, and the test should be run after an update.
Test details
Associated requirements |
Device.DevFund.Firmware.UpdateDriverPackage |
Platforms |
Windows RT (ARM-based) Windows 8 (x64) Windows 8 (x86) Windows Server 2012 (x64) Windows RT 8.1 Windows 8.1 x64 Windows 8.1 x86 Windows Server 2012 R2 |
Expected run time |
~5 minutes |
Categories |
Basic Certification |
Type |
Automated |
Running the test
The test returns Pass or Fail.
Troubleshooting
If the test fails, it means that this system has hit BitLocker recovery. Please collect BitLocker events in Event viewer at two locations:
Application and Services Logs > Microsoft > Windows > BitLocker-API > Management
Filter Windows Logs > System by event sources started with BitLocker
The events should give detailed reasonS why recovery is hit. After the root cause of BitLocker recovery is understood and fixed, run the test on a system that has never hit a BitLocker recovery to get a passing result.
If the system uses Secure Boot for integrity check (PCR[7]), please see the following steps for more diagnosis information.
The recovery might be triggered by the firmware update package.
If the system has TPM2.0, PCR [7] support is required. Otherwise, PCR [7] support is optional. Tree EFI Protocol specification has details about PCR [7] support.
Check to see if this system supports PCR [7] and is used by BitLocker/Device Encryption by issuing the following command from an elevated command prompt:
Manage-bde -protectors -get %systemdrive%If PCR validation profile shows PCR 7, 11 (Uses Secure Boot for integrity validation), the system is configured correctly.
If PCR validation profile doesn’t show that BitLocker uses Secure Boot for integrity validation (for example, PCR validation profile says PCR 0, 2, 4, 11), this indicates that BitLocker cannot use PCR [7] and one of the following events might be logged into the event log, which is found at Application and Services Logs > Microsoft > Windows > BitLocker-API > Management.
BitLocker cannot use Secure Boot for integrity because it is disabled.
BitLocker cannot use Secure Boot for integrity because the required UEFI variable X is not present.
BitLocker cannot use Secure Boot for integrity because the UEFI variable X could not be read. Error Message: X.
BitLocker cannot use Secure Boot for integrity because the expected TCG Log entry for variable X is missing or invalid.
BitLocker cannot use Secure Boot for integrity because the expected TCG Log entry for the OS Loader Authority is missing or invalid.
BitLocker cannot use Secure Boot for integrity because the expected TCG Log entry for the OS Loader Authority has invalid structure. The event is expected to be an EV_EFI_VARIABLE_AUTHORITY event. The event data must be formatted as an EFI_VARIABLE_DATA structure with VariableName set to EFI_IMAGE_SECURITY_DATABASEGUID and UnicodeName set to ‘db’.
BitLocker cannot use Secure Boot for integrity because the expected TCG Log entry for the OS Loader Authority is invalid. The contents of the EFI_VARIABLE_DATA.VariableData field should be an EFI_SIGNATURE_DATA structure with SignatureOwner set to the GUID {77fa9abd-0359-4d32-bd60-28f4e78f784b} (Microsoft).
BitLocker cannot use Secure Boot for integrity because the expected TCG Log entry for the OS Loader Authority is invalid. The EFI_SIGNATURE_DATA structure contained in the OS authority event could not be found in the Secure Boot ‘db’ signature database.
BitLocker cannot use Secure Boot for integrity because the signature of the boot loader could not be validated as a Windows signature chained to a trusted Microsoft root certificate.
BitLocker cannot use Secure Boot for integrity because the TCG Log entry for the OS Loader Authority is invalid. The signature contained in the EFI_SIGNATURE_DATA structure from the OS authority event could not be found in the verified certificate chain for the boot loader.
BitLocker cannot use Secure Boot for integrity because the expected TCG Log separator entry is missing or invalid.
BitLocker cannot use Secure Boot for integrity because the TCG Log for PCR [7] contains invalid entries.
If BitLocker/Device Encryption is using PCR [7] as reported by the manage-bde command in step 3 and the system hit recovery, you will see a BitLocker-Driver event in Windows Logs > System with Event ID 24658, stating that the Secure Boot configuration has changed unexpectedly. To diagnose the issue, find two most recent BitLocker-API events (Event ID 817) in Application and Services Logs > Microsoft > Windows > BitLocker-API > Management. Time stamp of one of the 817 events should be earlier than that of event 24658; time stamp of the other 817 event should be later. Event 817 is logged when BitLocker seals a key to TPM where PCR [7] is used. In the Details tab, you can find PCR [7] value for the boot session where this event is logged. Given the system hit a recovery during a reboot, PCR [7] values across these two boot sessions should be different. PCR [7] values logged in these two 817 events will tell the difference. In event 817, TCG log for that boot session is logged as well. If you have a tool to parse TCG log, that will reveal detailed information about PCR extension. If you don’t have such a tool, you can do the following:
Copy TBSLogGenerator.exe from the Windows HCK Controller to your test machine. It is located at %systemdrive%\Program Files (x86)\Windows Kits\8.1\Hardware Certification Kit\Tests\<architecture>\NTTEST\BASETEST\ngscb, where <architecture> is the architecture of your test machine. This can be amd64, x86 or ARM.
TBSLogGenerator.exe dumps PCR values and TCG log in a human-readable format for the boot session when TBSLogGenerator.exe gets run.
Repeat the steps that triggers BitLocker recovery. For both boot sessions across BitLocker recovery, use TBSLogGenerator.exe to dump PCR values and TCG logs.
Analyze two sets of PCR values and TCG logs to find the difference.