Fedora 18 UEFI Secure Boot gids

Fedora 18 UEFI Secure Boot gids

Josh Boyer Kevin Fenzi Peter Jones Josh Bressers Florian Weimer

UEFI Secure Boot gids

Ontwerp

Fedora 18 UEFI Secure Boot gids Uitgave 18.4 Auteur Auteur Auteur Auteur Auteur Redacteur

Josh Boyer Kevin Fenzi Peter Jones Josh Bressers Florian Weimer Eric Christensen

[email protected] [email protected] [email protected] [email protected] [email protected] [email protected]

Copyright © 2012-2013 Fedora Project Contributors. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. For guidelines on the permitted uses of the Fedora trademarks, refer to https://fedoraproject.org/wiki/ Legal:Trademark_guidelines. Linux® is the registered trademark of Linus Torvalds in the United States and other countries. Java® is a registered trademark of Oracle and/or its affiliates. XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries. All other trademarks are the property of their respective owners.

Ontwerp

Ontwerp

Preface v 1. Document conventies ...................................................................................................... v 1.1. Typografische conventies ...................................................................................... v 1.2. Pull-quote conventies ........................................................................................... vi 1.3. Opmerkingen en waarschuwingen ........................................................................ vii 2. We hebben terugkoppeling nodig! .................................................................................. viii 1. Wat is UEFI Secure Boot? 1.1. UEFI Secure Boot ........................................................................................................ 1.2. Microsoft eisen voor Secure Boot .................................................................................. 1.2.1. Implementatie details ......................................................................................... 1.3. Fedora Secure Boot ..................................................................................................... 1.4. Waarvoor beschermt Secure Boot jou? .......................................................................... 1.5. Potentiële Secure Boot risico's ...................................................................................... 1.5.1. Geforceerde verwijdering van functies in Secure Boot modus ............................... 1.5.2. Systeem verlaat Secure Boot ............................................................................. 1.5.3. Geen infrastructuur anders dan Microsoft aanbieden ........................................... 1.5.4. Niet bewezen herroepingsprocedures .................................................................

1 1 2 2 6 6 7 7 7 8 8

2. System Configuration 9 2.1. Entering the UEFI firmware ........................................................................................... 9 2.2. Disabling UEFI Secure Boot ....................................................................................... 10 2.3. Enabling Microsoft Secure Boot .................................................................................. 12 2.4. Known issues ............................................................................................................. 14 3. UEFI Secure Boot implementatie 3.1. Sleutels ...................................................................................................................... 3.2. Shim .......................................................................................................................... 3.3. GRUB ........................................................................................................................ 3.4. Kernel ........................................................................................................................ 3.4.1. Beperkingen ....................................................................................................

15 15 17 18 18 18

4. Gereedschappen 4.1. Shim .......................................................................................................................... 4.2. Pesign ....................................................................................................................... 4.3. EFIKeyGen ................................................................................................................ 4.4. sign-file ......................................................................................................................

21 21 21 21 21

5. Je eigen sleutels gebruiken 5.1. Sleutels aanmaken ..................................................................................................... 5.2. Sleutels aanmaken voor het bouwen van shim ............................................................. 5.3. Pakketten die opnieuw gebouwd moeten worden ......................................................... 5.4. Je sleutels in firmware inschrijven ...............................................................................

23 23 23 23 23

A. Herzieningsgeschiedenis

25

Register

27

iii

iv

Ontwerp

Ontwerp

Preface 1. Document conventies Dit handboek hanteert verscheidene conventies om bepaalde woorden of zinsdelen te benadrukken en aandacht te vestigen op specifieke delen van informatie. 1

In PDF en papieren edities gebruikt dit handboek Liberation Fonts set lettertypes. Het Liberation lettertype wordt ook gebruikt in HTML edities als dit lettertype op jouw computer geïnstalleerd is. Als dat niet het geval is, worden alternatieve, gelijkwaardige lettertypes gebruikt. Opmerking: bij Red Hat Enterprise Linux 5 en later wordt de Liberation Font set standaard ingesteld.

1.1. Typografische conventies Vier typografische conventies worden gebruikt om aandacht te vestigen op specifieke woorden en zinsdelen. Deze conventies, en de omstandigheden waaronder zij gebruikt worden, luiden als volgt: Mono-spaced Bold Wordt gebruikt om systeem input, waaronder shell commando's, bestandsnamen en paden aan te geven. Wordt ook gebruikt bij toets aanduiding of toetsencombinaties. Bijvoorbeeld: Om de inhoud van het bestand mijn_onwijsgoed_verkopende_boek in jouw huidige map te bekijken, type je het commando cat mijn_onwijsgoed_verkopende_boek in op de shell prompt en druk je op Enter om het commando uit te voeren. Bovenstaande bevat een bestandsnaam, een shell commando en een toets aanduiding, alle getoond in mono-spaced bold en alle te onderscheiden dankzij hun context. Toetsencombinaties kunnen worden onderscheiden van toets aanduidingen door het plusteken dat elk deel van een toetsencombinatie aan elkaar verbind. Bijvoorbeeld: Druk op Enter om het commando uit te voeren. Druk op Ctrl+Alt+F2 om naar de eerste virtuele terminal over te schakelen. Druk op Ctrl+Alt+F1 om terug te keren naar jouw X-Windows sessie. De eerste paragraaf benadrukt de bepaalde toets die moet worden ingedrukt. De tweede benadrukt twee toets combinaties (ieder een reeks van drie toetsen, waarbij de toetsen van elke reeks tegelijk moeten worden ingedrukt). Als broncode wordt besproken, worden klasse namen, methodes, functies, variabele namen en resultaten die in een paragraaf worden genoemd, weergegeven als hier boven afgedrukt, namelijk in mono-spaced bold. Bijvoorbeeld: Onder bestand gerelateerde klassen vallen filesystem voor bestandssystemen, file voor bestanden, en dir voor mappen. Elke klasse heeft zijn eigen set van rechten. Proportional Bold

1

https://fedorahosted.org/liberation-fonts/

v

Preface

Ontwerp

Wordt gebruikt om woorden of zinsdelen op een systeem aan te duiden, waaronder toepassing namen, dialoogtekst boxen, gelabelde knoppen, checkbox en radio-knop labels, menu titels en submenu titels. Bijvoorbeeld: Kies Systeem�� Voorkeuren�� Muis in de hoofdmenu balk om Muisvoorkeuren te openen. In de Knoppen tab, klik je de Linkshandige muis checkbox aan en klik je Sluiten om de primaire muisknop van links naar rechts te wisselen (waardoor de muis beter geschikt is geworden voor linkshandig gebruik). Om een speciaal teken in een gedit bestand op te nemen, kies je Toepassingen �� Hulpmiddelen�� Tekens en symbolen in de hoofd menubalk. Vervolgens kies je Zoeken�� Zoeken… in de Tekens en symbolen menubalk, typ je de naam van het teken in het Zoek veld en klik je op Volgende. Het teken dat je zoekt zal worden gemarkeerd in de Tekentabel. Dubbel-klik op dit teken om het in het Te kopiëren tekst veld op te nemen en klik dan de Kopiëren knop. Keer nu terug naar jouw document en kies Bewerken �� Plakken in de gedit menubalk. De bovenstaande tekst bevat toepassing namen, systeem-brede menu namen en onderdelen, toepassing specifieke menu namen, en knoppen en tekst van een GUI interface, alle getoond in proportional bold en alle te onderscheiden dankzij hun context. Mono-spaced Bold Italic of Proportional Bold Italic Voor mono-spaced bold of proportional bold geeft cursief gedrukt altijd vervangbare of wisselende teksten aan. Cursief wijst op niet letterlijke tekst of toont tekst die wisselt naar omstandigheden. Bijvoorbeeld: Om verbinding te maken met een andere computer met behulp van ssh, typ je ssh [email protected] in op een shell prompt. Als de machine op afstand example.com is en jouw gebruikersnaam op die machine is jan, dan type je ssh [email protected]. Het mount -o remount bestandssysteem commando koppelt het genoemde bestandssysteem opnieuw aan. Om bijvoorbeeld het /home bestandsysteem opnieuw aan te koppelen, gebruik je het mount -o remount /home commando. Om de versie van een huidig geïnstalleerd pakket te zien, gebruik je het rpm -q pakket commando. Dit zal het volgende resultaat opleveren: pakket-versievrijgave . Let op de woorden in bold italics in bovenstaande tekst — gebruikersnaam, domein.naam, bestandssysteem, pakket, versie en vrijgave. Elk woord is een plaats reservering, hetzij voor tekst die je invult als je een commando intypt, hetzij voor tekst die door het systeem wordt getoond. Buiten het standaard gebruik bij het presenteren van een titel van een werk, wordt cursief ingezet om het eerste gebruik van een nieuwe en belangrijke term te benadrukken. Bijvoorbeeld: Publican is een DocBook publicatie systeem.

