Disable Driver Signature Verification

Intro

I recently discussed if it is possible to create a computer profile that keeps the Driver Signature Verification disabled on fully encrypted Windows 11 using BitLocker with Secure Boot. It sounds straightforward, isn’t it?

The discussion was about managing such a profiled computer under Intune’s umbrella and using up-to-date hardware (Dell) with TPM2.0 and UEFI. Also, we talk about how the enrollment process with AutoPilot should look to keep a pleasant user experience. The shortcut to not managing such computers wasn’t the conclusion of the debate.

You properly ask yourself why we should disable such a security feature. I was told programmers might have this feature disabled for testing or debugging drivers still in development and not yet digitally signed.

There are a few components involved in the subject. The main areas are Driver Integrity, UEFI Secure Boot, and BitLocker.

Driver Signature Verification

Driver Signature Verification is a security feature in Windows to ensure that only signed drivers are loaded during the boot and the computer’s regular operation. It aims to prevent the loading of unsigned drivers that could be malicious or cause computer instability. A disabled Driver Signature Verification feature is often associated with the Test Mode. Windows will display a watermark on the desktop indicating that the computer is in Test Mode.

Run the following command with admin privileges to disable Driver Signature Verification:

bcdedit /set testsigning on

Secure Boot

Secure Boot helps ensure your computer boots using only validated boot software. When Secure Boot is activated, each piece of boot software is checked, including firmware drivers and the operating system. If the signatures are good, your computer boots, and the firmware will provide control for the operating system. To enable Secure Boot, the systems must be in UEFI Boot mode.

My experience is that all modern delivery computers have Secure Boot enabled by default. Secure Boot can run in Deploy Mode, meaning it is active. Also, Deploy Mode is a doable option for reporting only.

An interesting fact is to enable Secure Boot on running computers from Windows through WMI. However, disabling Secure Boot from Windows WMI down to firmware is impossible. Same for the Secure Boot Mode, you can switch from Audit to Deploy Mode, not the other way around when Windows is running. Such changes need to be executed before the operating system load.

The status of the Secure Boot Stale is verifiable with System Information: 

msinfo32.exe

BitLocker

BitLocker is leveraging the data stored in the TPM’s Platform Configuration Register (PCR).
Microsoft explains this integration: By default, BitLocker provides integrity protection for Secure Boot by utilizing the TPM PCR 7 measurement.
For computers with Secure Boot activated, BitLocker will utilize PCR 7. The default BCD validation profile used by BitLocker has testsigning as part of it.

Using the command-line tool for BitLocker shows the PCR Validation Profile:

manage-bde -protectors C: -get

Let’s combine it all

First, Secure Boot has to be disabled (Audit Mode only is possible as well). Secure Boot has been created to check the integrity of the drivers – no way around it. 

C:\Windows\System32>bcdedit /set testsigning on
An error has occurred setting the element data.
The value is protected by Secure Boot policy and cannot be modified or deleted.

Disabling Secure Boot can only be performed from BIOS. The operating system cannot disable it. It is not supported via CCTK or WMI as designed. However, from a disabled to an enabled state is desired by Dell Online Reference Guide.

C:\Program Files (x86)\Dell\CCTK\X86_64>cctk.exe --secureboot=disabled

Invalid argument for the provided option 'secureboot'.
secureboot:  When enabled, BIOS should only perform Secure Boot authentication and boot in UEFI mode without loading Compatibility Support Module (CSM). BIOS refers to this setting to decide on the POST behavior. You can disable this feature only from BIOS setup screen.

Going forward, two possible scenarios are possible. The scenario where Secure Boot is disabled from the beginning is unlikely, as it is industry standard, and all new computers delivered have it enabled by default. Never or less, the IT admin (or manufacturer) could turn it off before delivery to the user. The second way of disabling Secure Boot afterward is more likely.

Secure Boot is disabled from the start

