Abilitazione di avvio protetto, BitLocker e Device Guard in Windows 10 IoT Core

Articolo
04/03/2023

Windows 10 IoT Core include funzionalità di sicurezza come l'avvio protetto UEFI, la crittografia dei dispositivi BitLocker e Device Guard. Questi consentono ai generatori di dispositivi di creare dispositivi Windows IoT completamente bloccati che sono resilienti a molti tipi diversi di attacchi. Insieme, queste funzionalità forniscono la protezione ottimale che garantisce che una piattaforma verrà avviata in modo definito, bloccando i file binari sconosciuti e proteggendo i dati utente tramite l'uso della crittografia del dispositivo.

Ordine di avvio

È necessaria una conoscenza dell'ordine di avvio in un dispositivo Windows 10 IoT Core prima di poter approfondire i singoli componenti che forniscono una piattaforma sicura per il dispositivo IoT.

Esistono tre aree principali che si verificano da quando un dispositivo IoT è acceso, fino al caricamento e all'esecuzione del kernel del sistema operativo dell'applicazione installata.

Avvio protetto della piattaforma
Avvio protetto UEFI (Unified Extensible Firmware Interface)
Integrità del codice di Windows

Boot Order

Altre informazioni sul processo di avvio di Windows 10 sono disponibili qui.

Blocco dei dispositivi IoT

Per bloccare un dispositivo Windows IoT, è necessario tenere presenti le considerazioni seguenti.

Avvio protetto della piattaforma

Quando il dispositivo è acceso per la prima volta, il primo passaggio del processo di avvio complessivo consiste nel caricare ed eseguire caricatori di avvio del firmware, che inizializzano l'hardware sulle deviazioni e forniscono funzionalità di flashing di emergenza. L'ambiente UEFI viene quindi caricato e il controllo viene consegnato.

Questi caricatori di avvio del firmware sono specifici di SoC, quindi sarà necessario collaborare con il produttore del dispositivo appropriato per fare in modo che questi caricatori di avvio vengano creati nel dispositivo.

Avvio protetto UEFI

L'avvio protetto UEFI è il primo punto di imposizione dei criteri e si trova in UEFI. Limita il sistema a consentire solo l'esecuzione di file binari firmati da un'autorità specificata, ad esempio driver firmware, rom di opzione, driver UEFI o applicazioni e caricatori di avvio UEFI. Questa funzionalità impedisce l'esecuzione di codice sconosciuto sulla piattaforma e il potenziale indebolimento del comportamento di sicurezza. L'avvio protetto riduce il rischio di attacchi malware di preavvio al dispositivo, ad esempio i rootkit.

L'OEM deve archiviare i database di avvio protetto UEFI nel dispositivo IoT in fase di produzione. Questi database includono il database della firma (db), il database di firma revocato (dbx) e il database della chiave di registrazione chiave (KEK). Questi database vengono archiviati nel firmware non volatile RAM (NV-RAM) del dispositivo.

Database delle firme (db): elenca i firmatari o gli hash delle immagini dei caricatori del sistema operativo, delle applicazioni UEFI e dei driver UEFI che possono essere caricati nel dispositivo
Database delle firme revocato (dbx): elenca i firmatari o gli hash delle immagini dei caricatori del sistema operativo, delle applicazioni UEFI e dei driver UEFI non più attendibili e non possono essere caricati nel dispositivo
Key Enrollment Key database (KEK): contiene un elenco di chiavi di firma che possono essere usate per aggiornare la firma e i database di firma revocati.

Dopo aver creato e aggiunto questi database al dispositivo, l'OEM blocca il firmware dalla modifica e genera una chiave di firma della piattaforma (PK). Questa chiave può essere usata per firmare gli aggiornamenti della chiave kek o per disabilitare l'avvio protetto UEFI.

Ecco i passaggi eseguiti dall'avvio protetto UEFI:

