Sleutelbeheer voor Secure Boot in Windows en Linux

Als je Secure Boot gebruikt op Windows- en Linux-systemen, is sleutelbeheer niet langer optioneel.Dit heeft gevolgen voor het opstarten van het systeem, voor het bijwerken van de firmware met fwupd of de tools van de fabrikant, en in de komende jaren zelfs voor de vraag of uw machines nog bootloaders accepteren die zijn ondertekend met oude Microsoft-certificaten.

Het doel van dit artikel is om op een rustige maar grondige manier uit te leggen hoe het gehele ecosysteem van Secure Boot-sleutels en -certificaten werkt op moderne UEFI-platformen.Welke rol spelen PK, KEK, db en dbx? Hoe verhoudt dit zich tot Windows, tot Linux-distributies die gebruikmaken van shims en tot OEM-hardware? En welke concrete oplossingen bestaan ​​er voor het genereren, beveiligen en vernieuwen van deze sleutels zonder chaos te veroorzaken in fabrieken of professionele omgevingen?

Wat is Secure Boot en hoe past het in UEFI, Windows en Linux?

Secure Boot is een beveiligingsfunctie die is gedefinieerd in de UEFI-standaard en is geen uitvinding die exclusief door Microsoft is gedaan.Het is ontstaan ​​als een evolutie van het oude BIOS om een ​​standaardmechanisme te bieden waarmee de firmware de cryptografische handtekeningen kan controleren van de componenten die tijdens het opstarten worden geladen: optie-ROM's, UEFI-stuurprogramma's, UEFI-applicaties en, vooral, de opstartprogramma's van het besturingssysteem.

De truc is dat de firmware alleen binaire bestanden uitvoert waarvan de digitale handtekening kan worden geverifieerd met intern opgeslagen, vertrouwde sleutels.Dit verkleint het aanvalsoppervlak voor opstartmalware (bootkits, rootkits) die wordt geïnjecteerd voordat het besturingssysteem en de antivirussoftware de controle kunnen overnemen. Windows 8 introduceerde dit model als onderdeel van de Secure Boot-architectuur en het is sindsdien een vereiste geworden op moderne Windows-clientcomputers en Windows Server.

In de Linux-wereld werd Secure Boot op een meer controversiële manier ontvangen. Omdat veel distributies niet voorbereid waren om GRUB en de kernel correct te ondertekenen, en omdat het grootste deel van het ecosysteem afhankelijk is van Microsofts sleutelinfrastructuur om op consumentenhardware op te starten, is shim ontstaan: een kleine bootloader die door Microsoft is ondertekend en die op zijn beurt GRUB en de kernel verifieert met sleutels van de distributie zelf, en die wordt beheerd met tools zoals MOK-manager.

Hoewel Microsoft een van de relevante certificeringsinstanties voor Secure Boot is, geeft de standaard de uiteindelijke controle aan de eigenaar van de computer.Op vrijwel alle x86-moederborden kun je de sleuteldatabase beheren, je eigen sleutels toevoegen, die van Microsoft verwijderen of zelfs opstarten met een volledig aangepaste productcode. De controverse komt meer voort uit de standaardconfiguratie en de Windows-certificeringsvereisten dan uit de technologie zelf.

Public key cryptografie en PKI toegepast op beveiligd opstarten.

Secure Boot is volledig afhankelijk van een infrastructuur voor openbare sleutels (PKI).Dit houdt in dat er gewerkt wordt met asymmetrische sleutelparen (publiek en privé), X.509-certificaten en certificaatketens die een vertrouwensbasis creëren van de certificeringsinstantie (CA) tot de binaire bestanden die bij het opstarten worden uitgevoerd.

In dit model wordt de privésleutel gebruikt voor ondertekening en de publieke sleutel voor verificatie.Als iemand de privésleutel in handen krijgt, wordt alles wat ermee ondertekend is onbetrouwbaar. Het is dan verplicht om het bijbehorende certificaat in te trekken (door het aan dbx toe te voegen) om te voorkomen dat apparaten potentieel schadelijke binaire bestanden blijven laden.

