Ubuntu Wiki

Wat is UEFI Secure Boot?

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

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

De meeste x86 hardware komt van de fabriek voorgeladen met Microsoft sleutels. Dit betekent dat we er in het algemeen op kunnen vertrouwen dat de firmware op deze systemen binaire bestanden vertrouwt die zijn ondertekend door Microsoft, en de Linux-gemeenschap vertrouwt zwaar op deze aanname voor Secure Boot om te werken. Dit is hetzelfde proces dat wordt gebruikt door Red Hat en SUSE, bijvoorbeeld.

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

Initieel implementatieplan: Implementatieplan.

Ondersteunde architecturen

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

• arm64: Vanaf 20.04 (‘focal’) zijn een door Microsoft ondertekende shim-binaire en een door Canonical ondertekende grub-binaire beschikbaar in het Ubuntu-hoofdarchief als shim-signed of grub-efi-arm64-signed. Er is een GRUB-bug in onderzoek die moet worden opgelost voordat dit van begin tot eind werkt.

Testen van 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/Testing.

Hoe UEFI Secure Boot werkt op Ubuntu

Op Ubuntu zijn alle vooraf gebouwde binaire bestanden die bedoeld zijn om te worden geladen als onderdeel van het opstartproces, met uitzondering van het initrd-image, ondertekend door Canonical’s UEFI-certificaat, dat zelf impliciet wordt vertrouwd doordat het is ingesloten in de shim loader, zelf ondertekend door Microsoft.

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

Als het systeem opstart, laadt de firmware de shim binary zoals gespecificeerd in de firmware BootEntry variabelen. Ubuntu installeert zijn eigen BootEntry tijdens de installatie en kan deze elke keer bijwerken als de GRUB bootloader wordt bijgewerkt. Aangezien de shim binary is ondertekend door Microsoft, wordt deze gevalideerd en geaccepteerd door de firmware bij verificatie tegen certificaten die al aanwezig zijn in de firmware. Aangezien de shim binary zowel een Canonical certificaat als zijn eigen vertrouwensdatabase bevat, kunnen verdere elementen van de opstartomgeving, naast te zijn ondertekend door een van de acceptabele certificaten die vooraf in de firmware zijn geladen, worden ondertekend door Canonical’s UEFI-sleutel.

Het volgende dat door shim wordt geladen is de second-stage image. 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 gewijzigd toen het systeem eerder draaide).

Als het systeem normaal opstart, wordt de GRUB binary (grub*.efi) geladen en wordt geprobeerd deze te valideren tegen alle eerder bekende vertrouwde bronnen. De GRUB binary voor Ubuntu is ondertekend door de Canonical UEFI sleutel, dus het wordt met succes gevalideerd en het opstartproces gaat verder.

Bij het booten om door te gaan met sleutelbeheertaken, wordt de MokManager binary (mm*.efi) geladen. Deze binary wordt expliciet vertrouwd door shim door te zijn ondertekend door een efemere sleutel die alleen bestaat terwijl de shim binary wordt gebouwd. Dit betekent dat alleen de MokManager binary die met een bepaalde shim binary is gebouwd, zal mogen draaien en beperkt de mogelijkheid van compromittering door het gebruik van gecompromitteerd gereedschap. MokManager staat iedere gebruiker aan de systeemconsole toe om sleutels in te schrijven, vertrouwde sleutels te verwijderen, binaire hashes in te schrijven en Secure Boot validatie op shim-niveau aan te zetten, maar voor de meeste taken moet een eerder ingesteld wachtwoord worden ingevoerd om te bevestigen dat de gebruiker aan de console inderdaad de persoon is die om wijzigingen heeft gevraagd. Zulke wachtwoorden overleven alleen tijdens 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 booten, omdat de sleutelbeheerwijzigingen nodig kunnen zijn om het opstarten met succes te voltooien.

Zodra het systeem verder gaat met opstarten naar GRUB; het GRUB-proces laadt elke vereiste configuratie (meestal het laden van configuratie van de ESP (EFI System Partition), wijzend naar een ander configuratiebestand op de root- of opstartpartitie), die het zal wijzen naar de kernelimage om te laden.

EFI-toepassingen hebben tot dit punt volledige toegang tot de systeemfirmware, inclusief toegang tot het wijzigen van vertrouwde firmware-variabelen, de te laden kernel moet ook worden gevalideerd tegen de vertrouwensdatabase. Officiële Ubuntu kernels worden ondertekend door de Canonical UEFI sleutel, ze worden met succes gevalideerd, en de controle wordt overgedragen aan de kernel. Initrd images worden niet gevalideerd.

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

