Eigenlijk moet Secure Boot de pc beschermen tegen geïnfecteerde bootmanagers, maar momenteel heeft het zelf problemen. En dat zijn er schrikbarend veel.
Wat er mis is met Secure Boot
Je hebt in het vorige artikel al gelezen wat Secure Boot is. Nu gaan we dieper in op de details: wat er precies allemaal mis is met Secure Boot. Dat varieert van verlopen certificaten en problemen bij het vervangen door nieuwe, via slordige hardwarefabrikanten tot zwakke plekken in het ontwerp en in veel bootmanagers die momenteel worden gebruikt.
De huidige problemen hebben trouwens niets te maken met de moeilijkheden die Secure Boot sowieso al graag veroorzaakt. Zo zijn er steeds vaker computers waarop, als Secure Boot actief is, alleen de eigen bootmanagers van Windows worden uitgevoerd, wat in feite een opstartverbod betekent voor veel Linux-distributies.
Of er in de configuratievensters voor de UEFI-firmware een schakelaar zit waarmee je dit kunt veranderen, hangt weer af van de pc-fabrikant. Zo niet, dien dan een klacht in bij de fabrikant en kies de volgende keer vooral voor een computer van een ander merk. Maar nu even over de huidige problemen.
Probleem 1: verlopen
Elk certificaat heeft een vervaldatum, waarna het niet meer als geldig wordt beschouwd. En precies die datum bereiken enkele van Microsofts Secure Boot-gerelateerde certificaten halverwege het jaar. Het gaat in de eerste plaats om die twee waarmee de meeste bootmanagers zijn ondertekend, en aan de hand waarvan de UEFI-firmware na het opstarten controleert of een bootmanager betrouwbaar is.
Dat betekent overigens niet dat alle daarmee ondertekende bootmanagers na de vervaldatum ineens niet meer werken. Ze bevatten namelijk extra tijdstempelcertificaten (‘time stamp’). Die geven aan: ‘Ik verklaar dat het certificaat, dat eigenlijk al verlopen is, nog geldig was op het moment dat het bestand ermee werd ondertekend.’ Daardoor blijft de handtekening van reeds gepubliceerde bootmanagers geldig.

