Secure Boot: perché un PC può avviare codice non firmato nonostante la protezione attiva

Il concetto di Secure Boot è spesso avvolto da un’aura di invincibilità. Molti utenti pensano che, una volta attivata questa funzione nel firmware UEFI del proprio computer, il sistema sia immune da qualsiasi minaccia in grado di infettare il processo di avvio (bootloader). Tuttavia, la realtà tecnica è molto più sfumata: il fatto che Secure Boot è attivo, ma un PC può avviare altro codice è una condizione non solo possibile, ma necessaria per garantire la flessibilità dei moderni ecosistemi informatici.

Capire come funziona questa tecnologia e perché esistano dei “buchi” deliberati nella sua catena di fiducia è fondamentale per chiunque voglia comprendere la sicurezza informatica moderna.

Che cos’è davvero Secure Boot?

Secure Boot non è un antivirus, ma una funzionalità di sicurezza definita nella specifica UEFI. Il suo scopo principale è garantire che ogni componente software caricato durante il processo di avvio — dal firmware all’hardware, fino al bootloader del sistema operativo — sia autentico e non sia stato manomesso.

Il sistema si basa su una “catena di fiducia” (Chain of Trust):

1. Platform Key (PK): La chiave principale, solitamente fornita dal produttore della scheda madre.
2. Key Exchange Key (KEK): Chiavi utilizzate per aggiornare i database delle firme.
3. Signature Database (db): Contiene le firme (o gli hash) dei bootloader e dei driver autorizzati.
4. Forbidden Signature Database (dbx): Un “black list” di firme di componenti che sono stati revocati a causa di vulnerabilità note.

Quando accendi il PC, il firmware UEFI controlla la firma digitale di ogni elemento caricato. Se la firma corrisponde a una chiave presente nel database (solitamente firmata da Microsoft o dai produttori di hardware), il sistema procede. In caso contrario, il boot viene bloccato.

Perché il PC può avviare altro codice?

Se il sistema è così rigido, perché possiamo installare distribuzioni Linux, utilità di ripristino o altri sistemi operativi senza che il Secure Boot impedisca l’avvio? La risposta risiede nella gestione delle chiavi e nella filosofia di apertura dell’ecosistema UEFI.

1. La supremazia delle chiavi Microsoft

La maggior parte dei PC venduti con Windows preinstallato contiene nel database del firmware la chiave di certificazione di Microsoft. Poiché Microsoft agisce come un ente certificatore terzo, firma il codice di molti produttori di hardware e di distribuzioni Linux, rendendo quel codice “fidato” agli occhi del PC. Questo è il motivo per cui molte distro Linux (come Ubuntu o Fedora) si avviano senza problemi: il loro bootloader è firmato da una chiave autorizzata dal firmware.

2. Lo shim: il ponte verso la libertà

Per le distribuzioni Linux che non desiderano (o non possono) far firmare ogni singolo componente da Microsoft, è stato introdotto lo shim. Lo shim è un piccolo bootloader firmato da Microsoft che funge da “intermediario”. Quando il firmware UEFI avvia lo shim, esso stesso verifica la firma dei successivi componenti (come il kernel Linux o GRUB) utilizzando chiavi personalizzate che non risiedono necessariamente nel database ufficiale del firmware.

Configurazione UEFI e il ruolo delle chiavi MOK

Qui entriamo nel vivo del controllo utente. Se desideri avviare un kernel Linux compilato personalmente, un driver non ufficiale o un sistema operativo meno convenzionale, il firmware UEFI standard non riconoscerebbe quelle firme. È qui che entrano in gioco le Machine Owner Keys (MOK).

Le chiavi MOK sono un meccanismo di sicurezza aggiuntivo che permette all’utente (il proprietario della macchina) di gestire una propria lista di chiavi fidate, distinta da quelle preimpostate dal produttore.

Come funzionano le MOK nella catena di fiducia:

• Registrazione: Quando provi a caricare un modulo o un bootloader non firmato dalle autorità standard, il sistema (tramite shim) ti permette di registrare la chiave pubblica corrispondente.
• Interazione utente: Questa operazione avviene solitamente al riavvio del computer, tramite una utility gestita dal firmware chiamata MokManager. Poiché questa procedura richiede un accesso fisico alla macchina e una conferma manuale, è considerata sicura.
• Fiducia estesa: Una volta che la chiave MOK è stata registrata nel database del sistema, lo shim inizierà a considerare “autorizzato” qualsiasi codice firmato con quella chiave.

Questo processo permette di mantenere Secure Boot attivo — garantendo che il firmware sia protetto da rootkit di basso livello — pur permettendo l’esecuzione di software personalizzato.

La vulnerabilità insita nella flessibilità

Il fatto che il sistema consenta questa flessibilità non è privo di rischi. Se la catena di fiducia viene estesa eccessivamente o se una chiave privata utilizzata per firmare il software cade in mani sbagliate, la protezione di Secure Boot viene annullata.

Ecco alcuni rischi critici:

• Vulnerabilità nei bootloader (es. BlackLotus): Esistono casi in cui bootloader firmati correttamente contengono falle di sicurezza che permettono l’esecuzione di codice arbitrario. Anche se il bootloader è “autorizzato”, il codice che esegue non lo è. Questo è il motivo per cui il database dbx deve essere costantemente aggiornato.
• Gestione impropria delle MOK: Se un utente ignaro registra una chiave MOK fornita da un software malevolo, sta di fatto consegnando le chiavi del regno a quel software.
• Configurazione del firmware: In alcuni casi, il firmware UEFI permette all’utente di passare alla “Modalità Setup” o di disabilitare completamente le verifiche. In questi scenari, il sistema non è più in grado di garantire l’integrità del processo di avvio.

Come verificare lo stato della tua sicurezza

Per capire cosa sta realmente accadendo sul tuo PC, puoi utilizzare gli strumenti forniti dal sistema operativo. Su Linux, ad esempio, il comando mokutil --list-enrolled ti permetterà di vedere quali chiavi sono attualmente riconosciute dal sistema tramite il meccanismo MOK.

Inoltre, puoi verificare lo stato del Secure Boot direttamente da terminale o tramite le impostazioni del firmware:

• Su Windows: Apri “Informazioni di sistema” e cerca la voce “Stato Secure Boot”.
• Su Linux: Usa il comando mokutil --sb-state.

Conclusioni: un equilibrio necessario

La percezione che Secure Boot sia un interruttore binario (acceso o spento) è riduttiva. È invece un ecosistema dinamico. Il fatto che un PC possa avviare software diverso da quello originale non è un difetto, ma una necessità di interoperabilità.

Grazie alla combinazione di shim e chiavi MOK, Secure Boot riesce a mantenere un equilibrio precario: da un lato impedisce ai malware di basso livello (come i bootkit) di radicarsi nel sistema, dall’altro permette agli utenti esperti e ai ricercatori di mantenere il controllo sul proprio hardware.

La vera sicurezza non risiede nel bloccare ogni possibilità di esecuzione, ma nel garantire che, se viene eseguito “altro codice”, sia stato l’utente stesso ad autorizzarlo consapevolmente attraverso la catena di fiducia gestita dal firmware. Per mantenere il sistema protetto, l’unico vero consiglio è mantenere il sistema operativo aggiornato (per gestire i database di revoca dbx) e prestare estrema attenzione a quali chiavi MOK si decide di aggiungere al proprio database interno.

La tecnologia è sicura, ma la sua configurazione richiede la consapevolezza di chi siede davanti allo schermo. Secure Boot è un guardiano attento, ma è il proprietario del PC a decidere, in ultima istanza, chi può oltrepassare il cancello.