Tot nu toe wordt elke mislukte validatie van een te laden image beantwoord met een kritieke fout die het boot proces stopt. Het systeem zal niet doorgaan met booten, en kan automatisch herstarten na een periode van tijd, gezien het feit dat andere BootEntry variabelen boot paden kunnen bevatten die geldig zijn en vertrouwd.

Eenmaal geladen, zullen gevalideerde kernels de Boot Services van de firmware uitschakelen, waardoor privileges vervallen en effectief wordt overgeschakeld naar gebruikersmodus; waar toegang tot vertrouwde variabelen beperkt is tot alleen-lezen. Gezien de brede rechten die aan kernelmodules worden toegekend, moet elke module die niet in de kernel is ingebouwd ook worden gevalideerd bij het laden. Modules die door Canonical zijn gebouwd en met de officiële kernels worden meegeleverd, zijn ondertekend met de Canonical UEFI-sleutel en worden als zodanig vertrouwd. Voor zelfgebouwde modules moet de gebruiker de nodige stappen ondernemen om de modules te ondertekenen voordat het laden ervan door de kernel wordt toegestaan. Dit kan worden bereikt met het commando ‘kmodsign’ .

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

Gezien het feit 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 lokaal op het systeem moeten worden gebouwd om te worden ingepast in de draaiende kernel, biedt Ubuntu tooling om het ondertekeningsproces te automatiseren en te vereenvoudigen.

Hoe kan ik drivers niet-geautomatiseerd ondertekenen?

Sommige projecten vereisen het gebruik van aangepaste kernel drivers die niet zo zijn ingesteld dat ze werken met DKMS. In deze gevallen moet gebruik worden gemaakt van de hulpmiddelen in het shim-signed pakket: het update-secureboot-policy script is beschikbaar om een nieuwe MOK te genereren (als er nog geen DKMS-gebaseerde modules zijn die het genereren van een MOK hebben geactiveerd).

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 afsluiten met een melding van die strekking. Als de sleutel al geregistreerd is, zal het script afsluiten en niets doen. Als de sleutel bestaat, maar niet blijkt te zijn ingeschreven, zal de gebruiker worden gevraagd om een wachtwoord om te gebruiken na het herstarten, zodat de sleutel kan worden ingeschreven.

Een nieuwe MOK kan worden gegenereerd met het volgende commando:

sudo update-secureboot-policy --new-key

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

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

Beveiligingsimplicaties bij Machine-Owner Key management

De MOK die bij de installatie of bij een upgrade wordt gegenereerd, is machinespecifiek en mag alleen door de kernel of shim worden gebruikt 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.

De recente shimversies bevatten logica om de beperkingen van alleen module-tekenende sleutels te volgen. Deze sleutels zullen worden toegestaan om te worden ingeschreven in de firmware in shim’s vertrouwensdatabase, maar zullen worden genegeerd wanneer shim of GRUB images valideren om in firmware te laden. De verify() functie van shim zal alleen met succes images valideren die ondertekend zijn door 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 globale vertrouwensdatabase (die zowel die van de shim als die van de firmware bevat) en zullen alle meegeleverde sleutels accepteren als ondertekeningssleutels bij het laden van kernelmodules.

Gezien de beperkingen die zijn opgelegd aan de automatisch gegenereerde MOK en het feit dat gebruikers met superuser toegang tot het systeem en toegang tot de systeem console om het wachtwoord in te voeren dat nodig is bij het inschrijven van sleutels al high-level toegang tot het systeem hebben; de gegenereerde MOK sleutel wordt bewaard op het bestandssysteem als reguliere bestanden waarvan root de eigenaar is met alleen-lezen rechten. Dit wordt voldoende geacht om de toegang tot de MOK voor ondertekening door kwaadwillende gebruikers of scripts te beperken, vooral gezien het feit dat er geen MOK op het systeem bestaat tenzij er drivers van derden voor nodig zijn. Dit beperkt de mogelijkheid van compromittering door misbruik van een gegenereerde MOK-sleutel voor het ondertekenen van een kwaadaardige kernelmodule. Dit staat gelijk aan het in gevaar brengen van de gebruikersapplicaties, wat al mogelijk zou zijn met supergebruikerstoegang tot het systeem, en het beveiligen hiervan valt buiten het bereik van UEFI Secure Boot.

Voorgaande systemen hadden mogelijk Secure Boot validatie uitgeschakeld in shim. Als onderdeel van het upgrade proces, zullen deze systemen worden gemigreerd naar het opnieuw inschakelen van Secure Boot validatie in shim en het inschrijven van een nieuwe MOK-sleutel indien van toepassing.

MOK generatie en onderteken proces

