Konfigurer sikker oppstart med dine egne PK-, KEK- og db-nøkler

Konfigurer sikker oppstart med dine egne nøkler (PK, KEK og db) Det er en av de oppgavene som høres ut som noe fra et sikkerhetslaboratorium, men det påvirker i økende grad avanserte brukere, systemadministratorer og til og med OEM-er som monterer og selger datamaskiner. Sikker oppstart er ikke lenger en sjeldenhet: det er aktivert som standard på de fleste moderne hovedkort og er et krav for systemer som Windows 11, signerte Linux-distribusjoner og mange industrielle løsninger.

Hvis du vil kontrollere tastene til boot forsikring (i stedet for å nøye deg med de produsenten tilbyr), for å starte opp Linux, macOS med OpenCore eller din egen firmware uten å miste kompatibilitet med Windows, må du forstå hvordan PK, KEK og andre komponenter fungerer. databaser db/dbx og hvilken rolle verktøy som HSM spiller, TPM eller MOK. La oss se på det rolig, gå inn på tekniske detaljer, men med direkte og praktisk språk.

Hva er UEFI Secure Boot, og hvorfor bør du bry deg?

UEFI sikker oppstart er en utvidelse av UEFI-standarden som definerer en kryptografisk verifiseringsmekanisme for alle binærfiler som deltar i oppstartskjeden: fastvare, opsjons-ROM, drivere UEFI på disk, UEFI-applikasjoner og operativsystemlastere. Ideen er enkel: før noe kjøres, sjekker fastvaren at det er signert med en klarert nøkkel.

For å oppnå dette er Secure Boot avhengig av en offentlig nøkkelinfrastruktur (PKI)Det finnes private nøkler som signerer binærfiler, og offentlige nøkler/sertifikater lagret i fastvaren som bekrefter disse signaturene. Hvis noe ikke samsvarer, kjøres det ikke. Dette reduserer risikoen for rootkits og malware førstart, som tradisjonelt ble installert rett før operativsystemet for å omgå antivirusprogramvare.

I det moderne Windows-økosystemet, spesielt siden Windows 8 og forsterket i Windows 10 og Windows 11, bruker Microsoft denne Secure Boot-arkitekturen som grunnlag for sin pålitelig startkjedeFastvare → Boot Manager → WinLoad → Kjerne → Kritiske drivere → Antimalware. Hver lenke verifiserer den neste ved hjelp av signaturer.

I en typisk oppstartsprosess med sikker oppstart aktivert, er flyten: UEFI-fastvare validerer operativsystemlasteren (For eksempel ham Windows Boot Manager signert av Microsoft); deretter validerer Windows-oppstartskomponentene kritiske oppstartsdrivere og programvare mot skadelig programvare som er merket som sådan; derfra fortsetter normal initialisering av operativsystemet frem til påloggingsskjermen.

For sluttbrukeren Dette betyr at datamaskinen ikke vil starte opp fra en USB-stasjon eller partisjon som ikke er riktig signert, og for OEM-er/administratorer betyr det at de må administrere sertifikater, tilbakekallinger (dbx) og kompatibilitet med ulike operativsystemer uten å miste sikkerhet.

PKI, offentlig nøkkelkryptografi og sertifikattyper brukt i sikker oppstart

Grunnlaget for alt dette er en PKI (Public Key Infrastructure)Det vil si et sett med prosesser, enheter og verktøy som muliggjør utstedelse av sertifikater, verifisering av identiteter og tilbakekalling av kompromitterte nøkler. I forbindelse med sikker oppstart tjener PKI til å:

• Sjekk under oppstart Sjekk om et UEFI-bilde (driver, program, oppstartslaster) er pålitelig før du kjører det.
• Autentiser endringer i sikre variabler (PK, KEK, db, dbx) og fastvareoppdateringer, slik at bare autoriserte aktører kan endre dem.

En typisk PKI for sikker oppstart involverer flere komponenter: a sertifiseringsinstans (CA) som utsteder og signerer sertifikater, en registreringsenhet som verifiserer identiteten til personen som ber om sertifikatet, en katalog der nøkler og sertifikater lagres, og administrasjonssystemer som styrer livssyklusen deres.