1.2. Pull-quote conventies Terminal output en broncode lijsten worden worden visueel gescheiden van de omringende tekst. Output gestuurd naar een terminal wordt getoond in mono-spaced roman en als volgt gepresenteerd: books books_tests

vi

Desktop Desktop1

documentation downloads

drafts images

mss notes

photos scripts

stuff svgs

svn

Ontwerp

Opmerkingen en waarschuwingen

Opsommingen van broncode worden ook getoond in mono-spaced roman maar worden als volgt gepresenteerd en benadrukt: package org.jboss.book.jca.ex1; import javax.naming.InitialContext; public class ExClient { public static void main(String args[]) throws Exception { InitialContext iniCtx = new InitialContext(); Object ref = iniCtx.lookup("EchoBean"); EchoHome home = (EchoHome) ref; Echo echo = home.create(); System.out.println("Created Echo"); System.out.println("Echo.echo('Hello') = " + echo.echo("Hello")); } }

1.3. Opmerkingen en waarschuwingen Tenslotte gebruiken we drie visuele stijlen om aandacht te vestigen op informatie die anders misschien over het hoofd zou worden gezien.

Opmerking Een opmerking is een tip, handigheidje of een alternatieve benadering voor de taak die uitgevoerd moet worden. Het negeren van een opmerking zou geen ernstige gevolgen moeten hebben, maar het leven kan een stuk makkelijker worden als de opmerking gevolgd wordt.

Belangrijk Belangrijk aanduidingen wijzen op zaken die makkelijk over het hoofd kunnen worden gezien: veranderingen van configuratie die alleen voor de huidige sessie gelden, of voorzieningen die herstart moeten worden om een bepaalde verandering in te laten gaan. Het negeren van zaken met deze aanduiding heeft geen data verlies tot gevolg, maar kan leiden tot irritatie en frustratie.

Waarschuwing Een waarschuwing dient niet genegeerd te worden. Waarschuwingen negeren zal ongetwijfeld leiden tot data verlies.

vii

Preface

Ontwerp

2. We hebben terugkoppeling nodig! Als je een typografische fout in deze handleiding vindt, of je weet een manier om deze handleiding te verbeteren, zouden wij dat graag van jou horen! Meldt fouten in de uitgave Fedora via Bugzilla: http:// bugzilla.redhat.com/bugzilla/. Als je fouten meldt, vergeet dan alstublieft niet het kenmerk: UEFI_Secure_Boot_Guide te vermelden. Als je suggesties hebt om de documentatie te verbeteren, probeer dan zo duidelijk mogelijk deze suggesties te omschrijven. Als je fouten hebt ontdekt, vermeldt dan het sectie nummer en wat omringende tekst, zodat we de fout gemakkelijker kunnen vinden.

viii

Ontwerp

Ontwerp

Wat is UEFI Secure Boot? Secure Boot is een technologie waarbij de systeem firmware controleert of de systeem bootlader is ondertekend net een cryptografische sleutel die geautoriseerd wordt door een database in de firmware. Met voldoende ondertekeningsverificatie in de next-stage bootloder(s), kernel en potentieel, gebruikersruimte, is het mogelijk om het uitvoeren van niet ondertekende code te voorkomen. Secure Boot lijkt op Verified Booting. Bootpad validatie is ook onderdeel van andere technologieën zoals Trusted Boot. Bootpad validatie is onafhankelijk van beveiligde opslag van cryptografische sleutels en attestering op afstand.

1.1. UEFI Secure Boot UEFI Secure Boot is het bootpad validatie onderdeel van de UEFI specificatie (Unified Extensible Firmware Interface) sinds versie 2.3. Het specificeert ruwweg het volgende: • een programmeringsinterface voor cryptografisch beschermde UEFI variabelen in niet-vluchtige opslag, • hoe de vertrouwde X.509 root certificaten opgeslagen worden in UEFI variabelen, • validatie van UEFI toepassingen (bootladers en drivers) met gebruik van AuthentiCode ondertekeningen die in deze toepassingen zijn opgenomen, en • procedures voor het herroepen van bekende slechte certificaten en toepassing hashes. UEFI Secure Boot vereist geen speciale hardware, afgezien van niet-vluchtige (flash) opslag welke omgeschakeld kan worden van de lezen-schrijven modus naar alleen-lezen modus tijdens de systeem opstart. Deze opslag moet gebruikt worden voor het opslaan van de UEFI implementatie zelf en enkele van de beschermde UEFI variabelen (inclusief de vertrouwde root certificaat opslag). Vanuit het oogpunt van een gebruiker zal een systeem, waarvoor UEFI Secure Boot aangezet is en die geconfronteerd wordt met een bootpad waarmee geknoeid is, gewoon stoppen met werken totdat UEFI Secure Boot uitgezet wordt of als een ondertekende next-stage bootlader op boot media beschikbaar is. (Afbeelding 1.1, “Een typische foutboodschap van UEFI Secure Boot” toont een typische foutboodschap.) Op dezelfde manier draaien besturingssysteeminstallatieprogramma's zonder een cryptografisch geldige ondertekening niet en resulteren in een foutmelding. Gebruikers krijgen geen manier aangeboden voor het negeren van de beslissing van de bootlader om de ondertekening af te wijzen, dit in tegenstelling tot een vergelijkbaar scenario voor webserver certificaten. De gebruiker krijgt geen informatie van de certificaataanbieder aangeboden.

┌────────── Secure Boot Violation ──────────┐ │ │ ├───────────────────────────────────────────┤ │ Invalid signature detected. Check Secure │ │ Boot Policy in Setup │ │ │ │ │ │ [OK] │ └───────────────────────────────────────────┘

Afbeelding 1.1. Een typische foutboodschap van UEFI Secure Boot UEFI Secure Boot belet niet de installatie of verwijdering van second-stage bootladers of vereist geen expliciete gebruikersbevestiging van zulke veranderingen. Ondertekeningen worden geverifieerd 1

Hoofdstuk 1. Wat is UEFI Secure Boot?

Ontwerp

tijdens het opstarten, niet bij het installeren of vernieuwen van de bootlader. Daarom voorkomt UEFI Secure Boot bootpad manipulaties niet. Het voorkomt dat het systeem een gewijzigd bootpad uitvoert als zo'n verandering aangebracht is en vereenvoudigt de ontdekking hiervan.

Cliënt technologie UEFI Secure Boot is op dit moment in het algemeen alleen ingeschakeld op cliënt apparaten en wordt op dit moment niet aanbevolen voor server machines. Het is de verwachting dat server technologie in de toekomst Secure Boot mogelijk zal maken.