Dopo l'accensione del dispositivo, i database di firma vengono controllati in base alla chiave di firma della piattaforma (PK).
Se il firmware non è attendibile, il firmware UEFI avvia il ripristino specifico dell'OEM per ripristinare il firmware attendibile.
Se Windows Boot Manager non può essere caricato, il firmware tenterà di avviare una copia di backup di Windows Boot Manager. In caso di errore, il firmware UEFI avvia una correzione specifica dell'OEM.
Windows Boot Manager viene eseguito e verifica la firma digitale del kernel di Windows. Se attendibile, Windows Boot Manager passa il controllo al kernel di Windows.

Altre informazioni sull'avvio protetto, insieme alle linee guida per la creazione e la gestione delle chiavi, sono disponibili qui.

Integrità del codice di Windows

L'integrità del codice di Windows migliora la sicurezza del sistema operativo convalidando l'integrità di un driver o di un'applicazione ogni volta che viene caricata in memoria. CI contiene due componenti principali: Integrità del codice in modalità kernel (KMCI) e Integrità del codice in modalità utente (UMCI).

L'integrità del codice configurabile è una funzionalità di Windows 10 che consente ai generatori di dispositivi di bloccare un dispositivo e di consentirne solo l'esecuzione e l'esecuzione di codice firmato e attendibile. A tale scopo, i generatori di dispositivi possono creare criteri di integrità del codice in un dispositivo "golden" (versione finale dell'hardware e del software) e quindi proteggere e applicare questi criteri in tutti i dispositivi sul piano della fabbrica.

Per altre informazioni sulla distribuzione di criteri di integrità del codice, controllo e imposizione, vedere la documentazione technet più recente qui.

Ecco i passaggi eseguiti dall'integrità del codice di Windows:

Il kernel di Windows verificherà tutti gli altri componenti nel database della firma prima del caricamento. Sono inclusi driver, file di avvio e ELAM (antimalware di avvio anticipato).
Il kernel di Windows caricherà i componenti attendibili nel processo di avvio e proibirà il caricamento dei componenti non attendibili.
Il sistema operativo Windows 10 IoT Core viene caricato, insieme alle applicazioni installate.

Crittografia dispositivo BitLocker

Windows 10 IoT Core implementa anche una versione leggera di Crittografia dispositivi BitLocker, proteggendo i dispositivi IoT dagli attacchi offline. Questa funzionalità ha una forte dipendenza dalla presenza di un TPM sulla piattaforma, incluso il protocollo di pre-sistema operativo necessario in UEFI che esegue le misurazioni necessarie. Queste misurazioni pre-sistema operativo assicurano che il sistema operativo in un secondo momento abbia un record definitivo del modo in cui il sistema operativo è stato avviato; tuttavia, non applica alcuna restrizione di esecuzione.

Suggerimento

La funzionalità BitLocker in Windows 10 IoT Core consente la crittografia automatica del volume del sistema operativo basato su NTFS, associando al contempo tutti i volumi di dati NTFS disponibili. A tale scopo, è necessario assicurarsi che il GUID del volume EFIESP sia impostato su C12A7328-F81F-11D2-BA4B-00A0C93EC93B.

Device Guard in Windows IoT Core

La maggior parte dei dispositivi IoT viene compilata come dispositivi a funzione fissa. Ciò implica che i generatori di dispositivi conoscono esattamente quale firmware, sistema operativo, driver e applicazioni devono essere in esecuzione in un determinato dispositivo. A sua volta, queste informazioni possono essere usate per bloccare completamente un dispositivo IoT consentendo solo l'esecuzione di codice noto e attendibile. Device Guard in Windows 10 IoT Core consente di proteggere i dispositivi IoT assicurando che il codice eseguibile sconosciuto o non attendibile non possa essere eseguito nei dispositivi bloccati.

Sicurezza chiavi in mano in IoT Core

Per semplificare l'abilitazione delle principali funzionalità di sicurezza nei dispositivi IoT Core, Microsoft fornisce un pacchetto di sicurezza Chiavi in mano che consente ai generatori di dispositivi di compilare dispositivi IoT completamente bloccati. Questo pacchetto consentirà di:

Provisioning delle chiavi di avvio protetto e abilitazione della funzionalità nelle piattaforme IoT supportate
Installazione e configurazione della crittografia dei dispositivi con BitLocker
Avvio del blocco del dispositivo per consentire solo l'esecuzione di applicazioni e driver firmati