De aanbevolen algoritmen voor Secure Boot zijn RSA van minimaal 2048 bits en handtekeningen met SHA-256.De UEFI-standaard definieert handtekeningtypen zoals EFI_CERT_X509_GUID (volledige X.509-certificaten) of EFI_CERT_RSA2048_GUID (onbewerkte openbare sleutel of sleutelhash, om ruimte te besparen in de firmware), en Windows stemt zijn vereisten af ​​op dit beveiligingsniveau.

Een typisch digitaal certificaat bevat een unieke naam, de publieke sleutel en de handtekening van de uitgevende certificeringsinstantie (CA).Bij rootcertificaten is de handtekening zelfondertekend (de certificeringsinstantie ondertekent zichzelf), terwijl bij tussenliggende of uiteindelijke certificaten de handtekening afkomstig is van een certificeringsinstantie op een hoger niveau. Secure Boot maakt gebruik van deze certificaatketens om een ​​vertrouwde root-certificeringsinstantie in staat te stellen veel tussenliggende sleutels te authenticeren zonder de firmware te overladen met certificaten.

In de praktijk komen verschillende relevante CA's samen in een veilige opstartprocedure.Aan de ene kant de OEM (of diens vertegenwoordigers zoals de IBV of de ODM), en aan de andere kant Microsoft, met verschillende certificaten voor KEK, voor de UEFI CA die de Windows Boot Manager ondertekent, en voor de UEFI CA die het gebruikt om UEFI-stuurprogramma's en -laders van derden voor andere besturingssystemen zoals Fedora of Ubuntu te ondertekenen.

UEFI-vertrouwensbasis: PK, KEK, db en dbx

De Secure Boot-vertrouwensbasis in UEFI is gebaseerd op vier belangrijke elementen.De platformsleutel (PK), de sleuteluitwisselingssleutel (KEK), de toegestane handtekeningendatabase (db) en de verboden of ingetrokken handtekeningendatabase (dbx) worden allemaal opgeslagen als geauthenticeerde UEFI-variabelen.

De platformsleutel (PK) bepaalt wie de eigenaar is van het platform voor beveiligde opstartdoeleinden.Het is een certificaat, meestal X.509 RSA-2048 met een SHA-256-handtekening, waarvan het publieke deel (PKpub) tijdens de fabricage in de firmware wordt geschreven, waardoor het systeem de configuratiemodus verlaat en in de gebruikersmodus terechtkomt.

Het privégedeelte van de PK (PKpriv) moet altijd buiten het apparaat blijven, onder strikte beveiliging.Dit wordt gebruikt om elke bewerking te ondertekenen die KEK, db of dbx in de gebruikersmodus wijzigt, en ook om de primaire sleutel zelf te vervangen. Microsoft biedt OEM's de mogelijkheid om een ​​door hen beheerde primaire sleutel te gebruiken die is opgeslagen in een HSM, wat het beheer vereenvoudigt voor fabrikanten die geen volledige PKI willen implementeren.

De Key Exchange Key (KEK) fungeert als een vertrouwde verbinding tussen de firmware en de besturingssystemen of applicaties die db en dbx beheren.Elk systeem (Windows, Linux, OEM, derde partij) kan zijn openbare KEKpub-sleutel registreren in de KEK-variabele, zodat elke db- of dbx-update die met die sleutel is ondertekend, als legitiem wordt geaccepteerd.

Op de huidige Windows 11-systemen is het verplicht om ten minste de CA "Microsoft Corporation KEK 2K 2023" in de KEK-variabele op te nemen.Dit certificaat stelt Microsoft in staat om dbx-updates (intrekking van kwetsbare binaire bestanden of gecompromitteerde certificaten) te distribueren en, indien nodig, de db-inhoud aan te passen om nieuwe ondertekenaars te ondersteunen.

De db-database (_IMAGE_SECURITY_DATABASE) verzamelt de handtekeningen die als geldig worden beschouwd om te starten.Hier worden rootcertificaten zoals de "Windows UEFI CA 2023", de "Microsoft UEFI CA 2023", de "Microsoft Corporation UEFI CA 2011" of de "Microsoft UEFI Option ROM CA 2023" ingevoegd, evenals eventuele OEM CA's of hashes van specifieke binaire bestanden.

