Secure Boot: il cambio dei certificati è reale, ma lato Linux non c’è motivo di preoccuparsi

Negli ultimi mesi, si è diffusa una certa preoccupazione nel mondo Linux e tra gli utenti più tecnici riguardo al cosiddetto rollover dei certificati Secure Boot. Ma serve davvero preoccuparsi per la scadenza di certificati UEFI usati da Microsoft per firmare i componenti di avvio? Come spesso accade, la realtà tecnica è più complessa e molto meno drammatica.

Nel corso del 2026, i due certificati Microsoft fondamentali per il funzionamento del Secure Boot nelle piattaforme UEFI andranno ufficialmente in scadenza. Si tratta di:

• Microsoft Windows Production PCA 2011: utilizzato per la firma del bootloader di Windows (scadenza: ottobre 2026)
• Microsoft Corporation UEFI CA 2011: usato per firmare altri componenti come Shim per Linux e driver UEFI di terze parti (scadenza: giugno 2026)

La prospettiva di una “imminente” scadenza di questi certificati ha sollevato preoccupazioni, soprattutto nel mondo Linux. Si teme, infatti, che tale evento possa compromettere l’avvio dei sistemi.  In realtà il cosiddetto Secure Boot certificate rollover è una transizione gestibile e nella maggior parte dei casi invisibile per l’utente.

Come funziona il Secure Boot: una panoramica tecnica

La funzionalità di sicurezza Secure Boot, parte delle specifiche UEFI, è progettata per impedire l’esecuzione di codice non autorizzato all’avvio del sistema. Ogni firmware UEFI mantiene due database principali:

• db: contiene i certificati affidabili (trust anchors)
• dbx: contiene gli hash dei certificati revocati

Un bootloader o driver firmato è considerato valido se la sua catena di certificazione è ricollegabile a un certificato presente in db e non è esplicitamente revocato in dbx.

Sui sistemi x86 moderni, il contenuto tipico di db include almeno due certificati Microsoft, quelli citati in apertura.

Il ruolo di Shim e la catena di fiducia

Parlando di Linux, si chiama Shim il bootloader firmato da Microsoft che funge da ponte tra la root of trust Microsoft e i componenti firmati da una distribuzione (GRUB, kernel, ecc.). Microsoft non firma direttamente software soggetto a licenze GPL (come GRUB): l’idea di Shim è nata proprio per aggirare tale limitazione con un meccanismo flessibile.

Una root (o root certificate authority) è un certificato radice di fiducia preinstallato nel firmware UEFI del sistema. Ogni componente avviato, come un bootloader, un driver o un kernel, deve essere firmato digitalmente con una catena di certificati che termina proprio in uno di questi certificati radice contenuti nel database db.

Shim è firmato da un certificato intermedio (i.e. “Microsoft Windows UEFI Driver Publisher“) che a sua volta è emesso dalla CA Microsoft 2011. Questo certificato intermedio, però, è scaduto nel 2024. Eppure, milioni di sistemi Linux avviano Shim ogni giorno senza problemi, nonostante la scadenza formale del certificato. Come mai?

La risposta sta nel modo in cui il firmware UEFI gestisce il tempo e le validazioni. Il firmware non ha accesso a un orologio attendibile; non dispone di un meccanismo sicuro e sincronizzato per determinare l’ora esatta. Non può verificare se “oggi” sia davvero una data successiva alla scadenza del certificato, e quindi non può valutare correttamente se una firma sia ancora valida in senso temporale.

Le conseguenze di un errore temporale sarebbero disastrose. Immaginate un sistema che, per un semplice errore dell’orologio interno o una batteria CMOS scarica, ritenga un certificato come già scaduto. Se il firmware decidesse di bloccare l’avvio basandosi su quell’informazione, l’utente si ritroverebbe con una macchina che non può più avviarsi, magari senza nemmeno output video, se il driver UEFI della GPU viene rifiutato.

Perché Microsoft sta cambiando i certificati?

Il rollover dei certificati è correlato a un processo di aggiornamento delle chiavi a lungo termine. Microsoft inizierà presto a firmare con una nuova catena di certificati che fa capo a una nuova root non ancora inclusa nei db della maggior parte dei dispositivi esistenti.

Il cambio di certificati non è una formalità amministrativa o un semplice ricambio programmato. È una risposta diretta a minacce concrete emerse negli ultimi anni, in particolare alla scoperta del bootkit BlackLotus, uno dei primi malware noti capaci di aggirare completamente il Secure Boot, anche quando attivo e configurato correttamente.

Nel 2022, ricercatori di sicurezza hanno documentato come BlackLotus riuscisse a sfruttare una vulnerabilità nota in vecchie versioni del bootloader Shim, già revocate tramite meccanismi come SBAT (Secure Boot Advanced Targeting). Il malware si installava nella catena di avvio, mantenendo persistenza pre-OS anche in presenza di Secure Boot e aggirava le protezioni sfruttando la fiducia residua concessa ai certificati non più sicuri.

Per ripristinare un elevato livello di fiducia nel Secure Boot, Microsoft ha quindi avviato un cambio della root of trust: i produttori di dispositivi hardware (i.e. schede madri) stanno progressivamente fornendo aggiornamenti del firmware per aggiungere il nuovo certificato root.

Da parte sua, Microsoft ha rilasciato un aggiornamento generico UEFI conforme con le specifiche ufficiali per iniettare la nuova root nel db, utilizzabile anche senza il supporto del produttore.

Cosa succede se una macchina ha solo la vecchia root o solo la nuova?

Per chi utilizza Secure Boot sulle proprie macchine, ci sono due scenari da considerare:

1. Sistema con solo vecchia root. Potrà avviare software firmato con la vecchia CA (attuale scenario). Potrebbe non avviare nuovi software firmati solo con la nuova CA. La soluzione consiste ovviamente nell’aggiornare db per aggiungere la nuova root (via vendor o aggiornamento generico Microsoft).
2. Sistema con solo la nuova root. Potrebbe non avviare sistemi firmati con la vecchia CA. Non compatibile con le vecchie versioni di Linux, Windows o hardware con vecchi driver UEFI. Scenario poco realistico, almeno nel breve termine.

Il vero rischio: casi particolari e distribuzioni Linux datate

Il rischio reale legato al cambio dei certificati Secure Boot riguarda soprattutto situazioni particolari e meno comuni, che coinvolgono:

• Sistemi senza possibilità di aggiornare il firmware, come hardware più vecchio non più supportato o dispositivi isolati senza connessione Internet.
• Sistemi embedded o dispositivi specializzati, che spesso hanno firmware rigidi e difficilmente aggiornabili.
• Distribuzioni Linux obsolete, che usano versioni di Shim firmate solo con il vecchio certificato di Microsoft e che non supportano sistemi più recenti di revoca come SBAT.

In questi casi, il problema non è che i sistemi smettano improvvisamente di funzionare, ma che potrebbe essere necessario un aggiornamento manuale delle chiavi di sicurezza presenti nel firmware per poter avviare nuove versioni del sistema operativo o componenti firmati con i nuovi certificati.

In pratica, bisognerà aggiornare la lista delle chiavi di fiducia per permettere al sistema di riconoscere e caricare correttamente i nuovi software firmati.