- Turn the tables on your organization with Adaxes 2018.1’s Web Interface and reporting capabilities - Thu, Sep 20 2018
- Review: Softerra Adaxes – Automating Active Directory management - Thu, Jun 4 2015
- Azure Multi-Factor Authentication – Part 8: Delegating Administration - Tue, Apr 28 2015
What Secure Boot does
Secure Boot introduces digitally signed kernel files for Windows PE, Windows RT, Windows 8, and Windows Server 2012. These files are typically used when booting the computer, before Windows 8 boots. When Windows 8 boots, all the typical security measures we’ve known to date (such as UAC, BitLocker, ASLR, Service Hardening, EMET, and Windows Defender) will be effective; however, before that, the computer is vulnerable to boot kits and root kits.
The implication of signed files is that you need a key to decrypt them, based on the principles of Public Key Infrastructure (PKI). These keys need to be stored in the firmware of your computer. Unfortunately, the BIOS technology (dating back to 1981) doesn’t offer the ability to store encryption keys natively or to use these types of keys during boot. This introduces a significant requirement on your computer: you will need to use (U)EFI, the successor to BIOS.
Note: Secure Boot isn’t a Microsoft invention. It’s a security standard based on the open UEFI standard.
What’s stored in UEFI
Manufacturers of UEFI include these three databases with Secure Boot keys:
- Signatures Database
- Revoked Signatures Database
- Key Enrollment Key (KEK) Database
The first two databases contain keys for signers and image hashes of UEFI applications, which identify trusted hardware, firmware, and operating system loader code and a list of keys to identify known malware. The third database works as an update mechanism for the first two databases.
The integrity of the databases is ensured by a Platform Key (PK) that is generated by the UEFI manufacturer when the firmware is finalized.
Implications of Secure Boot
Microsoft has worked intensively with hardware manufacturers to support Secure Boot implementations for UEFI-enabled desktops, notebooks, and tablets by adding a list of keys that identify trusted hardware, firmware, and operating system loader code and a list of keys to identify known malware. This way, Microsoft has ensured Windows 8 will work with Secure Boot on computers meeting the UEFI v2.3.1 Errata B standard.
One of the implications of using Secure Boot is that you can no longer dual boot older Windows versions, and you can no longer boot from Linux-based installation media or Linux-based Operating System installations. Microsoft, with its intense grip on the PC ecosystem, has ensured its keys made it to the UEFI implementations. Other operating system vendors (such as the organizations in the more fragmented Linux ecosystem) have had less of an impact on UEFI manufacturers.
The Secure Boot controversy
The implementation of the Secure Boot standard within UEFI has led to a big controversy, where several people in the Open Source community have accused Microsoft of wanting to eradicate the Open Source ecosystem. It’s true that Microsoft forces hardware vendors to enable UEFI with Secure Boot by default (among other requirements) to make their hardware wear the Certified for Windows 8 stickers.
However, Linux organizations can contact hardware vendors themselves to get their keys included with firmware updates. Microsoft offers a program where keys can be included for a $99 fee, like Red Hat has done.
Working around the Secure Boot limitations
Secure Boot isn’t a required feature for x86 and x64 versions of Windows. On hardware capable of running these operating systems, you can disable Secure Boot in the UEFI of the computer, which allows you to run any boot loader code. On ARM-based hardware capable of running Windows RT, you cannot disable Secure Boot, and thus you cannot dual boot this hardware with Windows RT and untrusted kernel code.
Inner workings of Secure Boot
When a computer is started, Secure Boot checks the integrity of the UEFI firmware by using the PK. If this check fails, you will need to restore the firmware to a trusted firmware. Next, UEFI will check the integrity of the Windows Boot Loader files by decrypting them and validating them against the key databases. If this check fails, a backup of the Windows Boot Manager will be used.
With these two checks passed, Windows can now boot. However, if there’s a problem with the drivers or kernel files, the Windows Recovery Environment (Windows RE) is loaded to recover trusted versions of these files. Now Windows can enable anti-malware through the Early Launch Anti-Malware feature (also new in Windows 8) before other files. Eventually, the use mode processes are started.
Secure Boot’s hardware and software requirements
We’ve glanced over the workings of Secure Boot and scratched the surface of Secure Boot requirements. Below, however, is the full list of hardware and software requirements you’ll need to meet to enjoy the added layer of security that Secure Boot offers:
- A computer with UEFI 2.3.1 Errata B. Inside UEFI, the Secure Boot option should be enabled, and a present Compatibility Support Module (CSM) should be disabled.
Note: Secure Boot has been available since the 2.2 specification of UEFI. However, Windows RT, Windows 8, and Windows Server 2012 support Secure Boot only on systems with UEFI v2.3.1 Errata B.
- A Windows 8, Windows 8 Pro, Windows 8 Enterprise, Windows RT, Windows Server 2012 Standard, and/or Windows Server 2012 Datacenter UEFI-based installation.
Tip: Wolfgang Sommergut has written an excellent article on how to perform a UEFI-based installation of Windows right here on 4sysops.
Checking if Secure Boot is enabled or disabled
Since it’s not easy to see if the system is capable of Secure Boot or if Secure Boot is enabled, Microsoft has included a handy little PowerShell cmdlet to check this—specifically, Confirm-SecureBootUEFI.
Confirm-SecureBootUEFI
When you run this command, you get one of three results:
| True | The computer supports Secure Boot, and Secure Boot is enabled. |
| False | The computer supports Secure Boot, but Secure Boot is disabled. |
| Cmdlet not supported on this platform | The computer does not support Secure Boot or is a non-UEFI computer. |
How to enable Secure Boot
When the Confirm-SecureBootUEFI cmdlet returns False, it’s easy to enable Secure Boot. Windows is already implemented as a UEFI installation, so the only required action is to enable Secure Boot in the UEFI firmware. You may need to update the UEFI firmware.
When the Confirm-SecureBootUEFI returns Cmdlet not supported on this platform, however, enabling Secure Boot is slightly more work. You may need to update the UEFI firmware and then enable the Secure Boot option. You’ll also need to reimplement Windows as a UEFI installation. Check the article by Wolfgang Sommergut to see how.
How to disable Secure Boot
Disabling Secure Boot can be done in two steps:
- Disable the Secure Boot option in the UEFI firmware.
- Reimplement Windows as a non-UEFI installation.
This will allow the system to dual boot with operating systems that are not Secure Boot capable, such as previous Windows versions and several Linux distributions.
Just had an interesting case. Confirm-SecureBootUEFI told me that Secure Boot is disabled whereas the PC setup claimed that Secure Boot is enabled. I described in the forum how I solved the problem.