Kryptografien som brukes i Secure Boot er vanligvis basert på RSA-2048 med SHA-256Asymmetriske nøkkelpar genereres: en privat nøkkel for signering og en offentlig nøkkel som settes inn i X.509-sertifikater eller spesifikke UEFI-strukturer. Du kan ikke praktisk beregne den andre nøkkelen med den ene, så så lenge den private nøkkelen er beskyttet, er ordningen sikker.

Flere metoder brukes for sikker oppstart nøkkelkonsepter:

• Selvsignert sertifikatEt sertifikat der signeringen utføres med sin egen private nøkkel. Dette er standard praksis for rot-CA-er (den klarerte roten).
• Sertifikater utstedt av CACA-en signerer sertifikater fra enheter (OEM, Microsoft osv.) og kobler identiteten deres til en offentlig nøkkel. Det er her sertifikatkjederder du kan ha en rot, ett eller flere mellomliggende filer og det endelige signeringssertifikatet.
• X.509-sertifikaterEt standardformat som inkluderer DN, offentlig nøkkel, signaturalgoritme, serienummer, utsteder, emne og CA-signatur. I sikker oppstart brukes disse med typer som EFI_CERT_X509_GUID.

UEFI Secure Boot anbefaler offentlige nøkler på minst 2048 biter og X.509-sertifikater signert med sha256RSAMicrosoft-sertifikater (f.eks. UEFI CA 2011 og 2023, KEK-er og UEFI-driversertifikater) følger dette mønsteret og distribueres slik at OEM-er kan sette dem inn i signaturdatabaser.

Sikker oppstartsnøkler og databaser: PK, KEK, db og dbx

UEFI definerer en rekke sikre variabler i NVRAM som utgjør systemets tillitsrot: Platform Key (PK), Key Exchange Key (KEK) og autoriserte (db) og tilbakekalte (dbx) signaturdatabaser. I praksis bestemmer disse variablene hva som kan kjøres, hvem som kan oppdatere hva, og hvordan systemet bytter fra konfigurasjonsmodus til brukermodus.

La plattformnøkkel (PK) Det er det høyeste punktet i hierarkiet. Den offentlige delen (PKpub) skrives til fastvarens PK-variabel; den private delen (PKpriv) holdes utenfor nettstedet, ideelt sett i en HSM eller i det minste i et strengt kontrollert miljø. PK-en etablerer tillitsforholdet mellom plattformeieren og fastvaren: hvis du kontrollerer PK-en, kontrollerer du hvem som kan endre KEK, databasen og dbx.

Las Nøkkelutvekslingsnøkler (KEK) De etablerer tillitsforholdet mellom operativsystemet (og andre aktører) og fastvaren. Hvert system eller hver leverandør kan registrere en offentlig KEK (KEKpub) i KEK-variabelen. Database- og dbx-oppdateringer signeres med denne KEK-en. Microsoft distribuerer for eksempel sin Microsoft Corporation CA KEK 2K 2023, som OEM-er må inkludere for å tillate tilbakekallingsoppdateringer (dbx) og, om nødvendig, endringer i databasen.

Databasen over autoriserte signaturer db (EFI_IMAGE_SECURITY_DATABASE) Den inneholder sertifikater, offentlige nøkler og bilde-hasher som fastvaren kan laste inn. Disse inkluderer blant annet Windows UEFI CA 2023 (viktig for oppstart av Windows) og, eventuelt, Microsoft UEFI 2011, 2023 og alternative ROM-CA-er, samt OEM- eller tredjeparts CA-er du trenger (for eksempel for dine egne UEFI-drivere eller Linux-lastere signert av Microsoft UEFI CA 2023).

Databasen over forbudte signaturer dbx (EFI_IMAGE_SIGNATURE_DATABASE1) Den vedlikeholder en svarteliste over tilbakekalte eller sårbare binære hasher, nøkler og sertifikater. Før databasen sjekkes, sjekker fastvaren databasen (dbx), og hvis den finner et samsvar, forhindrer den kjøringen av det bildet. Windows krever at det finnes en database (dbx), selv om den i utgangspunktet kan inneholde en "dummy"-verdi (for eksempel SHA-256-hashen på 0) inntil offisielle Microsoft-oppdateringer slippes.

