{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"cs/secure-boot","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/secure-boot/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/secure-boot/"},"term":{"en":"Secure boot","da":"Sikker opstart (secure boot)"},"aka":{"en":["UEFI Secure Boot"],"da":["UEFI Secure Boot"]},"domain":["cs","security"],"cluster":"os","layer":"os","status":"current","era":2012,"summary":{"en":"A start-up check that lets a computer run only boot software and a kernel carrying a trusted digital signature.","da":"Et tjek ved opstart, der kun lader en computer køre opstartssoftware og en kerne med en betroet digital signatur."},"body":{"formal":{"en":"A chain of checks at start-up. The machine's built-in start-up software checks the digital signature of each start-up program and add-on driver against keys stored in the machine, and the signed start-up program then checks the kernel; any failed check stops the start.","da":"En kæde af tjek ved opstart. Maskinens indbyggede opstartssoftware tjekker den digitale signatur på hvert opstartsprogram og hver tilføjet driver mod nøgler gemt i maskinen, og det signerede opstartsprogram tjekker derefter kernen; et fejlet tjek stopper opstarten."},"plain":{"en":"Like a guard at the factory gate who checks every driver's badge before the working day starts, so nobody can slip in while the lights are still off.","da":"Som en vagt ved fabriksporten, der tjekker hver chaufførs adgangskort, før arbejdsdagen går i gang, så ingen kan snige sig ind, mens lyset endnu er slukket."},"inPractice":{"en":"A municipality gets laptops back from an outside repair shop. One refuses to start and shows a secure boot warning because its start-up program has been swapped, so IT takes it out of use and investigates.","da":"En kommune får bærbare retur fra et eksternt reparationsværksted. Én af dem nægter at starte og viser en secure boot-advarsel, fordi opstartsprogrammet er blevet udskiftet, så IT tager den ud af drift og undersøger den."},"whyItMatters":{"en":"Malware that loads before the operating system can hide from every protection that starts later, so the only safe place to stop it is at the very first step.","da":"Malware, der indlæses før styresystemet, kan gemme sig for al beskyttelse, der starter senere, så det eneste sikre sted at stoppe den er ved allerførste trin."}},"deepDive":{"en":"UEFI Secure Boot was introduced in UEFI 2.3.1 (Errata C, 2011) and became mainstream with Windows 8 certification in 2012. Its policy lives in authenticated UEFI variables: the Platform Key (PK), normally owned by the OEM, authorises updates to the Key Exchange Key database (KEK); KEK entries authorise updates to the signature database db (allowed certificates and hashes) and the forbidden database dbx (revoked certificates and hashes). Before executing any UEFI image, including boot loaders, drivers and option ROMs on add-in cards, the firmware verifies its Authenticode signature against db and checks that neither the image hash nor the signer appears in dbx. The chain then continues in software: Windows Boot Manager verifies winload and the kernel, while Linux distributions use a small shim signed by Microsoft's third-party UEFI CA, which embeds the distribution's own key and verifies GRUB and the kernel, with MOK (Machine Owner Key) letting administrators enrol their own keys.\n\nSecure Boot only enforces \"signed by a trusted key\"; it does not record what ran. Measured boot is the complement: each stage hashes the next into TPM Platform Configuration Registers (PCRs 0-7 for firmware and boot configuration), producing a log that can be attested remotely or used to seal disk-encryption keys, as BitLocker and systemd-cryptenroll do. Neither mechanism protects against compromise of the firmware itself, which is the domain of NIST SP 800-193 platform firmware resiliency and hardware roots of trust such as Intel Boot Guard.\n\nThe weak point is revocation. A signed but vulnerable boot component can be replayed forever unless its hash or certificate is added to dbx, and dbx has limited storage. BootHole (CVE-2020-10713) in GRUB2 and the BlackLotus bootkit, which exploited CVE-2022-21894 in Windows Boot Manager and was the first publicly known malware bypassing Secure Boot on fully patched Windows 11 (2023), required mass dbx updates and, for BlackLotus, a staged Microsoft mitigation under CVE-2023-24932. PKfail (2024) showed that hundreds of device models shipped with a test Platform Key whose private key had leaked, making Secure Boot on them bypassable.\n\nKey expiry is the current operational issue. Microsoft's original 2011 certificates run out during 2026: the Microsoft Corporation KEK CA 2011 and the Microsoft UEFI CA 2011 expired in June 2026, and the Windows Production PCA 2011 that signs the Windows boot manager expires on 19 October 2026. Devices must receive the 2023 replacement certificates in KEK and db (through Windows updates or OEM firmware) to keep receiving boot-component and dbx updates. Secure Boot can also be disabled or put into setup mode in firmware settings by anyone with physical access unless a firmware password is set, and it does nothing against attacks that start after the kernel has loaded. It should not be confused with Trusted Boot or with signed kernel modules, which extend verification later into the OS.","da":"UEFI Secure Boot blev indført i UEFI 2.3.1 (Errata C, 2011) og blev udbredt med certificeringskravene til Windows 8 i 2012. Politikken ligger i autentificerede UEFI-variabler: Platform Key (PK), normalt ejet af producenten, godkender opdateringer af Key Exchange Key-databasen (KEK); KEK-poster godkender opdateringer af signaturdatabasen db (tilladte certifikater og hashes) og forbudsdatabasen dbx (tilbagekaldte certifikater og hashes). Før firmwaren udfører et UEFI-image, herunder bootloadere, drivere og option ROM'er på udvidelseskort, verificerer den Authenticode-signaturen mod db og tjekker, at hverken imagets hash eller underskriveren står i dbx. Kæden fortsætter derefter i software: Windows Boot Manager verificerer winload og kernen, mens Linux-distributioner bruger en lille shim signeret af Microsofts tredjeparts-UEFI-CA, som indeholder distributionens egen nøgle og verificerer GRUB og kernen, og MOK (Machine Owner Key) lader administratorer indrullere egne nøgler.\n\nSecure Boot håndhæver kun \"signeret med en betroet nøgle\"; den registrerer ikke, hvad der blev kørt. Measured boot er komplementet: hvert trin hasher det næste ind i TPM'ens Platform Configuration Registers (PCR 0-7 for firmware og opstartskonfiguration), så der dannes en log, der kan attesteres over netværket eller bruges til at forsegle diskkrypteringsnøgler, som BitLocker og systemd-cryptenroll gør. Ingen af mekanismerne beskytter mod kompromittering af selve firmwaren; det hører under NIST SP 800-193 om robust platformsfirmware og hardwarebaserede tillidsankre som Intel Boot Guard.\n\nDet svage punkt er tilbagekaldelse. En signeret, men sårbar opstartskomponent kan genbruges for evigt, medmindre dens hash eller certifikat lægges i dbx, og dbx har begrænset plads. BootHole (CVE-2020-10713) i GRUB2 og BlackLotus-bootkittet, der udnyttede CVE-2022-21894 i Windows Boot Manager og i 2023 var den første offentligt kendte malware, der omgik Secure Boot på fuldt opdaterede Windows 11-maskiner, krævede massive dbx-opdateringer og for BlackLotus' vedkommende en trinvis afbødning fra Microsoft under CVE-2023-24932. PKfail (2024) viste, at hundredvis af enhedsmodeller var leveret med en test-Platform Key, hvis private nøgle var lækket, så Secure Boot på dem kunne omgås.\n\nUdløb af nøgler er det aktuelle driftsproblem. Microsofts oprindelige certifikater fra 2011 løber ud i løbet af 2026: Microsoft Corporation KEK CA 2011 og Microsoft UEFI CA 2011 udløb i juni 2026, og Windows Production PCA 2011, der signerer Windows' boot manager, udløber den 19. oktober 2026. Enhederne skal have 2023-afløserne lagt i KEK og db (via Windows-opdateringer eller firmware fra producenten) for fortsat at kunne modtage opdateringer af opstartskomponenter og dbx. Secure Boot kan desuden slås fra eller sættes i setup mode i firmwareindstillingerne af enhver med fysisk adgang, medmindre der er sat en firmwareadgangskode, og den gør intet mod angreb, der begynder, efter at kernen er indlæst. Den må ikke forveksles med Trusted Boot eller signerede kernemoduler, som fører verifikationen videre ind i styresystemet."},"edges":[{"type":"requires","to":"cs/digital-signature","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/kernel","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/operating-system","confidence":"high","strength":"normal"},{"type":"implements","to":"security/integrity","confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/malware","why":{"en":"Hidden malware that plants itself in the start-up code is refused, because its changes break the signature check.","da":"Skjult malware, der planter sig i opstartskoden, afvises, fordi dens ændringer får signaturtjekket til at fejle."},"confidence":"high","strength":"primary"}],"depth":3,"sources":[{"title":"UEFI Specification - Secure Boot and Driver Signing","url":"https://uefi.org/specifications","tier":"standard","publisher":"UEFI Forum"},{"title":"Secure boot (Windows hardware documentation)","url":"https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot","tier":"official-doc","publisher":"Microsoft"},{"title":"NIST SP 800-193 - Platform Firmware Resiliency Guidelines","url":"https://csrc.nist.gov/pubs/sp/800/193/final","tier":"standard","publisher":"NIST"},{"title":"Windows Secure Boot certificate expiration and CA updates","url":"https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e","tier":"official-doc","publisher":"Microsoft"}],"draft":true}