Fedora 18 Guida al UEFI Secure Boot - Josh Boyer Kevin Fenzi Peter Jones Josh Bressers Florian Weimer - Fedora Docs

Pagina creata da Letizia Gargiulo
 
CONTINUA A LEGGERE
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