Controleer de UEFI-certificaten van je pc voor Secure Boot

Het gebruik van het script is simpel. Download via de link bij dit artikel het zip-archief ct-UEFI CertInfo.zip. Pak het uit in een willekeurige map. Dat uitpakken is echt belangrijk. Als je het script in plaats daarvan rechtstreeks vanuit het zip-archief start, werkt het niet goed.

Na het uitpakken staan er drie bestanden in de doelmap. Klik met de rechtermuisknop op ct-UEFICertInfo.bat (als je de bestandsextensie niet ziet: het is het bestand met het pictogram met twee tandwielen). Kies in het contextmenu Als administrator uitvoeren. Wacht even tot de tabel is opgebouwd.

De kolomkoppen van de tabel geven aan wat er in de betreffende kolom staat, bijvoorbeeld Database of Type. Standaard is alles gesorteerd op de databases waarin de certificaten en hashes staan. Je kunt de sortering echter wijzigen door op een kolomkop te klikken. Nog een keer op dezelfde kop klikken sorteert in de tegenovergestelde richting. Als je terug wilt naar de oorspronkelijke weergave, klik je linksboven op de knop Terugzetten.

Met de knop Opslaan rechtsboven exporteer je de volledige tabel naar een tekstbestand, waarvan de bestandsnaam bestaat uit ct-UEFICertInfo-, de door Windows toegekende naam van de installatie (‘computernaam’) en de bestandsextensie .txt. Je kunt het volledige script dus op een USB-stick van computer naar computer meenemen, daar telkens de tabel met slechts één klik opslaan en alles later op je werkcomputer bekijken.

Als je op de knop Opslaan klikt terwijl er al een tekstbestand voor deze computer bestaat, voegt het script de nieuwe tabel onderaan in hetzelfde bestand toe.

Er zitten in totaal twaalf databases in het UEFI-certificaatgeheugen, maar dat ziet er ingewikkelder uit dan het is. Slechts vier zijn echt belangrijk. De belangrijkste voor Secure Boot is db (Database). De UEFI-firmware laat een bootmanager alleen door als deze succesvol is vergeleken met de informatie uit de db.

Terwijl de database db dus een lijst met toegestane certificaten is, is de database dbx precies het tegenovergestelde. Als een certificaat daar in zit, wordt elke bootmanager die ermee is ondertekend door de UEFI-firmware geblokkeerd. Dat geldt ook als hetzelfde certificaat tegelijkertijd in db staat, want een verbod heeft altijd voorrang op toestemming.

Code die iets aan db en dbx wil veranderen (bijvoorbeeld extra certificaten toevoegen), moet zelf ondertekend zijn. Hiervoor is echter een ander certificaat nodig, dat in de database KEK zit (Key Exchange Key). Meestal vind je hier een certificaat van Microsoft, en vaak ook een van de pc-fabrikant en/of Linux-distributeur.

De bovenste database in de hiërarchie is PK, wat staat voor Platform Key. Hier zit precies één certificaat, meestal van de pc-fabrikant. Dat is nodig als er wijzigingen in de KEK-database moeten worden aangebracht.

De UEFI-specificatie noemt nog meer databases. dbt is een lijst met goedgekeurde tijdstempelcertificaten. Deze bevestigen dat een ander certificaat, dat inmiddels is verlopen, op het moment van ondertekening nog geldig was. Maar omdat ook tijdstempelcertificaten kunnen verlopen, kun je deze aan de dbt toevoegen, zodat de UEFI-firmware ze toch accepteert.

De dbr-database is bedoeld voor certificaten waarmee een recovery-loader wordt gecontroleerd. Het gaat hier dus om herstelsoftware van de pc-fabrikant, waarmee je bijvoorbeeld de fabrieksinstellingen kunt herstellen.

dbt en dbr spelen in de praktijk geen rol. Microsoft gebruikt deze twee databases niet; ze zijn vrijwel altijd leeg. Ons script toont ze alleen voor de volledigheid.

Voor alle tot nu toe genoemde databases bestaan er telkens tegenhangers met ‘Default’ in de naam. Die spelen in de dagelijkse praktijk geen rol, want het gaat om de fabrieksinstellingen.

Als je echter in de firmware-instellingen een fabrieksreset uitvoert of zelfs alleen maar de certificaten terugzet naar de oorspronkelijke staat (Restore Factory Keys), wordt de inhoud van PK, KEK, db, dbx, dbt en dbr vervangen door de standaardinstellingen. Dat kan ernstige gevolgen hebben.

Als er bijvoorbeeld een nieuw certificaat aan de db wordt toegevoegd, maar niet aan dbDefault, zou het nieuwe certificaat uit db na een reset zijn verdwenen. Daardoor zouden ondertekende bootmanagers plotseling niet meer opstarten, terwijl dat vóór de reset wel kon.

In de tabel staan in de derde kolom zowel certificaten als hashes vermeld. De reden hiervoor is dat onze uitleg tot nu toe nog niet helemaal volledig was. De UEFI-firmware kan namelijk niet alleen de handtekening van een bootmanager controleren, maar ook de hash (controlesom) controleren. Als die in de db staat, wordt hij toegestaan, zelfs als hij geen geldige handtekening heeft.

