Last Updated on March 6, 2024 by Michael Morten Sonne

Intoduction

Microsoft have in collaboration with partners and vendors, gearing up to introduce replacement certificates that will establish new trust anchors for Unified Extensible Firmware Interface (UEFI) Certificate Authorities (CAs) in Secure Boot for the future.

Keep an eye out for phased updates to the Secure Boot database, which will incorporate trust for the new Database (DB) and Key Exchange Key (KEK) certificates. This optional servicing update for the new DB is accessible to all Secure Boot-enabled devices starting from February 13, 2024.

What is Secure Boot

Secure Boot, a security feature within UEFI, plays a crucial role in ensuring that only trusted software executes during the system’s boot sequence.

This is achieved by validating the digital signature of the software against a predefined set of trusted digital keys stored in the UEFI. As an industry standard, Secure Boot within UEFI outlines the protocols for managing certificates, authenticating firmware, and establishing the interface between the operating system (OS) and this verification process. For additional information on UEFI and Secure Boot, please see this article.

Common attacks Secure Boot potential threats that Secure Boot aims to mitigate:

• Bootkits and Rootkits: These are types of malware that attempt to compromise the bootloader or kernel during the boot process. Secure Boot helps prevent the execution of unauthorized bootloaders, protecting against such attacks.
• Firmware Attacks: Malicious actors may try to tamper with or replace the UEFI firmware. Secure Boot ensures that only signed and trusted firmware is loaded, defending against firmware-level attacks.
• Code Injection: Secure Boot guards against unauthorized code injection into the boot process, preventing attackers from injecting malicious code into critical system components.
• Unauthorized Kernel Modules: Secure Boot checks the digital signatures of kernel modules, preventing the loading of unsigned or tampered modules that could compromise the system’s integrity.
• Exploitation of Boot-Time Vulnerabilities: Some attackers may target vulnerabilities in the boot process itself. Secure Boot, by verifying the integrity of each stage in the boot sequence, helps mitigate the risk of exploiting such vulnerabilities.

It’s important to note that while Secure Boot is effective in mitigating these threats, no security measure is entirely foolproof. Staying vigilant with security updates and adopting best practices in system administration are also crucial for maintaining a secure computing environment.

Secure Boot was initially introduced to Windows systems with the release of Windows 8 as a defense against the emerging threat of pre-boot malware, specifically bootkits. Since its beginning, Secure Boot has remained an integral component of Microsoft’s Trusted Boot security architecture. It plays a crucial role in authenticating various modules, including UEFI firmware drivers, bootloaders, applications, and option ROMs (Read-Only Memory). These modules are firmware run by the PC BIOS during platform initialization before their execution.

In the final step of the Secure Boot process, the firmware verifies the trustworthiness of the Windows boot loader. Following this authentication, control is passed to the boot loader, which, in turn, verifies, loads into memory, and then launches Windows. This multi-layered process, combined with the UEFI firmware signing process, ensures that only verified code is executed before Windows starts, effectively preventing attackers from exploiting the boot path as an attack vector 🤝

For a more in-depth understanding of how Secure Boot fits into the broader context of Windows chip-to-cloud security, please refer to the Windows Security Book 📗

Trust and authenticity within Secure Boot rely on the Public-Key Infrastructure (PKI) model. This framework establishes a certificate management system that employs Certificate Authorities (CAs) to store digital certificates. These CAs, which include the Original Equipment Manufacturer (OEM) or their representatives and Microsoft, generate key pairs that serve as the foundation of trust for the system.

Establishing the root of trust in Secure Boot

The root of trust in Secure Boot is structured hierarchically, with the OEM typically managing the Platform Key (PK). The PK is used to sign updates to the Key Exchange Key (KEK) database. Subsequently, the KEK signs updates to both the Allowed Signature Database (DB) and the Forbidden Signature Database (DBX).

The Secure Boot Allowed Signature DB and the DBX are needed to Secure Boot’s functionality. The signing authority of bootloader modules must be approved by the Secure Boot DB, while the DBX is employed to revoke trust in previously endorsed boot components. Updates to the DB and DBX require the signature of a KEK found in the Secure Boot KEK database.