La procedura seguente consentirà di creare un'immagine di blocco usando il pacchetto di sicurezza Chiavi in mano

Create lockdown image

Prerequisiti

Un PC che esegue Windows 10 Enterprise (altre versioni di Windows non sono supportate dagli script forniti)
Windows 10 SDK - Obbligatorio per la generazione di certificati
Windows 10 ADK - Obbligatorio per la generazione cab
Piattaforma di riferimento: l'hardware di rilascio con firmware, sistema operativo, driver e applicazioni sarà necessario per il blocco finale

Dispositivi IoT di sviluppo

Windows 10 IoT Core funziona con vari siliconi usati in centinaia di dispositivi. Tra i dispositivi di sviluppo IoT suggeriti, i seguenti forniscono funzionalità TPM del firmware predefinite, insieme alle funzionalità di avvio protetto, avvio misurato, BitLocker e Device Guard:

Qualcomm DragonBoard 410c

Per abilitare l'avvio protetto, potrebbe essere necessario effettuare il provisioning di RPMB. Una volta che eMMC è stato lampeggiato con Windows 10 IoT Core (come indicato qui, premere [Power] + [Vol+] + [Vol-] contemporaneamente nel dispositivo quando si accende e selezionare "Provision RPMB" dal menu BDS. Si noti che si tratta di un passaggio irreversibile.
Intel MinnowBoardMax

Per MinnowBoard Max di Intel, la versione del firmware deve essere 0.82 o successiva (ottenere il firmware più recente). Per abilitare le funzionalità TPM, accendere la scheda con una tastiera e uno schermo collegato e premere F2 per immettere la configurazione UEFI. Passare a Gestione dispositivi -> Installazione del sistema -> Configurazione di sicurezza -> PTT e impostarla su <Abilita>. Premere F10 per salvare le modifiche e procedere con un riavvio della piattaforma.

Nota

Raspberry Pi 2 o 3 non supporta TPM e quindi non è possibile configurare gli scenari di blocco.

Generare pacchetti di blocco

Seguire le istruzioni nei due collegamenti seguenti:

Testare i pacchetti di blocco

È possibile testare i pacchetti di sicurezza generati qui <YOUR_IOT_ADD_ON_WORKSPACE>\Build<ARCH><OEM_NAME>. Sicurezza.* .cab> installandoli manualmente in un dispositivo sbloccato seguendo questa procedura

Eseguire il flashing del dispositivo con l'immagine sbloccata (immagine usata per l'analisi nel passaggio precedente).
Connessione al dispositivo (tramite SSH o con PowerShell)
Copiare i file di .cab seguenti nel dispositivo in una directory, ad esempio c:\OemInstall
- OEM. Custom.Cmd.cab
- OEM. Security.BitLocker.cab
- OEM. Security.SecureBoot.cab
- OEM. Security.DeviceGuard.cab
Avviare la gestione temporanea dei pacchetti generati eseguendo i comandi seguenti
```
applyupdate -stage c:\OemInstall\OEM.Custom.Cmd.cab
```
Se si usa un'immagine personalizzata, sarà necessario ignorare questo file e modificare c:\windows\system32\oemcustomization.cmd manualmente con il contenuto disponibile nel Output\OEMCustomization\OEMCustomization.cmd file
```
applyupdate -stage c:\OemInstall\OEM.Security.BitLocker.cab
applyupdate -stage c:\OemInstall\OEM.Security.SecureBoot.cab
applyupdate -stage c:\OemInstall\OEM.Security.DeviceGuard.cab
```
Infine, eseguire il commit dei pacchetti tramite
```
applyupdate -commit
```
Il dispositivo verrà riavviato nel sistema operativo di aggiornamento (che mostra gli ingranaggi) per installare i pacchetti e riavvierà nel sistema operativo principale. Dopo il riavvio del dispositivo in MainOS, l'avvio protetto verrà abilitato e SIPolicy dovrebbe essere attivato.
Riavviare il dispositivo per attivare la crittografia BitLocker.
Testare le funzionalità di sicurezza
- SecureBoot: provare bcdedit /debug on , verrà visualizzato un errore che informa che il valore è protetto da criteri di avvio protetto
- BitLocker: eseguire start /wait sectask.exe -waitencryptcomplete:1, se ERRORLEVEL è -2147023436 (ERROR_TIMEOUT), la crittografia non è completa. Quando si esegue sectask.exe da un file di .cmd omettere .start /wait
- DeviceGuard: eseguire qualsiasi file binario non firmato o un file binario firmato con certificato non incluso nell'elenco SIPolicy e verificare che non venga eseguito.

