Fedora 18 Guida al UEFI Secure Boot - Josh Boyer Kevin Fenzi Peter Jones Josh Bressers Florian Weimer - Fedora Docs
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Fedora 18 Guida al UEFI Secure Boot Josh Boyer Kevin Fenzi Peter Jones Josh Bressers Florian Weimer
Guida al UEFI Secure Boot Bozza Fedora 18 Guida al UEFI Secure Boot Edizione 18.4 Autore Josh Boyer jwboyer@redhat.com Autore Kevin Fenzi kevin@fedoraproject.org Autore Peter Jones pjones@redhat.com Autore Josh Bressers bressers@redhat.com Autore Florian Weimer fweimer@redhat.com Editor Eric Christensen sparks@redhat.com 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.
Bozza Bozza Preface v 1. Convenzioni del documento ............................................................................................. v 1.1. Convenzioni tipografiche ....................................................................................... v 1.2. Convenzioni del documento ................................................................................. vi 1.3. Note ed avvertimenti ........................................................................................... vii 2. Inviateci i vostri commenti! ............................................................................................ viii 1. Cos'é UEFI Secure Boot ? 1 1.1. UEFI Secure Boot ........................................................................................................ 1 1.2. Requisiti Microsoft per Boot Sicuro ................................................................................ 2 1.2.1. Dettagli sull'implementazione .............................................................................. 2 1.3. Fedora Secure Boot ..................................................................................................... 6 1.4. Da cosa protegge Secure Boot ? .................................................................................. 6 1.5. Potenziali rischi del Secure Boot ................................................................................... 7 1.5.1. Rimozione forzata di funzionalità in modalità Secure Boot .................................... 7 1.5.2. Transizioni di Sistema aldifuori di Secure Boot .................................................... 7 1.5.3. Nessuna infrastruttura di provisioning oltre a Microsoft Windows ........................... 8 1.5.4. Procedure di revoca non provate ........................................................................ 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. Implementazione del UEFI Secure Boot 15 3.1. Chiavi ........................................................................................................................ 15 3.2. Shim .......................................................................................................................... 17 3.3. GRUB ........................................................................................................................ 18 3.4. Kernel ........................................................................................................................ 18 3.4.1. Restrizioni ....................................................................................................... 18 4. Strumenti 21 4.1. Shim .......................................................................................................................... 21 4.2. Pesign ....................................................................................................................... 21 4.3. EFIKeyGen ................................................................................................................ 21 4.4. sign-file ...................................................................................................................... 21 5. Utilizzare le proprie chiavi 23 5.1. Creazione chiavi ......................................................................................................... 23 5.2. Ottenere le chiavi per la compilazione di shim .............................................................. 23 5.3. Pacchetti che necessitano di essere ricostruiti .............................................................. 23 5.4. Registrazione delle proprie chiavi nel firmware ............................................................. 23 A. Storico Revisioni 25 Indice analitico 27 iii
iv
Bozza Bozza Preface 1. Convenzioni del documento Questo manuale utilizza numerose convenzioni per evidenziare parole e frasi, ponendo attenzione su informazioni specifiche. 1 Nelle edizioni PDF e cartacea questo manuale utilizza caratteri presenti nel set Font Liberation . Il set Font Liberation viene anche utilizzato nelle edizioni HTML se il set stesso è stato installato sul vostro sistema. In caso contrario, verranno mostrati caratteri alternativi ma equivalenti. Da notare: Red Hat Enterprise Linux 5 e versioni più recenti, includono per default il set Font Liberation. 1.1. Convenzioni tipografiche Vengono utilizzate quattro convenzioni tipografiche per richiamare l'attenzione su parole e frasi specifiche. Queste convenzioni, e le circostanze alle quali vengono applicate, sono le seguenti. Neretto monospazio Usato per evidenziare l'input del sistema, incluso i comandi della shell, i nomi dei file ed i percorsi. Utilizzato anche per evidenziare tasti e combinazione di tasti. Per esempio: Per visualizzare i contenuti del file my_next_bestselling_novel nella vostra directory di lavoro corrente, inserire il comando cat my_next_bestselling_novel al prompt della shell e premere Invio per eseguire il comando. Quanto sopra riportato include il nome del file, un comando della shell ed un tasto, il tutto riportato in neretto monospazio e distinguibile grazie al contesto. Le combinazioni di tasti possono essere distinte dai tasti tramite il trattino che collega ogni parte della combinazione. Per esempio: Premere Invio per eseguire il comando. Premere Ctrl+Alt+F2 per smistarsi sul primo virtual terminal. Premere Ctrl+Alt+F1 per ritornare alla sessione X-Windows. Il primo paragrafo evidenzia il tasto specifico singolo da premere. Il secondo riporta due combinazioni di tasti, (ognuno dei quali è un set di tre tasti premuti contemporaneamente). Se si discute del codice sorgente, i nomi della classe, i metodi, le funzioni i nomi della variabile ed i valori ritornati indicati all'interno di un paragrafo, essi verranno indicati come sopra, e cioè in neretto monospazio. Per esempio: Le classi relative ad un file includono filesystem per file system, file per file, e dir per directory. Ogni classe possiede il proprio set associato di permessi. Proportional Bold Ciò denota le parole e le frasi incontrate su di un sistema, incluso i nomi delle applicazioni; il testo delle caselle di dialogo; i pulsanti etichettati; le caselle e le etichette per pulsanti di selezione, titoli del menu e dei sottomenu. Per esempio: 1 https://fedorahosted.org/liberation-fonts/ v
Preface Bozza Selezionare Sistema��� Preferenze��� Mouse dalla barra del menu principale per lanciare Preferenze del Mouse. Nella scheda Pulsanti, fate clic sulla casella di dialogo mouse per mancini, e successivamente fate clic su Chiudi per cambiare il pulsante primario del mouse da sinistra a destra (rendendo così il mouse idoneo per un utilizzo con la mano sinistra). Per inserire un carattere speciale in un file gedit, selezionare Applicazioni�� Accessori��� Mappa carattere dalla barra menu principale. Successivamente, selezionare Cerca��� Trova… dalla barra del menu Mappa carattere, inserire il nome del carattere nel campo Cerca e cliccare Successivo. Il carattere ricercato verrà evidenziato nella Tabella caratteri. Fare un doppio clic sul carattere evidenziato per posizionarlo nel campo Testo da copiare, e successivamente fare clic sul pulsante Copia. Ritornare ora al documento e selezionare Modifica��� Incolla dalla barra del menu di gedit. Il testo sopra riportato include i nomi delle applicazioni; nomi ed oggetti del menu per l'intero sistema; nomi del menu specifici alle applicazioni; e pulsanti e testo trovati all'interno di una interfaccia GUI, tutti presentati in neretto proporzionale e distinguibili dal contesto. Corsivo neretto monospazio o Corsivo neretto proporzionale Sia se si tratta di neretto monospazio o neretto proporzionale, l'aggiunta del carattere corsivo indica un testo variabile o sostituibile . Il carattere corsivo denota un testo che non viene inserito letteralmente, o visualizzato che varia a seconda delle circostanze. Per esempio: Per collegarsi ad una macchina remota utilizzando ssh, digitare ssh username@domain.name al prompt della shell. Se la macchina remota è example.com ed il nome utente sulla macchina interessata è john, digitare ssh john@example.com. Il comando mount -o remount file-system rimonta il file system indicato. Per esempio, per rimontare il file system /home, il comando è mount -o remount / home. Per visualizzare la versione di un pacchetto attualmente installato, utilizzare il comando rpm -q package. Esso ritornerà il seguente risultato: package- version-release. Da notare la parola in Corsivo neretto — nome utente, domain.name, file-system, pacchetto, versione e release. Ogni parola racchiude il testo da voi inserito durante l'emissione di un comando o per il testo mostrato dal sistema. Oltre all'utilizzo normale per la presentazione di un titolo, il carattere Corsivo denota il primo utilizzo di un termine nuovo ed importante. Per esempio: Publican è un sistema di pubblicazione per DocBook. 1.2. Convenzioni del documento Gli elenchi originati dal codice sorgente e l'output del terminale vengono evidenziati rispetto al testo circostante. L'output inviato ad un terminale è impostato su tondo monospazio e così presentato: books Desktop documentation drafts mss photos stuff svn books_tests Desktop1 downloads images notes scripts svgs vi
Bozza Note ed avvertimenti Gli elenchi del codice sorgente sono impostati in tondo monospazio ma vengono presentati ed evidenziati nel modo seguente: 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. Note ed avvertimenti E per finire, tre stili vengono usati per richiamare l'attenzione su informazioni che in caso contrario potrebbero essere ignorate. Nota Bene Una nota è un suggerimento o un approccio alternativo per il compito da svolgere. Non dovrebbe verificarsi alcuna conseguenza negativa se la nota viene ignorata, ma al tempo stesso potreste non usufruire di qualche trucco in grado di facilitarvi il compito. Importante Le caselle 'importante' riportano informazioni che potrebbero passare facilmente inosservate: modifiche alla configurazione applicabili solo alla sessione corrente, o servizi i quali necessitano di un riavvio prima di applicare un aggiornamento. Ignorare queste caselle non causa alcuna perdita di dati ma potrebbe causare irritazione e frustrazione da parte dell'utente. Avvertenza Un Avvertimento non dovrebbe essere ignorato. Se ignorato, potrebbe verificarsi una perdita di dati. vii
Preface Bozza 2. Inviateci i vostri commenti! Se individuate degli errori di battitura in questo manuale, o se pensate di poter contribuire al suo miglioramento, contattateci subito! Inviate i vostri suggerimenti tramite Bugzilla: http:// bugzilla.redhat.com/bugzilla/ sul componente Fedora. Quando inviate un bug report, assicuratevi di indicare l'identificatore del manuale: UEFI_Secure_Boot_Guide Se inviate un suggerimento per contribuire al miglioramento della guida, cercate di essere il più specifici possibile. Se avete individuato un errore, indicate il numero della sezione e alcune righe di testo, in modo da agevolare la ricerca dell'errore. viii
Bozza Capitolo 1. Bozza Cos'é UEFI Secure Boot ? Secure Boot è una tecnologia secondo la quale il boot loader di sistema controlla che al successivo avvio il loader sia firmato con una chiave crittografica autorizzata contenuta in un databse nel firmware. Con delle verifiche adeguate delle firme del(i) boot loader, del kernel e, potenzialmente, delo spazio utente, è possibile impedire l'esecuzione di codice non firmato. Secure Boot è una forma di Verified Booting. La validazione del percorso di avvio è anche parte di altre tecnologie come il Trusted Boot. Esso è indipendente dalla memorizzazione sicura delle chiavi crittografiche e dell'attestazione remota. 1.1. UEFI Secure Boot UEFI Secure Boot è una componente della validazione del percorso d'avvio della specifica UEFI (Unified Extensible Firmware Interface) a partire dalla versione 2.3 . In parole povere si specifica quanto segue: • un'interfaccia di programmazione per variabili UEFI crittograficamente protette nelle memorizzazioni non-volatili, • come i certificati radice X.509 attendibili sono memorizzati nelle variabili UEFI, • convalida delle applicazioni UEFI (boot loader e driver) usando firme AuthentiCode incorporate nelle stesse, e • procedure di revoca di certificati riconosciuti sbagliati ed hash di applicazioni. UEFI Secure Boot non richiede hardware specifico, a parte la memorizzazione non-volatile (flash) che può essere cambiata dalla modalità in lettura-scrittura a in sola-lettura durante l'avvio del sistema. Questo tipo di memorizzazione deve essere usata per memorizzare appunto la stessa implementazione UEFI ed alcune delle variabili UEFI protette (includendo il certificato radice attendibile). Dal punto di vista dell'utente, un sistema che ha abilitato UEFI Secure Boot, e che è confrontato con una percorso d'avvio compromesso, semplicemente smette di funzionare finché UEFI Secure Boot è disabilitato o un boot loader firmato è disponibile sul supporto d'avvio. (Figura 1.1, «Messaggio d'errore tipico da UEFI Secure Boot» mostra un tipico messaggio d'errore) Allo stesso modo il software d'installazione del sistema operativo senza una firma crittografica valida non funziona restituendo un messaggio d'errore. Gli utenti non dispongono di un modo per evitare la decisione del boot loader di rifiutare la firma, a differenza dei web server certificati nella stessa situazione. Nessuna informazione è fornita all'utente. ┌────────── Secure Boot Violation ──────────┐ │ │ ├───────────────────────────────────────────┤ │ Invalid signature detected. Check Secure │ │ Boot Policy in Setup │ │ │ │ │ │ [OK] │ └───────────────────────────────────────────┘ Figura 1.1. Messaggio d'errore tipico da UEFI Secure Boot UEFI Secure Boot non impedisce l'installazione o la rimozione di boot loader di secondo stadio, ne richiede conferme esplicite all'utente per ogni modifica. Le firme vengono veificate durante l'avvio 1
Capitolo 1. Cos'é UEFI Secure Boot ? Bozza e non quando il boot loader viene installato o aggiornato. Quindi, UEFI Secure Boot non blocca le modifiche dei percorsi di avvio, ma impedisce di far partire il sistema da un percorso d'avvio modificato una volta sia stato ritenuto tale e ne semplifica la rilevazione. Client Technology UEFI Secure Boot attualmente è generalemte solo abilitato per alcuni dispositivi e non è raccomandato per la distribuzione di server. Si prevede che la tecnologia server supporterà Secure Boot in futuro. 1.2. Requisiti Microsoft per Boot Sicuro Microsoft non ha pubblicato molti dettagli sulla loro implementazione del Secure Boot, che è basata su UEFI Secure Boot. Microsoft supporta UEFI Secure Boot solo con Windows 8, ma non è richiesto per l'utilizzo dello stesso. I sistemi in ambiente UEFI Secure Boot si avviano ancora se Secure Boot viene rimosso dall'UEFI. I clienti che vogliono usare versioni precedenti di Windows devono disabilitarlo perché Microsoft non fornisce boot loader firmati. Sulla base della documentazione pubblica, gli obiettivi di sicurezza seguenti per Microsoft Secure Boot sembrano probabili: • protezione dell'integrità dei media d'installazione che sono memorizzati su dispositivi scrivibili (come partizioni di ricovero), • protezione del percorso di avvio finché le contromisure euristiche (come software antivirus in modalità kernel) possono essere caricate durante l'avvio iniziale, e • ripristino automatico del percorso di avvio originale, forse dopo che il sistema è stato compromesso da malware, senza la completa reinstallazione del sistema operativo. Non è chiaro se ci sono piani per la restrizione dell'accesso (online) di contenuto ai sistemi che hanno UEFI Secure Boot abilitato ed il quale percorso di avvio è crittograficamente valido. Questo implicherebbe un'attestazione remota che non è parte delle specifiche di UEFI Secure Boot e che non può essere implementata con sicurezza senza il supporto di hardware addizionale. Inoltre implicherebbe che un UEFI Secure Boot non più veramente opzionale. Non ci sono prove secondo cui Microsoft possa bloccare chiunque con la loro implementazione del Secure Boot. Tuttavia, il ripristino automatico del percorso originale di avvio è molto più complicato quando altri boot loader possono coesistere nello stesso sistema. 1.2.1. Dettagli sull'implementazione Microsoft richiede che i PC client marchiati con il logo Windows 8 debbano avere UEFI Secure Boot abilitato ed installata la chiave fornita da Microsoft. Il certificato X.509 richiesto è mostrato in Figura 1.2, «Microsoft Trusted X.509 Certificate per la loro implementazione Secure Boot». I fornitori sono incoraggiati ad includere altri certificati di origine se necessario anche se non sono tenuti a farlo. 2
Bozza Dettagli sull'implementazione 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 Figura 1.2. Microsoft Trusted X.509 Certificate per la loro implementazione DgQWBBSpKQI5jhbEl3jNkPmeT5rhfFWvUzAZBgkrBgEEAYI3FAIEDB4KAFMAdQBi Secure Boot AEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBTV 9lbLj+iiXGJo0T2UkFvXzpoYxDBWBgNVHR8ETzBNMEugSaBHhkVodHRwOi8vY3Js 3 Lm1pY3Jvc29mdC5jb20vcGtpL2NybC9wcm9kdWN0cy9NaWNSb29DZXJBdXRfMjAx MC0wNi0yMy5jcmwwWgYIKwYBBQUHAQEETjBMMEoGCCsGAQUFBzAChj5odHRwOi8v d3d3Lm1pY3Jvc29mdC5jb20vcGtpL2NlcnRzL01pY1Jvb0NlckF1dF8yMDEwLTA2 LTIzLmNydDANBgkqhkiG9w0BAQsFAAOCAgEAFPx8cVGlecJusu85Prw8Ug9uKz8Q
Capitolo 1. Cos'é UEFI Secure Boot ? Bozza Microsoft si spetta di distribuire eventualmente delle richieste di revoca firmate in Windows Update. Tali richieste sono installate nelle variabili di configurazione del UEFI Secure Boot durante il successivo avvio del sistema, dopo la loro validazione contro la chiave Microsoft. Al momento non esiste alcuna lista nera. I boot loader da terzi attualmente non hanno accesso all'uso del certificato Microsoft Windows Production PCA 2011 per i propri prodotti. Invece, Microsoft fornisce un servizio di firma originariamente previsto per i driver UEFI. Tale servizio è stato esteso per includere anche gli altri boot loader. Microsoft revisiona le applicazioni UEFI presentate, fornisce una firma AuthentiCode usando la propria chiave e rilascia il risultato all'autore. Questa firma non identifica l'autore dell'applicazione (è uno pseudonimo) e, molto importante, è legata attraverso il certificato intermedio Microsoft Corporation UEFI CA 2011 (vedi Figura 1.3, «Certificato Microsoft X.509 per applicazioni UEFI da terzi») al certificato originario Microsoft Corporation Third Party Marketplace Root. Avvertimento Il funzionamento dei boot loader UEFI da terzi non è garantito nei sistemi Microsoft Secure Boot poiché i certificati necessari non sono parte delle specifiche Microsoft Secure Boot. 4
Bozza Dettagli sull'implementazione 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: […] Figura 1.3. 92:9b:f5:a6:bc:59:83:58 Certificato Microsoft X.509 per applicazioni UEFI da terzi -----BEGIN CERTIFICATE----- 5 MIIGEDCCA/igAwIBAgIKYQjTxAAAAAAABDANBgkqhkiG9w0BAQsFADCBkTELMAkG A1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQx HjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjE7MDkGA1UEAxMyTWljcm9z b2Z0IENvcnBvcmF0aW9uIFRoaXJkIFBhcnR5IE1hcmtldHBsYWNlIFJvb3QwHhcN
Capitolo 1. Cos'é UEFI Secure Boot ? Bozza Un regolare certificato di firma del codice non è sufficiente a garantire l'avvio su un sistema Microsoft Secure Boot. Microsoft infatti richiede un certificato di firma quando comunica con gli autori di un'applicazione UEFI, ma in ogni modo si tratta di un dettaglio interno non visibile all'utente finale. In un sistema operativo avviato, Microsoft Windows 8 supporta la validazione AuthentiCode e il caricamento di moduli kernel da terzi firmati. Windows dispone di infrastrutture per estendere la validazione crittografica per programmi dello spazio utente, sempre basate su AuthentiCode. 1.3. Fedora Secure Boot L'implementazione Fedora Secure Boot ha un singolo obbiettivo di sicurezza: impedire l'esecuzione di codice non firmato nei moduli kernel. Fedora può avviarsi in sistemi con Microsoft Secure Boot abilitato, con installato il certificato Microsoft per applicazioni UEFI da terzi. Questa modalità d'operazione è la più importante per l'installazione di Fedora su macchine preparate per Windows 8. Altro hardware non è in grado di fornire un ambiente Microsoft Secure Boot. Avvertimento I boot loader UEFI da terzi (come il bootloader Fedora) non sono garantiti sui sistemi Microsoft Secure Boot perché i certificati necessari non sono parte delle specifiche Windows 8 Hardware Certification Requirements. Se il proprio hardware è in questa categoria, bisogna disabilitare UEFI Secure Boot, registrare il certificato Microsoft mancante o registrare il certificato Fedora. Fedora parte anche su sistemi UEFI che non supportano o hanno disabilitato Secure Boot. Funziona con tutti i boot loader UEFI. Tali boot loader inoltre supportano l'avvio in un ambiente che esegue la validazione del percorso d'avvio tramite altri mezzi (non-UEFI). In questo modo, non ci sono restrizioni nell'esecuzione di codice in modalità kernel. Dettagli sull'implementazione Fedora Secure Boot sono compresi nella Capitolo 3, Implementazione del UEFI Secure Boot. Le restrizioni sull'esecuzione di codice in modalità kernel disabilitano certe funzionalità, vedi Sezione 3.4.1, «Restrizioni». 1.4. Da cosa protegge Secure Boot ? A livello più elementare, UEFI Secure Boot impedisce l'esecuzione di boot loader non firmati. L'effetto di eseguire il boot loader ovviamente dipende da quale boot loader si tratta. Quanto segue fa riferimento all'implementazione Secure Boot di Fedora. L'implementazione Microsoft è differente: Sezione 1.2, «Requisiti Microsoft per Boot Sicuro». Fedora ha esteso il legame di sicurezza dall'ambiente UEFI fin dentro il kernel. La verifica avviene prima del carimento dei moduli kernel ma non si estende alle applicazioni dello spazio utente. Possiamo essere certi che nessun codice eseguibile non firmato è presente finché il ramdisk iniziale (initrd) è caricato. Siccome i contenuti di initrd non sono crittograficamente firmati e contiene codice eseguibile, l'avvio del boot loader Fedora firmato può eventualmente portare effetti imprevisti. L'implementazione Fedora Secure Boot semplifica la verifica del percorso d'avvio in digital forensic. L'avvio di BIOS datati esegue codice potenzialmente malevolo caricato dal disco in fase molto precoce, il che rende difficile escludere che il sistema operativo sia stato manomesso ad un livello molto basso. (Alcune parti di questo vantaggio derivano dalla natura più dichiarativa della configurazione di avvio UEFI su disco). 6
Bozza Potenziali rischi del Secure Boot 1.5. Potenziali rischi del Secure Boot Secure Boot non proteggerà il PC dalla maggior parte dei malware o da aggressori. Esso protegge la fase d'avvio del sistema, ma non protegge contro il proprio sistema o i propri dati. In Fedora, se si usa Secure Boot, i moduli che il kernel carica possono essere controllati, a differenza però dei malware nello spazio utente. L'immagine del ramdisk iniziale (initrd) usata durante l'avvio non è protetta e potrebbe contenere codice malevolo. 1.5.1. Rimozione forzata di funzionalità in modalità Secure Boot Attualmente usiamo una blacklist per disabilitare le funzionalità kernel conosciute non sicure. In alcuni casi specifici vengono disabilitate, in molti casi si tratta di funzionalità poco conosciute o scarsamente utilizzate. Ad oggi, la lista di restrizione include: • modifica delle mappe di memoria del dispositivo tramite "setpci", e scrive nella memoria dallo spazio utente tramite sysfs • ibernazione (conosciuta anche come suspend to disk) • kexec e kdump (work in progress) • scrive su Machine Specific Registers scrive attraverso il modulo "msr" del kernel. • l'opzione a riga di comando acpi_rspd, che è usata per specificare dati ACPI personalizzati • operazioni IO su /dev/kmem In alternativa l'uso dei moduli systemtap è limitato a quei moduli che sono stati firmati con un certificato appropriato. E' raccomandato generare ogni certificato in loco, assicurandosi di seguire le appropriate pratiche di sicurezza per lo storage e l'uso di un certficato firmato. Quando si utilizza un certificato locale, è possibile registrarlo nel database locale della macchina usando l'utility mokutil, che richiederà poi un riavvìo per avere effetto. Una volta riavviato, shim si avvierà MokManager per presentarsi con un'interfaccia per la registrazione del certificato. Avvertimento E' estremamente importante che le giuste precauzioni vengano prese nell'utilizzo dei certificati locali così che non possano essere trovati ed usati da un malintenzionato che voglia sovvertire la sicurezza del modulo. Trattare quindi tali certificati come si farebbe con qualunque segreto e seguire le migliori precedure industriali per le chiavi crittografiche ed i certificati. 1.5.2. Transizioni di Sistema aldifuori di Secure Boot Un aggiornamento BIOS o una sostituzione della scheda madre pruò disabilitare Secure Boot su sistemi dove era precedentemente abilitato. Hardware addizionaleinstallato sulla macchina potrebbe avere requisiti incompatibili col Secure Boot (DMA user space, supporto SystemTap, moduli kernel non-Red Hat). Questo significa che il Secure Boot non può essere un requisito per la funzionalità del sistema ed è estremamente imprudente renderlo tale. 7
Capitolo 1. Cos'é UEFI Secure Boot ? Bozza 1.5.3. Nessuna infrastruttura di provisioning oltre a Microsoft Windows Alcuni produttori di sistema a quanto si dice richiedono un'installazione di Windows 8 per attivare Secure Boot. Per i clienti che vogliono abilitare Secure Boot potrebbe essere necessario avere una licenza Windows 8 personalizzata dai fornitori. Questo scenario non dovrebbe essere rilevante sebbene Red Hat sia basata su una separata origine di sicurezza sotto il nostro controllo, prevista in collaborazione con i fornitori di hardware. 1.5.4. Procedure di revoca non provate Non sappiamo se gli affari che girano intorno alla revoca ad oggi funzionano. Le revoche sono complesse perché devono essere sincronizzate tra tutti i fornitori dei sistemi operativi per supportare le configurazioni dual-boot. Senza alcuna coordinazione, una firma su percorso d'avvio potrebbe essere revocata prima che il sistema operativo sottostante abbia avuto la possibilità di aggiornarlo. Questo renderebbe non avviabili i sistemi. Non è chiaro in quali circostanze Microsoft rilascerà una revoca non richiesta. Potenziali ragioni per la revoca sono un fallito raggiungimento di un obbiettivo di sicurezza (esecuzione di codice non firmato in modalità kernel, possibile in condizioni di laboratorio) o lo sfruttamento effettivo del guasto tale da compromettere il percorso di avvio dei sistemi Windows 8 fuori dai laboratori. Quest'ultima potrebbe valere anche per soluzioni sul Secure Boot nei quali si carica codice non firmato dopo l'interazione con l'utente. 8
Bozza Capitolo 2. Bozza 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 Figura 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─────────────────────────────┘ Figura 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 Figura 2.2, «UEFI firmware start screen» will be shown. 9
Capitolo 2. System Configuration Bozza 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 Figura 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 Sezione 2.1, «Entering the UEFI firmware». Press the → key until you reach the Security tab, as shown in Figura 2.3, «UEFI firmware Security tab». 10
Bozza 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 Figura 2.3. UEFI firmware Security tab Press ↓ until you reach the Secure Boot item and hit Enter. The Image Execution Policy screen appears (Figura 2.4, «UEFI firmware Secure Boot settings»). 11
Capitolo 2. System Configuration Bozza 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 Figura 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 Sezione 2.1, «Entering the UEFI firmware». Then press the → key until you reach the Exit tab, as shown in Figura 2.5, «UEFI firmware Exit tab». 12
Bozza 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 Figura 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 Figura 2.6, «UEFI firmware confirmation for OS Optimized Defaults»). 13
Capitolo 2. System Configuration Bozza 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 Figura 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 (Figura 2.3, «UEFI firmware Security tab»), press ↓ to select Secure Boot, hit Enter, and check that Secure Boot is enabled, as in Figura 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 Figura 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
Bozza Capitolo 3. Bozza Implementazione del UEFI Secure Boot Il Fedora Secure Boot include il supporto per due metodi di avvio con macchine Secure Boot. Il primo metodo utilizza il servizio di firma ospitato da Microsoft per fornire una copia del bootloader shim con le chiavi Microsoft. Il secondo metodo è una forma più generale del primo in cui un sito o un utente può creare le proprie chiavi, distribuirli nel firmware di sistema e firmare i propri file binari. 3.1. Chiavi La scelta di usare il servizio di firma Microsoft era basata sulla semplicità. La chiave usata da Microsoft viene distribuita a tutto l'hardware conosciuto, così come si deve iniziare a fare in Fedora in modo da poterla usare senza problemi. I rischi esistono avendo a che fare con un servizio da terzi. Fedora Project si impegna a rimanere attenta in questo senso e risponderà a tutte le nuove informazioni in modo appropriato. L'uso della chiave in Fedora può essere fonte di confusione a causa della sua complessità. Ecco come i vari componenti sono firmati. Shim: E' firmato dal servizio di firma UEFI. Noi non controlliamo questa chiave. Shim contiene la chiave pubblica Fedora Boot CA. GRUB: E' firmato attraverso "Fedora Boot Signer", che richiama la Fedora Boot CA. GRUB non contiene alcuna chiave, ma interpella shim per la sua verifica. Kernel: Anche questo firmato attraverso Fedora Boot Signer. Il kernel contiene la chiave pubblica usata per firmare i moduli kernel. I Moduli Kernel: Sono firmati con una chiave privata generata durante la loro costruzione. Questa chiave non viene salvata ma ne verrà generata una nuova con ogni kernel. La Secure Boot CA di Fedora è usata per verificare l'integrità di GRUB e del kernel. La chiave pubblica può essere trovata nel pacchetto sorgente di shim. I dettagli della chiave sono: 15
Capitolo 3. Implementazione del UEFI Secure Boot Bozza 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 Figura 3.1. Certificato Fedora X.509 per la firma di Kernel e GRUB 16
Bozza Shim 3.2. Shim Fedora usa un loader di primo stadio chiamato shim il quale incorpora un certificato CA auto-firmato. Questo CA è poi usato per verificare il bootloader GRUB 2 (versione UEFI, programma PE/COFF firmato con AuthentiCode). Prima dell'avvio del kernel, GRUB 2 richiama shim per verificare la firma AuthentiCode del kernel. Oltre alla chiave Microsoft, shim supporta un certificato sicuro addizionale fornito dal proprietario ed un meccanismo per disabilitare la verifica della firma. L'informazione è mantenuta nelle variabili UEFI, non può essere scritta dopo l'avvio del sistema operativo. Shim contiene un controllo di presenza fisica e chiede conferma prima di aggiornare le impostazioni memorizzate nelle variabili UEFI. In Fedora ci sono due pacchetti alla base di shim. Quello chiamato "shim" è il risultato della compilazione del codice sorgente e non avvia il sistema siccome non è firmato. La compilazione serve ad incorporare la firma nel pacchetto shim; il risultante pacchetto shim-firmato poi contiene il file binario firmato che permette l'avvio del sistema. Il pacchetto shim contiene anche una blacklist delle chiavi corrotte conosciute o dei binari che non dovrebbero essere avviati. La blacklist è un file chiamato dbx.esl. Attualmente è incorporata nel binario shim durante la costruzione del pacchetto. Impedisce l'avvio di apposite versioni di grub. Sviluppi futuri potrebbero prevedere l'inserimento della blacklist nella memeoria UEFI. Nella sua forma corrente, l'aggiornamento della lista non fornirà ulteriore sicurezza come è possibile fare un downgrade del pacchetto shim per non aggiornarla volutamente. Se la blacklist viene memorizzata nel BIOS, sopravviverebbe al downgrade. Esiste anche una blacklist mantenuta e firmata da Microsoft, memorizzata nel BIOS. Microsoft fornirà tale lista a Fedora Project per includerla. In base ad essa è possibile avere degli aggiornamenti periodici del pacchetto shim-firmato che non cambieranno il binario di shim. Il file della blacklist non esiste ancora siccome non c'é niente da listare. Probabilmete verrà pacchettizzata singolarmente per evitare aggiornamenti continui del pacchetto shim-firmato. I dettagli sulla blacklist devono arrivare da Microsoft. Noi non siamo in grado di aggiornarla autonomamente. I dati sono firmati con una chiave Microsoft che impedisce l'aggiornamento non autorizzato della lista. Microsoft ha dichiarato che la blacklist serve ad impedire che il computer utilizzi chiavi compromesse e non venga esposto a vulnerabilità conosciute. In entrambi i metodi, shim, GRUB ed il kernel verificheranno che sia attiva la "modalità User", così come descritto da UEFI, che prevede il Secure Boot abilitato, e in base a questo rilevamento convaliderà la fase successiva con una chiave crittografica pubblica Fedora-specifica prima dell'avvio. La validazione è fatta tramite shim per GRUB, quest'ultimo richiamerà shim per validare il kernel. Una volta avviato, il kernel verificherà a sua volta che sia attiva la modalità Secure Boot, iniziando una serie di controlli: Questo validerà la linea di comando di boot per permettere solo determinate impostazioni kernel verificherà la firma dei moduli kernel prima di caricarli e si rifiuterà di caricarli se sono senza firma o firmati con una firma non trovata nelle variabili del key store UEFI (vedi note) rifiuterà ogni operazione dallo spazio utente che possa causare una DMA 1 Informazioni addizionali su shim possono essere trovati sul repository di sviluppo di shim . 1 https://github.com/mjg59/shim 17
Capitolo 3. Implementazione del UEFI Secure Boot Bozza Note Altre distribuzioni hanno scelto di non richiedere moduli del kernel firmati nella loro implementazione del Secure Boot. Fedora crede che per il pieno supporto a Secure Boot questo sia necessario. Stiamo lavorando per limitare l'impatto di questa scelta, pur continuando a non permettere l'esecuzione dei moduli non fidati. 3.3. GRUB GRUB è contenuto nel pacchetto grub2 ed è firmato con la chiave Fedora CA. Una volta crittograficamente verificato, il binario viene eseguito da shim. Il pacchetto di GRUB non contiene alcuna chiave materiale. Quando GRUB necessita di verificare l'integrità del kernel, richiamerà shim per eseguire il controllo. 3.4. Kernel Il Kernel è firmato con una chiave Fedora CA ed è verificato da shim prima che GRUB permetta l'esecuzione. I moduli del kernel caricati sono firmati con una chiave generata nel momento della compilazione, poi distrutta. Il Kernel importerà il database delle chiavi UEFI ed le userà per verificare i moduli. Questo comporta che i moduli 3rd, provenienti da terzi e firmati con una chiave UEFI (Microsoft) sicura, verranno caricati nel Kernel quando Secure Boot è abilitato. Importante E' importante notare che una volta caricato il ramdisk iniziale (initrd), l'esecuzione non è più sicura. Nonostante initrd potrebbe contenere moduli kernel firmati, esso ingloba anche codice per spazio utente non firmato. L'integrità di tale codice non può essere garantita. 3.4.1. Restrizioni Le restrizioni sono adatte per essere pienamente compatibili con Secure Boot. Ciò richiede di impedire l'esecuzione di qualunque codice non verficato a livello di supervisore. La maggior parte degli utenti non noterà queste restrizioni siccome molti pacchetti che richiedono un accesso di questo tipo sono stati corretti per funzionare indipendentemente. Ci sono, comunque, in questo momento alcuni servizi o funzionalità che non funzioneranno in una macchina con Secure Boot abilitato. Sono: kexec/kdump ibernazione (sospensione su disco) moduli di terze parti che non sono firmati, o firmati con una chiave sconosciuta systemtap kernel probing (e kprobes) 18
Puoi anche leggere