Guida al UEFI Secure Boot

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
Autore
Autore
Autore
Autore
Editor
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.
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. UEFI Secure Boot ........................................................................................................
1.2. Requisiti Microsoft per Boot Sicuro ................................................................................
1.2.1. Dettagli sull'implementazione ..............................................................................
1.3. Fedora Secure Boot .....................................................................................................
1.4. Da cosa protegge Secure Boot ? ..................................................................................
1.5. Potenziali rischi del Secure Boot ...................................................................................
1.5.1. Rimozione forzata di funzionalità in modalità Secure Boot ....................................
1.5.2. Transizioni di Sistema aldifuori di Secure Boot ....................................................
1.5.3. Nessuna infrastruttura di provisioning oltre a Microsoft Windows ...........................
1.5.4. Procedure di revoca non provate ........................................................................
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. Implementazione del UEFI Secure Boot
3.1. Chiavi ........................................................................................................................
3.2. Shim ..........................................................................................................................
3.3. GRUB ........................................................................................................................
3.4. Kernel ........................................................................................................................
3.4.1. Restrizioni .......................................................................................................
15
15
17
18
18
18
4. Strumenti
4.1. Shim ..........................................................................................................................
4.2. Pesign .......................................................................................................................
4.3. EFIKeyGen ................................................................................................................
4.4. sign-file ......................................................................................................................
21
21
21
21
21
5. Utilizzare le proprie chiavi
5.1. Creazione chiavi .........................................................................................................
5.2. Ottenere le chiavi per la compilazione di shim ..............................................................
5.3. Pacchetti che necessitano di essere ricostruiti ..............................................................
5.4. Registrazione delle proprie chiavi nel firmware .............................................................
23
23
23
23
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
[email protected] al prompt della shell. Se la macchina remota è
example.com ed il nome utente sulla macchina interessata è john, digitare ssh
[email protected].
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: packageversion-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
books_tests
vi
Desktop
Desktop1
documentation
downloads
drafts
images
mss
notes
photos
scripts
stuff
svgs
svn
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
AEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBTV
9lbLj+iiXGJo0T2UkFvXzpoYxDBWBgNVHR8ETzBNMEugSaBHhkVodHRwOi8vY3Js
Lm1pY3Jvc29mdC5jb20vcGtpL2NybC9wcm9kdWN0cy9NaWNSb29DZXJBdXRfMjAx
MC0wNi0yMy5jcmwwWgYIKwYBBQUHAQEETjBMMEoGCCsGAQUFBzAChj5odHRwOi8v
d3d3Lm1pY3Jvc29mdC5jb20vcGtpL2NlcnRzL01pY1Jvb0NlckF1dF8yMDEwLTA2
LTIzLmNydDANBgkqhkiG9w0BAQsFAAOCAgEAFPx8cVGlecJusu85Prw8Ug9uKz8Q
Secure Boot
3
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----MIIGEDCCA/igAwIBAgIKYQjTxAAAAAAABDANBgkqhkiG9w0BAQsFADCBkTELMAkG
A1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQx
HjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjE7MDkGA1UEAxMyTWljcm9z
b2Z0IENvcnBvcmF0aW9uIFRoaXJkIFBhcnR5IE1hcmtldHBsYWNlIFJvb3QwHhcN
5
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
Capitolo 2.
Bozza
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
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
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
Bozza
Restrizioni
Note
In futuro le iterazioni di supporto Secure Boot potranno anche essere possibili, tuttavia le
implementazioni per la sicurezza non sono fattibili con i tempi in the Fedora 18. Se serve
supporto per una qualsiasi di queste funzionalità, Secure Boot deve essere disabilitato.
Importante
Attualmente, shim in Fedora è firmato con scadenza Ottobre 2013, prima dell'end-of-life di
Fedora 18. Non siamo a conoscenza di tutto l' hardware che rispetta questa data di scadenza,
ma non sarà sempre così. Questa è la scadenza data alla firma da parte di Microsoft, Fedora non
ha controllo su di essa. Stiamo investigando a proposito e ci si aspetta di risolvere in futuro.
19
20
Bozza
Capitolo 4.
Bozza
Strumenti
Sono stati sviluppati diversi strumenti per permettere a Fedora di lavorare con il firmware UEFI Secure
Boot.
4.1. Shim
Shim è il software crittograficamente firmato che "crea la fiducia" tra il firmware UEFI e GRUB ed il
kernel. Shim è firmato crittograficamente da Verisign (attraverso Microsoft) così che il firmware possa
riconoscere il sistema Fedora e permettere al software di continuare nel processo di avvio. Shim
valida GRUB ed il kernel con una verifica crittografica basata sulla chiave Fedora usata per firmarli
tutti e tre.
4.2. Pesign
Pesign permette agli utenti di creare il proprio shim ed usare le proprie chiavi crittografiche. Usando
questo strumento, si può creare il proprio modello di sicurezza e non si è dovuti a richiedere quello
Microsoft. Una volta create le proprie chiavi e firmato il proprio shim, ed eventualmente firmati e
compilati GRUB e kernel, è possibile usare la modalità setup nel firmware per installare Fedora ed
usare lo strumento sbsetup come previsto da pesign per iscrivere le chiavi nel firmware.
4.3. EFIKeyGen
4.4. sign-file
21
22
Bozza
Capitolo 5.
Bozza
Utilizzare le proprie chiavi
5.1. Creazione chiavi
5.2. Ottenere le chiavi per la compilazione di shim
5.3. Pacchetti che necessitano di essere ricostruiti
5.4. Registrazione delle proprie chiavi nel firmware
23
24
Bozza
Bozza
Appendice A. Storico Revisioni
Revisione
Tue 11 March 2013
18.4
Aggiunti chiarimenti su alcune sezioni.
Eric Christensen
[email protected]
Revisione
Tue 19 February 2013
18.3
Include informazioni dai repository Floran.
Aggiunta figure.
Eric Christensen
[email protected]
Revisione
Wed 06 February 2013
Eric Christensen
18.2
[email protected]
Aggiunto testo in tutti i capitoli che include informazioni sulle chiavi pubbliche.
Revisione
Fri 04 January 2013
Eric Christensen
18.1
[email protected]
Capitolo 'Cosa è Secure Boot' aggiornato. (BZ 891758)
Capitolo 'Implementazione' aggiornato. (BZ 891924)
Updated Josh Boyer's email address. (BZ 891932)
Revisione 0
Thu Jul 12 2012
Eric Christensen
[email protected]
Creazione iniziale del libro con publican
25
26
Bozza
Bozza
Indice analitico
C
commento
informazioni di contatto per questo manuale,
viii
E
EFIKeyGen
definizione, 21
F
Fedora Secure Boot CA, 15
G
GRUB
integrity, 15
key, 15
K
kernel
integrity, 15
key, 15
keys
expiration
Fedora 18, 19
Fedora Secure Boot CA
public key, 15
GRUB, 15
kernel, 15
shim, 15
P
pesign
definizione, 21
sbsetup, 21
S
Secure Boot
blacklist, 17
implementation, 15
keys, 15
(vedi anche keys)
restrictions, 18
shim
definition, 21
explanation, 17
key, 15
sign-file
definizione, 21
27
28