I tillegg til disse hovedvariablene definerer UEFI DbDefault, DbxDefault og KEKDefaultder plattformleverandøren kan lagre standardnøkkelsett som brukes til å gjenopprette fabrikkinnstillingene for sikker oppstart fra selve fastvaregrensesnittet.

PK (plattformnøkkel): genererings-, registrerings- og bruksstrategier

I henhold til UEFI-spesifikasjonen (avsnitt 27.5.1 i versjon 2.3.1 Errata C), den Plattformnøkkel Det er det som formelt sett fastslår hvem som eier maskinen når det gjelder sikker oppstart. Når du registrerer en PKpub i PK-variabelen, avsluttes systemet. Oppsettmodus (konfigurasjonsmodus) og skriv inn brukermodusFra det øyeblikket krever alle endringer av sikre variabler gyldige signaturer.

PK-en bør ideelt sett være et X.509-sertifikat av typen EFI_CERT_X509_GUID med RSA-2048 offentlig nøkkelalgoritme og sha256RSA-signatur. Formatet kan også brukes EFI_CERT_RSA2048_GUID Hvis du har lite NVRAM-plass, men mister den ekstra fleksibiliteten til X.509. Det viktigste er at den private nøkkelen til PK-en være ekstremt godt beskyttet, helst i en HSM, og aldri brukes rutinemessig til fastvaresignering eller vedlikeholdsoperasjoner.

Som generasjonsstrategiDet finnes flere alternativer, og hvert av dem har sikkerhetsmessige og driftsmessige implikasjoner:

1. Én PK per lagMaksimal granularitet og sikkerhet (utviklet for myndigheter, banker og miljøer med høy sikkerhet). Hvis én nøkkel blir kompromittert, påvirker det bare én maskin, men du trenger massiv genereringskapasitet. lagring og nøkkelsporbarhet.
2. Én pakke per modellgod balanse for samtaler etter middag og bærbar av forbruk; hvis nøkkelen blir kompromittert, påvirker det alle enheter i den modellen.
3. Én pakke per produktlinje: forenkler styringen, men forsterker virkningen av et potensielt gap.
4. Én PK per OEM: den enkleste å betjene, men en forpliktelse i PK betyr å kompromittere hele utstyrsflåten, noe som er delikat med tanke på omdømme og støtte.

Microsoft tilbyr en PK administrert av dem selv For OEM-er som ikke ønsker å ta på seg byrden av å beskytte en produksjons-PK. Denne PK-en lagres i en Microsoft HSM i henhold til beste praksis for PKI og regnes som det anbefalte alternativet for mesteparten av Windows-økosystemet, forutsatt at det ikke finnes spesielle krav til suverenitet eller nøkkelsegregering.

La registrering og oppdatering PK gjøres via UEFI-tjenesten SetVariable()ved hjelp av variabelen EFI_GLOBAL_VARIABLE Den tilhørende prosedyren gjelder. Hvis systemet er i SetupMode, kan du registrere en ny PKpub uten forutgående signatur (selv om en autentisert struktur bygges internt); hvis den er i brukermodus, må den nye PKpuben signeres med gjeldende PKpriv. For å slette PK-en, skriv PK-variabelen med en størrelse på 0; i SetupMode kreves ingen signatur, mens den i brukermodus må signeres med gjeldende PKpriv.

Fra et operasjonelt synspunkt er det svært farlig å bruke produksjons-PK for å signere pakker som sletter PK-en eller gjenopprette systemet til SetupMode, fordi det ville tillate skadelig programvare med systemtilgang å deaktivere sikker oppstart via programvare. Denne typen operasjoner er vanligvis begrenset til testmiljøer eller strengt kontrollerte prosedyrer.

Hvis en PK er kompromittert eller en kunde ønsker tilordne eierskapet til plattformen på nytt (For eksempel en administrasjon som ønsker å bruke sine egne nøkler), kan du generere PK-er for en enhet, en modell eller en hel produktlinje, avhengig av den valgte strategien. Oppdateringen utføres ved hjelp av autentiserte variabler eller fastvareoppdateringspakker signert med den sikre fastvareoppdateringsnøkkelen, samtidig som du er forsiktig så du ikke mister tidligere registrerte KEK-, db- og dbx-filer.