1.2. Microsoft eisen voor Secure Boot Microsoft heeft niet veel details gepubliceerd over hun implementatie van Secure Boot, welke op UEFI Secure Boot gebaseerd is. Microsoft ondersteunt UEFI Secure Boot alleen met Windows 8, maar het is niet vereist voor het draaien van Windows 8. Systemen in een UEFI Secure Boot omgeving zullen nog steeds opstarten als Secure Boot ondersteuning uit de UEFI omgeving verwijderd wordt. Gebruikers die vorige versies van Windows willen gebruiken moeten Secure Boot uitzetten omdat Microsoft voor deze geen ondertekende bootladers aanbiedt. Gebaseerd op verkrijgbare gegevens lijken de volgende beveiligingsdoelstellingen voor Microsoft Secure Boot waarschijnlijk: • integriteitsbescherming van installatiemedia welke opgeslagen is op beschrijfbare media (zoals harde schijf herstelpartities), • Bescherming van het bootpad totdat heuristische tegenmaatregelen (zoals kernel modus anti-virus software) tijden het vroege opstarten geladen kan worden, en • automatisch herstellen van het originele bootpad, bijvoorbeeld nadat het systeem aangetast is door malware, zonder een complete herinstallatie van het gehele besturingssysteem. Het is niet duidelijk of er plannen zijn om toegang naar bepaalde (online) inhoud te beperken voor systemen waarvoor UEFI Secure Boot aangezet is en waarvan het bootpad cryptografisch geldig is. Dit zou een attestering op afstand aspect impliceren welke geen onderdeel is van de UEFI Secure Boot specificatie en die zonder extra hardware ondersteuning niet beveilig geïmplementeerd kan worden. Dit zou ook impliceren dat UEFI Secure Boot niet meer echt optioneel is. Er is geen bewijs dat Microsoft met hun implementatie van Secure Boot iemand probeert uit te sluiten. Het automatisch herstellen van het originele bootpad is echter veel gecompliceerder zodra andere bootlader op hetzelfde systeem aanwezig zijn.

1.2.1. Implementatie details Microsoft vereist dat cliënt PC's die het Windows 8 logo dragen UEFI Secure Boot ingeschakeld moeten hebben en door Microsoft aangeboden sleutels geïnstalleerd hebben. Het vereiste X.509 certificaat wordt getoond in Afbeelding 1.2, “Microsoft Trusted X.509 Certificaat voor hun Secure Boot implementatie”. Systeemleveranciers worden aangemoedigd om andere benodigde root certificaten op te nemen, maar de aanwezigheid hiervan is niet vereist.

2

Ontwerp

Implementatie details

Certificate: Data: Version: 3 (0x2) Serial Number: 61:07:76:56:00:00:00:00:00:08 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010 Validity Not Before: Oct 19 18:41:42 2011 GMT Not After : Oct 19 18:51:42 2026 GMT Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:dd:0c:bb:a2:e4:2e:09:e3:e7:c5:f7:96:69:bc: […] 87:65:b4:43:18:a8:b2:e0:6d:19:77:ec:5a:24:fa: 48:03 Exponent: 65537 (0x10001) X509v3 extensions: 1.3.6.1.4.1.311.21.1: 02:01:00 X509v3 Subject Key Identifier: A9:29:02:39:8E:16:C4:97:78:CD:90:F9:9E:4F:9A:E1:7C:55:AF:53 1.3.6.1.4.1.311.20.2: 1E:0A:00:53:00:75:00:62:00:43:00:41 X509v3 Key Usage: Digital Signature, Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE X509v3 Authority Key Identifier: keyid:D5:F6:56:CB:8F:E8:A2:5C:62:68:D1:3D:94:90:5B:D7:CE:9A:18:C4 X509v3 CRL Distribution Points: Full Name: URI:http://crl.microsoft.com/pki/crl/products/MicRooCerAut_2010-06-23.crl Authority Information Access: CA Issuers - URI:http://www.microsoft.com/pki/certs/ MicRooCerAut_2010-06-23.crt Signature Algorithm: sha256WithRSAEncryption 14:fc:7c:71:51:a5:79:c2:6e:b2:ef:39:3e:bc:3c:52:0f:6e: […] 04:cf:77:a4:62:1c:59:7e -----BEGIN CERTIFICATE----MIIF1zCCA7+gAwIBAgIKYQd2VgAAAAAACDANBgkqhkiG9w0BAQsFADCBiDELMAkG A1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQx HjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEyMDAGA1UEAxMpTWljcm9z b2Z0IFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IDIwMTAwHhcNMTExMDE5MTg0 MTQyWhcNMjYxMDE5MTg1MTQyWjCBhDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldh c2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBD b3Jwb3JhdGlvbjEuMCwGA1UEAxMlTWljcm9zb2Z0IFdpbmRvd3MgUHJvZHVjdGlv biBQQ0EgMjAxMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN0Mu6Lk Lgnj58X3lmm8ACG9aTMz760Ey1SA7gaDu8UghNn30ovzOLCrpK0tfGJ5Bf/jSj8E NSBw48Tna+CcwDZ16Yox3Y1w5dw3tXRGlihbh2AjLL/cR6Vn91EnnnLrB6bJuR47 UzV85dPsJ7mHHP65ySMJb6hGkcFuljxB08ujP10Cak3saR8lKFw2//1DFQqU4Bm0 z9/CEuLCWyfuJ3gwi1sqCWsiiVNgFizAaB1TuuxJ851hjIVoCXNEXX2iVCvdefcV zzVdbBwrXM68nCOLb261Jtk2E8NP1ieuuTI7QZIs4cfNd+iqVE73XAsEh2W0Qxio suBtGXfsWiT6SAMCAwEAAaOCAUMwggE/MBAGCSsGAQQBgjcVAQQDAgEAMB0GA1Ud Afbeelding 1.2. Microsoft Trusted X.509 Certificaat voor hun Secure Boot DgQWBBSpKQI5jhbEl3jNkPmeT5rhfFWvUzAZBgkrBgEEAYI3FAIEDB4KAFMAdQBi AEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBTV 9lbLj+iiXGJo0T2UkFvXzpoYxDBWBgNVHR8ETzBNMEugSaBHhkVodHRwOi8vY3Js Lm1pY3Jvc29mdC5jb20vcGtpL2NybC9wcm9kdWN0cy9NaWNSb29DZXJBdXRfMjAx MC0wNi0yMy5jcmwwWgYIKwYBBQUHAQEETjBMMEoGCCsGAQUFBzAChj5odHRwOi8v d3d3Lm1pY3Jvc29mdC5jb20vcGtpL2NlcnRzL01pY1Jvb0NlckF1dF8yMDEwLTA2 LTIzLmNydDANBgkqhkiG9w0BAQsFAAOCAgEAFPx8cVGlecJusu85Prw8Ug9uKz8Q

implementatie 3


Ontwerp

Er wordt verwacht dat Microsoft eventueel ondertekende intrekkingsverzoeken zal versturen in Windows Update. Deze verzoeken worden in de UEFI Secure Boot configuratievariabelen geïnstalleerd tijden de volgende systeem opstart, nadat ze gevalideerd zijn met de Microsoft sleutel. OP het moment van dit schrijven bestaat er nog geen blacklist. Bootladers van derden hebben op dit moment geen toegang tot het Microsoft Windows Production PCA 2011 certificaat dat Microsoft voor zijn eigen producten gebruikt. In plaats daarvan biedt Microsoft een ondertekeningsservice die origineel voor UEFI drivers bedoeld is. Deze service is uitgebreid om ook bootladers van derden te bevatten. Microsoft beoordeelt de ingezonden UEFI toepassingen, biedt een AuthentiCode ondertekening aan met gebruik van zijn eigen sleutel en stuurt het resultaat terug naar de indiener. Deze ondertekening identificeert de schrijver van de toepassing niet (het is pseudo anoniem) en, veel belangrijker, het wordt gekoppeld via het tussenliggende certificaat Microsoft Corporation UEFI CA 2011 (see Afbeelding 1.3, “Microsoft X.509 certificaat voor UEFI toepassingen van derden”) aan het Microsoft Corporation Third Party Marketplace Root root certificaat.

Waarschuwing Er wordt niet gegarandeerd dat UEFI bootladers van derden op Microsoft Secure Boot systemen werken omdat de benodigde certificaten geen onderdeel zijn van de Microsoft Secure Boot specificatie.

4

Ontwerp

Implementatie details

