INTRODUZIONE

 

UEFI E Secure Boot

La tecnologia UEFI ha rimpiazzato da molti anni il BIOS classico e sfrutta la crittografia asimmetrica per validare l’integrità del boot loader prima della sua esecuzione.
Il metodo di validazione si basa su una catena di fiducia (Chain of Trust):

• Il certificato PK (Platform Key), installato dal produttore della scheda madre, rappresenta la radice di fiducia dell’hardware.
• Mediante la PK viene autorizzata la KEK (Key Exchange Key), che identifica i produttori di sistemi operativi autorizzati a modificare i database delle firme.
• La KEK permette di aggiornare i database DB (Authorized Signature) e DBX (Forbidden Signature), che contengono i certificati o gli hash dei boot loader e dei driver effettivamente autorizzati all’avvio.

Microsoft, in quanto leader di mercato dei sistemi operativi per i PC, agisce come Autorità di Certificazione (CA) principale e le sue chiavi sono pre-installate nella quasi totalità dei dispositivi.
Di conseguenza, anche i sistemi Linux dipendono da questa infrastruttura: Microsoft firma digitalmente i componenti shim (piccoli boot loader intermedi), i quali a loro volta gestiscono una lista locale di chiavi chiamata MOK (Machine Owner Key).
Questo sistema a ponte permette alle distribuzioni Linux di aggiornare il proprio kernel senza dover richiedere una nuova firma a Microsoft per ogni rilascio.

Scadenza Microsoft Corporation UEFI CA 2011

Il certificato Microsoft Corporation UEFI CA 2011, utilizzato per oltre un decennio per firmare la quasi totalità dei boot loader e driver UEFI (inclusi quelli Linux), è giunto a fine vita naturale.
La scadenza non implicherà immediatamente il fallimento del boot dei sistemi operativi, poiché finché esso non verrà revocato, aggiungendolo al database DBX, i sistemi già installati potranno comunque avviarsi.
Tuttavia, verrà inibita la possibilità di installazione di nuovi sistemi operativi e non sarà più possibile applicare patch critiche per il boot loader, poiché le nuove versioni (firmate con la CA 2023) verrebbero considerate non attendibili dal firmware non aggiornato.
La sostituzione del vecchio certificato con la nuova CA 2023 non è una semplice operazione software, ma richiede un duplice intervento: l’aggiornamento delle variabili EFI attive (tramite patch del sistema operativo) e l’aggiornamento delle variabili di default (tramite aggiornamento del firmware BIOS/UEFI o caricamento manuale).
Il mancato aggiornamento, oltre alle limitazioni operative descritte, impedisce la revoca del vecchio certificato tramite DBX.
Questo lascia il parco macchine vulnerabile a boot loader compromessi o obsoleti, che possono essere sfruttati da malware di nuova generazione (come BlackLotus) per bypassare integralmente le protezioni del Secure Boot.

AUDITING

 

Prefazione

Prima di poter procedere con le operazioni correttive è necessario mappare lo stato attuale della propria flotta di dispositivi con Secure Boot attivo.
Tutti i comandi proposti in questo paragrafo necessitano dei diritti amministrativi (root o membro di Administrators) per poter essere eseguiti.
Le modifiche sul portale Microsoft Intune necessitano che l’utente abbia attivo il ruolo di Intune Administrator o di Global Administrator.

Audit dello stato del Secure Boot

Con i seguenti comandi è possibile verificare se il Secure Boot è abilitato e su Windows lo stato della CA 2023:

Metrica	PowerShell	Bash
Stato Secure Boot	((Get-SecureBootUEFI -Name SecureBoot).Bytes -contains 1)	mokutil –sb-state
Stato Update 2023	(Get-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing”).UEFICA2023Status	N/A

 

Audit dello stato del Secure Boot mediante Intune

Microsoft Intune include una funzionalità che analizza i dispositivi gestiti e genera un report dello stato del Secure Boot.
La funzionalità è disponibile solamente se si ha attivato la telemetria sul tenant, per farlo navigare su Tenant administration e poi cliccare su Connectors and tokens:

Selezionare Windows data ed abilitare Enable features that require Windows diagnostic data in processor configuration:

Affinché la modifica venga applicata è possibile che siano necessari fino a tre giorni.
Per visualizzare il report, navigare su Reports e selezionare Window quality update, navigare su Reports e selezionare Secure boot status:

Nella pagina successiva viene mostrato il report:

Mediante il pulsante Export è possibile esportarlo in un file CSV.
L’aggiornamento dello stato dei dispositivi può richiedere diverse ore da quando viene applicato a quando viene mostrato sul portale.

Audit dello stato delle variabili EFI

Di seguito viene riportata una tabella con i comandi necessari a verificare lo stato delle variabili EFI, al fine di evitare regressioni future, è necessario evidenziare la distinzione tra le variabili nello stato Active e quelle nello stato Default:

• Le variabili Active sono salvate nella NVRAM, vengono caricate durante il Secure Boot per essere utilizzate per la validazione del boot loader e possono venir aggiornate dal sistema operativo.
• Le variabili Default sono memorizzate nel chip BIOS/UEFI dal produttore della scheda madre, vengono utilizzate per sovrascrivere le variabili Active durante il ripristino alle impostazioni di fabbrica e per modificarle è necessario l’aggiornamento del firmware o l’upload manuale (dove applicabile).

 

Componente	Ambito		PowerShell		Bash
DB (Allowed)	Active (Live)		[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes) -match ‘2023’		grep -a “2023” /sys/firmware/efi/efivars/db-*
DB (Allowed)	BIOS (Default)		[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbDefault).Bytes) -match ‘2023’		grep -a “2023” /sys/firmware/efi/efivars/dbDefault-*
KEK (Editor)	Active (Live)		[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).Bytes) -match ‘2023’		grep -a “2023” /sys/firmware/efi/efivars/KEK-*
KEK (Editor)	BIOS (Default)		[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEKDefault).Bytes) -match ‘2023’		grep -a “2023” /sys/firmware/efi/efivars/KEKDefault-*
DBX (Revoked)	Active (Live)		[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).Bytes) -match ‘2011’		grep -a “2011” /sys/firmware/efi/efivars/dbx-*
DBX (Revoked)	BIOS (Default)		[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbxDefault).Bytes) -match ‘2011’		grep -a “2011” /sys/firmware/efi/efivars/dbxDefault-*

 

Audit della firma del boot loader

Successivamente, viene riportata una tabella con i comandi per verificare l’autorità emittente (issuer) che ha firmato il boot loader (o shim) in uso:

OS	Comando
Debian	apt-get install -y sbsigntool
	sbverify –list /boot/efi/EFI/debian/shimx64.efi
Proxmox	apt-get install -y sbsigntool
	mount /dev/sda2 /boot/efi # Not always required, change sda2
	sbverify –list /boot/efi/EFI/proxmox/shimx64.efi
RHEL	dnf install -y sbsigntools
	sbverify –list /boot/efi/EFI/redhat/shimx64.efi
Windows	mountvol Z: /S
	$bootMgrPath = “Z:\EFI\Microsoft\Boot\bootmgfw.efi”
	$signature = Get-AuthenticodeSignature -FilePath $bootMgrPath
	$signature.SignerCertificate.Issuer

 

Audit della firma dei drivers

Nella seguente tabella sono riportati i comandi per verificare l’autorità emittente (issuer) che ha firmato i drivers installati:

OS	Comando
Windows	$DriverPath = “C:\Windows\System32\drivers” Get-ChildItem -Path $DriverPath -Filter *.sys | ForEach-Object { $Signature = Get-AuthenticodeSignature -FilePath $_.FullName -ErrorAction SilentlyContinue [PSCustomObject]@{ FileName = $_.Name Subject = $Signature.SignerCertificate.Subject Issuer = $Signature.SignerCertificate.Issuer } } | Out-GridView -Title “Audit drivers signatures”

Su Linux generalmente non è necessario verificare che la firma dei drivers sia stata effettuata dalla nuova CA, poiché lo shim funge da intermediario nella catena di fiducia.

PROCEDURE DI RIMEDIO

 

Prefazione