Microsoft kan verlopen certificaten echter niet meer gebruiken om nieuwe bootmanagers daarmee geldig te ondertekenen. Zo zal bijvoorbeeld naar verwachting binnenkort de volgende Windows 11-versie 26H2 verschijnen, en ook die heeft een bootmanager. Om die te ondertekenen, heeft Microsoft dus een nieuw certificaat nodig waarvan de vervaldatum nog in de toekomst ligt.
En om ervoor te zorgen dat Secure Boot die nieuwe bootmanager doorlaat, moet ook de UEFI-firmware het nieuwe certificaat herkennen. Anders gezegd: als de firmware alleen de dan al verlopen certificaten kent, zul je Windows 11 26H2 niet kunnen installeren zolang Secure Boot actief is.
Dat Microsoft de oude certificaten niet meer als geldige certificaten kan gebruiken, is een vertrouwenskwestie want puur technisch gezien zou het hergebruik geen probleem zijn. Microsoft zou nieuwe bootmanagers nog steeds met het oude certificaat kunnen ondertekenen. Maar Microsoft heeft hier te maken met andere beperkingen. De belofte van een ‘betrouwbare pc’ kan alleen worden nagekomen als alle betrokkenen zich aan de richtlijnen houden, dus ook Microsoft. En bij die afspraak hoort nu eenmaal ook dat de vervaldata van certificaten consequent worden nageleefd.
Probleem 2: een allegaartje
Microsoft zit dus met geen andere keuze dan nieuwe certificaten uit te geven en bootmanagers daarmee te ondertekenen. Dat is al in 2023 gebeurd; de nieuwe heten Windows UEFI CA 2023 en Microsoft UEFI CA 2023. Die met Windows in de naam is voor de eigen bootmanagers van Microsoft, de andere voor Linux en dergelijke.
Er is nu zelfs een derde met de naam Microsoft Option ROM UEFI CA 2023. Dat is bedoeld voor Option-ROM’s, dus voor de firmware van aparte grafische en netwerkkaarten, SATA-, RAID- en USB-controllers en soortgelijke hardware, die bij actieve Secure Boot ook alleen ondertekend mogen opstarten.
Voor het gemak hebben we het hierna over de oude en de nieuwe certificaten. Op dezelfde manier noemen we de bootmanagers die met een oud certificaat zijn ondertekend gewoon ‘oud’, om ze te onderscheiden van de nieuwe, die met een van de nieuwe certificaten zijn ondertekend.
Deze nieuwe certificaten moeten nu geleidelijk op alle computers terechtkomen. Microsoft probeert ze al een tijdje via Windows Update te verspreiden, met wisselend succes. Ook de pc-fabrikanten zijn begonnen computers hiermee uit te leveren. Het resultaat is momenteel een driedeling.
Er zijn computers die alleen oude certificaten hebben. Daarop starten oude bootmanagers gewoon door zoals altijd, maar nieuwe bootmanagers niet. Dan zijn er computers die zowel oude als nieuwe certificaten herkennen; daarop starten zowel oude als nieuwe bootmanagers – en dat geldt voorlopig ook nog na de vervaldatum van de oude certificaten. Ten slotte zijn er computers die relatief nieuw zijn en waarvoor de fabrikanten alleen de nieuwe certificaten hebben meegeleverd. Daarop starten de oude bootmanagers niet meer op, en dat geldt ook voor zo’n beetje alle gangbare installatie- en rescue-media van tegenwoordig.
Probleem 3: certificaten vervangen
Op Windows-computers zorgt de ingebouwde updatefunctie ervoor dat de Secure Boot-certificaten worden bijgewerkt. Maar alle code die iets aan de certificaatopslag van de UEFI-firmware wil veranderen, moet ook ondertekend zijn. Ook het certificaat dat hiervoor wordt gebruikt, is in de meeste gevallen afkomstig van Microsoft en verloopt dit jaar eveneens.
En ook hier moet software die dit certificaat wil vervangen, weer ondertekend zijn, dit keer met een handtekening van de hardwarefabrikant. Bij de eigen Surface-apparaten van Microsoft is dat geen probleem, bij andere apparaten daarentegen wel. Daar moet de hardwarefabrikant meewerken.
Het is echt vervelend als ook het certificaat van de fabrikant al is verlopen, want dan kun je de UEFI-certificaatopslag niet meer bijwerken. Je hebt dan een firmware-update van de fabrikant nodig met daarin nieuwe certificaten, die je mogelijk handmatig moet installeren.
Wie over de technische vaardigheden en mogelijkheden beschikt, kan ook een eigen fabrikantcertificaat aanmaken en in de firmware opslaan, maar dat is eigenlijk alleen bedoeld voor grote bedrijven. Voor de meesten blijft alleen de BIOS-update over.
Probleem 4: support
Elke update van de certificaten vereist niet alleen dat de benodigde software is ondertekend, maar ook dat de fabrikant dergelijke software überhaupt beschikbaar stelt. Met andere woorden: De fabrikant moet nog steeds ondersteuning bieden.
Zo wordt Windows 8 al lang als verouderd beschouwd, en ook voor Windows 10 krijg je alleen nog ondersteuning als je je met een Microsoft-account bij het besturingssysteem aanmeldt, dus als je er met je gegevens voor betaalt. Bij Microsoft heet dat ‘Uitgebreide beveiligingsupdates’ (ESU). In eerste instantie zou Microsoft een jaar lang updates leveren, maar onlangs is het bedrijf weer van gedachten veranderd en het programma met een jaar verlengd.

