Specifica di verificabilità della sicurezza hardware

Introduzione

HSTI protegge da errori di configurazione delle funzionalità di sicurezza nei dispositivi Windows. Per i clienti, HSTI garantisce la massima sicurezza del computer acquistato per impostazione predefinita. Per IHVs e IBV, HSTI assicura che le promesse di sicurezza vengano mantenute. Per gli OEM e gli ODM, assicurarsi facilmente che i sistemi forniti siano configurati in modo sicuro e rimangano sicuri, senza dover sviluppare soluzioni proprietarie.

I risultati dei test HSTI verranno utilizzati dai test di compatibilità di Windows e possono essere usati per verificare che i dispositivi siano stati configurati correttamente per abilitare le funzionalità di sicurezza supportate. Questi test possono essere usati per identificare i dispositivi di progettazione non sicuri nel campo, ad esempio i dispositivi di progettazione che possono contenere chiavi di test non sicure. I risultati di questi test possono essere usati dal sistema operativo Windows per visualizzare una filigrana (o un indicatore simile) nei dispositivi non sicuri.

Priorità bassa

Il lettore dovrebbe conoscere i concetti fondamentali di UEFI e avere una conoscenza delle tecnologie di avvio protetto, tra cui la sezione 27 "Sicurezza" della specifica UEFI e NIST SP 800-147.

Questo requisito presenta tre aspetti:

• Interfacce indipendenti dalla piattaforma per l'esecuzione di query su stati di sicurezza hardware e firmware
• Progettazione e revisione del codice facoltativo delle implementazioni dell'interfaccia precedente
• Condivisione di documentazione e strumenti

Implementazione di alto livello

Il campo di bit

L'IHV definisce un campo di bit che rappresenta le funzionalità di sicurezza testabili della piattaforma. Questo campo di bit copre completamente tutti i bit definibili disponibili per gli oggetti HSTI restituiti da qualsiasi test IHV, IBV o OEM HSTI. L'implementatore IHV deve progettare la definizione del campo di bit e fornire la documentazione appropriata affinché IBV restituisca correttamente i risultati dei test HSTI.

SecurityFeaturesRequired

Il campo SecurityFeaturesRequired viene utilizzato solo nell'elaborazione quando un campo in un oggetto HSTI IHV è il metodo con cui l'IHV definisce il campo di bit delle funzionalità di sicurezza necessarie.

SecurityFeaturesImplemented

Si tratta di un campo di bit delle funzionalità di sicurezza implementate dai test che restituiscono l'oggetto HSTI.

SecurityFeaturesVerified

Si tratta di un campo di bit delle funzionalità di sicurezza verificate dai test che restituiscono l'oggetto HSTI.

Linee guida per l'implementazione

L'IHV svilupperà progettazioni di sicurezza di riferimento per le piattaforme conformi ai requisiti di compatibilità di Windows. Inoltre, IHV e IBV implementeranno anche test programmatici che verificano l'abilitazione corretta delle implementazioni di sicurezza di riferimento e segnalano i risultati tramite l'interfaccia di test di sicurezza hardware. Questi test vengono distribuiti agli OEM e agli ODM come moduli compilati (non di origine) e devono funzionare senza modifiche. Se un OEM/ODM si discosta dalle progettazioni di sicurezza di riferimento, questi moduli di test potrebbero segnalare errori e l'OEM/ODM dovrà contattare Microsoft per esaminare le modifiche e implementare un'istanza HSTI aggiuntiva che segnala queste eccezioni. Gli OEM devono essere in grado di sfruttare questi moduli di sicurezza senza alcuna modifica necessaria seguendo la progettazione e la documentazione di riferimento. Gli OEM che desiderano aggiungere moduli di sicurezza aggiuntivi o modificare il comportamento di qualsiasi modulo di sicurezza devono essere sottoposti a una revisione della progettazione con Microsoft.

Nell'ambito dell'implementazione degli implementatori del modulo di test includerà uno struct. Un prototipo di questo struct è incluso di seguito nella sezione "Prototipo". L'IHV definirà il significato di ogni bit nell'elenco di controllo dei riferimenti alla sicurezza. L'IHV definirà ulteriormente il significato di ogni bit nei campi di bit. Infine, L'IHV include un campo di bit "Obbligatorio" nello struct OEM e per tutti i requisiti che possono testare a livello di codice verranno impostati un bit nel campo di bit "Implementato".