The configuration of Secure Boot DB and KEK for Windows devices has remained consistent since Windows 8. Microsoft force every OEM to incorporate three certificates managed by Microsoft for Windows and to support the third-party hardware and OS ecosystem. These certificates include the Microsoft Corporation KEK CA 2011 stored in the KEK database, and two certificates stored in the DB – the Microsoft Windows Production PCA 2011, which signs the Windows bootloader (and a lot of other binaries in Windows itself – you can etc, look at C:\Windows\explorer.exe), and the Microsoft UEFI CA 2011 (or third-party UEFI CA), which signs third-party OS and hardware driver components.

All three Microsoft certificates are set to expire in 2026. Therefore, in collaboration with partners, Microsoft is gearing up to introduce the replacement certificates, establishing the new trust anchors for UEFI Certificate Authorities (CA) in the future. Microsoft will implement Secure Boot database updates in phases to instill trust in the new Database (DB) and Key Exchange Key (KEK) certificates.

The initial DB update will include the addition of the Microsoft Windows UEFI CA 2023 to the system DB. This new CA will be utilized to sign Windows boot components before the expiration of the Windows Production CA 2011. This DB update will be optional for the February 2024 servicing and preview updates (for my Windows 11 devices it is KB5034765) and can be manually applied to devices. Microsoft plans to gradually release this DB update as it validates devices and ensures firmware compatibility globally.

The full DB update will follow a controlled rollout process to reach all Windows customers during the April 2024 servicing and preview updates, anticipating the certificate expiration in 2026. Simultaneously, efforts to update the Microsoft UEFI CA 2011 (also known as the third-party UEFI CA) and Microsoft Corporation KEK CA 2011 will commence in late 2024, following a similar controlled rollout process as this DB update.

The important of this update

While Microsoft has consistently conducted DBX updates worldwide since the introduction of Secure Boot, this marks the first extensive DB update. Microsoft are actively engaged in collaboration with OEM partners to identify and rectify bugs in firmware implementation that may lead to unbootable systems or render a device unresponsive to the DB update. To ensure a successful rollout, devices with identified issues will be temporarily suspended from receiving the update until a fix is released.

Microsoft is adopting a deliberate and cautious approach in implementing this update. Through this DB update, Microsoft aims to maintain its capability to service the boot components of all Windows devices.

Where to look for your BitLocker recovery keys

In your Microsoft account: Sign in to your Microsoft account on another device to find your recovery key. This is the most likely place to find it.

Note: If the device was set up, or if BitLocker was turned on, by somebody else, the recovery key may be in that person’s Microsoft account!

On a printout you saved: Your recovery key may be on a printout that was saved when BitLocker was activated. Look where you keep important papers related to your computer or similary.

On a USB flash drive: Plug the USB flash drive into your locked PC and follow the instructions. If you saved the key as a text file on the flash drive, use a different computer to read the text file.

In a work or school account: If your device was ever signed into an organization using a work or school email account, your recovery key may be stored in that organization’s Entra ID account associated with your device or in Intune. You may be able to access it directly or you may need to contact their IT help desk to access your recovery key.

Manually apply DB update

The DB update will be accessible on February 13, 2024, accompanied by manual steps to enable customers to test firmware compatibility, particularly for organizations devices. If you wish to manually apply the DB update to verify compatibility with your system, kindly refer to the provided instructions. It is advisable to perform these actions using non-critical hardware that represents devices within your environment.

Prior to initiating the database update, ensure that you have conducted the required prerequisite checks listed here – I would not do this without doing this!

If you plan to manually apply this update to a substantial number of devices, it´s recommend starting with individual devices sharing the same firmware and specifications. This approach helps minimize the risks associated with firmware bugs in your devices.

If you are utilizing BitLocker like I do or if your enterprise has implemented BitLocker on your machine, make sure to back up the BitLocker keys!

Backup BitLocker Recovery keys

Microsoft Account (private)

For users utilizing a local account instead of an Entra ID or Microsoft account (MSA), you can either print your recovery password, save it to a file, and store it in a secure location – some users are offline with all if they can 😉