Maar zelfs met Windows 11 ben je niet per se aan de veilige kant. Net als bij Windows 10 verschijnen er ook van Windows 11 elk jaar nieuwe versies. De namen bestaan uit het jaar van uitgave en de helft van het jaar; de versie die in de tweede helft van 2025 is uitgekomen, heet 25H2. Elk van deze versies krijgt slechts twee jaar (Home & Pro) of drie jaar (Enterprise & Education) ondersteuning.
Home- en Pro-edities moeten dus minimaal op versie 24H2 staan om nog updates te krijgen. Er zijn weliswaar LTS-versies met langere ondersteuning, maar die verkoopt Microsoft niet aan particuliere klanten.
Als er een nieuw certificaat van de hardwarefabrikant nodig is, moet die ook meewerken. Veel van hen ondersteunen computers die ouder zijn dan twee jaar niet meer. We hebben al concrete klachten over HP ontvangen. Bovendien moet een fabrikant support kunnen bieden: niet elk bedrijfje uit het Verre Oosten of waar dan ook biedt support – en al helemaal niet levenslang.
Probleem 5: PKfail
Het certificaat van de fabrikant kan je ook om een andere reden in de weg staan. Sommige fabrikanten hebben geen eigen certificaten in de firmware gezet, maar die van derden erin gelaten, die nooit bedoeld waren voor levering aan klanten. Het is gebruikelijk dat pc-fabrikanten firmware inkopen, bijvoorbeeld bij AMI of Phoenix. Die BIOS-producenten slaan daarin een certificaat op dat uitdrukkelijk alleen bedoeld is voor testdoeleinden van de hardwarefabrikant, en niemand kan bepalen wie er allemaal mee kan ondertekenen.
Criminelen kunnen hiermee dus vervalste updates voor de UEFI-certificaatopslag maken, die de firmware zou accepteren. Je herkent zulke testcertificaten onder andere doordat hun naam de woorden DO NOT TRUST of Test bevat.
Als de hardwarefabrikant zo’n testcertificaat in de firmware laat zitten, is de betrouwbaarheid van Secure Boot verdwenen. Daarom is het zo belangrijk dat de fabrikanten goed opletten wat ze leveren. Maar dat doen ze nu eenmaal niet allemaal.
Achteraf kan zo’n fout alleen via een BIOS-update worden verholpen. Omdat de certificaten van de producenten intern ‘Platform Key’ worden genoemd, is dit probleem bekend geworden onder de naam ‘PKfail’.
Probleem 6: BlackLotus
Alsof dat allemaal nog niet erg genoeg was, dook er een tijdje geleden nog een ander probleem op. Er werd ontdekt dat bootmanagers kwetsbaarheden bevatten die misbruikt kunnen worden om Secure Boot te omzeilen. Daar zaten heel wat bootmanagers bij die correct waren ondertekend met een Microsoft-certificaat. Dit beveiligingsprobleem werd bekend als ‘Black Lotus’.
Voor zulke gevallen zijn er twee verschillende tegenmaatregelen bedacht. Ten eerste het blokkeren van het certificaat waarmee de onveilige bootmanagers zijn ondertekend. Hiervoor is er een extra gedeelte in de UEFI-certificaatopslag. Terwijl de geldige certificaten in een gedeelte met de naam db (database) staan, komen geblokkeerde certificaten in een ander gedeelte met de naam dbx terecht.
Het blokkeren van het certificaat zou echter betekenen dat in één klap alle bootmanagers die daarmee zijn ondertekend, verboden zouden worden, dus ook diegene die helemaal niet als onveilig zijn aangemerkt. Daarom is er een tweede oplossing. In de dbx komen de checksums terecht van alle bootmanagers die als onveilig bekend staan. De firmware berekent bij het opstarten de checksum van het bootmanager-bestand, controleert of die ook in de dbx staat, en zo ja, blokkeert het opstarten ervan, ondanks een geldige handtekening.
De methode op zich is beproefd; er worden steeds weer afzonderlijke bootmanagers op deze manier geblokkeerd. BlackLotus was echter iets nieuws. Deze bootkit maakt gebruik van meerdere kwetsbaarheden in zo veel bootmanagers dat de poging om al hun checksums in de dbx op te slaan mislukt door ruimtegebrek. De UEFI-specificatie schrijft hiervoor geen minimumgrootte voor; elke fabrikant kan doen wat hij wil.
Zelfs in Redmond zag men na een tijdje in dat dit waarschijnlijk niet zou werken. Plan B luidt: we blokkeren de certificaten toch maar en vervangen ze door nieuwe. En dat ondanks de gevolgen. Zodra de blokkering van kracht wordt, starten bootmanagers die met de oude certificaten zijn ondertekend niet meer op. Alleen die met nieuwe certificaten starten nog op. Dat maakt dan wel een einde aan de warboel die hierboven als probleem 2 werd beschreven, maar is dat ook wenselijk?
Wanneer de blokkering precies van kracht wordt, is niet bekend. Microsoft zegt in het Knowledge Base-artikel KB 5025885 op het moment van schrijven alleen dat de datum ‘op een later tijdstip bekendgemaakt’ wordt.
Probleem 7: reset
UEFI-firmware heeft in de configuratievensters meestal ergens een knop om terug te zetten naar de fabrieksinstellingen. Maar daarbij wordt ook het certificaatgeheugen gereset. Met een beetje pech laadt het besturingssysteem de nieuwe certificaten weliswaar eerst in, maar na zo’n BIOS-reset zijn ze weer verdwenen. Alle daarmee ondertekende bootmanagers werken dan ineens niet meer, en dat kan ook de installatie op de SSD beïnvloeden.
In theorie zouden updates er dus voor moeten zorgen dat ook de fabrieksinstellingen worden bijgewerkt. Maar of dat echt altijd het geval is, is een ander verhaal.
Probleem 8. Microsoft
Wat nog bovenop alle eerder genoemde problemen komt: het bijwerken van de certificaten en het vervangen van de oude bootmanagers doet Microsoft op Windows-computers zoals gewoonlijk via de ingebouwde updatefunctie. En wat via die functie wordt verspreid, lijdt al jaren onder het feit dat er vooraf slechts rudimentair wordt getest. Reken er dus maar op dat er bij het updaten iets mis kan gaan.
In onze volgende artikelen lees je wat je dan kunt doen als het gaat om je UEFI-certificaten controleren, de UEFI-bootmanager controleren en zelf maatregelen nemen.
Axel Vahldiek en Marco den Teuling
Praat mee