Gli IBV e gli OEM possono impostare bit nel campo "Implementato" se hanno presentato una progettazione per verificare in modo progamatico la presenza delle funzionalità di sicurezza rappresentate da tali bit a Microsoft. Se questi test superano, possono impostare il campo "Verificato" nei rispettivi struct.

I moduli di test per IHV, IBV e OEM devono essere eseguiti, se presenti. Un valore true impostato a un bit nel campo SecurityFeaturesEnabled indica un risultato del test superato. Se un test non viene eseguito o non viene superato, il valore 0 deve essere impostato per il bit rappresentativo.

Esempio di logica di elaborazione dei risultati

Questo esempio è rappresentativo della logica che verrà usata dall'elaborazione dei risultati. I campi di bit implementati devono seguire il formato implementato da un valore 1 e un valore 0 indica che non è implementato. Se viene implementato un elemento, è necessario. I campi di bit dei risultati devono seguire il formato che un valore 0 indica che un test non è riuscito o non è presente e un valore 1 significa solo superato in modo affermativo.

Dopo aver calcolato tutti i risultati, il campo di bit dei risultati IHV sarà NXORd con il campo di bit Obbligatorio. Tutti i campi di bit dei risultati non IHV sono ANDed con i rispettivi campi di bit implementati. I campi di bit risultanti sono tutti ORd insieme per ottenere i risultati complessivi. Un risultato passing di questa operazione sarà un campo di bit costituito interamente da 1s.

Risultati finali e proprietà

Fornitori di hardware indipendenti (IHV) e fornitori di BIOS indipendenti (IBV)

I fornitori di siliconi e IBV che supportano i sistemi standby Connessione ed devono implementare le interfacce indipendenti dalla piattaforma per eseguire query sui rispettivi stati di sicurezza hardware e firmware delle piattaforme di riferimento. Queste implementazioni devono essere distribuite come moduli compilati. È preferibile che questi moduli siano firmati e che venga eseguito un controllo della firma quando vengono eseguiti. Lo scopo è quello di eseguire query sui progetti hardware e firmware e stati per segnalare il provisioning di sicurezza appropriato della piattaforma.

OEM e ODM

Gli OEM e gli ODM non devono modificare o manomettere i test HSTI che sono stati forniti dai fornitori. Gli OEM e gli ODM sono tenuti a garantire che i sistemi superino i test HSTI come componente dei requisiti di certificazione Windows:

Requisito di certificazione hardware Windows - Windows 8.1 WHCR

• System.Fundamentals.Firmware.UEFISecureBoot
• System.Fundamentals.Firmware.CS.UEFISecureBoot. Connessione edStandby

Invece di apportare modifiche, se un OEM richiede un metodo per fornire un metodo alternativo per garantire la stessa sicurezza o una maggiore sicurezza, l'OEM potrebbe fornire controlli di sicurezza aggiuntivi. I controlli di sicurezza OEM devono coprire almeno completamente un test di sicurezza IHV o IBV. Prima dell'uso, gli OEM devono inviare una revisione della progettazione da Parte di Microsoft e sono soggetti agli stessi requisiti di divulgazione della documentazione e degli strumenti di altri provider di test HSTI. Dopo l'approvazione di Microsoft, l'OEM può includere test di sicurezza che si estendono sui test IHV e IBV.

Si noti che l'attestazione OEM non è necessaria come parte della progettazione HSTI. HSTI non è un elenco di requisiti per gli OEM, è un'interfaccia per garantire un test di sicurezza a livello di codice efficace di firmware, hardware e parametri di configurazione.

Interfacce dello stato di sicurezza

Le interfacce sono basate su EFI Adapter Information Protocol definito in UEFI versione 2.4.

Interfaccia dello stato di sicurezza della piattaforma

Riepilogo

Informazioni sulla sicurezza della piattaforma: restituisce informazioni sulla conformità della piattaforma con il requisito di certificazione hardware Windows System.Fundamentals.Firmware.CS.UEFISecureBoot, System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnessioneedStandby e System.Fundamentals.Firmware.CS.UEFISecureBoot.Provisioning.

Prototipo

InformationType

#define ADAPTER_INFO_PLATFORM_SECURITY_GUID \
     {0x6be272c7, 0x1320, 0x4ccd, { 0x90, 0x17, 0xd4, 0x61, 0x2c, 0x01, 0x2b, 0x25 }}

#define PLATFORM_SECURITY_VERSION_VNEXTCS   0x00000003

