Protezione del sistema: come una radice di attendibilità basata su hardware consente di 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.

Protezione del sistema 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)

Protezione del sistema Secure Launch, introdotto per la prima volta in Windows 10 versione 1809, mira ad alleviare questi problemi sfruttando 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.

Protezione del sistema avvio sicuro.

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 viene usato Protezione del sistema avvio sicuro per l'avvio tardivo, il codice SMM può accedere potenzialmente 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 Protezione del sistema 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. Quindi Protezione del sistema include una serie di tecnologie che consentono l'analisi remota dell'integrità del dispositivo.

Durante l'avvio di Windows, una serie di misurazioni dell'integrità viene eseguita da Protezione del sistema usando il modulo Trusted Platform 2.0 (TPM 2.0) del dispositivo. Protezione del sistema Avvio protetto 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.

Integrità dell'ora di avvio.

Dopo l'avvio del sistema, Protezione del sistema 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 Protezione del sistema indica che il dispositivo non è integrità, il sistema di gestione può eseguire una serie di azioni, ad esempio negando l'accesso del dispositivo alle risorse.

Requisiti di licenza ed edizione di Windows

Nella tabella seguente sono elencate le edizioni di Windows che supportano Protezione del sistema:

Windows Pro Windows Enterprise Windows Pro Education/SE Windows Education
Sì Sì Sì Sì

Protezione del sistema diritti di licenza 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 Protezione del sistema

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:
  • Esattamente gli attributi di stile "TXT PS2" alla creazione come indicato di seguito:
    • AuthWrite
    • PolicyDelete
    • WriteLocked
    • WriteDefine
    • AuthRead
    • WriteDefine
    • Noda
    • Scritto
    • PlatformCreate
  • Un criterio esattamente PolicyCommandCode(CC = TPM2_CC_UndefineSpaceSpecial) (SHA256 NameAlg and Policy)
  • Dimensioni esattamente di 70 byte
  • NameAlg = SHA256
  • Inoltre, deve essere stato inizializzato e bloccato (TPMA_NV_WRITTEN = 1, TPMA_NV_WRITELOCKED = 1) al momento dell'avvio del sistema operativo.
I dati dell'indice PS DataRevocationCounters, SINITMinVersion e PolicyControl devono essere tutti 0x00
Criteri AUX I criteri AUX necessari devono essere i seguenti:
  • A = TPM2_PolicyLocality (località 3 & località 4)
  • B = TPM2_PolicyCommandCode (TPM_CC_NV_UndefineSpecial)
  • authPolicy = {A} OR {{A} AND {B}}
  • authPolicy digest = 0xef, 0x9a, 0x26, 0xfc, 0x22, 0xd1, 0xae, 0x8c, 0xec, 0xff, 0x59, 0xe9, 0x48, 0x1a, 0xc1, 0xec, 0x53, 0x3d, 0xbe, 0x22, 0x8b, 0xec, 0x6d, 0x17, 0x93, 0x0f, 0x4c, 0xb2, 0xcc, 0x5b, 0x97, 0x24
Indice NV TPM Il firmware della piattaforma deve configurare un indice NV TPM per l'uso da parte del sistema operativo con:
  • Handle: 0x01C101C0
  • Attributi:
    • TPMA_NV_POLICYWRITE
    • TPMA_NV_PPREAD
    • TPMA_NV_OWNERREAD
    • TPMA_NV_AUTHREAD
    • TPMA_NV_POLICYREAD
    • TPMA_NV_NO_DA
    • TPMA_NV_PLATFORMCREATE
    • TPMA_NV_POLICY_DELETE
  • Un criterio di:
    • A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
    • B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
    • authPolicy = {A} OR {{A} AND {B}}
    • Valore digest di 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e, 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1
Firmware della piattaforma Il firmware della piattaforma deve contenere tutto il codice necessario per eseguire un avvio sicuro di Intel® Trusted Execution Technology:
  • Intel® SINIT ACM deve essere trasportato nel BIOS OEM
  • Le piattaforme devono essere fornite con un ACM di produzione firmato dal firmatario Intel® ACM di produzione corretto per la piattaforma
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:
  • Handle: 0x01C101C0
  • Attributi:
    • TPMA_NV_POLICYWRITE
    • TPMA_NV_PPREAD
    • TPMA_NV_OWNERREAD
    • TPMA_NV_AUTHREAD
    • TPMA_NV_POLICYREAD
    • TPMA_NV_NO_DA
    • TPMA_NV_PLATFORMCREATE
    • TPMA_NV_POLICY_DELETE
  • Un criterio di:
    • A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
    • B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
    • authPolicy = {A} OR {{A} AND {B}}
    • Valore digest di 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e, 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1
Firmware della piattaforma Il firmware della piattaforma deve contenere tutto il codice necessario per eseguire l'avvio sicuro:
  • Le piattaforme AMD® Secure Launch devono essere fornite con amd® DRTM driver devnode esposto e il driver AMD® DRTM installato

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:
  • NON contengono mapping a EfiConventionalMemory (ad esempio nessuna memoria di proprietà di OS/VMM)
  • Non devono avere autorizzazioni di esecuzione e scrittura per la stessa pagina
  • Le piattaforme devono consentire solo le pagine della modalità di monitoraggio contrassegnate come eseguibili
  • La mappa di memoria deve segnalare la modalità di monitoraggio come EfiReservedMemoryType
  • Le piattaforme devono fornire un meccanismo per proteggere le tabelle delle pagine della modalità monitoraggio dalla modifica
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.