dbx (EFI_IMAGE_SIGNATURE_DATABASE1) doet precies het tegenovergestelde: het slaat expliciet ingetrokken certificaten, sleutels of hashes op.Elke overeenkomst in dbx blokkeert de uitvoering van het binaire bestand, zelfs als de handtekening ervan overeenkomt met iets in db. Windows vereist dat er altijd een dbx-bestand bestaat en distribueert regelmatig updatepakketten met nieuwe intrekkingen, vooral wanneer er kwetsbaarheden worden ontdekt in bootloaders of UEFI-stuurprogramma's.

Vereisten voor de Secure Boot-configuratie op Windows 11-computers en Linux-systemen.

Voor moderne Windows 11-apparaten, met name versie 25H2, specificeert Microsoft een minimale UEFI Secure Boot-configuratie.OEM's moeten vooraf een PK (van henzelf of van Microsoft), de "Microsoft Corporation KEK 2K 2023", de "Windows UEFI CA 2023" in db en het nieuwste dbx-pakket in dbx installeren.

Op systemen die ook ontworpen zijn om Linux of andere UEFI-applicaties van derden te draaien, wordt de inhoud van de database uitgebreid.Naast Windows UEFI CA 2023 wordt aanbevolen om ook Microsoft UEFI CA 2023, Microsoft Corporation UEFI CA 2011 en Microsoft UEFI Option ROM CA 2023 te installeren, zodat option ROMs, externe UEFI-drivers en loaders van andere platforms kunnen opstarten zonder dat de gebruiker de firmware hoeft aan te passen.

OEM's kunnen, indien nodig, hun eigen UEFI CA in dB toevoegen.Bijvoorbeeld om interne UEFI-stuurprogramma's of gespecialiseerde loaders te ondertekenen. Op dezelfde manier kunt u met de variabelen dbDefault, dbxDefault en KEKDefault standaardsets van sleutels en handtekeningen definiëren die de firmware kan terugzetten naar de fabrieksinstellingen.

In de Linux-wereld speelt nog een andere factor een rol: het verlopen van Microsoft-certificaten.De oude sleutels zullen uiteindelijk volledig verlopen (de deadline van september 2025 is met name relevant), en dat betekent dat bootloaders die met die certificaten zijn ondertekend, mogelijk niet meer opstarten, of dat firmware-updates via fwupd kunnen mislukken als de nieuwe Microsoft KEK- en CA-sleutels niet zijn geïnstalleerd.

Distributies zoals Ubuntu, Fedora en openSUSE, samen met hun commerciële varianten (RHEL, SLE), lopen doorgaans voorop wat betreft Secure Boot-compatibiliteit.Ze integreren goed met fwupd, GNOME Software of Discover om belangrijke updates met een paar klikken en een herstart toe te passen, terwijl andere distributies nog steeds aanraden om Secure Boot direct uit te schakelen omdat ze GRUB of de kernel niet correct ondertekenen.

Typische gebruiksscenario's en veelvoorkomende problemen met Secure Boot

Op een thuis- of gaming-pc beschermt Secure Boot je tegen kwaadaardige bootloaders, maar kan conflicteren met oudere hardware of niet-ondertekende software.Het komt relatief vaak voor dat je dit moet uitschakelen om een ​​live-USB met tools, een exotische distributie of oude grafische kaarten die geen ondertekende UEFI-ROM's beschikbaar stellen, op te starten.

In professionele of zakelijke omgevingen is het vrijwel verplicht om Secure Boot actief en correct geconfigureerd te hebben.Veel implementaties vertrouwen op deze laag om het risico op inbreuken op laag niveau te verminderen en combineren het gebruik ervan met TPM 2.0 en volledige schijfversleuteling (BitLocker op Windows, LUKS op Linux), waarbij de ontsleutelingssleutels worden versleuteld tot de opstartintegriteit.

Windows 11 heeft de eisen verder aangescherpt door TPM 2.0 en Secure Boot tegelijkertijd als officiële vereisten in te voeren.Hoewel er aangepaste installatieprogramma's bestaan ​​die deze controles omzeilen, moet iedereen die de "ondersteunde route" wil volgen ervoor zorgen dat de firmware in pure UEFI-modus staat, met Secure Boot beschikbaar en, indien mogelijk, ingeschakeld.