Certificate: Data: Version: 3 (0x2) Serial Number: 61:08:d3:c4:00:00:00:00:00:04 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root Validity Not Before: Jun 27 21:22:45 2011 GMT Not After : Jun 27 21:32:45 2026 GMT Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:a5:08:6c:4c:c7:45:09:6a:4b:0c:a4:c0:87:7f: 06:75:0c:43:01:54:64:e0:16:7f:07:ed:92:7d:0b: b2:73:bf:0c:0a:c6:4a:45:61:a0:c5:16:2d:96:d3: f5:2b:a0:fb:4d:49:9b:41:80:90:3c:b9:54:fd:e6: bc:d1:9d:c4:a4:18:8a:7f:41:8a:5c:59:83:68:32: bb:8c:47:c9:ee:71:bc:21:4f:9a:8a:7c:ff:44:3f: 8d:8f:32:b2:26:48:ae:75:b5:ee:c9:4c:1e:4a:19: 7e:e4:82:9a:1d:78:77:4d:0c:b0:bd:f6:0f:d3:16: d3:bc:fa:2b:a5:51:38:5d:f5:fb:ba:db:78:02:db: ff:ec:0a:1b:96:d5:83:b8:19:13:e9:b6:c0:7b:40: 7b:e1:1f:28:27:c9:fa:ef:56:5e:1c:e6:7e:94:7e: c0:f0:44:b2:79:39:e5:da:b2:62:8b:4d:bf:38:70: e2:68:24:14:c9:33:a4:08:37:d5:58:69:5e:d3:7c: ed:c1:04:53:08:e7:4e:b0:2a:87:63:08:61:6f:63: 15:59:ea:b2:2b:79:d7:0c:61:67:8a:5b:fd:5e:ad: 87:7f:ba:86:67:4f:71:58:12:22:04:22:22:ce:8b: ef:54:71:00:ce:50:35:58:76:95:08:ee:6a:b1:a2: 01:d5 Exponent: 65537 (0x10001) X509v3 extensions: 1.3.6.1.4.1.311.21.1: 02:03:01:00:01 1.3.6.1.4.1.311.21.2: 04:14:F8:C1:6B:B7:7F:77:53:4A:F3:25:37:1D:4E:A1:26:7B:0F:20:70:80 X509v3 Subject Key Identifier: 13:AD:BF:43:09:BD:82:70:9C:8C:D5:4F:31:6E:D5:22:98:8A:1B:D4 1.3.6.1.4.1.311.20.2: 1E:0A:00:53:00:75:00:62:00:43:00:41 X509v3 Key Usage: Digital Signature, Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE X509v3 Authority Key Identifier: keyid:45:66:52:43:E1:7E:58:11:BF:D6:4E:9E:23:55:08:3B:3A:22:6A:A8 X509v3 CRL Distribution Points: Full Name: URI:http://crl.microsoft.com/pki/crl/products/ MicCorThiParMarRoo_2010-10-05.crl Authority Information Access: CA Issuers - URI:http://www.microsoft.com/pki/certs/ MicCorThiParMarRoo_2010-10-05.crt Signature Algorithm: sha256WithRSAEncryption 35:08:42:ff:30:cc:ce:f7:76:0c:ad:10:68:58:35:29:46:32: […] Afbeelding 1.3. Microsoft X.509 certificaat voor UEFI toepassingen van 92:9b:f5:a6:bc:59:83:58 -----BEGIN CERTIFICATE----MIIGEDCCA/igAwIBAgIKYQjTxAAAAAAABDANBgkqhkiG9w0BAQsFADCBkTELMAkG A1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQx HjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjE7MDkGA1UEAxMyTWljcm9z b2Z0IENvcnBvcmF0aW9uIFRoaXJkIFBhcnR5IE1hcmtldHBsYWNlIFJvb3QwHhcN

derden 5


Ontwerp

Een regulier code ondertekeningscertificaat is niet voldoende om opstarten op een Microsoft Secure Boot systeem te garanderen. Microsoft vereist een code ondertekeningscertificaat bij het communiceren met UEFI toepassingsschrijvers, maar dat is een intern detail dat voor eindgebruikers op geen enkele wijze zichtbaar is. In opgestarte besturingssysteem ondersteunt Microsoft Windows 8 AuthentiCode validatie en het laden van ondertekende kernel modules van derden. Windows heeft infrastructuur om cryptografische validatie uit te breiden naar gebruikersruimte programma's, opnieuw gebaseerd op AuthentiCode.

1.3. Fedora Secure Boot De Fedora Secure Boot implementatie heeft een enkele beveiligingsdoelstelling: het belet het uitvoeren van niet ondertekende code in de kernel modus. Fedora kan opstarten op systemen waarvoor Microsoft Secure Boot aangezet is, aangenomen dat het Microsoft certificaat voor UEFI toepassingen van derden geïnstalleerd is. Deze werkmodus is het belangrijkst voor het installeren van Fedora op machines die voorbereid zijn voor Windows 8. Andere hardware zal zelden een Microsoft Secure Boot omgeving aanbieden.

Waarschuwing Er wordt niet gegarandeerd dat UEFI bootladers van derden (zoals de Fedora bootlader) werken op Microsoft Secure Boot systemen omdat de benodigde certificaten geen onderdeel zijn van de Windows 8 Hardware Certification Requirements. Als jouw hardware in deze categorie valt, moet je UEFI Secure Boot uitzetten, het ontbrekende Microsoft certificaat inschrijven, of het Fedora certificaat inschrijven. Fedora start ook op bij UEFI systemen die Secure Boot niet ondersteunen of dit uitgezet hebben. Dit werkt met alle UEFI bootladers. Deze bootladers draaien ook in een omgeving welke bootpad validatie uitvoert op andere (niet-UEFI) manieren. In deze modus zijn er geen beperkingen voor het uitvoeren van code in de kernel modus. Details van de Fedora Secure Boot implementatie worden behandeld in Hoofdstuk 3, UEFI Secure Boot implementatie. Restricties op kernel modus code uitvoering beperkt bepaalde functionaliteit, zie Paragraaf 3.4.1, “Beperkingen”.

1.4. Waarvoor beschermt Secure Boot jou? Op het meest fundamentele niveau belet UEFI Secure Boot het draaien van niet-ondertekende bootladers. Het effect van het draaien van de bootlader hangt vanzelfsprekend van die bootlader af. Het volgende refereert naar de Fedora implementatie van Secure Boot. De Microsoft implementatie is anders, zie Paragraaf 1.2, “Microsoft eisen voor Secure Boot”. Fedora heeft de vertrouwensketen uitgebreid van de UEFI omgeving naar de kernel. Verificatie gebeurt voor het laden van kernel modules, maar het wordt niet uitgebreid naar gebruikersruimte toepassingen. We kunnen er zeker van zijn dat er geen ongetekende uitvoerbare code aanwezig is totdat de initiële ramdisk (initrd) geladen wordt. Omdat de initrd inhoud niet cryptografisch ondertekend is en uitvoerbare code bevat, kan het opstarten van een ondertekende Fedora bootlader eventueel tot willekeurige effecten leiden. De Fedora Secure Boot implementatie vereenvoudigt verificatie van het bootpad in digitale forensics. Het vroegere BIOS opstarten voert in een zeer vroeg stadium potentieel gevaarlijke code uit vanaf

6

Ontwerp

Potentiële Secure Boot risico's

de schijf, wat het erg moeilijk maakt om er zeker van te zijn dat er niet op een laag niveau met het besturingssysteem geknoeid is. (Deze voordelen komen gedeeltelijk door de meer uitgebreide beschrijvingswijze van de UEFI boot configuratie op schijf.)

1.5. Potentiële Secure Boot risico's Secure Boot zal je PC niet beschermen tegen malware of aanvallers. Secure Boot beschermt alleen de opstartfase van een systeem, maar beschermt niet tegen aanvallen op je draaiende systeem of data. Als je in Fedora Secure Boot gebruikt , kan dat beperken welke modules de kernel laadt, maar dit geeft geen extra bescherming tegen gebruikersruimte malware. De initiële ramdisk (initrd) schijfimage die gebruikt wordt tijdens het opstarten is niet ondertekend en kan verdachte code bevatten.