KEK, db og dbx: hvordan de administreres og kombineres med Microsoft- og tredjepartsnøkler

variabel CEC Den inneholder en liste over nøkler (vanligvis X.509-sertifikater) som er autorisert til å oppdatere databaser og dbx-filer. Når plattformen er i brukermodus, må eventuelle endringer i disse databasene pakkes inn i en autentiseringsstruktur signert av en av de nåværende nøkkelsignaturene (KEK-er). Dette lar for eksempel Microsoft publisere tilbakekallingsoppdateringer (dbx-filer) gjennom... Windows Update uten at OEM-en trenger å gripe inn i hvert tilfelle.

For å registrere nye KEK-er kan du bruke SetVariable() med attributtet EFI_VARIABLE_APPEND_WRITEeller les gjeldende database med GetVariable()Legg til den nye oppføringen og skriv den på nytt uten det attributtet. I SetupMode kreves ikke en signatur; i brukermodus må strukturen signeres med PKpriv faktiske.

Det er også mulig å slette KEK-er, men forsiktighet anbefales: Hvis ingen PK er installert, krever ikke slettingsforespørsler en signatur. Hvis en PK er tilstede, krever sletting av KEK-er en pakke signert av den PK-en, og endring av db/dbx krever en pakke signert av en av de gjenværende KEK-ene. For Windows-kompatibilitet kreves det at minst følgende KEK inkluderes: Microsoft Corporation CA KEK 2K 2023, som Microsoft publiserer for OEM-er.

La db Dette er databasen over tillatte signaturer. Den inneholder CA-ene som signerer operativsystemlastere (som Windows UEFI CA 2023), UEFI-driversertifikater (Microsoft UEFI CA 2011/2023, Option ROM UEFI CA 2023), og eventuelt OEM- og tredjepartssertifikater. På systemer som bare må starte Windows, kan en mer restriktiv database leveres. På systemer som må støtte Linux, tredjeparts opsjons-ROM-er eller flere UEFI-applikasjoner, anbefales det å inkludere alle relevante Microsoft CA-er og, hvis aktuelt, en UEFI CA fra OEM-en.

La dbx Denne listen inneholder hasher av binærfiler, sertifikater og nøkler som ikke lenger er klarerte (på grunn av sårbarheter, nøkkeltyveri osv.). Fastvaren prioriterer alltid dbx: hvis et bilde samsvarer med noe i dbx, blokkeres det selv om det også vises som tillatt i dbx. Microsoft distribuerer med jevne mellomrom dbx-pakker med nye tilbakekallinger, og kravene til maskinvaresertifisering i Windows krever at en dbx-fil skal være tilstede fra fabrikken (selv om det er en plassholderverdi frem til den første oppdateringen).

I kravene til enheter med Windows 11 25H2 Forhåndslastet er merket som obligatorisk for OEM-er å klargjøre:

• PKOEM-pakke eller Microsoft-administrert pakke.
• CECMicrosoft Corporation CA KEK 2K 2023.
• dbminst Windows 2023 UEFI CA; for enheter som også støtter Linux eller andre, er Microsoft UEFI CA 2023, Microsoft Corporation UEFI CA 2011 og Microsoft Option ROM UEFI CA 2023 lagt til.
• dbx: den nyeste dbx-pakken levert av Microsoft.

Sikre fastvareoppdateringsnøkler og UEFI-oppdateringsflyt

I tillegg til PK, KEK, db og dbx har plattformer som følger moderne sikkerhetsanbefalinger en sikker fastvareoppdateringsnøkkel En separat, dedikert kopi som kun brukes til å signere fastvareoppdateringskapsler. Den offentlige delen (eller en hash) er lagret i et beskyttet område: beskyttet flashminne i tradisjonelle PC-er eller OTP-sikringer i SoC-er.

Tanken er at alle firmwareoppdateringer Eventuelle endringer i innholdet i UEFI-flashminnet må signeres med denne nøkkelen eller en som er koblet til den. Fastvaren, når kapselen mottas via UpdateCapsule()Den verifiserer signaturen ved hjelp av den interne offentlige nøkkelen. Hvis verifiseringen mislykkes, forkastes oppdateringen. Dette er i tråd med NIST 800-147-retningslinjene for sikre fastvareoppdateringer.