Le procedure correttive descritte in questo capitolo si concentrano sull’inserimento della nuova CA 2023 in DB e sull’aggiornamento del boot loader.
In base al produttore dell’hardware e a quello del sistema operativo la procedura da applicare varia, si consiglia di procedere inizialmente seguendo i passaggi necessari per l’aggiornamento del firmware (dove applicabile) e successivamente all’applicazione della patch del sistema operativo.
Per i produttori di hardware per cui in questo documento non è stata fornita una procedura specifica è, tipicamente, possibile procedere effettuando l’aggiornamento del BIOS/firmware, oppure manualmente iniettando la CA direttamente in DB o in PK.
L’ultimo step consigliato è quello della revoca della CA 2011 inserendola in DBX, alcuni produttori, come HP, sconsigliano di procedere, poiché hanno implementato altre misure di sicurezza per mitigare i rischi legati ai rootkit come BlackLotus e perciò la procedura non porterebbe benefici reali.

Avvertenze sulla revoca

Le procedure manuali di revoca della CA 2011 rappresentano un’operazione distruttiva e irreversibile per la catena di avvio se eseguite prematuramente.
Non procedere con la revoca finché non è stata verificata l’intera catena di boot (boot loader, kernel, driver UEFI e firmware hardware).
L’applicazione del DBX su sistemi non pronti causerà un Secure Boot Violation, rendendo il sistema incapace di avviarsi.

Aggiornamento delle variabili di default e della firma del firmware

 

Macchine Virtuali

 

Proxmox

Le VM su Proxmox supportano il Secure Boot mediante il BIOS chiamato OVMF (UEFI) e l’aggiunta del disco EFI, in cui vengono memorizzare le variabili PK, DB, DBX e KEK attive.
Per una scelta di design del firmware OVMF, le variabili di default non sono disponibili all’interno delle VM, perciò è normale che venga restituito un errore quando si eseguono i rispettivi comandi indicati nella tabella di auditing.
Dalla versione 8.2 di Proxmox VE è stata introdotta una nuova funzionalità che consente agli amministratori di iniettare la nuova CA nelle variabili memorizzate nel disco EFI delle VM direttamente dalla Web UI.
Selezionare la VM da modificare, navigare nel menù Hardware, cliccare sul disco EFI e successivamente su Disk Action, nel menù a tendina che viene aperto è possibile selezionare Enroll Updated Certificates:

Si dovrebbe aprire una finestra di dialogo che avverte che la modifica delle variabili EFI potrebbe causare la finestra di ripristino BitLocker all’avvio successivo e che consiglia un comando da eseguire su PowerShell:

In realtà, il problema non è limitato al BitLocker, poiché qualsiasi strumento di sblocco automatico di partizioni cifrate mediante PCR 7 e TPM viene impattato (es. LUKS con systemd-cryptenroll) e perciò è necessario procedere con cautela.
Su alcune VM con BitLocker attivo potrebbe non essere richiesto effettuare questa operazione poiché lo sblocco mediante BitLocker utilizza dei profili di validazione diversi (es. PCR 0,2,4,11) che non includono
lo stato del database delle firme (PCR 7), ma per cautela si consiglia di procedere comunque.
Su Windows è possibile eseguire il seguente comando:

A differenza del commando proposto da Proxmox, questo impatta solo il primo riavvio.
Su Linux non esiste un comando che sospende la protezione perciò è necessario rimuovere lo slot dal TPM, riavviare la VM e ricrearlo.
Per rimuoverlo, se si utilizza systemd-cryptenroll, è possibile eseguire il seguente comando (sostituire sda3 con la partizione cifrata):

Sia su Windows che su Linux è fortemente consigliato effettuare il backup della chiave di ripristino BitLocker/LUKS prima di procedere e di non far affidamento solamente al TPM.

VMware 7 e precedenti

Su VMware 7 e precedenti non è disponibile la versione di virtual hardware necessaria per l’aggiornamento automatico delle variabili EFI.
A causa di questa limitazione si consiglia di procedere all’aggiornamento mediante la procedura specifica per il sistema operativo della macchina guest e di inserire una nota affinché nessuno effettui il reset delle variabili EFI dal BIOS della VM.
Se per qualche necessità specifica non fosse possibile procedere mediante patch del sistema operativo, Broadcom fornisce una procedura che permette di sostituire la PK della VM, permettendo quindi di iniettare la CA 2023.
La procedura prevede la creazione di un disco aggiuntivo, formattato in FAT32, in cui copiare la PK, in formato DER, scaricata dal repository ufficiale.
Al riavvio successivo, mediante la modifica di un parametro della VM, è possibile registrare la chiave.
KB di Broadcom: https://knowledge.broadcom.com/external/article/423919/manual-update-of-secure-boot-variables-i.html
Come per VMware 8 e successivi, è possibile aggiornare i VMware Tools alla versione 12.4 o superiore per garantire che i drivers siano firmati dalla nuova CA.