1.5.1. Geforceerde verwijdering van functies in Secure Boot modus We gebruiken op dit moment een zwarte lijst aanpak voor het uitschakelen bekende onveilige kernel functionaliteit. In sommige gevallen is specifieke functionaliteit uitgeschakeld. In de meeste gevallen is deze functionaliteit obscuur en wordt zelden gebruikt. Op dit moment bevat de lijst van beperkte functionaliteit het volgende: • verandering van apparaat geheugenadres mappen met "setpci", en het schrijven naar dat geheugen vanuit de gebruikersruimte met sysfs • slaapstand (ook bekend als onderbreken naar schijf) • kexec en kdump (het aanpakken hiervan is nog in uitvoering) • schrijven naar Machine Specific Registers schrijft via de "msr" kernel module. • de acpi_rspd commandoregel optie, die gebruikt wordt voor het specificeren van aangepaste ACPI data • io bewerkingen op /dev/kmem Daarnaast wordt het gebruik van systemtap modules beperkt tot de modules die onderkend zijn met een juist certificaat. Het wordt aanbevolen dat zo'n certificaat on-site aangemaakt wordt, met inachtneming van het opvolgen van de juiste beveiligingspraktijken voor opslag en gebruik ban een ondertekeningscertificaat. Als een site-lokaal certificaat gebruikt wordt, kan het in de lokale database van de machine ingeschreven worden met het mokutil hulpprogramma, waarna een herstart nodig is om effect te krijgen. Na opnieuw opstarten, zal shim MokManager opstarten om je een interface te tonen waarmee je het certificaat kunt inschrijven.

Waarschuwing Het is van cruciaal belang dat juiste voorzorgsmaatregelen genomen worden bij het gebruik van site-lokale certificaten, zodat ze niet gevonden en gebruikt kunnen worden door een aanvaller om modulebeveiliging te ondermijnen. Behandel zulke certificaten zoals je met kritieke geheimen zou doen en volg de beste industriepraktijken op voor cryptografische sleutels en certificaten.

1.5.2. Systeem verlaat Secure Boot Een BIOS upgrade of moederbord vervanging kan Secure Boot uitzetten op systemen waar het eerst ingeschakeld was. Extra hardware die geïnstalleerd wordt in een machine kan vereisten hebben die

7


Ontwerp

niet compatibel zijn met Secure Boot (gebruikersruimte DMA, SystemTap ondersteuning, niet-Red Hat kernel modules). Dit betekent dat Secure Boot geen vereiste kan zijn voor systeemfunctionaliteit en het is niet verstandig om het onderdeel te maken van een beleidsvereiste.

1.5.3. Geen infrastructuur anders dan Microsoft aanbieden Sommige systeemleveranciers vereisen een Windows 8 installatie om Secure Boot te activeren. Gebruikers die Secure Boot willen aanzetten moeten misschien een Windows 8 cliënt licentie verkrijgen die aangepast wordt door de systeemleverancier. Dit scenario zou niet relevant zijn als Red Hat rekent op een aparte vertrouwde root onder onze controle, aangeboden in samenwerking met hardwareleveranciers.

1.5.4. Niet bewezen herroepingsprocedures We weten niet of de processen rond het herroepen echt werken. Herroepen is complex omdat dit gesynchroniseerd moet worden met besturingssysteemleveranciers om dual-boot configuraties te ondersteunen. Zonder een dergelijke synchronisatie kan een ondertekening van een bootpad herroepen worden voordat het betreffende besturingssysteem een kans heeft gehad om het te updaten. Dit maakt systemen niet opstartbaar. Het is niet duidelijk onder welke omstandigheden Microsoft een ongevraagde herroeping zal uitvoeren. Potentiële herroeping redenen zijn een mislukking om een beveiligingsdoel te bereiken (dat betekend dat het uitvoeren van niet ondertekende code in de kernel modus mogelijk is in lab condities), of actuele uitbuiting van zo'n mislukking voor het aanvallen van het bootpad van Windows 8 systemen buiten laboratoria. Het laatste kan ook van toepassing zijn op Secure Boot tijdelijke oplossingen die niet getekende code laden na gebruikersinteractie.

8

Ontwerp

Ontwerp

System Configuration This chapter describes how to configure systems for use with UEFI Secure Boot. The required steps vary from system to system because they depend on how the firmware implements the UEFI specification, but the descriptions should give you an idea where to look.

System can become unbootable If the operating systems installed on your machine do not provide UEFI boot loaders, or if those boot loaders are not accepted by the new Secure Boot configuration because the signatures are not recognized, your system will no longer boot after switching on Secure Boot.

2.1. Entering the UEFI firmware When the system is booting, try pressing the Enter, Del, F1 or Esc keys. Usually, instructions will appear telling you how to enter the firmware, similar to Afbeelding 2.1, “Firmware activation instructions” (which still refers to the UEFI firmware as BIOS Setup Utility, so you are expected to press F1).

┌───────────────────────────────────────────────────────────┐ │ Startup Interrupt Menu │ │───────────────────────────────────────────────────────────│ │ Press one of the following keys to continue: │ │ │ │ ESC to resume normal startup │ │ F1 to enter the BIOS Setup Utility │ │ F12 to choose a temporary startup device │ │ │ │ Press ENTER to continue │ │ │ └─────────────────────────────9─────────────────────────────┘

Afbeelding 2.1. Firmware activation instructions You may want to insert a USB stick to prevent a full operating system from booting, so that you can reboot more quickly and try out different keys faster. If the firmware is protected by a password and you do not know this password, you need to check your system or mainboard manual for password reset instructions. Once you have entered the firmware, a screen similar to Afbeelding 2.2, “UEFI firmware start screen” will be shown.

9

Hoofdstuk 2. System Configuration

Ontwerp

Lenovo BIOS Setup Utility Main Devices Advanced Power Security Startup Exit ┌────────────────────────────────────────────────────────────────────────────────────────┐ │ │ │► System Summary │ │► System Time & Date │ │ │ │ Machine Type and Model 0896A9G │ │ System Brand ID Lenovo Product │ │ System Serial Number RUYWEQZ │ │ Asset Tag INVALID │ │ System UUID 1846F489-64F1-4714-83D8-A02FD2C79AD1 │ │ Ethernet MAC address D5-3D-7E-60-29-2C │ │ BIOS Revision Level F1KT44AUS │ │ Boot Block Revision Level F144A │ │ BIOS Date (MM/DD/YY) 12/21/2012 │ │ License Status │ │ Language [English] │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └────────────────────────────────────────────────────────────────────────────────────────┘ F1 Help ↑↓ Select Item +/Change Values F9 Setup Defaults ESC Exit ←→ Select Menu Enter Select►Sub-Menu F10 Save and Exit

Afbeelding 2.2. UEFI firmware start screen

2.2. Disabling UEFI Secure Boot Systems which come with Microsoft Windows 8 pre-installed typically have enabled UEFI Secure Boot, and ship the Microsoft keys in the firmware. The Lenovo desktop system we use as an example makes disabling Secure Boot fairly straightforward. First, enter the firmware as described in Paragraaf 2.1, “Entering the UEFI firmware”. Press the → key until you reach the Security tab, as shown in Afbeelding 2.3, “UEFI firmware Security tab”.

10

Ontwerp

Disabling UEFI Secure Boot

Lenovo BIOS Setup Utility Main Devices Advanced Power Security Startup Exit ┌────────────────────────────────────────────────────────┬───────────────────────────────┐ │ │ Help Message │ │ Hardware Password Manager [Enabled] │───────────────────────────────│ │ Secure Boot Status [Enabled] │Select whether to enable or │ │ │disable Secure Boot │ │ Adminstrator Password Not Installed │[Enabled] Enable Secure │ │ Power-On Password Not Installed │Boot,BIOS will prevent │ │ │un-authorised OS be loaded. │ │ Set Administrator Password Enter │[Disable] Disables Secure │ │ Set Power-On Password Enter │Boot. │ │ │ │ │ Allow Flashing BIOS to a Previous [Yes] │ │ │ Version │ │ │ │ │ │ Require Admin. Pass. when Flashing [No] │ │ │ Require POP on Restart [No] │ │ │ │ │ │► Fingerprint Setup │ │ │► Hard Disk Password │ │ │► System Event Log │ │ │► Secure Boot │ │ │ │ │ │ Configuration Change Detection [Disabled] │ │ │ │ │ └────────────────────────────────────────────────────────┴───────────────────────────────┘ F1 Help ↑↓ Select Item +/Change Values F9 Setup Defaults ESC Exit ←→ Select Menu Enter Select►Sub-Menu F10 Save and Exit

