Wat is UEFI Secure Boot?

UEFI Secure boot is een verificatiemechanisme om ervoor te zorgen dat code die door firmware wordt gestart, wordt vertrouwd.

juist, veilig gebruik van UEFI Secure Boot vereist dat elk binair programma dat geladen wordt bij het opstarten gevalideerd wordt tegen bekende sleutels, die zich in de firmware bevinden, die vertrouwde leveranciers en bronnen voor de binaries aanduiden, of vertrouwde specifieke binaries die geïdentificeerd kunnen worden via cryptografische hashing.

De meeste x86-hardware komt uit de fabriek die vooraf is geladen met Microsoft-sleutels. Dit betekent dat we over het algemeen kunnen vertrouwen op de firmware op deze systemen om binaries te vertrouwen die zijn ondertekend door Microsoft, en de Linux-gemeenschap vertrouwt sterk op deze veronderstelling voor Veilig opstarten om te werken. Dit is hetzelfde proces gebruikt door Red Hat en SUSE, bijvoorbeeld.

veel ARM-en andere architecturen ondersteunen ook UEFI Secure Boot, maar zijn mogelijk geen pre-loading sleutels in firmware. Op deze architecturen kan het nodig zijn om boot images opnieuw te ondertekenen met een certificaat dat in firmware is geladen door de eigenaar van de hardware.

oorspronkelijk uitvoeringsplan: uitvoeringsplan.

Ondersteunde architecturen

• amd64: een shim-binair ondertekend door Microsoft en grub-binair ondertekend door Canonical worden geleverd in het hoofdarchief van Ubuntu als shim-signed of grub-efi-amd64-signed.

• arm64: vanaf 20.04 (‘focal’) wordt een shim-binair ondertekend door Microsoft en grub-binair ondertekend door Canonical in het hoofdarchief van Ubuntu geleverd als shim-signed of grub-efi-arm64-signed. Er wordt een GRUB bug onderzocht die opgelost moet worden voordat dit van begin tot eind werkt.

testen UEFI Secure Boot

Als u geïnteresseerd bent in het testen van Secure Boot op uw systeem, raadpleeg dan de how-to hier: UEFI/SecureBoot/testen.

hoe UEFI Secure Boot werkt op Ubuntu

Op Ubuntu worden alle vooraf gebouwde binaries die bedoeld zijn om te worden geladen als onderdeel van het opstartproces, met uitzondering van de initrd-afbeelding, ondertekend door Canonical ‘ s UEFI-certificaat, dat zelf impliciet wordt vertrouwd door ingebed te zijn in de shim-lader, zelf ondertekend door Microsoft.

op architecturen of systemen waar vooraf geladen ondertekeningscertificaten van Microsoft niet beschikbaar zijn of in firmware zijn geladen, kunnen gebruikers de bestaande handtekeningen op shim of grub vervangen en ze laden zoals ze willen, waarbij ze verifiëren met hun eigen certificaten die in de firmware van het systeem zijn geïmporteerd.

als het systeem opstart, laadt de firmware het shim binaire programma zoals gespecificeerd in firmware bootentry variabelen. Ubuntu installeert zijn eigen BootEntry tijdens de installatie en kan het updaten wanneer de GRUB bootloader wordt bijgewerkt. Omdat de shim binary is ondertekend door Microsoft; het wordt gevalideerd en geaccepteerd door de firmware bij het verifiëren met certificaten die al aanwezig zijn in de firmware. Aangezien de shim binary zowel een Canonical certificaat als zijn eigen vertrouwensdatabase insluit, kunnen andere elementen van de boot omgeving, naast het ondertekenen door een van de acceptabele certificaten die vooraf zijn geladen in firmware, worden ondertekend door Canonical ‘ s UEFI sleutel.

het volgende dat door shim wordt geladen is de afbeelding in de tweede fase. Dit kan een van de twee dingen zijn: ofwel GRUB, als het systeem normaal opstart; of MokManager, als sleutelbeheer vereist is, zoals geconfigureerd door firmware variabelen (meestal veranderd wanneer het systeem eerder actief was).

als normaal wordt opgestart; de GRUB binary (grub*.efi) wordt geladen en de validatie ervan wordt geprobeerd tegen alle eerder bekende vertrouwde bronnen. De GRUB binary Voor Ubuntu is ondertekend door de canonieke UEFI sleutel, dus het is succesvol gevalideerd en het opstartproces gaat door.