I praksis brukes vanligvis én oppdater nøkkel etter modell eller produktlinjeSelv om det teoretisk sett er sikrere å ha en separat nøkkel for hver enhet, kompliserer det logistikken betraktelig: du må generere og administrere millioner av unike oppdateringspakker. Det er avgjørende å skille oppdateringsnøkkelen fra primærnøkkelen: hvis du bruker den samme nøkkelen og den blir kompromittert, mister du ikke bare kontrollen over de sikre variablene, men også den pålitelige muligheten til å oppdatere primærnøkkelen på produksjonsenheter.

I Windows distribueres UEFI-fastvareoppdateringer vanligvis som fastvaredrivere som systemet legger til i lageret sitt og bruker ved hjelp av UpdateCapsule() under oppstart. Fastvaren må eksponere ACPI ESRT-tabell slik at Windows vet hvilke enheter som kan oppdateres og hvordan. Kapslene kan ligge i minnet (vanlig scenarie) eller på disk.

Den typiske prosessen for en fastvareoppdatering med moderne UEFI-støtte ville være: last ned og installer fastvarepakken på Windows, start på nytt, oppstartslasteren oppdager kapselen og gir den videre til UpdateCapsule()Fastvaren bekrefter signaturen og installerer oppdateringen, starter på nytt, og operativsystemet fullfører oppstarten med den nye versjonen.

Løsninger for generering og lagring av nøkler: HSM, TPM, smartkort og alternativer

For å administrere Secure Boot-nøkler (PK, OEM KEK, firmware-nøkler osv.) profesjonelt, er det ikke nok å bare lagre dem på en USB-stasjon i en skuff. Det anbefales å bruke en... HSM (maskinvaresikkerhetsmodul)en enhet designet for å generere, lagre og bruke nøkler sikkert, ofte med sertifiseringer FIPS 140-2 nivå 3.

HSM-er kan være nettverkstilkoblet eller lokalt tilkoblet (PCIe, USB, PCMCIA). nettverk HSM Det er det mest komplette alternativet: flere servere kan få tilgang til det, høy tilgjengelighet kan konfigureres, det tillater krypterte sikkerhetskopier av nøkler, og det integrerer vanligvis sterk fleroperatørautentisering (f.eks. "k av m"-ordninger, 3 av 5 tokener må være til stede for å få tilgang til visse operasjoner).

den Uavhengige HSM-er PCIe-kort og USB-dongler fungerer bra i mindre eller isolerte miljøer, og integreres ofte med API-er som Microsofts CAPI eller CNG. De kan tilby begrenset sikkerhetskopiering og høy tilgjengelighet, men er fortsatt langt bedre enn rent programvarebaserte løsninger.

Som alternativer på lavere nivå har du TPM (Trusted Platform Module)TPM-er kan generere og lagre nøkler og er svært nyttige for fulldiskkryptering (BitLocker), målt oppstartsintegritet osv. For et masseproduksjonsmiljø mangler imidlertid TPM-er vanligvis den kryptografiske behandlingshastigheten og nøkkellagringskapasiteten som tilbys av HSM-er, og er ikke designet for å holde tusenvis av OEM-nøkler.

Du kan også bruke smartkort eller utvidede valideringssertifikater (EV) lagret på maskinvaretokener: de gir fysisk beskyttelse og autentisering, men deres begrensede lagringskapasitet og ytelse, sammen med behovet for manuell inngripen, gjør dem uegnet for storskala produksjon eller automatiseringsanlegg.

Til slutt finnes det programvaresentriske tilnærminger (som å bruke kryptografiske API-er for operativsystemer og nøkkelbeholdere på krypterte disker eller isolerte virtuelle maskiner), og til og med verktøy som makecert i eldre Windows-miljøer. Selv om de er brukbare for testing eller laboratorier, anbefales de ikke fra et sikkerhetsmessig synspunkt for administrasjon av PK-er og fastvarenøkler i produksjon fordi de utvider angrepsflaten betraktelig.