Afbeelding 2.3. UEFI firmware Security tab Press ↓ until you reach the Secure Boot item and hit Enter. The Image Execution Policy screen appears (Afbeelding 2.4, “UEFI firmware Secure Boot settings”).

11


Ontwerp

Lenovo BIOS Setup Utility Main Devices Advanced Power Security Startup Exit ┌────────────────────────────────────────────────────────┬───────────────────────────────┐ │ Image Execution Policy │ Help Message │ │────────────────────────────────────────────────────────│───────────────────────────────│ │ Secure Boot Status User Mode │Select whether to enable or │ │ Secure Boot [Enabled] │disable Secure Boot │ │ │[Enabled] Enable Secure │ │ Reset to Setup Mode │Boot,BIOS will prevent │ │ │un-authorised OS be loaded. │ │ │[Disable] Disables Secure │ │ │Boot. │ │ │ │ │ │ . │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └────────────────────────────────────────────────────────┴───────────────────────────────┘ F1 Help ↑↓ Select Item +/Change Values F9 Setup Defaults ESC Exit ←→ Select Menu Enter Select►Sub-Menu F10 Save and Exit

Afbeelding 2.4. UEFI firmware Secure Boot settings Make sure that Secure Boot is selected, and press Enter, hit ↑ to choose Disabled, and press Enter again. The previous step only disables verification of cryptographic signatures, it does not remove some restrictions Microsoft imposes on firmware settings. If you want to boot non-UEFI operating systems, it is necessary to disable the OS Optimized Defaults.

2.3. Enabling Microsoft Secure Boot Systems which do not ship with Microsoft Windows 8 typically do not enable UEFI Secure Boot (or its Microsoft variant). However, many of these systems still contain the Microsoft keys in the firmware, and enabling Microsoft Secure Boot is relatively straightforward. For example, on a Lenovo desktop system, you need to enter the firmware as described in Paragraaf 2.1, “Entering the UEFI firmware”. Then press the → key until you reach the Exit tab, as shown in Afbeelding 2.5, “UEFI firmware Exit tab”.

12

Ontwerp

Enabling Microsoft Secure Boot

Lenovo BIOS Setup Utility Main Devices Advanced Power Security Startup Exit ┌────────────────────────────────────────────────────────┬───────────────────────────────┐ │ │ Help Message │ │ Save Changes and Exit │───────────────────────────────│ │ Discard Changes and Exit │Some settings below are │ │ │changed accordingly. Select │ │ Load Optimal Defaults │"Enabled" to meet Microsoft(R) │ │ OS Optimized Defaults [Disabled] │Windows 8 (R) Certification │ │ │Requirement. │ │ │Affected settings are CSM │ │ │Support, Boot mode, Boot │ │ │Priority, Secure Boot, Secure │ │ │RollBack Prevention. │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └────────────────────────────────────────────────────────┴───────────────────────────────┘ F1 Help ↑↓ Select Item +/Change Values F9 Setup Defaults ESC Exit ←→ Select Menu Enter Select►Sub-Menu F10 Save and Exit

Afbeelding 2.5. UEFI firmware Exit tab Press ↓ to select the OS Optimized Defaults entry. Press Enter to change the settings. A confirmation dialog will appear, and need to choose Yes. (See Afbeelding 2.6, “UEFI firmware confirmation for OS Optimized Defaults”).

13


Ontwerp

Lenovo BIOS Setup Utility Main Devices Advanced Power Security Startup Exit ┌────────────────────────────────────────────────────────┬───────────────────────────────┐ │ │ Help Message │ │ Save Changes and Exit │───────────────────────────────│ │ Discard Changes and Exit │Some settings below are │ │ │changed accordingly. Select │ │ Load Optimal Defaults │"Enabled" to meet Microsoft(R) │ │ OS Optimized Defaults ┌───────────────────────────────────────────┐Certification │ │ │ Attention! │ │ │ ├───────────────────────────────────────────┤ngs are CSM │ │ │ If OS Optimized Defaults is changed to │mode, Boot │ │ │ Enable, some settings including Secure │re Boot, Secure │ │ │ Boot,CSM,IPV4 and IPV6 will be changed. │ntion. │ │ │ Do you really want to continue? │ │ │ │ Select Yes to continue to Enable the OS │ │ │ │ Optimized Defaults. │ │ │ │ Select No to discontinue the operation. │ │ │ │ │ │ │ │ │ │ │ │ [Yes] [No] │ │ │ └───────────────────────────────────────────┘ │ │ │ │ │ │ │ │ │ │ │ │ │ └────────────────────────────────────────────────────────┴───────────────────────────────┘ F1 Help ↑↓ Select Item +/Change Values F9 Setup Defaults ESC Exit ←→ Select Menu Enter Select►Sub-Menu F10 Save and Exit

Afbeelding 2.6. UEFI firmware confirmation for OS Optimized Defaults Afterwards, check that OS Optimized Defaults has changed to Enabled. Press ← several times until you reach the Security tab (Afbeelding 2.3, “UEFI firmware Security tab”), press ↓ to select Secure Boot, hit Enter, and check that Secure Boot is enabled, as in Afbeelding 2.4, “UEFI firmware Secure Boot settings”. Return to the Exit tab, choose Save Changes and Exit, and press Enter. Confirm saving the settings, and reboot. Microsoft Secure Boot is now enabled.

2.4. Known issues When Fedora is installed on an UEFI system, existing boot loaders (for example, the code found in the Master Boot Record) are not overwritten. Therefore, Fedora has considerably less control over the boot process. In some cases, systems cannot dual-boot between Fedora and other operating systems. Even if Fedora is selected manually in the firmware boot loader selection dialog (choose a temporary startup device in Afbeelding 2.1, “Firmware activation instructions”), the other operating system is started. This is not a problem with UEFI Secure Boot; on the affected systems, it also happens with Secure Boot disabled. UEFI Secure Boot (and its Microsoft variant) require secure firmware updates. Typically, this is implemented by writing a signed update to a staging area, where the firmware picks it up during the next boot, verifies it, and then proceeds to overwrite the actual firmware. However, this process is still far from foolproof and firmware updates still can make devices unusable, requiring a firmware replacement.

14

Ontwerp

Ontwerp

UEFI Secure Boot implementatie De Fedora Secure Boot implementatie bevat ondersteuning voor twee opstartmethodes met het Secure Boot mechanisme. De eerste methode gebruikt de ondertekenservice gehost door Microsoft om een kopie van de shim bootlader te bieden die ondertekend is met de Microsoft sleutels. De tweede methode is een meer algemene vorm van de eerste, hierbij kan een site of een gebruiker zijn eigen sleutels aanmaken, ze inzetten in systeemsoftware en zijn eigen binaire programma's ondertekenen.

3.1. Sleutels De oplossing om de Microsoft ondertekenservice te gebruiken blinkt uit ddor zijn eenvoud. De sleutel die Microsoft gebruikt wordt geleverd bij alle bekende hardware, met als resultaat dat Fedora in staat is om op deze hardware zonder problemen op te starten. Er zijn natuurlijk risico's verbonden aan het afhankelijk zijn van derden voor deze service. Fedora Project heeft zich verplicht om de ontwikkelingen op dit gebied te blijven volgen en zal bij nieuw binnenkomende informatie gepast reageren. Het gebruik van de sleutel in de Fedora implementatie kan verwarrend overkomen door zijn complexiteit. Hierna volgt hoe de verschillende onderdelen ondertekend zijn. Shim: Deze wordt ondertekend door de UEFI ondertekenservice. Over deze sleutel hebben we geen controle. De shim bevat de Fedora Boot CA publieke sleutel. GRUB: Deze wordt ondertekend met de "Fedora Boot Signer" sleutel, welke uit de Fedora Boot CA sleutel volgt. GRUB bevat geen sleutels, het roept shim aan voor zijn verificatie. Kernel: Deze wordt ook ondertekend door de Fedora Boot Signer. De kernel bevat die publieke sleutel die gebruikt wordt om kernel modules te ondertekenen. Kernel modules: Deze worden tijdens het bouwen ondertekend met een privé sleutel. Deze sleutel wordt niet opgeslagen, bij elke nieuwe bouw van de kernel wordt een nieuwe sleutel gebruikt. De Fedora Secure Boot CA wordt gebruikt om de integriteit van GRUB en de kernel te verifiëren. De publieke sleutel kan op dit moment gevonden worden in het shim bronpakket. De details van de sleutel zijn:

15

Hoofdstuk 3. UEFI Secure Boot implementatie

Certificate: Data: Version: 3 (0x2) Serial Number: 2574709492 (0x9976f2f4) Signature Algorithm: sha256WithRSAEncryption Issuer: CN=Fedora Secure Boot CA Validity Not Before: Dec 7 16:25:54 2012 GMT Not After : Dec 5 16:25:54 2022 GMT Subject: CN=Fedora Secure Boot CA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:ae:f5:f7:52:81:a9:5c:3e:2b:f7:1d:55:f4:5a: 68:84:2d:bc:8b:76:96:85:0d:27:b8:18:a5:cd:c1: 83:b2:8c:27:5d:23:0a:d1:12:0a:75:98:a2:e6:5d: 01:8a:f4:d9:9f:fc:70:bc:c3:c4:17:7b:02:b5:13: c4:51:92:e0:c0:05:74:b9:2e:3d:24:78:a0:79:73: 94:c0:c2:2b:b2:82:a7:f4:ab:67:4a:22:f3:64:cd: c3:f9:0c:26:01:bf:1b:d5:3d:39:bf:c9:fa:fb:5e: 52:b9:a4:48:fb:13:bf:87:29:0a:64:ef:21:7b:bc: 1e:16:7b:88:4f:f1:40:2b:d9:22:15:47:4e:84:f6: 24:1c:4d:53:16:5a:b1:29:bb:5e:7d:7f:c0:d4:e2: d5:79:af:59:73:02:dc:b7:48:bf:ae:2b:70:c1:fa: 74:7f:79:f5:ee:23:d0:03:05:b1:79:18:4f:fd:4f: 2f:e2:63:19:4d:77:ba:c1:2c:8b:b3:d9:05:2e:d9: d8:b6:51:13:bf:ce:36:67:97:e4:ad:58:56:07:ab: d0:8c:66:12:49:dc:91:68:b4:c8:ea:dd:9c:c0:81: c6:91:5b:db:12:78:db:ff:c1:af:08:16:fc:70:13: 97:5b:57:ad:6b:44:98:7e:1f:ec:ed:46:66:95:0f: 05:55 Exponent: 65537 (0x10001) X509v3 extensions: Authority Information Access: CA Issuers URI:https://fedoraproject.org/wiki/Features/SecureBoot X509v3 Authority Key Identifier: keyid:FD:E3:25:99:C2:D6:1D:B1:BF:58:07:33:5D:7B:20:E4:CD:96:3B:42 X509v3 Extended Key Usage: Code Signing X509v3 Subject Key Identifier: FD:E3:25:99:C2:D6:1D:B1:BF:58:07:33:5D:7B:20:E4:CD:96:3B:42 Signature Algorithm: sha256WithRSAEncryption 37:77:f0:3a:41:a2:1c:9f:71:3b:d6:9b:95:b5:15:df:4a:b6: f4:d1:51:ba:0d:04:da:9c:b2:23:f0:f3:34:59:8d:b8:d4:9a: 75:74:65:80:17:61:3a:c1:96:7f:a7:c1:2b:d3:1a:d6:60:3c: 71:3a:a4:c4:e3:39:03:02:15:12:08:1f:4e:cd:97:50:f8:ff: 50:cc:b6:3e:03:7d:7a:e7:82:7a:c2:67:be:c9:0e:11:0f:16: 2e:1e:a9:f2:6e:fe:04:bd:ea:9e:f4:a9:b3:d9:d4:61:57:08: 87:c4:98:d8:a2:99:64:de:15:54:8d:57:79:14:1f:fa:0d:4d: 6b:cd:98:35:f5:0c:06:bd:f3:31:d6:fe:05:1f:60:90:b6:1e: 10:f7:24:e0:3c:f6:33:50:cd:44:c2:71:18:51:bd:18:31:81: 1e:32:e1:e6:9f:f9:9c:02:53:b4:e5:6a:41:d6:65:b4:2e:f1: cf:b3:b8:82:b0:a3:96:e2:24:d8:83:ae:06:5b:b3:24:74:4d: d1:a4:0a:1d:0a:32:1b:75:a2:96:d1:0e:3e:e1:30:c3:18:e8: cb:53:c4:0b:00:ad:7e:ad:c8:49:41:ef:97:69:bd:13:5f:ef: ef:3c:da:60:05:d8:92:fc:da:6a:ea:48:3f:0e:3e:73:77:fd: a6:89:e9:3f

Afbeelding 3.1. Fedora X.509 certificaat voor het ondertekenen van kernel en GRUB

16

Ontwerp

Ontwerp

Shim

3.2. Shim Fedora gebruikt een first-stage bootlader met de naam shim welke een zelf ondertekende CA certificaat bevat. Deze CA wordt dan gebruikt voor het verifiëren van de GRUB 2 bootlader (UEFI versie, een PE/COFF programma ondertekend met AuthentiCode). Voor het opstarten van een kernel, roept GRUB 2 terug naar shim om de AuthentiCode ondertekening van de kernel te verifiëren. Naast de Microsoft sleutel ondersteunt shim ook extra vertrouwde certificaten geleverd door de eigenaar en een mechanisme om ondertekeningsverificatie uit te zetten. De informatie wordt bewaard in UEFI variabelen die niet overschreven kunnen worden nadat het besturingssysteem opgestart is. Shim bevat een fysieke aanwezigheidscontrole en vraagt om een bevestiging voordat het de instellingen die opgeslagen zijn in deze UEFI variabelen vernieuwt. In Fedora zijn er twee pakketten die shim vormen. Het pakket met de naam "shim" is het resultaat van het compileren van de broncode van shim. Dit pakket zal het systeem niet opstarten als het niet ondertekend is. Het resultaat van het bouwen van sim pakket wordt ondertekend en daarna opgenomen in het shim-signed pakket. Het shim-signed pakket bevat het ondertekende binaire programma dat in staat is om het systeem op te starten. Het shim pakket bevat ook een blacklist van bekende slechte sleutels of binaire programma's die niet mogen opstarten. De blacklist is een bestand met de naam dbx.esl in het shim pakket. Deze blacklist wordt op dit moment tijdens het bouwen in het shim binaire programma opgenomen. Het wordt gebruikt om te beletten dat een bekend exploiteerbare versie van grub opgestart wordt. Met ontwikkelingen in de toekomst kan deze blacklist naar UEFI geheugen verplaatst worden. In zijn huidige vorm zal het vernieuwen van de blacklist geen extra beveiliging bieden omdat je het shim pakket kunt downgraden om het vernieuwen van de blacklist te voorkomen. Als de blacklist in de BIOS wordt opgeslagen, zal een blacklist vernieuwing een shim downgrade overleven. Daarnaast is er een blacklist die Microsoft onderhoudt en tekent, welk opgeslagen in de BIOS voor gebruik. Microsoft zal die aan Fedora Project geven om op te nemen. Dit kan periodieke vernieuwingen voor het shim-signed pakket veroorzaken waarbij het actuele shim binaire programma niet verandert. Dit blacklist bestand bestaat nu nog niet omdat er nog niets opgeplaatst is. De blacklist zal waarschijnlijk zijn eigen pakket krijgen om te voorkomen dat het shim-signed pakket een update moet krijgen. De details op deze blacklist komen van Microsoft en Fedora Project kan deze blacklist niet vernieuwen. De data wordt ondertekend met een Microsoft sleutel die ongeoorloofde vernieuwingen voor deze zal voorkomen. Microsoft heeft gesuggereerd dat de blacklist gebruikt moet worden om te voorkomen dat de computer opstart met aangetaste sleutels en bekende kwetsbaarheden. In beide boot methodes zullen shim, GRUB en de kernel detecteren dat ze opgestart worden in wat UEFI beschrijft als "User mode" met ingeschakelde Secure Boot, en na het detecteren hiervan zullen de de volgende fase valideren met een Fedora-specifieke cryptografische sleutels alvorens op te starten. De validatie wordt voor GRUB via shim uitgevoerd, en GRUB roept shim aan om ook de kernel te valideren. Zodra de kernel opgestart is, zal het ook detecteren dat het zich in Secure Boot modus bevindt, wat een aantal dingen zal veroorzaken: het zal de boot commandoregel alleen valideren om bepaalde kernelinstellingen toe te staan het zal modules tijdens het laden controleren op ondertekeningen en ze niet laden als ze niet ondertekend zijn of ondertekend zijn met een handtekening die niet teruggevonden wordt in de UEFI sleutelopslagvariabelen (zie opmerking) het zal alle bewerkingen vanuit de gebruikersruimte weigeren welke een gebruikers-gedefinieerde DMA veroorzaken.