Generare un'immagine di blocco

Dopo aver verificato che i pacchetti di blocco funzionino in base alle impostazioni definite in precedenza, è quindi possibile includere questi pacchetti nell'immagine seguendo i passaggi indicati di seguito. Leggere la guida alla produzione IoT per istruzioni di creazione di immagini personalizzate.

Nella directory dell'area di lavoro aggiornare i file seguenti dalla directory di output generata in precedenza
- SecureBoot : Copy ..\Output\SecureBoot\*.bin ..\Workspace\Common\Packages\Security.SecureBoot
  - SetVariable_db.bin
  - SetVariable_kek.bin
  - SetVariable_pk.bin
- Bitlocker: Copy ..\Output\Bitlocker\*.* ..\Workspace\Common\Packages\Security.Bitlocker
  - DETask.xml
  - Security.Bitlocker.wm.xml
  - setup.bitlocker.cmd
- DeviceGuard : Copy ..\Output\DeviceGuard\*.* ..\Workspace\Common\Packages\Security.DeviceGuard
  - SIPolicyOn.p7b
  - SIPolicyOff.p7b
Aggiungere RetailOEMInput.xml e TestOEMInput.xml nella directory ProductName con l'ID funzionalità del pacchetto di blocco
- <Feature>SEC_BITLOCKER</Feature>
- <Feature>SEC_SECUREBOOT</Feature>
- <Feature>SEC_DEVICEGUARD</Feature>
Generare nuovamente l'immagine
- buildpkg all In questo modo vengono generati nuovi pacchetti di blocco in base ai file di criteri precedenti.
- buildimage ProductName test(or)retail (questo genera un nuovo flash.ffu)
Eseguire il flashing del dispositivo con questo nuovo Flash.ffu e convalidare le funzionalità di sicurezza.

Vedere SecureSample come esempio di configurazione della dragon board di blocco.

Sviluppo con CodeSigning Enforcement Enabled

Dopo aver generato i pacchetti e aver attivato il blocco, tutti i file binari introdotti nell'immagine durante lo sviluppo dovranno essere firmati in modo appropriato. Assicurarsi che i file binari in modalità utente siano firmati con la chiave *.\Keys\ **-UMCI.pfx. Per la firma in modalità kernel, ad esempio per i driver, è necessario specificare le proprie chiavi di firma e assicurarsi che siano incluse anche in SIPolicy precedente.

Sblocco di unità crittografate

Durante lo sviluppo e il test, quando si tenta di leggere il contenuto da un dispositivo crittografato offline (ad esempio, scheda SD per MinnowBoardMax o eMMC di DragonBoard tramite la modalità di archiviazione di massa USB), 'diskpart' può essere usato per assegnare una lettera di unità a MainOS e volume di dati (si supponga v: per MainOS e w: per Dati). I volumi verranno visualizzati bloccati e dovranno essere sbloccati manualmente. Questa operazione può essere eseguita in qualsiasi computer in cui sia installato il certificato OEM-DRA.pfx (incluso nell'esempio DeviceLockDown). Installare il file PFX e quindi eseguire i comandi seguenti da un prompt cmd amministrativo:

manage-bde -unlock v: -cert -cf OEM-DRA.cer
manage-bde -unlock w: -cert -cf OEM-DRA.cer

Se è necessario accedere di frequente al contenuto offline, è possibile configurare il blocco automatico bitLocker per i volumi dopo lo sblocco iniziale usando i comandi seguenti:

manage-bde -autounlock v: -enable
manage-bde -autounlock w: -enable

Disabilitazione di BitLocker

In caso di necessità di disabilitare temporaneamente BitLocker, initare una sessione remota di PowerShell con il dispositivo IoT ed eseguire il comando seguente: sectask.exe -disable.