Videogames zijn inmiddels ook indirect onderdeel geworden van de Secure Boot-trend. in combinatie met anti-cheat op kernelniveau. Titels zoals Valorant, League of Legends, Battlefield 6 en Call of Duty: Black Ops 7 vereisen zelfs Windows met Secure Boot om hun anti-cheatsysteem te laten functioneren, waardoor oudere computers zonder UEFI of TPM worden uitgesloten.

In de Linux-omgeving is Secure Boot cruciaal in versleutelde dual-boot-scenario's.Als je Windows en Linux op één computer hebt staan ​​en je Linux-partitie is versleuteld, zijn er altijd onversleutelde bestanden (initramfs, bootloader, shim/GRUB) die aantrekkelijk zijn voor een aanvaller die Windows wil compromitteren. Secure Boot, mits correct geconfigureerd, voorkomt dat een aanvaller je initramfs vervangt door een bestand dat het wachtwoord steelt, omdat de firmware een niet-ondertekend binair bestand met een vertrouwde sleutel zou weigeren.

Hoe u Secure Boot veilig kunt in- of uitschakelen

Het in- of uitschakelen van Secure Boot gebeurt altijd via de UEFI-firmware van het apparaat, niet via het besturingssysteem zelf.Windows biedt echter snelkoppelingen om direct naar het firmwaremenu te herstarten.

Vanaf Windows 10 of 11 is de eenvoudigste manier via het geavanceerde herstelmenu.Ga naar Instellingen > Update en beveiliging > Herstel > Geavanceerd opstarten, tik op 'Nu opnieuw opstarten' en kies na het opnieuw opstarten Probleemoplossing > Geavanceerde opties > UEFI-firmware-instellingen. De computer start dan opnieuw op, maar komt direct in de BIOS/UEFI-interface terecht.

Binnen UEFI plaatst elke fabrikant de Secure Boot-optie op een iets andere plek.Deze instelling vindt u meestal in het tabblad "Opstarten" of "Beveiliging". Mogelijk moet u eerst een beheerderswachtwoord instellen om deze instelling te wijzigen. Daarna kunt u schakelen tussen Ingeschakeld/Uitgeschakeld of de toetsen verwijderen om terug te keren naar de configuratiemodus.

Het is belangrijk om te onthouden dat het uitschakelen van Secure Boot een aanzienlijke impact heeft op de kwetsbaarheid voor aanvallen.Je geeft hiermee de mogelijkheid om bootloaders, kernels of diagnostische tools uit te voeren zonder een geverifieerde handtekening. Als de computer is blootgesteld aan geavanceerde malware, vergroot dit het risico op bootkits die zeer moeilijk te detecteren en te verwijderen zijn.

Bij computers die met vooraf geïnstalleerd Windows worden geleverd, configureren sommige fabrikanten Secure Boot op een nogal beperkende manier.Op bepaalde "gesloten" desktop- en laptopcomputers moet de gebruiker dit uitschakelen als hij veel Linux-distributies wil opstarten die het handtekeningmodel van Microsoft nog niet volledig ondersteunen of geen ondertekende shims aanbieden.

Sleutelbeheer voor Secure Boot in productie- en OEM-omgevingen.

Wanneer we het hebben over OEM's, ODM's of integrators die op grote schaal apparatuur produceren, verandert sleutelbeheer van een technisch detail in een compleet PKI-project.Het is niet voldoende om simpelweg een certificaat te genereren: het is noodzakelijk om te definiëren hoeveel verschillende privésleutels er zullen zijn, waar elke privésleutel wordt opgeslagen en voor hoeveel jaar firmware-updates kunnen worden uitgebracht of KEK/db/dbx kunnen worden gewijzigd.

De gebruikelijke opties voor de platformsleutel (PK) variëren van één per apparaat tot één per OEM.Het gebruik van één PK per apparaat maximaliseert de isolatie (als er één gecompromitteerd raakt, heeft dit alleen gevolgen voor die machine), maar het is een logistieke en opslagramp. Eén PK per model of productlijn is meestal de verstandige oplossing, vooral voor desktops en laptops voor consumenten.