Het sleutel generatie en onderteken proces is enigszins verschillend, afhankelijk van of we te maken hebben met een gloednieuwe installatie of een upgrade van een systeem waarop voorheen Ubuntu draaide; deze twee gevallen zijn hieronder duidelijk gemarkeerd.

In alle gevallen, als het systeem niet in UEFI mode opstart, zullen er geen speciale kernel module ondertekeningsstappen of sleutel generatie gebeuren.

Als Secure Boot is uitgeschakeld, vindt het genereren van MOK’s en het inschrijven nog steeds plaats, omdat de gebruiker later Secure Boot kan inschakelen. Het systeem zou in dat geval naar behoren moeten werken.

De gebruiker installeert Ubuntu op een nieuw systeem

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

Stuurprogramma’s of kernelmodules van derden die door het systeem zijn vereist, worden automatisch gebouwd wanneer het pakket wordt geïnstalleerd, en het bouwproces omvat een ondertekeningsstap. De ondertekeningsstap gebruikt automatisch de eerder gegenereerde MOK om de module te ondertekenen, zodat deze onmiddellijk kan worden geladen zodra het systeem opnieuw wordt opgestart en de MOK is opgenomen in de vertrouwensdatabase van het systeem.

Als de installatie is voltooid en het systeem opnieuw is opgestart, wordt de gebruiker bij de eerste keer opstarten geconfronteerd met het MokManager programma (onderdeel van de geïnstalleerde shim loader), als een set tekst-mode panelen die alle de gebruiker om de gegenereerde MOK te registreren. De gebruiker selecteert “Enroll MOK”, krijgt een vingerafdruk te zien van het certificaat dat moet worden aangemeld en wordt gevraagd om de aanmelding te bevestigen. Na bevestiging wordt de nieuwe MOK ingevoerd in de firmware en wordt de gebruiker gevraagd het systeem opnieuw op te starten.

Wanneer het systeem opnieuw wordt opgestart, worden de stuurprogramma’s van derden, ondertekend door de zojuist ingeschreven MOK, indien nodig geladen.

De gebruiker upgradet een UEFI-enabled Ubuntu-systeem naar een nieuwe release waarbij het systeem stuurprogramma’s van derden vereist

Bij de upgrade worden de shim en shim-ondertekende pakketten geüpgraded. De post-install taken van het shim-ondertekende pakket gaan verder met het genereren van een nieuwe MOK, en vraagt de gebruiker om een wachtwoord dat duidelijk wordt vermeld als zijnde vereist zodra het upgrade proces is voltooid en het systeem opnieuw is opgestart.

Tijdens de upgrade worden de kernelpakketten en modules van derden geüpgraded. Modules van derden worden herbouwd voor de nieuwe kernels en hun post-build proces gaat verder om ze automatisch te ondertekenen met de MOK.

Na de upgrade wordt de gebruiker aangeraden zijn systeem opnieuw op te starten.

Bij het opnieuw opstarten wordt de gebruiker het MokManager programma gepresenteerd (onderdeel van de geïnstalleerde shim loader), als een set van tekst-mode panelen die alle de gebruiker om de gegenereerde MOK in te schrijven. De gebruiker selecteert “Enroll MOK”, krijgt een vingerafdruk te zien van het certificaat dat hij wil inschrijven, en wordt gevraagd om de inschrijving te bevestigen. De gebruiker wordt ook gevraagd om de Secure Boot validatie opnieuw in te schakelen (in het geval dat deze uitgeschakeld bleek te zijn); en MokManager vraagt opnieuw om bevestiging van de gebruiker. Zodra alle stappen zijn bevestigd, wordt de shimvalidatie weer ingeschakeld, wordt de nieuwe MOK ingevoerd in de firmware en wordt de gebruiker gevraagd het systeem opnieuw op te starten.

Wanneer het systeem opnieuw wordt opgestart, worden de stuurprogramma’s van derden, ondertekend door de zojuist ingeschreven MOK, indien nodig geladen.

In alle gevallen, zodra het systeem draait met UEFI Secure Boot ingeschakeld en een recente versie van shim; de installatie van een nieuwe DKMS-module (stuurprogramma van derden) zal doorgaan om de gebouwde module te ondertekenen met de MOK. Dit gebeurt zonder tussenkomst van de gebruiker als er een geldige MOK-sleutel op het systeem aanwezig is en deze al lijkt te zijn aangemeld.

Als er geen MOK bestaat of de bestaande MOK niet is aangemeld, wordt er automatisch een nieuwe sleutel aangemaakt vlak voor het ondertekenen en wordt de gebruiker gevraagd de sleutel aan te melden door een wachtwoord op te geven dat bij het opnieuw opstarten vereist is.