bij het opstarten om verder te gaan met sleutelbeheertaken, de mokmanager binary (mm*.efi) is geladen. Deze binaire code wordt expliciet vertrouwd door shim door te worden ondertekend door een kortstondige sleutel die alleen bestaat terwijl de shim binaire code wordt gebouwd. Dit betekent dat alleen de mokmanager binary gebouwd met een bepaalde shim binary zal worden toegestaan om te draaien en beperkt de mogelijkheid van compromis door het gebruik van gecompromitteerde tools. MokManager staat elke gebruiker die aanwezig is op de systeemconsole toe om sleutels in te schrijven, vertrouwde sleutels te verwijderen, binaire hashes in te schrijven en veilige opstartvalidatie in te schakelen op het shim-niveau, maar de meeste taken vereisen een eerder ingesteld wachtwoord om te bevestigen dat de gebruiker op console inderdaad de persoon is die wijzigingen heeft aangevraagd. Dergelijke wachtwoorden overleven slechts over een enkele run van shim / MokManager; en worden gewist zodra het proces is voltooid of geannuleerd. Zodra het sleutelbeheer is voltooid, wordt het systeem opnieuw opgestart en gaat het niet gewoon verder met het opstarten, omdat de wijzigingen in het sleutelbeheer nodig kunnen zijn om het opstarten met succes te voltooien.

zodra het systeem verder gaat met opstarten naar GRUB; laadt het GRUB proces elke vereiste configuratie (meestal wordt de configuratie geladen vanuit de ESP (EFI systeem partitie), wijzend naar een ander configuratie bestand op de root of boot partitie), wat het naar de kernel image zal wijzen om te laden.

EFI-toepassingen tot nu toe met volledige toegang tot de firmware van het systeem, inclusief toegang tot veranderende vertrouwde firmware-variabelen, moet de te laden kernel ook worden gevalideerd ten opzichte van de vertrouwensdatabase. Officiële Ubuntu-kernels worden ondertekend door de canonieke UEFI-sleutel, ze zijn met succes gevalideerd en de controle wordt overgedragen aan de kernel. Initrd-afbeeldingen worden niet gevalideerd.

in het geval van Onofficiële kernels, of kernels gebouwd door gebruikers, moeten extra stappen worden genomen als gebruikers dergelijke kernels willen laden met behoud van de volledige mogelijkheden van UEFI Secure Boot. Alle kernels moeten ondertekend zijn om door GRUB te mogen laden als UEFI Secure Boot is ingeschakeld, dus de gebruiker zal moeten doorgaan met zijn eigen ondertekening. Als alternatief kunnen gebruikers validatie in shim uitschakelen terwijl ze opgestart worden met Secure Boot ingeschakeld op een officiële kernel door gebruik te maken van ‘sudo mokutil –disable-validation’, een wachtwoord op te geven wanneer daarom gevraagd wordt, en opnieuw op te starten; of om Secure Boot in firmware helemaal uit te schakelen.

tot op dit punt is er een kritieke fout opgetreden bij het valideren van een te laden image die het opstartproces stopt. Het systeem zal niet doorgaan met opstarten, en kan automatisch herstarten na een periode van tijd gezien het feit dat andere bootentry variabelen bootpaden kunnen bevatten die geldig en vertrouwd zijn.

eenmaal geladen, zullen gevalideerde kernels de opstartservices van de firmware uitschakelen, waardoor privileges vervallen en effectief overschakelen naar gebruikersmodus; waar de toegang tot vertrouwde variabelen beperkt is tot alleen-lezen. Gezien de brede rechten die aan kernelmodules worden verleend, moet elke module die niet in de kernel is ingebouwd ook worden gevalideerd bij het laden. Modules gebouwd en verzonden door Canonical met de officiële kernels worden ondertekend door de canonieke UEFI sleutel en als zodanig, worden vertrouwd. Op maat gemaakte modules vereisen dat de gebruiker de nodige stappen neemt om de modules te ondertekenen voordat ze geladen worden door de kernel. Dit kan worden bereikt met het commando’ kmodsign’.

unsigned modules worden gewoon geweigerd door de kernel. Elke poging om ze in te voegen met insmod of modprobe zal mislukken met een foutmelding.

gegeven dat veel gebruikers modules van derden nodig hebben om hun systemen goed te laten werken of om sommige apparaten te laten functioneren; en dat deze modules van derden vereisen lokaal bouwen op het systeem te worden gemonteerd op de draaiende kernel, Ubuntu biedt tooling te automatiseren en vereenvoudigen van het ondertekeningsproces.

Hoe kan ik stuurprogramma ‘ s niet automatisch ondertekenen?