• Visit this portal to confirm the backup of your BitLocker keys before your next reboot on your self-owned device. In the rare event that the device becomes inoperable after receiving the update, the hard drive can still be unlocked.
• If the keys have been successfully backed up, the portal should appear like this:

• In case the keys are not backed up, kindly use Windows Search to find Manage BitLocker, and then choose Back up your recovery key followed by saving it to your MSA account.

• Now you will have an option like the one for a work account in the next step – but sorry I not have a screenshot of that one here 😒
• Your Bitlocker Recovery key is now saved and you are good to go for the update.

Microsoft Work account

For users utilizing a work account (Entra ID) instead of a private Microsoft account (MSA), you can either save the recovery key to your Entra ID account (Windows still shows Azure AD – the renameing is not done here jet – but I think it will do in in the upcomming Windows updates/versions), print your recovery password, save it to a file and store it in a secure location – some users are offline with all if they can 😉

• Visit this *portal to confirm the backup of your BitLocker keys before your next reboot on your device. In the rare event that the device becomes inoperable after receiving the update, the hard drive can still be unlocked.
  *It will open this portal: https://account.activedirectory.windowsazure.com/r/#/profile
• An administrator can also check if the Bitlocker recovery code is saved in the portal or in the Intune portal under your device – talk with your IT department about this if unsure!
• If the keys have been successfully backed up, the user interface (UI) should appear as follows:

• If you click on one of the Get Bitlocker-keys, you should get a pop-up like this:

In case the keys are not backed up, kindly use Windows Search to find Manage BitLocker, and then choose Back up your recovery key followed by saving it to your Azure AD account.

• Your Bitlocker Recovery key is now saved and you are good to go for the update.

DB update

How to update

These are the steps to install updates: a Windows update, a registry modification and the execution of aWndows task (special one). Following these actions, the certificates will be updated. My PowerShell script can handle everything except the installation of the Windows update.

Script guide

The script

See the script on The PowerShell Script tab – it´s hosted on my public repo on my GitHub account here: https://github.com/michaelmsonne/public

• Apply the February 2024 (or later) security update.
• Download my PowerShell script here: UpdateSecureBootCAs.ps1 at main · michaelmsonne/public (github.com)
• To use the script in PowerShell, you need Administrator rights. If you run it without Administrator privileges, it will prompt you for permission and restart accordingly.

.\UpdateSecureBootCAs.ps1

The flow to update it:

• Select menu 1 – it will set the registery key as needed
• Select menu 2 – now the task we need to run/trigger will start (Microsoft > Windows > PI > Secure-Boot-Update) – wait for it to cpmplete
• Select menu 3 or reboot your computer yourself
• Select menu 4 after a reboot or two, and your input should look like this:

• Your update it now complete! 🥳

If it is not updated, the script’s output will display as follows when “Windows UEFI CA 2023” is not included in the data blob:

Troubleshooting

For troubleshooting in the case of errors while applying the DB update, please see KB5016061: Secure Boot DB and DBX variable update events – Microsoft Support

Conclusion

Updating Secure Boot CA (Certificate Authority) certificates is crucial for several reasons, making it a recommended practice.

Firstly, it enhances security by ensuring that the system’s trusted certificates are current, thereby safeguarding against potential vulnerabilities and unauthorized access.

Secondly, regular updates help in addressing any identified security flaws or weaknesses in the existing certificates. This proactive approach contributes to the overall resilience of the system, reducing the risk of security breaches.

Lastly, keeping the Secure Boot CA certificates up-to-date aligns with best security practices, promoting a robust and reliable computing environment. Therefore, performing these updates is not only necessary for maintaining a secure system but also aligns with good cybersecurity hygiene.

Thank you for taking the time to visit my blog. Kindly share it with others if you find it helpful for them! 😉🔐👍

Stay tuned for the new post about something cool! 🥳

References

Windows Secure Boot Key Creation and Management Guidance | Microsoft Learn

KB5036210: Deploying Windows UEFI CA 2023 certificate to Secure Boot Allowed Signature Database (DB) – Microsoft Support

Specifications | Unified Extensible Firmware Interface Forum (uefi.org)