VMware 8 e successivi

Su VMware 8 e successivi è sufficiente aggiornare il virtual hardware per inserire tra le variabili EFI la nuova CA.
La versione hardware minima richiesta è la 21 che è stata introdotta con vSphere 8.0 Update 2:

Per far sì che anche i drivers vengano aggiornati, è necessario aggiornare i VMware Tools alla versione 12.4 o superiore, mediante il pacchetto ufficiale su Windows o il pacchetto open-vm-tools su Linux e BSD.

Macchine fisiche

 

PC

 

Prefazione

I produttori principali di PC hanno lavorato insieme a Microsoft per rendere la transizione alla nuova catena di fiducia il più trasparente possibile.
Nella maggior parte dei casi l’aggiornamento del BIOS, svolto manualmente o mediante la funzionalità Enterprise di Intune per l’aggiornamento del firmware, è sufficiente per aggiornare le variabili EFI di default, senza bisogno di disabilitare il BitLocker.

Dell

I PC Dell rilasciati dopo il 1° Gennaio 2026 includono già la nuova CA nelle variabili EFI, per quelli precedenti è necessario verificare sul sito del produttore se la versione del BIOS che si sta utilizzando è sufficientemente aggiornata.
Per effettuare questa verifica è possibile proseguire come segue:

• Navigare sul sito www.dell.com/support ed inserire il modello del proprio computer
• Navigare nella sezione “Driver e download” e scegliere BIOS come categoria
• Cliccare sulla versione del BIOS disponibile e selezionare “Leggi tutto” (Read More) sotto la voce Informazioni importanti (Important Information)
• Cercare la dicitura esatta: “This BIOS contains the new 2023 Secure Boot Certificates”

La presenza di questa frase conferma che i certificati sono integrati nell’aggiornamento.

HP

I PC HP rilasciati nel 2024 e successivi includono già la nuova CA nelle variabili EFI, per quelli precedenti, ma non ancora fuori ciclo vita (EOSL), è possibile aggiungerla mediante un aggiornamento del BIOS e per quelli non più supportati HP sta sviluppando un metodo di patching manuale per i sistemi operativi Windows client.
Quando il PC HP è pronto per proseguire con l’aggiornamento delle variabili EFI live, mediante Windows Update, l’output del seguente comando include la stringa SBKPFV3:

Se quella stringa non è presente, Windows non proverà ad eseguire l’aggiornamento delle variabili EFI in autonomia, però sarà comunque possibile forzarlo, a proprio rischio e pericolo, modificando la chiave di registro AvailableUpdates.
HP ha annunciato che non rilascerà un aggiornamento per la revoca della CA 2011 mediante DBX e sconsiglia di effettuare questa operazione manualmente.

Lenovo

Lenovo non fornisce una data dopo la quale i PC rilasciati ospitano già la nuova CA nelle variabili EFI, però fornisce una tabella che in base al modello indica la versione minima del BIOS richiesta.
La tabella è disponibile al seguente link: https://support.lenovo.com/us/en/solutions/HT518129

SERVERS

 

Prefazione

Analogamente a come avviene per i PC, mediante l’aggiornamento del BIOS è possibile aggiornare le variabili EFI di default dei servers della maggior parte dei produttori.
Molti produttori consentono l’iniezione manuale o mediante API dei certificati nelle variabili EFI, questa procedura è consigliata se non è disponibile un aggiornamento del firmware ufficiale.
Sui servers si raccomanda una maggiore cautela durante la revoca dei certificati, specialmente se non sono disponibili service pack recenti che includono gli aggiornamenti del firmware, poiché è più facile rompere la catena di fiducia rispetto che sui PC dove si trovano drivers più standard.

HPE

Per i server HPE, analogamente a come è avvenuto per gli altri produttori, sono stati rilasciati i service pack con l’aggiornamento del firmware per la transizione alla nuova catena di fiducia.
Inoltre, è possibile iniettare i nuovi certificati mediante le API Redfish delle iLO, nel caso in cui non si possa procedere con l’aggiornamento del firmware si debba procedere massivamente.