sommige projecten vereisen mogelijk het gebruik van aangepaste kerneldrivers die niet zo zijn opgezet dat ze met DKMS werken. In deze gevallen moeten mensen gebruik maken van de tools in het shim-signed pakket: het update-secureboot-policy script is beschikbaar voor het genereren van een nieuwe MOK (als er geen dkms-gebouwde modules hebben geactiveerd genereren van een reeds).

gebruik het volgende commando om een bestaande sleutel in te schrijven in shim:

sudo update-secureboot-policy --enroll-key

als er geen MOK bestaat, zal het script worden afgesloten met een bericht van die strekking. Als de sleutel al is ingeschreven, zal het script stoppen, zonder iets te doen. Als de sleutel bestaat maar niet wordt getoond om te worden ingeschreven, zal de gebruiker worden gevraagd om een wachtwoord te gebruiken na het opnieuw opstarten, zodat de sleutel kan worden ingeschreven.

men kan een nieuwe MOK genereren met behulp van het volgende commando:

sudo update-secureboot-policy --new-key

en vervolgens de nieuw gegenereerde sleutel inschrijven in shim met het eerder genoemde commando voor die taak.

kernelmodules kunnen dan worden ondertekend met het commando kmodsign (zie UEFI/SecureBoot/Signing) als onderdeel van hun bouwproces.

beveiligingsimplicaties in Machine-eigenaar sleutelbeheer

De MOK gegenereerd tijdens de installatie of bij upgrade is machinespecifiek, en alleen toegestaan door de kernel of shim om kernelmodules te ondertekenen, door gebruik te maken van een specifieke KeyUsage OID (1.3.6.1.4.1.2312.16.1.2) die de beperkingen van de MOK aangeeft.

recente shim-versies bevatten logica om de beperkingen van module-signing-only-sleutels te volgen. Deze sleutels mogen worden ingeschreven in de firmware in shim ‘ s trust database, maar worden genegeerd wanneer shim of GRUB afbeeldingen valideren om in firmware te laden. Shim ‘ s verify () functie zal alleen succesvol afbeeldingen valideren die zijn ondertekend met sleutels die niet de “Module-signing only” (1.3.6.1.4.1.2312.16.1.2) KeyUsage OID bevatten. De Ubuntu-kernels gebruiken de global trust-database (die zowel shim ’s als de firmware’ s bevat) en zullen een van de meegeleverde sleutels accepteren als ondertekentoetsen bij het laden van kernelmodules.

gezien de beperkingen die worden opgelegd aan de automatisch gegenereerde MOK en het feit dat gebruikers met superuser toegang tot het systeem en toegang tot de systeemconsole om het wachtwoord in te voeren dat nodig is bij het inschrijven van sleutels, al toegang hebben tot het systeem op hoog niveau; de gegenereerde mok-sleutel wordt op het bestandssysteem bewaard als gewone bestanden die eigendom zijn van root met alleen-lezen rechten. Dit wordt voldoende geacht om de toegang tot de MOK te beperken voor ondertekening door kwaadaardige gebruikers of scripts, vooral gezien het feit dat er geen MOK bestaat op het systeem, tenzij het vereist drivers van derden. Dit beperkt de mogelijkheid van compromis van het misbruik van een gegenereerde mok-sleutel tot het ondertekenen van een kwaadaardige kernel module. Dit is gelijk aan het compromitteren van de userland applicaties die al mogelijk zouden zijn met superuser toegang tot het systeem, en het beveiligen van dit is buiten het bereik van UEFI Secure Boot.

vorige systemen hebben mogelijk een beveiligde Opstartvalidatie uitgeschakeld in shim. Als onderdeel van het upgradeproces zullen deze systemen worden gemigreerd om opnieuw beveiligde bootvalidatie in shim mogelijk te maken en indien van toepassing een nieuwe MOK-sleutel in te schrijven.

MOK-generatie en ondertekeningsproces

het sleutelgeneratie-en ondertekeningsproces is iets anders, afhankelijk van of we te maken hebben met een gloednieuwe installatie of een upgrade van het systeem waarop Ubuntu eerder werd uitgevoerd; deze twee gevallen zijn hieronder duidelijk aangegeven.

in alle gevallen, als het systeem niet opstart in UEFI-modus, zullen er geen speciale kernelmodule ondertekeningsstappen of sleutelgeneratie plaatsvinden.

als Secure Boot is uitgeschakeld, gebeurt MOK-generatie en inschrijving nog steeds, omdat de gebruiker later Secure Boot kan inschakelen. Het systeem moet goed werken als dat het geval is.