The IT admin disables Secure Boot before BitLocker starts encryption of the computer (assumption #1: the IT admin knows the BIOS password, assumption #2: a BIOS password is set).
When Secure Boot is disabled right from the beginning before enrollment and encryption, TPM PCR 7 is not utilized for the measurement. Bitlocker should use PCR 0, 2, 4, 11.

PCR 7 Configuration is shown in System Information:

msinfo32.exe

Putting the machine from the current state into Test Mode will trigger a Recovery Key screen upon the next reboot because the BitLocker integrity check has detected modification to the BCD (Boot Configuration Data).

This problem gets addressed in the chapter further down.

Secure Boot gets disabled afterward

The IT admin disables Secure Boot after BitLocker encryption. I would assume this is the most frequently used scenario: disabling Secure Boot afterward to not interrupt with delivery-zero-touch-process (AutoPilot). So BitLocker would utilize PCR 7 for its measurement in such circumstances.

Upon deactivating Secure Boot, BitLocker will trigger a Recovery Key screen with the next start of the operating system, as the integrity chain is damaged. Then BitLocker should switch to using PCR 0, 2, 4, 11.

The action to avoid the Recovery Key screen is to programmatically not allow BitLocker ever to use PCR 7, even if Secure Boot is on, by utilizing the policy Allow Secure Boot for integrity validation set to Disabled.

The policy is unavailable in Intune; hence, using the corresponding registry key is okay.

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE]
"OSUseEnhancedBcdProfile"=dword:00000001

This key should be set before disk encryption starts. The best point in time is during the device preparation phase of AutoPilot.
[…] Encryption itself wouldn’t even start until the user logged in[…] , as found out by Niall C. Brady in one of his excellent posts.

At this stage, we have a computer without Secure Boot, encrypted with BitLocker, and not using PCR 7. The switch to Test mode should be doable now. However, the Recovery Key screen will pop up due to the same problem as in the previous scenario; the integrity check will fail due to unauthorized modification to the BCD.

Custom BCD Profile

The policy Use enhanced Boot Configuration Data validation profile allows modification of the default BCR profile of BitLocker. The value all:testsigning is required for the ignore list to avoid the Recovery Key screen when toggling Test Mode on or off.

An Intune policy was unavailable, falling back to registry edit.

As stated previously, those keys should exist before BitLocker encryption of the computer; otherwise, they are not considered. 

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE]
"OSAllowSecureBootForIntegrity"=dword:00000000
"OSUseEnhancedBcdProfile"=dword:00000001
"OSBcdAdditionalSecurityCriticalSettings"=hex(7):00,00
"OSBcdAdditionalExcludedSettings"=hex(7):61,00,6c,00,6c,00,3a,00,74,00,65,00,\
  73,00,74,00,73,00,69,00,67,00,6e,00,69,00,6e,00,67,00,00,00,00,00

When switching between Test Mode and not, the BCD modification is accepted and does not trigger a BitLocker Recovery Key screen.

Where are we now?

As per the profile’s request, the user can switch back and forth to Test Mode without an unpleasant Recovery Key screen on a fully encrypted computer, unfortunately, without the UEFI Secure Boot security feature.

Just turning Secure Boot off is not problematic; even so, physical access to the computer is needed; the key is avoiding the Recovery Key screen of Bitlocker for user satisfaction.

An essential consideration for BitLocker is vital, as its integrity check needs to be handled. Timing is critical for this part. If integrity has been checked before the first encryption of the computer, the switch to Test Mode will trigger a disliked Recovery Key screen.

The correct follow in my case study

  1. Whether Secure Boot is on or off.
  2. The user starts the enrollment. Apply a script during the enrollment, including the registry keys and values from above.
  3. BitLocker encryption will start without utilizing PCR7 when the user preparation phase starts. Modification to the default BCD profile gets applied (allow Test Mode).
  4. The user should request to physically disable Secure Boot on the computer.

Doing so, we are time-independent, and the user and IT admin can collaborate on when to disable Secure Boot after enrollment.

Lessons learned

It isn’t straightforward, which is good. It is not as easy as it sounds. David Weston did an excellent presentation about Hardware security, Security by-default, and ‘Attack big rocks’ of Windows at the BlueHat IL 2023 .

  • You cannot disable Driver Signature Verification without admin privileges.
  • You cannot disable Driver Signature Verification when Secure Boot is active.
  • You cannot use the new BCD Validation Profile when the “Allow Secure Boot for integrity validation” policy is enabled or not configured.
  • You cannot disable Secure Boot from the OS.
  • You can quickly switch to Safe Mode using msconfig.exe.
  • You should not disable Secure Boot on a fully encrypted machine using PCR 7. It will trigger a Recovery key screen.
  • You should not start encryption of the computer before policy adjustments. It will trigger a Recovery key screen.
  • Windows Driver code signing requirements
  • PCR banks on TPM 2.0 devices

Disabling Secure Boot should be approached with caution as it compromises the computer’s security defenses; while I don’t recommend it, there might be instances where flexibility is required.

That’s it.

⚛️