Meestal komen controlesommen echter alleen in de dbx terecht. Zo kun je afzonderlijke bootmanagers blokkeren zonder meteen alle bootmanagers uit te sluiten die met hetzelfde certificaat zijn ondertekend. Dat komt zelfs zo vaak voor dat ons script niet de afzonderlijke checksums weergeeft, maar deze gewoon bij elkaar optelt (onderverdeeld in die van Microsoft en die van andere fabrikanten).

Hashes en certificaten kunnen ook door elkaar in databases voorkomen, en wel in alle. Zodra Microsoft op een gegeven moment het plan uitvoert om de oude certificaten uit 2011 te blokkeren, zal de dbx zelfs standaard beide bevatten.

De kolom met de certificaten en hashes is meestal gekleurd. Groen betekent dat het certificaat geldig is, rood betekent het tegenovergestelde. Vermeldingen in de dbx zijn standaard rood, omdat alles daarin verboden is.

Maar ook in de db kunnen er rode vermeldingen staan, namelijk als een certificaat of hash niet alleen in de db, maar tegelijkertijd ook in de dbx staat. Want het verbod heeft immers voorrang.

Behoort jouw pc tot die computers waarbij een hardwarefabrikant geen eigen PK-certificaten in de firmware heeft opgeslagen, maar helaas een testcertificaat van de firmwarefabrikant heeft overgenomen? Dit beveiligingslek staat bekend als PKfail, en op getroffen computers zijn er ook rode vermeldingen bij PK. Om precies te zijn: het script kleurt alle PK-certificaten rood waarvan de naam de woorden ‘Test’, ‘not trust’ (niet vertrouwen) of ‘not ship’ (niet leveren) bevat.

Daarnaast hebben we van de ontdekkers van PKfail (zie pk.fail) een lijst met bekende serienummers van zulke certificaten overgenomen, die ons script gebruikt om nog meer bekende testresten te markeren.

Twee kolommen van de tabel geven data weer. Vanaf wanneer is een certificaat geldig en tot wanneer? En weer wordt het kleurrijk. Groen betekent ‘is geldig’ of ‘is nog langer dan een jaar geldig’. Geel betekent dat er minder dan een jaar te gaan is tot de vervaldatum. Rood staat voor nog niet of niet meer geldig.

Let op: dat een certificaat nog niet of niet meer geldig is, betekent niet dat de firmware het niet meer zou accepteren (ook al komt dat in sommige gevallen voor). Het is juist een teken dat de fabrikant met dit certificaat nog niet of niet meer mag ondertekenen(!). Even ter herinnering: het gaat hier niet om technische beveiligingsmaatregelen, maar om het vertrouwen in de fabrikanten dat ze zich aan hun eigen richtlijnen houden.

De laatste kolom heet Thumbprint (voor vingerafdruk), hier staan de checksums van de certificaten. We hebben ze toegevoegd omdat ze kunnen dienen als korte, unieke identificatiecode, wat vergelijkingen en online zoekopdrachten vergemakkelijkt.

Je weet nu wel wat er allemaal in de tabel kan staan, maar hoe kom je erachter welke status je computer heeft? Daarvoor volstaat een blik in db en dbx.

Als in db het certificaat Microsoft Windows Production PCA 2011 staat en dit groen is gemarkeerd, mogen oude Windows-bootmanagers opstarten. Nieuwe zijn toegestaan als Windows UEFI CA 2023 aanwezig is. Zijn beide certificaten aanwezig en groen, dan mogen zowel oude als nieuwe opstarten.

Hetzelfde geldt voor niet-Windows-bootmanagers, zoals die voor Linux, alleen heten ze hier Microsoft Corporation UEFI CA 2011 (oud) en Microsoft UEFI CA 2023 (nieuw). Vroeger gold het oude ook voor de Option-ROM’s, dus de firmware van aparte grafische en netwerkkaarten, SATA-, RAID- en USB-controllers en soortgelijke hardware, die bij actieve Secure Boot ondertekend moet zijn.

Daarvoor is er nu een apart certificaat: Microsoft Option ROM UEFI CA 2023. Omdat de namen op het eerste gezicht verwarrend kunnen lijken: het jaartal 2011 staat altijd voor oude certificaten, 2023 altijd voor nieuwe.

Als er ‘Windows’ in de naam staat, geldt een certificaat alleen voor Windows-bootmanagers. Bij die voor Linux en dergelijke ontbreekt ‘Windows’ in de naam.

Dus als je een standaard Windows- of Linux-installatie hebt en momenteel alle vijf genoemde certificaten in de db van je computer staan (er kunnen nog meer zijn van de hardwarefabrikant of toegevoegd door vorige eigenaren of software-installaties), dan mag alles opstarten en kun je lekker achteroverleunen. In ieder geval voorlopig.

Vanwege de Black Lotus-beveiligingsproblemen (zie het vorige artikel) wil Microsoft de oude certificaten uit 2011 op een gegeven moment aan de dbx toevoegen, oftewel blokkeren. Wanneer dat gaat gebeuren, wil het bedrijf nog niet verklappen, maar dan verandert die geruststellende groene melding in een ten minste gedeeltelijk rode en heb je mogelijk nieuwe bootmanagers nodig. Meer hierover in het volgende artikel.

Axel Vahldiek en Marco den Teuling

Overzicht van links bij dit artikel