Naast de PK hebben OEM's specifieke sleutels nodig om firmware-updates veilig te ondertekenen.De zogenaamde "veilige firmware-updatesleutel" wordt doorgaans als publieke sleutel of hash opgeslagen in een beveiligd gedeelte van het apparaat (beveiligd flashgeheugen of fuses in de SoC), en alle updatecapsules moeten worden ondertekend met de bijbehorende privésleutel of een daaraan gekoppelde sleutel.

Al deze handelingen worden weerspiegeld in de Windows-workflow voor het bijwerken van firmware via de UEFI-capsule.Windows verzamelt de updates in zijn stuurprogrammaopslag, roept de functie UpdateCapsule() aan vóór ExitBootServices(), en de firmware valideert de handtekening, controleert de sleutel aan de hand van de opgeslagen hash, en als alles overeenkomt, flasht de nieuwe firmware.

De sleutel voor de firmware-update mag nooit hetzelfde zijn als de PK.Als PKpriv gecompromitteerd zou zijn en gebruikt zou worden om firmware te ondertekenen, zou de aanvaller Secure Boot kunnen uitschakelen en de legitieme firmware kunnen vervangen door een gemodificeerde versie, waardoor zelfs het herstellen van het platform met een nieuwe PK onmogelijk zou worden.

Sleutelbeheeroplossingen: HSM, TPM, software en andere.

