Secure Boot è un meccanismo di sicurezza definito nelle specifiche UEFI (Unified Extensible Firmware Interface) che verifica la firma crittografica di ogni componente della catena di avvio — bootloader, driver UEFI, kernel del sistema operativo — prima di eseguirlo. Se la firma non è valida o non è firmata con una chiave fidata, il componente viene rifiutato e il boot si interrompe. L’obiettivo è impedire l’esecuzione di codice non autorizzato durante la fase di avvio, prima che il sistema operativo e le sue difese siano operativi.
Il problema che risolve
I bootkit e i rootkit pre-OS sono tra le forme di malware più pericolose perché si installano nella catena di avvio (MBR, VBR, UEFI firmware) e vengono eseguiti prima del sistema operativo, con privilegi superiori a qualsiasi software di sicurezza. Un rootkit pre-OS può nascondere la propria presenza al sistema operativo e persistere attraverso reinstallazioni dell’OS che non toccano il firmware. Secure Boot taglia alla radice questo vettore verificando l’autenticità di ogni step del boot.
Database di chiavi UEFI
Secure Boot si basa su un insieme di database memorizzati nella memoria non volatile del firmware UEFI:
PK (Platform Key): la chiave radice del sistema Secure Boot. Chi possiede la PK controlla l’intera catena di fiducia. Tipicamente detenuta dal produttore dell’hardware (OEM). È firmata da sé stessa.
KEK (Key Exchange Key): chiavi autorizzate ad aggiornare i database db e dbx. Microsoft e i produttori di hardware mantengono KEK nei sistemi commerciali.
db (Signature Database): database delle firme e dei certificati fidati. Un bootloader o driver è eseguibile se il suo hash è nel db o se è firmato con un certificato la cui catena risale a un certificato nel db. Microsoft CA (usata per firmare Windows Boot Manager e shim per Linux) è nel db di tutti i PC compatibili Windows.
dbx (Forbidden Signature Database): blacklist di firme revocate. Usato per bloccare versioni vulnerabili di bootloader che potrebbero essere usate per aggirare Secure Boot (es. i numerosi aggiornamenti dbx per revocare versioni vulnerabili di GRUB, shim e bootloader Windows).
Flusso di verifica
UEFI Firmware (verificato dal TPM/flash protetto)
└── verifica firma → Bootloader (Windows Boot Manager / GRUB shim)
└── verifica firma → Kernel
└── verifica firma → Moduli del kernel (driver)Ogni livello verifica il successivo prima di cedergli il controllo. La catena di fiducia parte dal firmware UEFI — che deve essere a sua volta protetto da scrittura non autorizzata (flash protection) e misurato dal TPM.
Secure Boot su Linux
Linux non è firmato direttamente con la Microsoft CA. La soluzione adottata è lo shim: un piccolo bootloader firmato da Microsoft che a sua volta verifica e carica GRUB con un certificato proprio della distribuzione. Ogni distribuzione principale (Ubuntu, Fedora, Debian) ha il proprio certificato di firma per il kernel. Questo permette di avviare Linux su sistemi con Secure Boot abilitato senza modificare i database UEFI.
Limitazioni e critiche
Controllo del vendor: su molti laptop consumer, il PK è detenuto solo dall’OEM e Microsoft — l’utente non può aggiungere proprie chiavi senza disabilitare Secure Boot. Su workstation e server, tipicamente è possibile gestire i propri database di chiavi.
Non protegge il firmware stesso: Secure Boot verifica i componenti caricati dal firmware, ma non protegge il firmware UEFI da modifiche (attacchi come LoJax, MosaicRegressor). La protezione del firmware richiede meccanismi separati (Intel Boot Guard, AMD Platform Secure Boot, write protection hardware del flash SPI).
BootHole e simili: nel 2020 è stata scoperta una vulnerabilità critica in GRUB2 (BootHole, CVE-2020-10713) che permetteva di bypassare Secure Boot anche con bootloader firmato. Ha richiesto il più grande aggiornamento dbx della storia — con effetti collaterali su molte distribuzioni Linux. Dimostra che la sicurezza della catena dipende dall’assenza di vulnerabilità nei componenti firmati, non solo dalla verifica delle firme.