#define PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE   0x00000001  // IHV
#define PLATFORM_SECURITY_ROLE_PLATFORM_IBV 0x00000002
#define PLATFORM_SECURITY_ROLE_IMPLEMENTOR_OEM 0x00000003 
#define PLATFORM_SECURITY_ROLE_IMPLEMENTOR_ODM  0x00000004  
                        

InformationBlock corrispondente:

typedef struct { 
    UINT32  Version,
    UINT32  Role,
    CHAR16  ImplementationID[256],
    UINT32  SecurityFeaturesSize,
    UINT8   SecurityFeaturesRequired[],     //Ignored for non-IHV
    UINT8   SecurityFeaturesImplemented[],
    UINT8   SecurityFeaturesVerified[],
    // CHAR16   ErrorString[];
} ADAPTER_INFO_PLATFORM_SECURITY;
                        

0x4827 JTAG not disabled http://somewhere.net/docs/remediate4827.html \r\n0x2744 Platform Secure Boot key not provisioned http://somewhere.net/docs/remediate2744.html

Considerazioni sulla gestione della memoria

Ai fini della compatibilità tra i moduli HSTI, gli implementatori useranno AllocatePool() e non AllocatePages().

Revisione della progettazione dell'implementazione di HSTI

Microsoft eseguirà revisioni preliminari della progettazione di tutte le implementazioni dell'interfaccia di test. Esempi di domande che possono essere poste in una revisione di progettazione sono disponibili nella sezione Considerazioni sulla progettazione di HSTI.

Revisioni del codice facoltative

Gli implementatori HSTI possono richiedere revisioni del codice eseguite da Microsoft. Le revisioni del codice possono essere fornite in base alla priorità e alla disponibilità delle risorse e non sono garantite. Le revisioni del codice saranno soggette a un accordo di non divulgazione.

Condivisione di documentazione e strumenti

I fornitori di siliconi e firmware devono rendere disponibili a Microsoft tutti gli strumenti e la documentazione di riferimento relativi alla sicurezza necessari forniti agli OEM. Questa documentazione e gli strumenti devono essere resi disponibili non più tardi rispetto a quelli forniti agli OEM Windows. Questo dovrebbe includere, ma non solo, tutta la documentazione e gli strumenti correlati alla fusing, installazione e aggiornamento di firmware, firmware e ripristino di avvio, diagnostica hardware, diagnostica firmware e diagnostica di avvio. Questa documentazione e gli strumenti forniti devono essere completamente sufficienti per eseguire controlli HSTI in un ambiente lab.

Considerazioni sulla progettazione di HSTI

Di seguito è riportato un elenco illustrativo delle considerazioni di progettazione che un implementatore HSTI deve prendere in considerazione per l'implementazione HSTI. Questo non è un elenco rigoroso di requisiti, né è un elenco completo di considerazioni. L'implementatore HSTI scriverà i test per convalidare le funzionalità di sicurezza che si stanno lavorando per la copertura più completa possibile. Prima della revisione della progettazione con Microsoft, è consigliabile esaminare questo elenco per ottenere ispirazione e considerare che è probabile che Microsoft voglia che se si implementano queste funzionalità, è consigliabile testarle il più a lungo possibile.

Controlli HSTI dei fornitori/fornitori di siliconi (IHV)

1. Usare solo RSA 2048 e SHA256 (o livello di forza di crittografia simile)
2. Il codice del firmware deve essere presente nell'archiviazione protetta
   1. Proteggi spiflash?
   2. Implementare la sola lettura fino alla reimpostazione per le partizioni eMMC
   3. Il controllo del firmware firmato è supportato: il firmware installato dall'OEM è di sola lettura o protetto dal processo di aggiornamento del firmware sicuro.
3. Processo di aggiornamento del firmware sicuro
   1. Il processo di aggiornamento del firmware sicuro è attivato per impostazione predefinita con le chiavi di test? (CONSIGLIATO)
   2. Verificare se le chiavi di test vengono usate nell'ambiente di produzione?
   3. Si consente il rollback alla versione non sicura del firmware? In caso affermativo, qual è il meccanismo di protezione? Cancellare il TPM quando si verifica il rollback?
4. Sono presenti backdoor per eseguire l'override di SecureBoot
   1. Il sistema supporta la richiesta inline di ignorare Secureboot? Se sì, è disabilitato mentre SecureBoot è abilitato?
   2. Hai backdoor di produzione? Verificare che siano disabilitati mentre SecureBoot è abilitato e sempre disabilitato nel sistema di produzione?
