System Guard: come una radice di attendibilità basata su hardware aiuta a proteggere Windows
Per proteggere risorse critiche come lo stack di autenticazione di Windows, i token di accesso Single Sign-On, lo stack biometrico Windows Hello e il modulo Virtual Trusted Platform, il firmware e l'hardware di un sistema devono essere attendibili.
System Guard riorganizza le funzionalità di integrità del sistema Windows esistenti in un unico tetto e configura il set successivo di investimenti nella sicurezza di Windows. È progettato per garantire queste garanzie di sicurezza:
- Proteggere e mantenere l'integrità del sistema all'avvio
- Verificare che l'integrità del sistema sia stata effettivamente mantenuta tramite attestazione locale e remota
Mantenimento dell'integrità del sistema all'avvio
Radice statica di attendibilità per la misurazione (SRTM)
Con Windows 7, uno dei mezzi usati dagli utenti malintenzionati per rendere persistente ed eludere il rilevamento consiste nell'installare nel sistema quello che viene spesso definito bootkit o rootkit. Questo software dannoso inizierebbe prima dell'avvio di Windows o durante il processo di avvio stesso, consentendogli di iniziare con il massimo livello di privilegi.
Con Windows 10 in esecuzione su hardware moderno, una radice di attendibilità basata su hardware consente di garantire che nessun firmware o software non autorizzato (ad esempio un bootkit) possa iniziare prima del bootloader di Windows. Questa radice di attendibilità basata su hardware deriva dalla funzionalità di avvio protetto del dispositivo, che fa parte dell'interfaccia UEFI (Unified Extensible Firmware Interface). Questa tecnica di misurazione dei componenti UEFI di avvio iniziale statici è denominata radice statica di attendibilità per la misurazione (SRTM).
Poiché ci sono migliaia di fornitori di PC che producono molti modelli con diverse versioni del BIOS UEFI, al momento dell'avvio diventa un numero incredibilmente elevato di misurazioni SRTM. Esistono due tecniche per stabilire l'attendibilità in questo caso: mantenere un elenco di misurazioni SRTM "non valide" note (noto anche come elenco di blocchi) o un elenco di misurazioni SRTM "buone" note (noto anche come elenco consentiti).
Ogni opzione presenta uno svantaggio:
- Un elenco di misurazioni SRTM "negative" note consente a un hacker di modificare solo 1 bit in un componente per creare un hash SRTM completamente nuovo che deve essere elencato. Ciò significa che il flusso SRTM è intrinsecamente fragile: una modifica secondaria può invalidare l'intera catena di attendibilità.
- Un elenco di misurazioni SRTM "buone" note richiede che ogni nuova misura di combinazione BIOS/PC venga aggiunta con attenzione, il che è lento. Inoltre, una correzione di bug per il codice UEFI può richiedere molto tempo per progettare, compilare, ripetere, convalidare e ridistribuire.
Avvio sicuro: radice dinamica dell'attendibilità per la misurazione (DRTM)
System Guard Secure Launch, introdotto per la prima volta in Windows 10 versione 1809, mira ad alleviare questi problemi usando una tecnologia nota come DYNAMIC Root of Trust for Measurement (DRTM). DRTM consente al sistema di avviarsi liberamente in codice non attendibile inizialmente, ma poco dopo avvia il sistema in uno stato attendibile prendendo il controllo di tutte le CPU e forzandole verso il basso un percorso di codice noto e misurato. Ciò offre il vantaggio di consentire al codice UEFI iniziale non attendibile di avviare il sistema, ma di passare in modo sicuro a uno stato attendibile e misurato.
Secure Launch semplifica la gestione delle misurazioni SRTM perché il codice di avvio non è ora correlato a una configurazione hardware specifica. Ciò significa che il numero di misurazioni del codice valide è ridotto e gli aggiornamenti futuri possono essere distribuiti in modo più ampio e rapido.
Protezione SMM (System Management Mode)
La modalità di gestione del sistema (SMM) è una modalità CPU speciale nei microcontroller x86 che gestisce la gestione dell'alimentazione, la configurazione hardware, il monitoraggio termico e qualsiasi altra cosa che il produttore ritiene utile. Ogni volta che viene richiesta una di queste operazioni di sistema, viene richiamato un interrupt non mascherabile (SMI) in fase di esecuzione, che esegue il codice SMM installato dal BIOS. Il codice SMM viene eseguito nel livello di privilegi più elevato ed è invisibile al sistema operativo, il che lo rende una destinazione attraente per le attività dannose. Anche se l'avvio sicuro di System Guard viene usato per l'avvio tardivo, il codice SMM può potenzialmente accedere alla memoria dell'hypervisor e modificare l'hypervisor.
Per difendersi da questo, vengono usate due tecniche:
- Protezione del paging per impedire l'accesso inappropriato a codice e dati
- Supervisione e attestazione hardware SMM
La protezione dal paging può essere implementata per bloccare determinate tabelle di codice in sola lettura per evitare manomissioni. Ciò impedisce l'accesso a qualsiasi memoria non assegnata.
Una funzionalità del processore applicata all'hardware nota come gestore SMI supervisore può monitorare SMM e assicurarsi che non accerta ad alcuna parte dello spazio indirizzi a cui non dovrebbe accedere.
La protezione SMM si basa sulla tecnologia Secure Launch e richiede il funzionamento. In futuro, Windows 10 misurerà anche il comportamento di questo gestore SMI e attesta che non è stata manomessa alcuna memoria di proprietà del sistema operativo.
Convalida dell'integrità della piattaforma dopo l'esecuzione di Windows (runtime)
Mentre System Guard offre una protezione avanzata che aiuterà a proteggere e mantenere l'integrità della piattaforma durante l'avvio e in fase di esecuzione, la realtà è che dobbiamo applicare una mentalità "presupporre violazione" anche alle nostre tecnologie di sicurezza più sofisticate. Possiamo fidarci che le tecnologie stiano facendo correttamente il loro lavoro, ma abbiamo anche bisogno della capacità di verificare che siano riuscite a raggiungere i loro obiettivi. Per l'integrità della piattaforma, non è sufficiente considerare attendibile la piattaforma, che potrebbe essere compromessa, per attestarne automaticamente lo stato di sicurezza. System Guard include quindi una serie di tecnologie che consentono l'analisi remota dell'integrità del dispositivo.
Durante l'avvio di Windows, System Guard esegue una serie di misurazioni dell'integrità usando il modulo Trusted Platform 2.0 (TPM 2.0) del dispositivo. Avvio sicuro di System Guard non supporta versioni TPM precedenti, ad esempio TPM 1.2. Questo processo e i dati sono isolati dall'hardware da Windows per garantire che i dati di misurazione non siano soggetti al tipo di manomissione che potrebbe verificarsi se la piattaforma fosse stata compromessa. Da qui, le misurazioni possono essere usate per determinare l'integrità del firmware del dispositivo, dello stato di configurazione hardware e dei componenti correlati all'avvio di Windows, per citarne alcuni.
Dopo l'avvio del sistema, System Guard firma e sigilla queste misurazioni usando il TPM. Su richiesta, un sistema di gestione come Intune o Microsoft Configuration Manager può acquisirli per l'analisi remota. Se System Guard indica che il dispositivo non ha integrità, il sistema di gestione può eseguire una serie di azioni, ad esempio negare l'accesso del dispositivo alle risorse.
Requisiti di licenza ed edizione di Windows
Nella tabella seguente sono elencate le edizioni di Windows che supportano System Guard:
| Windows Pro | Windows Enterprise | Windows Pro Education/SE | Windows Education |
|---|---|---|---|
| Sì | Sì | Sì | Sì |
I diritti di licenza di System Guard sono concessi dalle licenze seguenti:
| Windows Pro/Pro Education/SE | Windows Enterprise E3 | Windows Enterprise E5 | Windows Education A3 | Windows Education A5 |
|---|---|---|---|---|
| Sì | Sì | Sì | Sì | Sì |
Per ulteriori informazioni sulle licenze di Windows, vedi Panoramica delle licenze di Windows.
Requisiti di sistema per System Guard
Questa funzionalità è disponibile per i processori seguenti:
- Processori Intel® vPro™ a partire da Intel® Coffeelake, Whiskeylake o silicio successivo
- Processori AMD® a partire da Zen2 o versioni successive
- Processori Qualcomm® con chipset SD850 o versioni successive
Requisiti per i processori Intel® vPro™ a partire da Intel® Coffeelake, Whiskeylake o silicio successivo
| Nome | Descrizione |
|---|---|
| CPU a 64 bit | Per l'hypervisor e la sicurezza basata su virtualizzazione (VBS) è necessario un computer a 64 bit con almeno quattro core (processori logici). Per altre informazioni su Hyper-V, vedere Hyper-V in Windows Server 2016 o Introduzione a Hyper-V in Windows 10. Per altre informazioni sull'hypervisor, vedere Specifiche di Hypervisor. |
| Trusted Platform Module (TPM) 2.0 | Le piattaforme devono supportare un TPM discreto 2.0. I TPM integrati/firmware non sono supportati, ad eccezione dei chip Intel che supportano platform trust technology (PTT), un tipo di TPM hardware integrato che soddisfa le specifiche TPM 2.0. |
| Protezione DMA windows | Le piattaforme devono soddisfare la specifica di protezione DMA di Windows (tutte le porte DMA esterne devono essere disattivate per impostazione predefinita fino a quando il sistema operativo non le abilita in modo esplicito). |
| Buffer di comunicazione SMM | Tutti i buffer di comunicazione SMM devono essere implementati nei tipi di memoria EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS o EfiReservedMemoryType. |
| Tabelle di pagine SMM | NON deve contenere alcun mapping a EfiConventionalMemory(ad esempio nessuna memoria di proprietà di OS/VMM). NON deve contenere mapping alle sezioni di codice all'interno di EfiRuntimeServicesCode. NON deve avere autorizzazioni di esecuzione e scrittura per la stessa pagina Deve consentire SOLO che le pagine TSEG possano essere contrassegnate come eseguibili e che la mappa di memoria debba segnalare TSEG EfiReservedMemoryType. Il gestore SMI del BIOS deve essere implementato in modo che le tabelle di pagine SMM siano bloccate in ogni voce SMM. |
| Standby moderno/connesso | Le piattaforme devono supportare Modern/Connected Standby. |
| Indice AUX TPM | La piattaforma deve configurare un indice AUX con indice, attributi e criteri che corrispondano esattamente all'indice AUX specificato nel dg TXT con dimensioni dei dati esattamente pari a 104 byte (per i dati AUX SHA256). (NameAlg = SHA256) Le piattaforme devono configurare un indice PS (Platform Supplier) con:
|
| Criteri AUX | I criteri AUX necessari devono essere i seguenti:
|
| Indice NV TPM | Il firmware della piattaforma deve configurare un indice NV TPM per l'uso da parte del sistema operativo con:
|
| Firmware della piattaforma | Il firmware della piattaforma deve contenere tutto il codice necessario per eseguire un avvio sicuro di Intel® Trusted Execution Technology:
|
| Aggiornamento del firmware della piattaforma | È consigliabile aggiornare il firmware di sistema tramite UpdateCapsule in Windows Update. |
Requisiti per i processori AMD® a partire da Zen2 o versioni successive
| Nome | Descrizione |
|---|---|
| CPU a 64 bit | Per l'hypervisor e la sicurezza basata su virtualizzazione (VBS) è necessario un computer a 64 bit con almeno quattro core (processori logici). Per altre informazioni su Hyper-V, vedere Hyper-V in Windows Server 2016 o Introduzione a Hyper-V in Windows 10. Per altre informazioni sull'hypervisor, vedere Specifiche di Hypervisor. |
| Trusted Platform Module (TPM) 2.0 | Le piattaforme devono supportare un TPM discreto 2.0 OR Microsoft Pluton TPM. |
| Protezione DMA windows | Le piattaforme devono soddisfare la specifica di protezione DMA di Windows (tutte le porte DMA esterne devono essere disattivate per impostazione predefinita fino a quando il sistema operativo non le abilita in modo esplicito). |
| Buffer di comunicazione SMM | Tutti i buffer di comunicazione SMM devono essere implementati nei tipi di memoria EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS o EfiReservedMemoryType. |
| Tabelle di pagine SMM | NON deve contenere alcun mapping a EfiConventionalMemory(ad esempio nessuna memoria di proprietà di OS/VMM). NON deve contenere mapping alle sezioni di codice all'interno di EfiRuntimeServicesCode. NON deve avere autorizzazioni di esecuzione e scrittura per la stessa pagina Il gestore SMI del BIOS deve essere implementato in modo che le tabelle di pagine SMM siano bloccate in ogni voce SMM. |
| Standby moderno/connesso | Le piattaforme devono supportare Modern/Connected Standby. |
| Indice NV TPM | Il firmware della piattaforma deve configurare un indice NV TPM per l'uso da parte del sistema operativo con:
|
| Firmware della piattaforma | Il firmware della piattaforma deve contenere tutto il codice necessario per eseguire l'avvio sicuro:
Per la piattaforma deve essere abilitata la protezione anti rollback del firmware del processore protetto AMD® La piattaforma deve avere AMD® Memory Guard abilitato. |
| Aggiornamento del firmware della piattaforma | È consigliabile aggiornare il firmware di sistema tramite UpdateCapsule in Windows Update. |
Requisiti per i processori Qualcomm® con chipset SD850 o versioni successive
| Nome | Descrizione |
|---|---|
| Comunicazione in modalità monitoraggio | Tutti i buffer di comunicazione della modalità monitoraggio devono essere implementati in EfiRuntimeServicesData (scelta consigliata), sezioni di dati di EfiRuntimeServicesCode come descritto dai tipi di memoria Memory Attributes Table, EfiACPIMemoryNVS o EfiReservedMemoryType |
| Tabelle pagina modalità monitoraggio | Tutte le tabelle di pagine modalità monitoraggio devono:
|
| Standby moderno/connesso | Le piattaforme devono supportare Modern/Connected Standby. |
| Firmware della piattaforma | Il firmware della piattaforma deve contenere tutto il codice necessario per l'avvio. |
| Aggiornamento del firmware della piattaforma | È consigliabile aggiornare il firmware di sistema tramite UpdateCapsule in Windows Update. |