17

Hoofdstuk 3. UEFI Secure Boot implementatie

Ontwerp 1

Extra informatie over shim kan gevonden worden op de shim development repository .

Opmerking Andere distributies hebben ervoor gekozen om in hun Secure Boot implementatie geen ondertekende kernelmodules te vereisen. Fedora vindt dat dit vereist is voor volledige ondersteuning van Secure Boot. We werken eraan om de impact hiervan te beperken terwijl we ervoor zorgen dat niet vertrouwde modulecode niet uitgevoerd kan worden.

3.3. GRUB GRUB bevindt zich in het grub2 pakket en wordt ondertekend met de Fedora CA sleutel. Zodra het binaire programma cryptografisch geverifieerd is, wordt het uitgevoerd door shim. Het GRUB pakket bevat geen sleutel materiaal. Als GRUB de integriteit van de kernel moet verifiëren zal het terugvallen op shim om de controle uit te voeren.

3.4. Kernel De kernel wordt ondertekend met de Fedora CA sleutel en wordt geverifieerd door shim voordat GRUB de uitvoering zal toestaan. Modules die door de kernel geladen worden zijn ondertekend met een sleutel die tijdens het bouwen van de kernel gegenereerd is en daarna vernietigd wordt. De kernel zal de UEFI sleutel database importeren en deze gebruiken om de kernel modules te verifiëren. Dit betekent dat kernel modules van derden die ondertekend zijn met een sleutel die door UEFI (Microsoft) vertrouwd wordt, in de kernel geladen zal worden als Secure Boot aangezet is.

Belangrijk Het is belangrijk om op te merken dat zodra de kernel de initiële ramdisk (initrd) laadt, de uitvoering niet meer vertrouwd wordt. Hoewel de initrd ondertekende kernel modules kan bevatten, het zal ook niet ondertekende gebruikersruimte code bevatten. De integriteit van deze code kan niet gegarandeerd worden.

3.4.1. Beperkingen Er zijn beperkingen aanwezig om volledig te voldoen aan Secure Boot. Dit vereist van ons om elke uitvoering van niet geverifieerde code op het supervisor niveau te voorkomen. De meeste gebruikers zullen deze beperkingen niet opmerken omdat de meeste gebruikersruimte pakketten die zo'n toegang nodig hadden gerepareerd zijn om zonder die toegang te werken. Er zijn echter een paar services of functies die op dit moment niet zullen werken op een machine waarvoor Secure Boot aangezet is. Dit zijn onder andere: kexec/kdump overwinteren (slaapstand naar schijf) modules van derden die niet ondertekend zijn, of ondertekend met een onbekende sleutel systemtap kernel probing (en kprobes)

1

https://github.com/mjg59/shim

18

Ontwerp

Beperkingen

Opmerking In toekomstige iteraties van Secure Boot ondersteuning kunnen de bovenstaande misschien mogelijk zijn, in de Fedora 18 ontwikkelperiode waren veilige implementatie hiervan echter niet mogelijk. Als je de ondersteuning van een van deze functies nodig hebt, moet je Secure Boot uitzetten.

Belangrijk Op dit moment is de Fedora shim ondertekend zodat het verloopt op October 2013, voor het einde van de levensduur van Fedora. We zijn ons niet bewust van hardware dat zich aan deze vervaldatum houdt, maar het is mogelijk. Dit is de datum die Microsoft aan de ondertekening heeft gegeven, Fedora heeft hier geen controle over. We onderzoeken dit probleem en verwachten het in de toekomst op te lossen.

19

20

Ontwerp

Ontwerp

Gereedschappen Er zijn verschillende gereedschappen ontwikkeld om Fedora toe te staan met de UEFI Secure Boot firmware te kunnen werken.

4.1. Shim Shim is de cryptografisch ondertekende software die het vertrouwen tussen de UEFI firmware en GRUB en de kernel software creëert. Shim wordt cryptografisch ondertekend door Verisign (via Microsoft) zodat de UEFI firmware het Fedora systeem cryptografisch zal herkennen en de software toe zal staan om verder te gaan met het boot proces. De shim valideert GRUB en kernel met een cryptografische verificatie gebaseerd op een Fedora sleutel die gebruikt wordt om alle drie te ondertekenen.

4.2. Pesign Pesign laat gebruikers hun eigen shim aanmaken en hun eigen cryptografische sleutels gebruiken. Met dit gereedschap kan iemand zijn eigen vertrouwensmodel aanmaken en is het niet vereist om het Microsoft vertrouwensmodel te vertrouwen. Zodra de gebruiker zijn sleutels aangemaakt heeft en zijn shim heeft ondertekend, en optioneel GRUB en kernel heeft ondertekend en gebouwd, dan kan de instel mode in de firmware gebruikt worden om Fedora te installeren en het sbsetup gereedschap gebruiken dat door pesign aangeboden wordt om eigen sleutels in de firmware toe te passen.

4.3. EFIKeyGen 4.4. sign-file

21

22

Ontwerp

Ontwerp

Je eigen sleutels gebruiken 5.1. Sleutels aanmaken 5.2. Sleutels aanmaken voor het bouwen van shim 5.3. Pakketten die opnieuw gebouwd moeten worden 5.4. Je sleutels in firmware inschrijven

23

24

Ontwerp

Ontwerp

Bijlage A. Herzieningsgeschiedenis Herziening Tue 11 March 2013 Eric Christensen 18.4 [email protected] Verduidelijkingen toegevoegd aan sommige secties.

Herziening Tue 19 February 2013 18.3 Informatie van Florian's repo toegevoegd. Afbeeldingen toegevoegd.

Eric Christensen [email protected]

Herziening Wed 06 February 2013 Eric Christensen 18.2 [email protected] Aan alle hoofdstukken tekst toegevoegd met informatie over de publieke sleutels.

Herziening Fri 04 January 2013 Eric Christensen 18.1 [email protected] 'Wat is Secure Boot' hoofdstuk vernieuwt. (BZ 891758) 'Implementatie' hoofdstuk vernieuwt. (BZ 891924) Email adres van Josh Boyer vernieuwt. (BZ 891932)

Herziening 0

Thu Jul 12 2012

Eric Christensen [email protected]

Initiële aanmaak met publican

25

26

Ontwerp

Ontwerp

Register E EFIKeyGen definitie, 21

F Fedora Secure Boot CA, 15

G GRUB integriteit, 15 sleutel, 15

K kernel integriteit, 15 sleutel, 15

P pesign definitie, 21 sbsetup, 21

S Secure Boot beperkingen, 18 blacklist, 17 implementatie, 15 sleutels, 15 (zie ook sleutels) shim definitie, 21 sleutel, 15 uitleg, 17 sign-file definitie, 21 sleutels Fedora Secure Boot CA publieke sleutel, 15 GRUB, 15 kernel, 15 shim, 15 vervaldatum Fedora 18, 19

T terugkoppeling contact informatie voor deze handleiding, viii

27

28

Fedora 18 UEFI Secure Boot gids

Recommend Documents