5. [CS] Supporto dell'integrità dell'avvio
   1. L'integrità dell'avvio è supportata ed è abilitata per impostazione predefinita?
   2. La piattaforma usa la memoria OTP (On-Die ROM) o OTP (One-Time Programmable) per l'archiviazione del codice di avvio iniziale e fornisce la logica di reimpostazione attiva per l'esecuzione da ROM on-die o da SRAM sicuro su die.
6. [CS] Protezione da DMA interno ed esterno
   1. Mantenere DMA interno solo per i componenti necessari durante l'avvio? E è disabilitato per tutti gli altri componenti.
   2. Mantenere DMA esterno attivo solo per i componenti necessari durante l'avvio? E è disabilitato per tutti gli altri componenti.
   3. Se il firmware ha un'opzione per abilitare e disabilitare la protezione DMA, per impostazione predefinita la configurazione della spedizione deve avere la protezione DMA abilitata per impostazione predefinita
   4. Quali bus/dispositivi (fusibili, motori di sicurezza, TZ, video, cache, IMEM, memoria kernel) sono in grado di accedere DMA a diverse aree di archiviazione NV e volatili e come sono protette?
   5. Supportare l'implementazione del bit MOR
7. Protezione da debugger hardware esterno
   1. Si supporta JTAG? È OFF JTAG quando SecureBoot è ON
   2. Fornire il backdoor di produzione per disabilitare la protezione JTAG? Verificare se questa backdoor non è presente nei sistemi di produzione?
   3. Cancellare TPM quando JTAG è abilitato?
   4. È supportato qualsiasi altro debugger hardware? E fare gli stessi controlli per esso.
8. È stato effettuato correttamente il provisioning per ogni segreto univoco del dispositivo?
9. Quali sono i fusibili di sicurezza disponibili (specifici del fornitore)
   1. FUSE SOC SecureBoot
   2. Segreti univoci per dispositivo, ad esempio verifica dell'autenticità o fusibili di crittografia
   3. Fusibili JTAG
   4. SoC Apps Processor SecureBoot fuse
   5. SoC MBA Processor SecureBoot fuse
   6. SoC Modern Processor SecureBoot fuse
   7. Eventuali altri fusibili specifici soC per la piattaforma

Controlli HSTI IBV

1. Usare solo RSA 2048 e SHA256 (o superiore ma non inferiore a questo)
2. Moduli di supporto per la compatibilità (CSM)
   1. È possibile abilitare CSM
   2. Controllare il blocco del caricamento di CSM quando SecureBoot è abilitato
   3. [CS] Verificare se CSM non è presente nei sistemi CS in modo permanente
3. Il codice del firmware deve essere presente nell'archiviazione protetta
   1. Proteggi spiflash?
   2. Implementare la sola lettura fino alla reimpostazione per le partizioni eMMC
   3. Il controllo del firmware firmato è supportato: il firmware installato dall'OEM è di sola lettura o protetto dal processo di aggiornamento del firmware sicuro.
4. Processo di aggiornamento del firmware sicuro
   1. Il processo di aggiornamento del firmware sicuro è attivato per impostazione predefinita con le chiavi di test?
   2. Verificare se le chiavi di test vengono usate nell'ambiente di produzione?
   3. Si consente il rollback alla versione non sicura del firmware? In caso affermativo, qual è il meccanismo di protezione? Cancellare il TPM quando si verifica il rollback?
   4. Le chiavi di test vengono usate?
5. Sono presenti backdoor per eseguire l'override di SecureBoot
   1. Il sistema supporta la richiesta inline di ignorare Secureboot? Se sì, è disabilitato mentre SecureBoot è abilitato?
   2. Hai backdoor di produzione? Verificare che siano disabilitati mentre SecureBoot è abilitato e sempre disabilitato nel sistema di produzione?
6. [CS] Protezione da DMA interno ed esterno
   1. Mantenere DMA interno solo per i componenti necessari durante l'avvio? E è disabilitato per tutti gli altri componenti.
   2. Mantenere DMA esterno attivo solo per i componenti necessari durante l'avvio? E è disabilitato per tutti gli altri componenti.
   3. Se il firmware ha un'opzione per abilitare e disabilitare la protezione DMA, per impostazione predefinita la configurazione della spedizione deve avere la protezione DMA abilitata per impostazione predefinita
   4. Quali bus/dispositivi (fusibili, motori di sicurezza, TZ, video, cache, IMEM, memoria kernel) sono in grado di accedere DMA a diverse aree di archiviazione NV e volatili e come sono protette?
   5. Supportare l'implementazione del bit MOR