Om Secure Boot-sleutels correct te beheren, wordt doorgaans gebruikgemaakt van hardwarebeveiligingsmodules (HSM's).Dit zijn gecertificeerde apparaten (in veel gevallen FIPS 140-2 niveau 2 of 3) die zijn ontworpen om privésleutels te genereren, op te slaan en te gebruiken zonder deze ooit in platte tekst buiten de hardware weer te geven.

Netwerk-HSM's zijn de meest robuuste optie voor fabrieken of datacenters.Ze bieden hoge beschikbaarheid, veilige back-ups en gecontroleerde toegang vanaf meerdere servers, en cryptografische versnelling om grote hoeveelheden certificaten te genereren en te ondertekenen zonder de productielijn te vertragen.

Op zichzelf staande HSM's (USB, PCIe, PCMCIA) zijn geschikt voor kleinere toepassingen of laboratoria.Ze kunnen worden geïntegreerd met cryptografische API's van Microsoft (CAPI, CNG) of andere, en sommige modellen bieden ook back-up- en replicatiemechanismen, hoewel niet altijd op het niveau van een netwerk-HSM.

In al deze gevallen is sterke authenticatie de hoeksteen.Veel HSM's ondersteunen "k van m"-tokenschema's: er worden bijvoorbeeld vijf cryptografische kaarten gegenereerd en de gelijktijdige aanwezigheid van drie is vereist om toegang te krijgen tot bepaalde sleutels. Dit verdeelt de verantwoordelijkheid over verschillende rollen (beveiliging, beheer, operationele zaken) en vermindert het risico op misbruik door individuen.

Er zijn minder krachtige alternatieven die zich richten op de hardware van de pc zelf, zoals TPM of smartcards.Een TPM kan sleutels genereren en beveiligen voor schijfversleuteling en andere functies, maar beschikt doorgaans niet over de verwerkingskracht, opslagcapaciteit en certificeringen die nodig zijn om duizenden PK- of firmware-sleutels in de fabriek te beheren.

Smartcards en USB-tokens met EV-certificaten hebben enkele eigenschappen gemeen met HSM's. (niet-exporteerbare sleutels, basisbescherming tegen manipulatie), maar ze zijn onhandig voor geautomatiseerde productieprocessen en missen de schaalbaarheid en hoge beschikbaarheid die nodig zijn wanneer firmware-images continu moeten worden ondertekend.

Ten slotte zijn er puur softwarematige benaderingen voor het genereren en opslaan van sleutels, die niet aanbevolen worden voor OEM-omgevingen.Met tools zoals makecert of standaard cryptografische API's kun je certificaten aanmaken en opslaan op versleutelde schijven of geïsoleerde machines, maar het aanvalsrisico is veel groter en, tenzij gecombineerd met extreme fysieke beveiligingsmaatregelen, neemt het risico op sleutellekken onaanvaardbaar toe.

Genereren, opslaan en ophalen van privésleutels

De ruimte die een RSA-2048-sleutel inneemt is in absolute termen klein (2048 bits), maar de sleutel zit hem in de symbolische waarde en het beheer op lange termijn.Een PK- of firmware-updatesleutel moet mogelijk tien jaar of langer veilig toegankelijk zijn om incidenten op te lossen of nieuwe firmwareversies te genereren.

Het algemene advies is om privésleutels altijd op aparte hardware op te slaan.Of het nu gaat om een ​​HSM in een datacenter of, in veel bescheidener scenario's, een cryptografische token in bewaring, back-ups moeten op aparte fysieke locaties worden bewaard, zelfs in verschillende geografische regio's, om de impact van rampen te minimaliseren.

De processen voor sleutelherstel moeten net zo goed gedefinieerd zijn als de processen voor sleutelgeneratie.Het kan voorkomen dat u een primaire sleutel opnieuw moet genereren omdat een klant met hoge beveiligingseisen zijn eigen primaire sleutel wil registreren, omdat een potentieel lek wordt gedetecteerd, of simpelweg omdat intern beleid periodieke rotaties voorschrijft (bijvoorbeeld elke X jaar volgens de richtlijnen van de Federal Bridge CA).

In het geval van KEK- en firmware-updatesleutels is herstel nog crucialer.KEKpriv wordt gebruikt om nieuwe versies van db en dbx te ondertekenen, en de "priv"-sleutel van de firmware ondertekent updates die naar miljoenen apparaten worden verzonden. Het verliezen van een van deze sleutels zonder back-up kan ertoe leiden dat u geen gecompromitteerde certificaten meer kunt intrekken of beveiligingspatches kunt distribueren.

Authenticatie op hoog niveau (FIPS 140-2 niveau 3) voegt een extra beveiligingslaag toe aan dit hele proces.Het vereist de individuele identificatie van elke gebruiker die toegang krijgt tot de module, het registreren van hun handelingen en de toepassing van fysieke beveiligingsmaatregelen (zegels, sabotagesensoren, veilige verwijdering van gegevens bij inbraakpogingen) die het risico op stille diefstal van sleutels drastisch verminderen.

Secure Boot, ondertekening door derden en Linux-compatibiliteit

Secure Boot is op zichzelf geen DRM-mechanisme of een belemmering om Linux te installeren.Het beperkt welke binaire bestanden bij het opstarten mogen worden uitgevoerd. Dit kan legitiem zijn voor de beveiliging, maar ook onhandig als het te restrictief is geconfigureerd.

De gebruikelijke kritiek dat het een Microsoft-tool is om alternatieve systemen te blokkeren, houdt geen stand wanneer de UEFI-specificatie wordt bekeken.De gebruiker of beheerder kan zijn eigen sleutels registreren, de sleutels van Microsoft verwijderen, de primaire sleutel wijzigen of ervoor kiezen om alleen binaire bestanden te vertrouwen die door de eigen organisatie zijn ondertekend. Dit wordt door Debian en andere distributies duidelijk beschreven in hun eigen documentatie.

Wat zeker is, is dat veel Linux-distributies er in de praktijk voor hebben gekozen om gebruik te maken van de essentiële infrastructuur van Microsoft om het leven gemakkelijker te maken voor minder technisch onderlegde gebruikers.Bij gebruik van shims die zijn ondertekend door Microsoft UEFI CA 2011 of 2023, herkent de firmware de loader van de distributie direct, zonder dat de gebruiker handmatig PK, KEK of db hoeft aan te raken.

Microsoft biedt ook een specifieke CA aan voor het ondertekenen van UEFI-stuurprogramma's en -applicaties van derden.Elke hardwarefabrikant of -ontwikkelaar die wil dat zijn optionele ROM of UEFI-stuurprogramma opstart via Secure Boot-hardware, kan zijn binaire bestanden ter ondertekening aanbieden en distribueren, in de wetenschap dat ze zullen werken op computers die de Microsoft CA in de database hebben.

Het minst aantrekkelijke aspect van dit systeem is dat de sleutels verlopen en worden ingetrokken.Wanneer een oud rootcertificaat bijna verloopt, moet het worden vervangen door een nieuw certificaat. U moet er ook voor zorgen dat alle apparaten de bijbehorende updates via KEK/db/dbx hebben ontvangen, anders loopt u het risico dat zaken zoals fwupd, bepaalde bootloaders of UEFI-ROM's niet meer door de firmware worden ondersteund.

Als je dual-boot gebruikt met Windows en Linux, of als je Linux-implementaties hebt met Secure Boot ingeschakeld, is het raadzaam om regelmatig te controleren op belangrijke updates die door Microsoft en je distributie zijn uitgebracht.In veel distributies hoeft u alleen maar de firmware-updatepakketten uit de softwarestore of pakketbeheerder te accepteren, de computer opnieuw op te starten en de firmware de wijzigingen te laten toepassen; in andere distributies moet u de opdrachtregel en specifieke hulpprogramma's gebruiken.

Dual boot met Windows en Linux, EFI-partities en opstartvolgorde

Voor het opzetten van een schone dual-boot tussen Windows en Linux is enige kennis vereist over de interactie tussen UEFI, de EFI-partitie en de GRUB-opstartmanager.Met Secure Boot ingeschakeld is het nog belangrijker om niet te improviseren, en het is raadzaam om de instellingen te controleren. opstartproces in UEFI-systemen.

Als je Windows al in UEFI-modus met GPT-partitionering hebt geïnstalleerd, is het eerste wat je moet doen de Windows-partitie verkleinen en de vrijgekomen ruimte reserveren voor Linux.Schakel vóór het wijzigen van de schijfgrootte functies zoals Snel opstarten en BitLocker uit om verrassingen te voorkomen. Het is cruciaal om te controleren of er een EFI-partitie (FAT32, enkele honderden MB) bestaat die beide systemen kunnen delen.

Bij het installeren van Linux wordt aangeraden om handmatig te partitioneren en de bestaande EFI-partitie te respecteren.Het wordt gemount als /boot/efi in plaats van een nieuwe te creëren. Van daaruit worden naar behoefte partities voor /, /home en swap aangemaakt, en wordt GRUB geïnstalleerd als de UEFI-opstartmanager, die ook naar de EFI-partitie verwijst.

Als de distributie Secure Boot ondersteunt, worden een ondertekende shim en GRUB geïnstalleerd, die de firmware zonder verdere problemen zal accepteren.Anders moet u mogelijk Secure Boot tijdelijk uitschakelen om de installatie te voltooien, of handmatig extra certificaten in de database registreren zodat de firmware de Linux-bootloader vertrouwt. Dit komt vaak voor bij compatibiliteitsproblemen. Voeg opstartparameters toe aan GRUB..

Na de installatie kan het systeem direct in Windows opstarten, omdat de GRUB-opstartoptie geen prioriteit heeft.In dat geval moet je toegang krijgen tot de UEFI en de opstartvolgorde wijzigen, of, vanuit Linux, efibootmgr gebruiken om de volgorde aan te passen. Je kunt hier ook mee experimenteren vanuit Windows. bcdedit, bootrec en reagentcMaar het is overzichtelijker om UEFI de prioriteiten te laten bepalen.

Met alles correct geconfigureerd en de sleutels goed beheerd, kan een robuuste dual-boot-omgeving worden onderhouden, met versleutelde schijven en Secure Boot actief., zonder dat u telkens opties hoeft in- en uit te schakelen wanneer u van systeem wisselt, en zonder dat u de beveiligingsvoordelen van de moderne UEFI-Secure Boot-TPM-architectuur hoeft op te geven.

Uiteindelijk maakt inzicht in het beheer van Secure Boot-sleutels in Windows en Linux – van PK en KEK tot db/dbx, HSM, TPM en dual booting – het verschil tussen een onbetrouwbaar systeem dat niet meer opstart wanneer een certificaat verloopt en een robuust platform dat klaar is voor firmware-updates, nieuwe distributies en steeds strengere beveiligingsvereisten, zonder dat u de controle over uw eigen machines verliest.