Sikker oppstartstilstander, SetupMode og et praktisk eksempel på problemer med dine egne nøkler

En viktig detalj når du begynner å Konfigurer sikker oppstart med dine egne nøkler Det er å forstå forskjellen mellom Oppsettmodus y brukermodusMens systemet er i SetupMode (vanligvis «Secure Boot: Disabled, SetupMode: 1»), kan alle sikre variabler endres uten en signatur. I det øyeblikket du registrerer en primærnøkkel (PK), settes SetupMode til 0, SecureBoot til 1, og fastvaren går inn i brukermodus: fra da av er bare autentiserte endringer tillatt.

Dette kan sees med verktøy som f.eks. bootctl eller ved å konsultere variablene direkte i /sys/firmware/efi/efivarsFor eksempel kan en bruker med et ASRock B450M Pro4-hovedkort og en Ryzen 5 2400G se noe slikt i bootctlUEFI-fastvare 2.70, sikker oppstart aktivert, SetupMode i brukermodus og ingen TPM2. Hvis du prøver å bruke sbkeysync Det kan hende du støter på en feil når du skal sette inn Microsoft-sertifikater i databasen fra Linux. «Operasjon ikke tillatt» når man skriver i /sys/firmware/efi/efivars/db-..., nettopp fordi den ikke lenger er i SetupMode og nøklene den prøver å bruke ikke samsvarer med de fastvaren forventer (nåværende PK/KEK).

Mange firmware tilbyr en rekke funksjoner gjennom grensesnittet sitt alternativer for sikker oppstartspolicy: bruk fabrikknøkler, bytt til tilpasset policy, slett alle nøkler, slett bare PK-en eller gjenopprett alle nøkler til standardverdier, og alternativer for endre UEFI-oppstartslogoenSletting av PK-en returnerer vanligvis maskinen til SetupMode, men noen firmware legger til ekstra beskyttelse («Oppdatering av den sikre variabelen er blokkert») og krever spesifikke omstartssekvenser eller brukerens fysiske tilstedeværelse.

På de samme grensesnittene kan du se nåværende status for sikker oppstart (aktivert/deaktivert), modusen (bruker/konfigurasjon), og få tilgang til menyene «Vis sikre oppstartsnøkler» og «Tilpasset sikker oppstartspolicy», der du kan inspisere eller manipulere PK, KEK, db og dbx. Hver betydelig endring krever vanligvis en omstart for at den skal tre i kraft.

Denne oppførselen er viktig når du for eksempel allerede har skrevet inn din egen PK/KEK/db For å starte opp en Linux-distribusjon signert med nøklene dine og deretter legge til Microsofts .auth-filer for å gjenopprette kompatibilitet med Windows Boot Manager: Hvis du ikke lenger er i SetupMode og .auth-pakkene dine ikke er signert med PKpriv som er kjent for hovedkortet, vil fastvaren ganske enkelt avvise endringen.

Sikker oppstart i Linux: shim, GRUB2, MOK og dine egne nøkler

I Linux-verdenen har mange distribusjoner måttet tilpasse seg sikker oppstart for å kunne starte opp på moderne maskinvare uten at brukeren må deaktivere denne funksjonen i BIOSI openSUSE (og tilsvarende i andre distribusjoner) kombinerer UEFI-oppstart med Secure Boot flere komponenter: mellomlegg, GRUB2den signerte kjernen og MOK (Maskineiernøkler).

UEFI-fastvaren, som som standard bare stoler på Microsoft-sertifikater (og i noen tilfeller OEM-sertifikater), lastes inn først. shim.efiShim er en liten oppstartslaster signert av en Microsoft UEFI CA. Den inkluderer distribusjonens innebygde CA (for eksempel openSUSE) og, valgfritt, en brukeradministrert MOK-database. Shim validerer GRUB2 (signert med distribusjonens CA), og GRUB2 laster på sin side bare kjerner signert med den samme CA-en eller med manuelt tillagte MOK-er.

Å tillate tilpassede kjerner eller egne drivere Uten å bryte Secure Boot tilbyr Linux MokManager-mekanismen. Når shim prøver å laste inn en EFI-binærfil med signatur den ikke gjenkjenner, kan den starte MokManager for å la brukeren importere et nytt sertifikat til MOK. Det er en interaktiv prosess under oppstart: du velger "Registrer nøkkel fra disk", peker på DER-sertifikatet ditt, bekrefter, og etter omstart blir nøkkelen en del av MOK, og shim vil tillate at binærfiler signert med den lastes inn.

