Gå til indhold
atlas

Sikker opstart (secure boot)

Også kendt som: UEFI Secure Boot

Et tjek ved opstart, der kun lader en computer køre opstartssoftware og en kerne med en betroet digital signatur.

Kladde - dette opslag er endnu ikke gennemgået.

Formelt

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.

Forklaret enkelt

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.

I praksis

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.

Hvorfor det betyder noget

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.

Sådan kommer du i gang

De typiske trin i rækkefølge. Tilpas dem til jeres organisation.

  1. Tjek Secure Boot-status på alle pc'er og servere, fx med msinfo32 eller Confirm-SecureBootUEFI på Windows, mokutil --sb-state på Linux eller enhedsrapporten i jeres værktøj til enhedsstyring.
  2. Skift maskiner, der stadig starter i legacy BIOS- eller CSM-tilstand, til ren UEFI, konvertér først disken med mbr2gpt, hvor det er nødvendigt, og slå derefter Secure Boot til i firmwareindstillingerne.
  3. Sæt en administratoradgangskode på firmwaren, så ingen med fysisk adgang kan slå Secure Boot fra eller sætte maskinen i setup-tilstand.
  4. Gør Secure Boot og UEFI-firmware til et krav, når I køber nye pc'er, servere og appliances, og spørg leverandørerne, hvordan de opdaterer boot-nøgler og firmware.
  5. På Linux-systemer med egne kernemoduler eller drivere skal de signeres med en Machine Owner Key, der er tilmeldt via MOK, i stedet for at slå Secure Boot fra for at få dem til at indlæse.
  6. Hold firmware, spærrelisten (dbx) og boot-certifikaterne opdateret via Windows-opdateringer eller leverandørens firmware, herunder skiftet fra Microsofts 2011-certifikater til 2023-certifikaterne, og bekræft resultatet i jeres rapporter.
  7. Kombinér Secure Boot med TPM, measured boot og diskkryptering som BitLocker, og brug attestering af enhedens tilstand i betinget adgang, så en enhed, der fejler kontrollerne, mister adgangen.
  8. Undersøg alle Secure Boot-overtrædelser og enheder, der pludselig melder den slået fra, og behandl dem som en mulig bootkit, indtil I ved bedre.

Typiske faldgruber

  • At slå Secure Boot fra for at få en usigneret driver eller et Linux-modul til at virke og aldrig slå det til igen.
  • At gå ud fra, at Secure Boot er i orden, fordi det er slået til, mens spærrelisten dbx og boot-certifikaterne ikke er opdateret i årevis.
  • At lade firmwareindstillingerne være uden adgangskode, så alle ved tastaturet kan slå Secure Boot fra på et minut.

Gode vejledninger

Teknisk uddybning

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.

Secure 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.

Det 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.

Udlø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.

Hvad du bør lære først

Alt det, dette bygger på - grundlaget først.

  1. Kryptografisk nøgle
  2. →Hashing
  3. →Kerne (kernel)
  4. →Styresystem
  5. →Asymmetrisk kryptografi (public key)
  6. →Digital signatur
  7. →Sikker opstart (secure boot)

Relationer

Implementerer
Integritet
Afbøder
Malware
Bruges sammen med
Hærdning (hardening)

Kilder og videre læsning

Standarder og officielle tekster

Officiel dokumentation

Hvor dataene kommer fra

Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.

Se gennemgangskøenForeslå en rettelse på GitHubDette begreb som JSON

Test dig selv

Indlæser…

Atlas er i beta.