de gebruiker installeert Ubuntu op een nieuw systeem

De gebruiker stapt door het installatieprogramma. In een vroeg stadium, bij het voorbereiden van de installatie en alleen als het systeem modules van derden nodig heeft om te werken, wordt de gebruiker gevraagd om een systeemwachtwoord dat duidelijk is gemarkeerd als vereist nadat de installatie is voltooid, en terwijl het systeem wordt geïnstalleerd, wordt een nieuwe MOK automatisch gegenereerd zonder verdere interactie van de gebruiker.

drivers of kernelmodules van derden die nodig zijn voor het systeem zullen automatisch worden gebouwd wanneer het pakket is geïnstalleerd, en het bouwproces bevat een ondertekeningstap. De ondertekeningsstap gebruikt automatisch de eerder gegenereerde MOK om de module te ondertekenen, zodat deze onmiddellijk kan worden geladen zodra het systeem opnieuw is opgestart en de MOK is opgenomen in de vertrouwensdatabase van het systeem.

zodra de installatie is voltooid en het systeem opnieuw wordt opgestart, wordt de gebruiker bij het opstarten het MokManager-programma (onderdeel van de geà nstalleerde shim-Lader) gepresenteerd, als een set tekstmodus-panelen die alle gebruikers om de gegenereerde MOK in te schrijven. De gebruiker selecteert “inschrijven MOK”, krijgt een vingerafdruk van het certificaat te registreren, en wordt gevraagd om de inschrijving te bevestigen. Eenmaal bevestigd, de nieuwe MOK zal worden ingevoerd in de firmware en de gebruiker zal worden gevraagd om het systeem opnieuw op te starten.

wanneer het systeem opnieuw opstart, zullen stuurprogramma ‘ s van derden die zijn ondertekend door de zojuist ingeschreven MOK worden geladen als dat nodig is.

de gebruiker upgrade een UEFI-enabled Ubuntu-systeem naar een nieuwe release waar het systeem vereist derden drivers

bij upgrade, de shim en shim-ondertekend pakketten worden bijgewerkt. Post-install taken van het shim-ondertekende pakket gaat door met het genereren van een nieuwe MOK, en vraagt de gebruiker om een wachtwoord dat duidelijk wordt vermeld als vereist zodra het upgradeproces is voltooid en het systeem opnieuw is opgestart.

tijdens de upgrade worden de kernelpakketten en modules van derden opgewaardeerd. Modules van derden worden herbouwd voor de nieuwe kernels en hun post-build proces gaat door om ze automatisch te ondertekenen met de MOK.

na een upgrade wordt de gebruiker aangeraden om zijn systeem opnieuw op te starten.

bij het opnieuw opstarten wordt de gebruiker het MokManager-programma (onderdeel van de geà nstalleerde shim-Lader) gepresenteerd, als een set tekstmodus-panelen die alle gebruikers gebruiken om de gegenereerde MOK in te schrijven. De gebruiker selecteert “inschrijven MOK”, krijgt een vingerafdruk van het certificaat te registreren, en wordt gevraagd om de inschrijving te bevestigen. De gebruiker wordt ook gepresenteerd met een prompt om opnieuw in te schakelen veilige boot validatie (in het geval bleek te zijn uitgeschakeld); en MokManager opnieuw vereist bevestiging van de gebruiker. Zodra alle stappen zijn bevestigd, shim validatie is opnieuw ingeschakeld, de nieuwe MOK zal worden ingevoerd in de firmware en de gebruiker zal worden gevraagd om het systeem opnieuw op te starten.

wanneer het systeem opnieuw opstart, zullen stuurprogramma ‘ s van derden die zijn ondertekend door de zojuist ingeschreven MOK worden geladen als dat nodig is.

in alle gevallen, zodra het systeem draait met UEFI Secure Boot ingeschakeld en een recente versie van shim; zal de installatie van een nieuwe dkms module (third-party driver) doorgaan met het ondertekenen van de gebouwde module met de MOK. Dit gebeurt zonder gebruikersinteractie als er een geldige mok-sleutel op het systeem bestaat en al lijkt te zijn ingeschreven.

als er geen MOK bestaat of de bestaande MOK niet is ingeschreven, wordt er automatisch een nieuwe sleutel aangemaakt vlak voor ondertekening en wordt de gebruiker gevraagd om de sleutel in te schrijven door een wachtwoord op te geven dat nodig is bij het opnieuw opstarten.