Hvis du vil gå den ekstra milen og starte Linux med Secure Boot uten å være avhengig av Microsoft-nøkler, anbefaler noen guider tilbakestill fastvarenøkler og last inn dine egne PK-, KEK- og db-filer, inkludert kun din egen CA og, om nødvendig, distroens CA (for eksempel, shim-opensuse.der (i databasen). På eldre maskinvare som ikke støtter flere signaturer i samme EFI-binærfil, er det noen ganger nødvendig å fjerne den ekstra openSUSE-signaturen i shimen og bare la Microsoft-signaturen være igjen, eller omvendt, ved hjelp av verktøy som pesign.

Det er også mulig å konsultere og manipulere data fra Linux. EFI-variabler direkte gjennom /sys/firmware/efi/vars eller ved å sjekke statusen for sikker oppstart med kommandoer som od om variabelen SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c/dataHver fastvare er forskjellig, men denne lavnivåtilgangen er veldig nyttig for feilsøkingssituasjoner der BIOS-menyen er uklar eller har feil.

Bruke WSL på Windows for å generere nøkler og signere OpenCore og andre binærfiler

En stadig vanligere situasjon er at brukere ønsker oppstart av macOS med OpenCore på en PC-maskin med sikker oppstart aktivert. Siden fastvaren vanligvis bare stoler på Microsoft og noen ganger OEM-en, må du opprette dine egne nøkler, sette dem inn i fastvaren og bruke dem til å signere alle OpenCore EFI-binærfiler (inkludert drivere og verktøy), samtidig som du bevarer Microsoft-sertifiseringsinstansene som er nødvendige for at Windows skal kunne fortsette oppstarten.

I stedet for å installere et komplett Linux-system på en separat disk eller i en virtuell maskin, er et veldig praktisk alternativ å bruke WSL (Windows Subsystem for Linux) på Windows 10/11. Installere Ubuntu fra Microsoft Store (eller via wsl --install (i PowerShell) får du et ekte Linux-miljø under panseret, med støtte for verktøy som openssl, sbsigntool y efitools, med direkte tilgang til Windows-filsystemet under /mnt/c, /mnt/dOsv

Fra den Ubuntu i WSL kan du opprette en arbeidsmappe, generere tre par nøkler (PK, KEK og ISK eller lignende) med openssl req -new -x509 -newkey rsa:2048 -sha256 -days ...konfigurere gjenkjennelige CN-navn og begrense tillatelser til private nøkler med chmod 0600Deretter kan du laste ned de nødvendige Microsoft-sertifikatene (Windows Production PCA 2011, UEFI-driversignerings-CA eller nyere versjoner) og konvertere dem fra DER til PEM.

med cert-to-efi-sig-liste Du genererer signaturlistene i ESL-format (én for hvert sertifikat/nøkkel), og kombinerer deretter de du vil inkludere i databasen til én. db.esl (for eksempel din ISK.esl pluss Microsoft CA ESL-ene). Bruker sign-efi-sig-list du lager filene .auth som fastvaren deretter vil godta for å fylle ut PK, KEK og db: PK signert med seg selv, KEK signert av PK og db signert av KEK.

Neste trinn er signer OpenCore EFI-binærfiler med ISK-en din: verktøy som sbsign tillat signering av hver .efi med --key ISK.key --cert ISK.pemgenerere signerte versjoner som du deretter plasserer i strukturen EFI/OC (OpenCore.efi, BOOTx64.efi, drivere, verktøy…). Det finnes skript som automatiserer denne prosessen, automatisk laster ned gjeldende versjon av OpenCore, legger til drivere som HfsPlus.efi, og signerer alle .efi-filer rekursivt, slik at alt ligger klart i en «Signert»-mappe.

Til slutt kopierer du din PK.auth, KEK.auth og db.auth Utenfor WSL (for eksempel til en FAT-partisjon som er tilgjengelig fra fastvaren), går du inn i hovedkortets BIOS/UEFI, og registrerer dem i riktig rekkefølge fra menyen "tilpasset sikker oppstartsnøkkel". Når dette er gjort, vil fastvaren stole på både nøklene dine og Microsoft CA-nøklene som er inkludert i databasen, og du vil kunne starte opp Windows, OpenCore og andre EFI-signerte binærfiler med dine egne nøkler uten å deaktivere sikker oppstart.

Hele denne prosessen, som høres komplisert ut i starten, ender opp med å bli relativt håndterbar når du forstår PK → KEK → db/dbx-hierarkiet og har passende verktøy i et komfortabelt miljø som WSL.

Windows-krav for sikker oppstart, HCK-testing og systemkontroller

Fra et sertifiseringssynspunkt definerer Microsoft en rekke maskinvare- og fastvarekrav For at en enhet skal anses som kompatibel med Windows med sikker oppstart, må følgende krav være oppfylt: eksponere en UEFI-implementering av minst versjon 2.3.1 (seksjon 27 for sikker oppstart), støtte autentiserte variabler, ha en gyldig PK og KEK, ha en database med nødvendige Windows-sertifiseringsinstanser, og vedlikeholde en oppdatert dbx-fil for å forhindre tilbakestilling av fastvare og tilbakekalte binærfiler.

OEM-produsenter må sørge for at sikker variabel lagring Den er isolert fra operativsystemet og kan ikke endres stille fra programvare uten tilhørende signaturer. Alle fastvarekomponenter må også signeres (RSA-2048 med SHA-256), og systemet må implementere mekanismer for å beskytte mot nedgraderinger av fastvare (rollbacks) til sårbare versjoner.

For å validere en plattform tilbyr Microsoft verktøy og tester i Maskinvaresertifiseringssett (HCK)Det finnes automatiske og manuelle tester for sikker oppstart som bekrefter aspekter som om sikker oppstart faktisk er aktivert, om PK-en ikke er en kjent testnøkkel, om KEK-en inneholder Microsofts produksjons-KEK, om databasen har Windows-produksjons-CA, om dbx finnes, og om maksimale variabler (f.eks. 32 KB) kan opprettes og slettes riktig.

I tillegg finnes det PowerShell-cmdleter for å inspisere og endre UEFI-variabler på en autentisert måte: Bekreft-SecureBootUEFI (indikerer om sikker oppstart er PÅ), Get-SecureBootUEFI (leser variabler), Angi SecureBootUEFI (skriv/legg ved) og Format-SecureBootUEFI (skaper strukturer) EFI_SIGNATURE_LIST y EFI_VARIABLE_AUTHENTICATION_2Fra et avansert brukerperspektiv er disse verktøyene svært nyttige for å sjekke om PK/KEK/db-konfigurasjonen samsvarer med det du forventer.

Hvis du jobber med Linux i dobbeltoppstart, kan du også bruke msinfo32 I Windows, for å se "Sikker oppstartsstatus" og, som allerede nevnt, direkte konsultere variabler som SecureBoot og SetupMode fra /sys/firmware/efi/vars eller bruk efibootmgr å manipulere EFI-oppstartsbehandlingsoppføringer (opprette, slette eller endre rekkefølgen på oppstartsalternativer som EFI\Microsoft\Boot\bootmgfw.efi o EFI\opensuse\grubx64.efi).

Alt i alt innebærer det å konfigurere sikker oppstart med tilpassede nøkler en grundig forståelse av plattformens PKI-hierarki, velge riktig nøkkelgenererings- og lagringsstrategi (ideelt sett ved bruk av en HSM), kombinere Microsoft-, OEM- og tredjepartsnøkler i databasen og KEK uten å bryte kompatibiliteten, og håndter verktøyene med letthet Dette gjelder både fastvare- og operativsystemkomponenter (WSL, OpenSSL, efitools, sbkeysync, PowerShell-cmdlets). Når denne logikken er forstått, blir det relativt enkelt å vedlikeholde systemer som starter opp Windows, Linux og til og med OpenCore med sikker oppstart aktivert, noe som minimerer risikoen for oppstartsskadelig programvare og opprettholder reell kontroll over hvem som har tilgang til tillitskjeden.