Section 6: Secure Boot

The Big Picture: A Guard at the Front Door

The firmware starts first, and it starts the bootloader, which starts Windows. If an attacker slips a fake bootloader in at the very start, it runs before Windows and before any antivirus, and it can hide forever. Secure Boot is a UEFI feature that puts a guard at the door: the firmware only runs programs that carry a trusted digital signature.

6.1 Why Secure Boot Exists

What it is: Secure Boot protects against bootkits and rootkits.

The problem: With legacy BIOS, the firmware simply ran the first sector of the disk, whatever it contained. A bootkit replaced it, so it ran first and could control Windows from below. Antivirus runs inside Windows, so it was too late to see it.

The idea: Check before running. Every boot program must prove who made it.

WITHOUT Secure Boot                    WITH Secure Boot
Firmware ─► runs anything              Firmware ─► checks signature ─► trusted? ─► run
                                                                     │ no
                                                                     ▼
                                                              refuse, show an error

It does not stop all attacks. It protects one important stage: the chain from firmware to the OS loader. Windows then continues the chain (loading only signed kernel pieces).

Windows tip: Check if Secure Boot is on:

• msinfo32 ► Secure Boot State: On, Off or Unsupported
• PowerShell as Administrator:

Confirm-SecureBootUEFI

It prints True (on) or False (off). On a PC that boots in legacy mode, it gives an error saying the cmdlet is not supported.

6.2 Public Key Infrastructure (PKI)

What it is: Secure Boot uses public-key cryptography. This uses a pair of keys:

Analogy: A wax seal. Only the king has the seal stamp (private key). Anyone can look at the seal pattern (public key) and see if it is the real king's. They cannot make a fake seal because they do not own the stamp.

Hash. A hash is a short fingerprint of a file, computed by a formula (for example SHA-256). If even one bit of the file changes, the hash changes totally.

A certificate is a small file that says "this public key belongs to this company", signed by an authority. A system of such authorities and certificates is called PKI (Public Key Infrastructure).

The keys stored in the firmware for Secure Boot:

PK  ── allows ──►  KEK  ── allow updates to ──►  db  (allowed)
                                              └►  dbx (blocked)

6.3 Signature Verification

What it is: When the firmware loads an .efi file, it checks it in a fixed way.

The steps:

1. Hash the .efi file with SHA-256.
2. Does the dbx (block list) contain this hash or the signing certificate? If yes, refuse.
3. Read the signature attached to the file (made with the maker's private key).
4. Is the signing certificate (or the file's hash) in the db (allow list)? If yes, run.
5. If it is in neither, refuse (or ask the user, depending on settings).

bootmgfw.efi
   │
   ├─ compute hash
   │
   ▼
In dbx? ──yes──► BLOCKED
   │ no
   ▼
Signature valid and signer in db? ──no──► BLOCKED  ("Security violation")
   │ yes
   ▼
RUN

The chain of trust. Each step verifies the next one:

UEFI firmware (trust root; holds the keys)
   ▼ verifies
Windows Boot Manager (bootmgfw.efi, signed by Microsoft)
   ▼ verifies
Windows kernel and early drivers (signed)
   ▼ loads
ELAM antimalware driver, then the rest of Windows

If the check fails: The PC shows a message such as "Secure Boot Violation" or "Invalid signature detected" and won't start that program. Usually this means a boot file was changed, a disk image is untrusted, or an unsigned Linux/USB tool was tried.

6.4 Microsoft's Key Role

What it is: Most PCs sold with Windows trust Microsoft's certificates by default. This is why Microsoft sits at the center.

The Linux situation. A Linux distribution cannot get its own key into every PC's firmware. So most distributions ship a small program called shim, signed by Microsoft's third-party CA. Shim then checks the distribution's own bootloader. That way Linux boots on Secure Boot PCs.

Updates to the lists. The dbx gets new entries over time (for example when a bootloader is found to have a flaw). Windows Update can deliver these. This is why a revoked old loader can stop working.

Certificates expire and get replaced. Microsoft's first set of Secure Boot certificates (from 2011) are due to expire starting in 2026. Microsoft has been rolling out new 2023 certificates through Windows Update and firmware updates. PCs keep booting, but a PC without the new certificates may not get future security updates to the boot chain. Check Microsoft's current guidance and your PC maker's firmware updates if you manage PCs.

Windows 11 and Secure Boot. Windows 11 requires a PC that is Secure Boot capable (the feature must exist; the firmware needs UEFI).

Look at the keys (PowerShell, Administrator):

Get-SecureBootUEFI -Name PK
Get-SecureBootUEFI -Name db

These commands return the raw data of the stored key lists.

6.5 Disabling Secure Boot

What it is: Secure Boot can usually be turned off in the firmware setup, because owners need freedom (for example to install an unsigned OS).

Why you might turn it off:

How (general steps; menus differ by maker):

1. Enter the firmware setup (Practical Lab, or Windows Settings ► Recovery ► Advanced startup).
2. Go to the Boot or Security tab.
3. Find Secure Boot. On some PCs you must first clear the keys or choose "Other OS" mode.
4. Set it to Disabled. Save and exit (usually F10).

Risks and consequences:

Good habit: Leave Secure Boot on unless you have a clear reason. If you turn it off to test something, turn it back on afterwards.

Other modes you may see:

Summary