Aggiornamento delle variabili live e della firma del boot loader

 

Linux

 

Aggiornamento delle variabili live

Le variabili live su Linux vengono gestite diversamente in base a se si tratta di una macchina fisica o virtuale e nell’ultimo caso il comportamento varia in base al hypervisor.
Generalmente se non vengono modificate durante l’aggiornamento del firmware (o dell’hardware virtuale), ma le variabili di default risultano corrette, è possibile procedere dal BIOS al reset delle chiavi EFI, per far sì che esse vengano memorizzate in NVRAM sovrascrivendo le attuali variabili live.
In alternativa, è possibile provare ad aggiornarle eseguendo i seguenti comandi:

Come ultima spiaggia, se non sono presenti aggiornamenti firmware, è possibile iniettarle manualmente impostando il Secure Boot in modalità Setup Mode o Delete PK ed applicando a mano il file EFI Signature List (.esl).
Prima di procedere è necessario installare il pacchetto efitools, su Debian eseguire:

Per applicare a mano la patch di DB eseguire:

Analogamente, per applicare a mano la patch di DBX eseguire:

Se viene mostrato un errore simile al seguente, significa che non si ha autorizzato dal BIOS la modifica delle variabili EFI:

 

Aggiornamento della firma dello shim

Su Linux è necessario mantenere aggiornato il pacchetto shim-signed o shim-x64 affinché la nuova CA venga aggiunta tra le autorità emittenti dello shim.
In alcuni sistemi è possibile che nonostante il Secure Boot sia abilitato, il pacchetto sia mancante, in questi casi è necessario installarlo.

Su Debian eseguire:

Su RHEL eseguire:

Dal momento che il pacchetto viene installato sarà sufficiente installare gli aggiornamenti medianti package manager per mantenere la firma dello shim aggiornata.

Windows

 

Windows mediante Intune

Microsoft mediante Intune mette a disposizione tre policies per rimediare al problema della scadenza dei certificati:

Nome	Funzionalità	Caso d’uso
Configure Microsoft Update Managed Opt-In	Delega a Microsoft la gestione dell’aggiornamento (necessita la telemetria attiva – vedi capitolo Auditing)	Dispositivi per i quali non si è sicuri della compatibilità delle nuove chiavi EFI
Configure High Confidence Opt-Out	Inibisce l’aggiornamento delle chiavi EFI mediante aggiornamento mensile di qualità sui dispositivi con alta confidenza (testati da Microsoft)	Dispositivi per i quali non si vuole procedere all’aggiornamento delle chiavi EFI
Enable SecureBoot Certificate Updates	Richiede a Microsoft di installare la patch al prossimo aggiornamento mediante Window Update	Dispositivi su cui si ha testato le nuove chiavi EFI e si desidera procedere rapidamente alla loro distribuzione

 

Se si volesse procedere con l’aggiornamento delle variabili EFI mediante rollout automatico con Windows Update sarebbe importante assicurarsi di non aver configurato la policy Configure High Confidence Opt-Out o di averla configurata disabilitata.
Tutte le tre policies sono raggruppate nella stessa categoria, per configurarle recarsi sul portale Microsoft Intune, navigare su Devices, selezionare Windows e nella sezione Configuration, dopo aver cliccato su Create, selezionare New Policy:

Nel menù laterale selezionare la piattaforma Windows 10 and later ed il tipo Settings catalog, poi cliccare su Create per proseguire:

 

Assegnare un nome significativo alla policy e proseguire cliccando su Next:

Cliccare su Add settings, cercare Secure Boot e selezionare le policy desiderate.
Policy per il rollout automatico gestito da Microsoft (Configure Microsoft Update Managed Opt-In):

Policy per il rollout controllato dagli amministratori IT (Enable SecureBoot Certificate Updates):

Proseguire cliccando su Next, opzionalmente assegnare uno Scope tag e proseguire nuovamente cliccando su Next:

Nella schermata successiva è possibile assegnare la policy ad uno o più gruppi ed eventualmente prevedere delle esclusioni:

Dopo aver cliccato su Add groups è possibile selezionare il gruppo desiderato:

Proseguire cliccando su Next ed infine confermare cliccando su Create:

Aprendo la policy, cliccando su View report è possibile visualizzare il report per verificare su quali dispositivi è stata applicata:

Quando la policy viene applicata con successo viene mostrata la dicitura Success in prossimità del dispositivo che l’ha applicata:

Invece, in caso di errore, viene mostrata la dicitura Error in prossimità del dispositivo su cui la policy ha fallito:

Cliccando il nome del dispositivo viene mostrato il numero di errore:

Il codice 65000 indica un errore del CSP (Configuration Service Provider).
In ambienti virtualizzati come Proxmox, questo errore potrebbe venir causato dal firmware (OVMF) che blocca la scrittura delle variabili da parte del sistema operativo guest, poiché la gestione è delegata all’hypervisor.
Dopo qualche ora che la policy viene applicata ed il dispositivo viene riavviato, lo stato del certificato per il dispositivo sul report del Secure Boot cambia da Not up to date a Up to date.
Prima (Not up to date):

Dopo (Up to date):

Windows mediante GPO

In assenza di Intune, la distribuzione dell’aggiornamento può avvenire mediante GPO.
Queste policy operano secondo il principio del Desired State: il valore nel registro viene imposto in modo persistente (Registry Tattooing) e non viene rimosso automaticamente dal sistema operativo nemmeno a operazione conclusa.
Inoltre, su Intune le policies sono state tutte raggruppate in un’unica categoria, invece le GPO richiedono che venga abilitato l’aggiornamento degli altri prodotti Microsoft mediante una policy aggiuntiva (Windows Update for Business), che agisce sull’agente di Windows Update.
Infine, se si utilizza il WSUS (deprecato) è necessario assicurarsi che le classificazioni Updates e Security Updates siano sincronizzate e che non ci siano patch da approvare.

Di seguito una tabella riassuntiva delle policies:

Nome	Categoria	Descrizione
Enable Secure Boot Certificate Deployment	Secure Boot	Abilita l’aggiornamento delle variabili EFI per il Secure Boot mediante Windows Update (rilascio immediato)
Automatic Certificate Deployment via Updates	Secure Boot	Abilita l’aggiornamento automatico (abilitato di default), quando Microsoft ritiene che l’hardware lo supporti, mediante patch mensile (rilascio graduale)
Certificate Deployment via Controlled Feature Rollout	Secure Boot	Abilita l’aggiornamento automatico “intelligente”, mediante l’analisi dei dati diagnostici (rilascio controllato)
Configure Automatic Updates	Windows Update	Configura gli aggiornamenti automatici e mediante l’opzione “Install updates for other Microsoft products” abilita l’aggiornamento delle variabili EFI, oltre che di altri prodotti, come SQL Server, IIS…
Allow Diagnostic Data	Data Collection	Abilita i dati diagnostici, per utilizzare il rilascio controllato è necessaria almeno l’opzione “Send required diagnostic data”

 

Di seguito dove trovare le categorie interessate:

 

Nome	Percorso
Secure Boot	Computer Configuration > Administrative Templates > Windows Components > Secure Boot
Data Collection	Computer Configuration > Administrative Templates > Windows Components > Data Collection and Preview Builds
Windows Update	Computer Configuration > Administrative Templates > Windows Components > Windows Update > Manage end user experience

 

Aprire lo snap-in Group Policy Management, selezionare Group Policy Objects, effettuare click destro e cliccare su New:

Assegnare un nome alla policy e confermare cliccando su OK:

Selezionare la nuova policy, effettuare click destro e cliccare su Edit:

Navigare ai rispettivi percorsi indicati nella tabella precedente per configurare le policies.
Ad esempio, se si volesse configurare la policy per il rilascio immediato nella categoria Secure Boot bisognerebbe configurare come segue:

Inoltre, sarebbe necessario abilitare l’opzione Install updates for other Microsoft products nella policy Configure Automatic Updates:

È probabile che l’organizzazione abbia già configurato la policy nell’immagine precedente per gli aggiornamenti automatici, in questo caso è necessario abilitare l’opzione indicata in quella policy.
Se invece si utilizzasse la policy Certificate Deployment via Controlled Feature Rollout, per il rilascio controllato, essa richiederebbe che venga abilitata la telemetria required:

Dopo aver configurato le opzioni desiderate, selezionare la OU alla quale la si vuole assegnare, effettuare click destro e cliccare su Link an Existing GPO…:

Selezionare la policy e confermare cliccando su OK:

La rimozione della GPO non comporta la pulizia automatica del registro.

Windows mediante chiavi di registro

Se non sono disponibili strumenti di gestione remota come Intune e le GPO, è possibile intervenire direttamente sul registro.
Tutti i valori delle chiavi presenti delle seguenti tabelle riassuntive sono di tipo REG_DWORD.
Tabella riassuntiva per la chiave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot:

 

Nome	Descrizione
AvailableUpdates	Bitmask che abilita l’operazione di aggiornamento dei vari componenti coinvolti durante il Secure Boot
HighConfidenceOptOut	Se impostata a “1” viene bloccato il rilascio delle patch anche se il dispositivo viene considerato affidabile
MicrosoftUpdateManagedOptIn	Se impostata a “1” abilita il rilascio controllato (necessita la telemetria “required”)

 

Per il rilascio immediato delle patch per il Secure Boot si consiglia di impostare il valore 0x5944 della chiave AvailableUpdates.

RISOLUZIONE DEI PROBLEMI

 

Analisi del registro

Quando viene configurata la policy di Intune per l’aggiornamento automatico, la chiave AvailableUpdates viene impostata a 0x5944, nelle fasi successive la chiave viene decrementata dei valori bitmask delle rispettive fasi, ad esempio il valore 0x4400 significa che gli aggiornamenti di DB, KEK e della firma del boot loader sono conclusi con successo e che è necessario procedere alla modifica di DBX (revoca).
Il valore della chiave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing chiamato UEFICA2023Status descrive lo stato dell’aggiornamento mediante delle stringhe (più user friendly delle bitmask):

• NotStarted
• InProgress
• Updated

Sempre la stessa chiave, nella fase InProgress, memorizza i valori chiamati UEFICA2023Error e UEFICA2023ErrorEvent che riportano rispettivamente il codice ed il numero dell’evento del primo errore che è stato riscontrato durante l’aggiornamento della CA 2023 (se non si è concluso con successo o se è richiesto un riavvio).
Inoltre, essa memorizza anche i valori chiamati BootMgrLastUpdateError e BootMgrLastUpdateErrorReason che riportano il codice e la ragione del primo errore che è stato riscontrato durante l’aggiornamento the Boot Manager (boot loader).
Durante la fase InProgress potrebbe essere richiesto un riavvio manuale, dato che l’aggiornamento delle variabili EFI non scatena il riavvio automatico del dispositivo.
Situazione del registro prima dell’aggiornamento:

Situazione del registro durante l’aggiornamento:

Situazione del registro dopo l’aggiornamento:

In questo caso il PC non ha ancora revocato la CA 2011.

Analisi dell’Event Viewer

Mediante l’Event Viewer è possibile consultare i logs di sistema per capire in che fase dell’aggiornamento si trova il PC ed analizzare le cause di eventuali errori.
Aprire l’Event Viewer, navigare su Windows Logs > Service e selezionare Filter Current Log…:

Filtrare mediante Event Source impostandola su TPM-WMI:

Di seguito una tabella riassuntiva degli eventi:

 

Event ID	Descrizione	Azione
1808	Aggiornamento completato: variabili EFI e boot loader aggiornati	Nessuna
1801	Le chiavi non sono ancora applicate. Indica lo stato di Confidence e i Buckets di rollout	Attendere
1036 / 1045	DB aggiornato correttamente con la CA 2023	Nessuna
1037	DBX aggiornato correttamente con la CA 2011 (i vecchi supporti di boot, tipo le ISO, non funzioneranno più)	Aggiornare i media di Recovery e le ISO/templates sul virtualizzatore
1043	KEK aggiornata correttamente con la CA 2023	Nessuna
1795 / 1796	Errore del firmware o errore generico di scrittura in NVRAM	Riavviare ed eventualmente verificare le patch del firmware
1032	L’aggiornamento è sospeso perché manderebbe BitLocker in modalità Recovery	Sospendere temporaneamente il BitLocker per 2 reboot e riavviare
1033	Rilevato un componente del boot non compatibile con la revoca mediante DBX	Aggiornare il firmware e/o i drivers e riavviare
1797 / 1798	Fallito il controllo preliminare prima della revoca mediante DBX	Verificare se la CA 2023 sia presente in DB e che il boot loader sia stato firmato da essa