Linee guida per la creazione e la gestione delle chiavi di avvio protetto di Windows

  • Articolo

Questo documento illustra gli OEM e gli ODM nella creazione e gestione delle chiavi e dei certificati di avvio protetto in un ambiente di produzione. Vengono affrontate domande relative alla creazione, all'archiviazione e al recupero di chiavi della piattaforma (PK), alle chiavi di aggiornamento del firmware sicure e alle chiavi di scambio delle chiavi di terze parti.

Nota

Gli OEM dei dispositivi, le aziende e i clienti possono trovare i file binari PK, KEK, DB e DBX consigliati da Microsoft nel repository open source di avvio protetto di Microsoft. I file binari vengono formattati nel formato EDKII previsto per integrarsi facilmente nel firmware.

Nota

Microsoft Corporation KEK CA 2011 è impostato per scadere nel 2026 e tutti gli OEM devono creare, firmare e inviare aggiornamenti per la nuova MICROSOFT Corporation KEK CA 2023 a Microsoft. Ciò consentirà a Microsoft di aggiornare i dispositivi sul mercato con la nuova CA microsoft KEK, consentendo ai sistemi di continuare a ricevere gli aggiornamenti db e DBX dopo il 2026. Per istruzioni e materiale collaterale per i test, visitare https://aka.ms/KEKUpdatePackage

I requisiti di Windows per UEFI e Avvio protetto sono disponibili in Requisiti di certificazione hardware Windows. Questo documento non introduce nuovi requisiti o rappresenta un programma Windows ufficiale. È concepita come materiale sussidiario oltre i requisiti di certificazione, per facilitare la creazione di processi efficienti e sicuri per la creazione e la gestione delle chiavi di avvio protette. Questo è importante perché l'avvio protetto UEFI si basa sull'uso dell'infrastruttura a chiave pubblica per autenticare il codice prima di poter essere eseguito.

Il lettore dovrebbe conoscere i concetti fondamentali di UEFI, conoscenza di base dell'avvio protetto (capitolo 27 della specifica UEFI) e del modello di sicurezza PKI.

I requisiti, i test e gli strumenti che convalidano l'avvio protetto in Windows sono attualmente disponibili tramite il Kit di certificazione hardware Windows (HCK). Tuttavia, queste risorse HCK non indirizzano la creazione e la gestione delle chiavi per le distribuzioni di Windows. Questo documento illustra la gestione delle chiavi come risorsa per aiutare i partner a distribuire le chiavi usate dal firmware. Non è previsto come materiale sussidiario prescrittivo e non include nuovi requisiti.

In questa pagina:

  • 1. Avvio protetto, Gestione delle chiavi e Windows contiene informazioni sulla sicurezza di avvio e sull'architettura PKI come si applica a Windows e Avvio protetto.
  • 2. Le soluzioni di gestione delle chiavi sono concepite per aiutare i partner a progettare una soluzione di gestione e progettazione chiave adatta alle proprie esigenze.
  • 3. Riepilogo e risorse includono appendici, elenchi di controllo, API e altri riferimenti.

Questo documento funge da punto di partenza per lo sviluppo di PC pronti per i clienti, strumenti di distribuzione factory e procedure consigliate per la sicurezza chiave.

1. Avvio protetto, Windows e Gestione delle chiavi

La specifica UEFI (Unified Extensible Firmware Interface) definisce un processo di autenticazione dell'esecuzione del firmware denominato Avvio protetto. Come standard di settore, l'avvio protetto definisce il modo in cui il firmware della piattaforma gestisce i certificati, autentica il firmware e il modo in cui il sistema operativo si interfaccia con questo processo.

L'avvio protetto si basa sul processo PKI (Public Key Infrastructure) per autenticare i moduli prima che possano essere eseguiti. Questi moduli possono includere driver firmware, rom di opzione, driver UEFI su disco, applicazioni UEFI o caricatori di avvio UEFI. Tramite l'autenticazione delle immagini prima dell'esecuzione, l'avvio protetto riduce il rischio di attacchi malware di preavvio, ad esempio rootkit. Microsoft si basa sull'avvio protetto UEFI in Windows 8 e versioni successive come parte dell'architettura di sicurezza di avvio attendibile per migliorare la sicurezza della piattaforma per i clienti. L'avvio protetto è necessario per i PC client Windows 8 e versioni successive e per Windows Server 2016, come definito nei requisiti di compatibilità hardware di Windows.

Il processo di avvio protetto funziona come segue e come illustrato nella figura 1:

  1. Componenti di avvio del firmware: il firmware verifica che il caricatore del sistema operativo sia attendibile (Windows o un altro sistema operativo attendibile).
  2. Componenti di avvio di Windows: BootMgr, WinLoad, Avvio del kernel Windows. I componenti di avvio di Windows verificano la firma in ogni componente. Tutti i componenti non attendibili non verranno caricati e attiveranno invece la correzione dell'avvio protetto.
    • Inizializzazione del software antivirus e antimalware: questo software viene controllato per una firma speciale rilasciata da Microsoft verificando che si tratti di un driver critico di avvio attendibile e verrà avviato all'inizio del processo di avvio.
    • Inizializzazione del driver critico di avvio: le firme in tutti i driver di avvio critico vengono controllate come parte della verifica dell'avvio protetto in WinLoad.
  3. Inizializzazione aggiuntiva del sistema operativo
  4. Schermata di accesso di Windows

immagine dell'architettura di integrità della piattaforma

Figura 1: Architettura di avvio attendibile di Windows

L'implementazione dell'avvio protetto UEFI fa parte dell'architettura di avvio attendibile di Microsoft, introdotta in Windows 8.1. Una tendenza crescente nell'evoluzione degli exploit di malware è destinata al percorso di avvio come vettore di attacco preferito. Questa classe di attacco è stata difficile da proteggere, poiché i prodotti antimalware possono essere disabilitati da software dannoso che impedisce il caricamento del tutto. Con l'architettura di avvio attendibile di Windows e la relativa creazione di una radice di attendibilità con avvio protetto, il cliente è protetto da codice dannoso in esecuzione nel percorso di avvio assicurando che solo il codice "noto valido" certificato e i caricatori di avvio possano essere eseguiti prima del caricamento del sistema operativo stesso.

1.1 Public-Key Infrastructure (PKI) e Avvio protetto

L'infrastruttura a chiave pubblica stabilisce l'autenticità e l'attendibilità in un sistema. L'avvio protetto sfrutta l'infrastruttura a chiave pubblica per due scopi generali:

  1. Durante l'avvio per determinare se i moduli di avvio anticipato sono attendibili per l'esecuzione.
  2. Per autenticare le richieste di servizio, includere la modifica dei database di avvio protetto e gli aggiornamenti al firmware della piattaforma.

Un'infrastruttura a chiave pubblica è costituita da:

  • Autorità di certificazione (CA) che rilascia i certificati digitali.
  • Autorità di registrazione che verifica l'identità degli utenti che richiedono un certificato dalla CA.
  • Directory centrale in cui archiviare e indicizzare le chiavi.
  • Un sistema di gestione dei certificati.

1.2 Crittografia a chiave pubblica

La crittografia a chiave pubblica usa una coppia di chiavi crittografiche correlate matematicamente, note come chiave pubblica e privata. Se si conosce una delle chiavi, non è possibile calcolare facilmente l'altro. Se viene usata una chiave per crittografare le informazioni, solo la chiave corrispondente può decrittografare tali informazioni. Per l'avvio protetto, la chiave privata viene usata per firmare digitalmente il codice e la chiave pubblica viene usata per verificare la firma nel codice per dimostrare l'autenticità. Se una chiave privata viene compromessa, i sistemi con chiavi pubbliche corrispondenti non sono più sicuri. Ciò può causare attacchi al kit di avvio e danneggiare la reputazione dell'entità responsabile di garantire la sicurezza della chiave privata.

In un sistema di chiavi pubbliche di avvio protetto sono disponibili gli elementi seguenti:

  • 1.2.1 Crittografia RSA 2048

    RSA-2048 è un algoritmo di crittografia asimmetrico. Lo spazio necessario per archiviare un modulo RSA-2048 in formato non elaborato è di 2048 bit.

  • 1.2.2 Certificato autofirmato

    Un certificato firmato dalla chiave privata corrispondente alla chiave pubblica del certificato è noto come certificato autofirmato. I certificati dell'autorità di certificazione radice rientrano in questa categoria.

  • 1.2.3 Autorità di certificazione

    L'autorità di certificazione rilascia certificati firmati che confermano l'identità dell'oggetto del certificato e associano tale identità alla chiave pubblica contenuta nel certificato. La CA firma il certificato usando la chiave privata. Rilascia la chiave pubblica corrispondente a tutte le parti interessate in un certificato ca radice autofirmato.

    In Avvio protetto le autorità di certificazione includono l'OEM (o i relativi delegati) e Microsoft. Le ca generano le coppie di chiavi che formano la radice dell'attendibilità e quindi usano le chiavi private per firmare operazioni legittime, ad esempio i moduli EFI di avvio anticipato consentiti e le richieste di manutenzione del firmware. Le chiavi pubbliche corrispondenti vengono incorporate nel firmware UEFI nei PC abilitati per l'avvio protetto e vengono usate per verificare queste operazioni.

    Altre informazioni sull'utilizzo di ca e scambi di chiavi sono facilmente disponibili su Internet, che si riferisce al modello di avvio protetto.

  • 1.2.4 Chiave pubblica

    Il public Platform Key viene fornito sul PC ed è accessibile o "pubblico". In questo documento si userà il suffisso "pub" per indicare la chiave pubblica. Ad esempio, PKpub indica la metà pubblica dell'infrastruttura a chiave pubblica.

  • 1.2.5 Chiave privata

    Affinché l'infrastruttura a chiave pubblica funzioni, la chiave privata deve essere gestita in modo sicuro. Deve essere accessibile a pochi utenti altamente attendibili in un'organizzazione e che si trova in una posizione fisicamente sicura con restrizioni avanzate dei criteri di accesso. In questo documento si userà il suffisso "priv" per indicare la chiave privata. Ad esempio, PKpriv indica la metà privata dell'infrastruttura a chiave pubblica.

  • 1.2.6 Certificati

    L'uso principale per i certificati digitali consiste nel verificare l'origine dei dati firmati, ad esempio i file binari e così via. Un uso comune dei certificati è per la sicurezza dei messaggi Internet tramite Transport Layer Security (TLS) o Secure Sockets Layer (SSL). La verifica dei dati firmati con un certificato consente al destinatario di conoscere l'origine dei dati e se è stata modificata in transito.

    Un certificato digitale in generale contiene, a livello generale, un nome distinto (DN), una chiave pubblica e una firma. Il DN identifica un'entità, ad esempio una società, che contiene la chiave privata corrispondente alla chiave pubblica del certificato. Firma del certificato con una chiave privata e inserimento della firma nel certificato collega la chiave privata alla chiave pubblica.

    I certificati possono contenere altri tipi di dati. Ad esempio, un certificato X.509 contiene il formato del certificato, il numero di serie del certificato, l'algoritmo utilizzato per firmare il certificato, il nome della CA che ha rilasciato il certificato, il nome e la chiave pubblica dell'entità che richiede il certificato e la firma della CA.

  • 1.2.7 Certificati di concatenamento

    Da: Catene di certificati:

    root ca è autofirmato, altri firmati da root ca

    Figura 2: Catena di tre certificati

    I certificati utente vengono spesso firmati da una chiave privata diversa, ad esempio una chiave privata della CA. Si tratta di una catena di due certificati. Verificare che un certificato utente sia autentico comporta la verifica della firma, che richiede la chiave pubblica della CA, dal relativo certificato. Ma prima di poter usare la chiave pubblica della CA, è necessario verificare il certificato ca contenitore. Poiché il certificato della CA è autofirmato, la chiave pubblica della CA viene usata per verificare il certificato.

    Un certificato utente non deve essere firmato dalla chiave privata della CA radice. Può essere firmato dalla chiave privata di un intermediario il cui certificato è firmato dalla chiave privata della CA. Si tratta di un'istanza di una catena di tre certificati: certificato utente, certificato intermedio e certificato CA. Tuttavia, più intermediari possono far parte della catena, quindi le catene di certificati possono essere di qualsiasi lunghezza.

1.3 Requisiti dell'infrastruttura a chiave pubblica di avvio protetto

La radice di attendibilità definita dall'UEFI è costituita dalla chiave della piattaforma e da qualsiasi chiave inclusa nel core del firmware un OEM o ODM. La sicurezza pre-UEFI e una radice di attendibilità non sono gestite dal processo di avvio protetto UEFI, ma invece dalle pubblicazioni National Institute of Standards and Technology (NIST) e Trusted Computing Group (TCG) a cui si fa riferimento in questo documento.

  • 1.3.1 Requisiti di avvio protetto

    Per implementare l'avvio protetto, è necessario considerare i parametri seguenti:

    • Requisiti dei clienti
    • Requisiti di compatibilità hardware Windows
    • Requisiti di generazione e gestione delle chiavi.

    È necessario selezionare l'hardware per la gestione delle chiavi di avvio protetto, ad esempio moduli di protezione hardware (HSM), prendere in considerazione requisiti speciali per i PC da spedire a governi e altre agenzie e infine il processo di creazione, popolamento e gestione del ciclo di vita di varie chiavi di avvio protetto.

  • 1.3.2 Chiavi correlate all'avvio protetto

    Di seguito sono riportate le chiavi usate per l'avvio protetto:

    chiave pk, kek, db, dbx e firmware, chiave winrt

    Figura 3: Chiavi correlate all'avvio protetto

    La figura 3 precedente rappresenta le firme e le chiavi in un PC con avvio protetto. La piattaforma è protetta tramite una chiave della piattaforma installata dall'OEM nel firmware durante la produzione. Altre chiavi vengono usate dall'avvio protetto per proteggere l'accesso ai database che archiviano le chiavi per consentire o impedire l'esecuzione del firmware.

    Il database autorizzato (db) contiene chiavi pubbliche e certificati che rappresentano componenti firmware attendibili e caricatori del sistema operativo. Il database di firma non consentito (dbx) contiene hash di componenti dannosi e vulnerabili, nonché chiavi e certificati compromessi e blocca l'esecuzione di tali componenti dannosi. La forza di questi criteri si basa sulla firma del firmware usando Authenticode e l'infrastruttura a chiave pubblica (PKI). PKI è un processo ben definito per la creazione, la gestione e la revoca di certificati che stabiliscono attendibilità durante lo scambio di informazioni. L'infrastruttura a chiave pubblica è alla base del modello di sicurezza per l'avvio protetto.

    Di seguito sono riportati altri dettagli su queste chiavi.

  • 1.3.3 Platform Key (PK)

    Come indicato nella sezione 27.5.1 di UEFI 2.3.1 Errata C, la chiave della piattaforma stabilisce una relazione di trust tra il proprietario della piattaforma e il firmware della piattaforma. Il proprietario della piattaforma registra la metà pubblica della chiave (PKpub) nel firmware della piattaforma come specificato nella sezione 7.2.1 dell'UEFI 2.3.1 Errata C. Questo passaggio sposta la piattaforma in modalità utente dalla modalità di installazione. Microsoft consiglia che la chiave della piattaforma sia di tipo EFI_CERT_X509_GUID con algoritmo di chiave pubblica RSA, lunghezza della chiave pubblica di 2048 bit e algoritmo di firma sha256RSA. Il proprietario della piattaforma può usare il tipo EFI_CERT_RSA2048_GUID se lo spazio di archiviazione è un problema. Le chiavi pubbliche vengono usate per controllare le firme come descritto in precedenza in questo documento. Il proprietario della piattaforma può successivamente usare la metà privata della chiave (PKpriv):

    • Per modificare la proprietà della piattaforma, è necessario inserire il firmware in modalità di configurazione definita da UEFI che disabilita l'avvio protetto. Ripristinare la modalità di installazione solo se è necessario eseguire questa operazione durante la produzione.
    • Per i dispositivi desktop e server, gli OEM possono gestire l'infrastruttura a chiave pubblica e l'infrastruttura a chiave pubblica necessaria associata o scegliere di usare l'infrastruttura a chiave pubblica gestita da Microsoft per gli OEM. L'infrastruttura a chiave pubblica gestita da Microsoft è protetta dai moduli di protezione hardware Microsoft e gestita come parte delle procedure consigliate per l'infrastruttura a chiave pubblica. È l'infrastruttura a chiave pubblica preferita per l'ecosistema Windows.

    1.3.3.1 Per registrare o aggiornare una chiave di scambio delle chiavi (KEK) che registra la chiave della piattaforma

    Il proprietario della piattaforma registra la metà pubblica della chiave della piattaforma (PKpub) chiamando il setVariable() del servizio di avvio UEFI come specificato nella sezione 7.2.1 della specifica UEFI 2.3.1 errata C e reimpostando la piattaforma. Se la piattaforma è in modalità di installazione, il nuovo PKpub verrà firmato con la controparte PKpriv corrispondente. Se la piattaforma è in modalità utente, il nuovo PKpub deve essere firmato con il PKpriv corrente. Se l'infrastruttura a chiave pubblica è di tipo EFI_CERT_X509_GUID, questa operazione deve essere firmata dal PKpriv immediato, non da una chiave privata di qualsiasi certificato emesso nell'infrastruttura a chiave pubblica.

    1.3.3.2 Cancellazione della chiave della piattaforma

    Il proprietario della piattaforma cancella la metà pubblica della chiave della piattaforma (PKpub) chiamando l'avvio UEFI Ser\\vice SetVariable() con una dimensione variabile pari a 0 e reimpostando la piattaforma. Se la piattaforma è in modalità di installazione, non è necessario autenticare la variabile vuota. Se la piattaforma è in modalità utente, la variabile vuota deve essere firmata con il PKpriv corrente. Per informazioni dettagliate, vedere la sezione 7.2(Servizi variabili) nella specifica UEFI 2.3.1 Errata C. È consigliabile che il PKpriv di produzione non venga mai usato per firmare un pacchetto per reimpostare la piattaforma, perché ciò consente di disabilitare l'avvio protetto a livello di codice. Si tratta principalmente di uno scenario di test di pre-produzione.

    La chiave della piattaforma può anche essere cancellata usando un metodo sicuro specifico della piattaforma. In questo caso, anche la modalità di installazione della variabile globale deve essere aggiornata a 1.

    image: pk determina la modalità di installazione o la modalità utente

    Figura 4: Diagramma dello stato della chiave della piattaforma

    1.3.3.3 Generazione pk

    In base alle raccomandazioni UEFI, la chiave pubblica deve essere archiviata in una risorsa di archiviazione non volatile, che è resistente alle manomissioni e all'eliminazione sul PC. Le chiavi private rimangono sicure presso il partner o nell'ufficio di sicurezza dell'OEM e solo la chiave pubblica viene caricata nella piattaforma. Sono disponibili altri dettagli nella sezione 2.2.1 e 2.3.

    Microsoft fornisce un'infrastruttura a chiave pubblica per gli OEM per eliminare la responsabilità di mantenere e proteggere il certificato PK. L'infrastruttura a chiave pubblica è protetta da moduli di protezione hardware Microsoft e gestita come parte delle operazioni PKI Microsoft.

    Il numero di pk generated è a discrezione del proprietario della piattaforma (OEM). Queste chiavi possono essere:

    1. Uno per PC. Avere una chiave univoca per ogni dispositivo. Questo può essere necessario per enti pubblici, istituti finanziari o altri clienti server con esigenze di sicurezza elevata. Potrebbe richiedere ulteriore potenza di archiviazione e elaborazione di crittografia per generare chiavi private e pubbliche per un numero elevato di PC. In questo modo si aggiunge la complessità dei dispositivi di mapping con la chiave pubblica corrispondente durante il push degli aggiornamenti del firmware ai dispositivi in futuro. Sono disponibili alcune soluzioni HSM diverse per gestire un numero elevato di chiavi in base al fornitore del modulo di protezione hardware. Per altre informazioni, vedi Secure Boot Key Generation Using HSM .For more info, see Secure Boot Key Generation Using HSM.

    2. Uno per modello. Avere una chiave per modello PC. Il compromesso è che se una chiave viene compromessa, tutti i computer all'interno dello stesso modello sarebbero vulnerabili. Questa opzione è consigliata da Microsoft per i PC desktop.

    3. Uno per linea di prodotto. Se una chiave viene compromessa, un'intera linea di prodotti sarebbe vulnerabile.

    4. Uno per OEM. Anche se questo può essere il più semplice da configurare, se la chiave è compromessa, ogni PC prodotto sarebbe vulnerabile. Per velocizzare l'operazione sul piano della fabbrica, l'infrastruttura PK e potenzialmente altre chiavi potrebbero essere pregenerate e archiviate in una posizione sicura. Questi potrebbero essere recuperati e usati in un secondo momento nella riga di montaggio. I capitoli 2 e 3 hanno maggiori dettagli.

    1.3.3.4 Reimpostazione della chiave pubblica

    Ciò può essere necessario se l'infrastruttura a chiave pubblica viene compromessa o come requisito da parte di un cliente che per motivi di sicurezza può decidere di registrare la propria infrastruttura a chiave pubblica.

    È possibile eseguire la reimpostazione della chiave per un modello o un PC in base al metodo selezionato per creare l'infrastruttura a chiave pubblica. Tutti i PC più recenti verranno firmati con l'infrastruttura PK appena creata.

    L'aggiornamento dell'infrastruttura a chiave pubblica in un PC di produzione richiede un aggiornamento di variabile firmato con l'infrastruttura a chiave pubblica esistente che sostituisce l'infrastruttura a chiave pubblica o un pacchetto di aggiornamento del firmware. Un OEM può anche creare un pacchetto SetVariable() e distribuirne la distribuzione con una semplice applicazione, ad esempio PowerShell, che modifica semplicemente l'infrastruttura a chiave pubblica. Il pacchetto di aggiornamento del firmware verrebbe firmato dalla chiave di aggiornamento del firmware sicuro e verificato dal firmware. Se si esegue un aggiornamento del firmware per aggiornare l'infrastruttura a chiave pubblica, è necessario assicurarsi che la chiave kek, il database e il dbx vengano mantenuti.

    In tutti i PC è consigliabile non usare l'infrastruttura a chiave pubblica come chiave di aggiornamento del firmware sicuro. Se il PKpriv viene compromesso, quindi è la chiave di aggiornamento del firmware sicuro (poiché sono uguali). In questo caso, l'aggiornamento per registrare un nuovo PKpub potrebbe non essere possibile perché il processo di aggiornamento è stato compromesso.

    Nei PC SO PC c'è un altro motivo per cui non usare l'infrastruttura PK come chiave di aggiornamento del firmware sicuro. Ciò è dovuto al fatto che la chiave di aggiornamento del firmware sicuro viene bruciata in modo permanente nei PC che soddisfano i requisiti di certificazione hardware Windows.

  • 1.3.4 Chiavi di scambio chiavi (KEK) stabilisce una relazione di trust tra il sistema operativo e il firmware della piattaforma. Ogni sistema operativo (e potenzialmente, ogni applicazione di terze parti che deve comunicare con il firmware della piattaforma) registra una chiave pubblica (KEKpub) nel firmware della piattaforma.

    1.3.4.1 Registrazione delle chiavi di scambio delle chiavi

    Le chiavi di scambio delle chiavi vengono archiviate in un database di firma, come descritto in Database di firma 1.4 (Db e Dbx)). Il database della firma viene archiviato come variabile UEFI autenticata.

    Il proprietario della piattaforma registra le chiavi di scambio delle chiavi chiamando SetVariable() come specificato nella sezione 7.2(Servizi variabili) nella specifica UEFI 2.3.1 Errata C. con l'attributo EFI_VARIABLE_APPEND_WRITE impostato e il parametro Data contenente le nuove chiavi o leggendo il database usando GetVariable(), aggiungendo la nuova chiave di scambio di chiavi alle chiavi esistenti e quindi scrivendo il database usando SetVariable()come specificato nella sezione 7.2(Servizi variabili) nella specifica UEFI 2.3.1 Errata C senza il set di EFI_VARIABLE_APPEND_WRITE attributi.

    Se la piattaforma è in modalità di installazione, la variabile di database della firma non deve essere firmata, ma i parametri della chiamata SetVariable() devono comunque essere preparati come specificato per le variabili autenticate nella sezione 7.2.1. Se la piattaforma è in modalità utente, il database della firma deve essere firmato con il PKpriv corrente

    1.3.4.2 Cancellazione della chiave kek

    È possibile "cancellare" (eliminare) la chiave kek. Si noti che se l'infrastruttura a chiave pubblica non è installata nella piattaforma, le richieste "cancella" non devono essere firmate. Se sono firmati, per cancellare la chiave kek è necessario un pacchetto con firma PK e per cancellare db o dbx è necessario un pacchetto firmato da qualsiasi entità presente nella chiave di crittografia della chiave di crittografia.

    1.3.4.3 Microsoft KEK

    I seguenti 2 certificati microsoft KEK sono necessari per abilitare la revoca delle immagini non valido aggiornando il dbx e potenzialmente per l'aggiornamento del database per prepararsi per le immagini firmate di Windows più recenti.

  1. Microsoft Corporation KEK CA 2011

    • Hash del certificato SHA-1: 31 59 0b fd 89 c9 d7 4e d0 87 df ac 66 33 4b 39 31 25 4b 30.
    • SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Microsoft fornirà il certificato ai partner e può essere aggiunto come EFI_CERT_X509_GUID firma di tipo o EFI_CERT_RSA2048_GUID .
    • Il certificato della chiave kek Microsoft può essere scaricato da: https://go.microsoft.com/fwlink/?LinkId=321185.

  2. Microsoft Corporation KEK 2K CA 2023

    • Hash del certificato SHA-1: 45 9a b6 fb 5e 28 4d 27 2d 5e 3e 6a bc 8e d6 63 82 9d 63 2b.
    • SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Microsoft fornirà il certificato ai partner e può essere aggiunto come EFI_CERT_X509_GUID firma di tipo o EFI_CERT_RSA2048_GUID .
    • Il certificato della chiave kek Microsoft può essere scaricato da: https://go.microsoft.com/fwlink/?linkid=2239775.

1.3.4.4 KEKDefault Il fornitore della piattaforma deve fornire un set predefinito di chiavi di scambio delle chiavi nella variabile KEKDefault. Per altre informazioni, vedere la sezione 27.3.3 specifica UEFI .

1.3.4.5 KEK OEM/3rd party - aggiunta di più KEK

I clienti e i proprietari della piattaforma non devono avere la propria chiave kek. Nei PC non Windows RT l'OEM potrebbe avere chiavi KEK aggiuntive per consentire l'OEM aggiuntivo o un controllo di terze parti attendibile del db e dbx.

  • 1.3.5 Chiave di aggiornamento del firmware di avvio protetto La chiavedi aggiornamento del firmware sicuro viene usata per firmare il firmware quando deve essere aggiornato. Questa chiave deve avere un livello minimo di forza chiave RSA-2048. Tutti gli aggiornamenti del firmware devono essere firmati in modo sicuro dall'OEM, dal relativo delegato attendibile, ad esempio ODM o IBV (independent BIOS Vendor) o da un servizio di firma sicura.

    In base alla pubblicazione NIST 800-147 Field Firmware Update deve supportare tutti gli elementi delle linee guida:

    Qualsiasi aggiornamento all'archivio flash del firmware deve essere firmato dall'autore.

    Il firmware deve controllare la firma dell'aggiornamento.

  • 1.3.6 Creazione di chiavi per l'aggiornamento del firmware sicuro

    La stessa chiave verrà usata per firmare tutti gli aggiornamenti del firmware perché la metà pubblica risiederà nel PC. È anche possibile firmare l'aggiornamento del firmware con una chiave che concatena la chiave di aggiornamento del firmware sicuro.

    Potrebbe esserci un tasto per PC come PK o uno per modello o uno per ogni linea di prodotto. Se è presente una chiave per PC che significherebbe che milioni di pacchetti di aggiornamento univoci dovranno essere generati. Prendere in considerazione la disponibilità delle risorse in base al metodo che funzionerebbe per l'utente. Avere una chiave per modello o linea di prodotto è un buon compromesso.

    La chiave pubblica secure firmware Update (o il relativo hash per risparmiare spazio) verrebbe archiviata in alcune risorse di archiviazione protette nella piattaforma, in genere flash protetto (PC) o fusibili programmabili monouso (SOC).

    Se viene archiviato solo l'hash di questa chiave (per risparmiare spazio), l'aggiornamento del firmware includerà la chiave e la prima fase del processo di aggiornamento verificherà che la chiave pubblica nell'aggiornamento corrisponda all'hash archiviato nella piattaforma.

    Le capsule sono un mezzo per cui il sistema operativo può passare i dati all'ambiente UEFI in un riavvio. Windows chiama UEFI UpdateCapsule() per distribuire gli aggiornamenti del firmware del sistema e del PC. Al momento dell'avvio prima di chiamare ExitBootServices(), Windows passerà tutti i nuovi aggiornamenti del firmware trovati in Windows Driver Store in UpdateCapsule(). Il firmware di sistema UEFI può usare questo processo per aggiornare il firmware del sistema e del PC. Sfruttando il supporto di questo firmware di Windows, un OEM può basarsi sullo stesso formato e processo comune per l'aggiornamento del firmware sia per il sistema che per il firmware del PC. Il firmware deve implementare la tabella ACPI ESRT per supportare UEFI UpdateCapsule() per Windows.

    Per informazioni dettagliate sull'implementazione del supporto per windows UEFI Firmware Update Platform, vedere la documentazione seguente: Windows UEFI Firmware Update Platform.

    Le capsule di aggiornamento possono essere in memoria o sul disco. Windows supporta gli aggiornamenti in memoria.

    1.3.6.1 Capsule (Capsule-in-Memory)

    Di seguito è riportato il flusso degli eventi per il funzionamento di una capsula di aggiornamento in memoria.

    1. Una capsula viene messa in memoria da un'applicazione nel sistema operativo
    2. L'evento Mailbox è impostato per informare il BIOS dell'aggiornamento in sospeso
    3. I riavvii del PC, verifica l'immagine della capsula e l'aggiornamento vengono eseguiti dal BIOS

  • 1.3.7 Flusso di lavoro di un tipico aggiornamento del firmware

    1. Scaricare e installare il driver del firmware.
    2. Riavvia.
    3. Il caricatore del sistema operativo rileva e verifica il firmware.
    4. Il caricatore del sistema operativo passa un BLOB binario a UEFI.
    5. UEFI esegue l'aggiornamento del firmware (questo processo è di proprietà del fornitore del processore).
    6. Il rilevamento del caricatore del sistema operativo viene completato correttamente.
    7. Il sistema operativo termina l'avvio.

1.4 Database di firma (Db e Dbx)

  • 1.4.1 Database di firma consentito (db)

    Il contenuto del database EFI _IMAGE_SECURITY_DATABASE controlla quali immagini sono attendibili durante la verifica delle immagini caricate. Il database può contenere più certificati, chiavi e hash per identificare le immagini consentite.

    Per consentire il caricamento del caricatore del sistema operativo Windows, è necessario includere i 2 certificati seguenti nel database:

  1. Microsoft Windows Production PCA 2011

    • Hash del certificato SHA-1: 58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d.
    • SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Microsoft fornirà il certificato ai partner e può essere aggiunto come EFI_CERT_X509_GUID firma di tipo o EFI_CERT_RSA2048_GUID .
    • Windows Production PCA 2011 può essere scaricato da qui: https://go.microsoft.com/fwlink/p/?linkid=321192.

  2. WINDOWS UEFI CA 2023

    • Hash del certificato SHA-1: 45 a0 fa 32 60 47 73 c8 24 33 c3 b7 d5 9e 74 66 b3 ac 0c 67.
    • SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Microsoft fornirà il certificato ai partner e può essere aggiunto come EFI_CERT_X509_GUID firma di tipo o EFI_CERT_RSA2048_GUID .
    • Windows UEFI CA 2023 può essere scaricato da qui: https://go.microsoft.com/fwlink/?linkid=2239776.

Ad eccezione dei sistemi bloccati solo per l'avvio di Windows, l'OEM deve prendere in considerazione l'inclusione delle CA UEFI di Microsoft 3rd Party per consentire l'esecuzione di driver e applicazioni UEFI da terze parti nel PC senza richiedere passaggi aggiuntivi per l'utente.

  1. Microsoft Corporation UEFI CA 2011

    • Hash del certificato SHA-1: 46 de f6 3b 5c e6 1c f8 ba 0d e2 e6 63 9c 10 19 d0 ed 14 f3.
    • SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Microsoft fornirà il certificato ai partner e può essere aggiunto come EFI_CERT_X509_GUID firma di tipo o EFI_CERT_RSA2048_GUID .
    • Microsoft Corporation UEFI CA 2011 può essere scaricato da qui: https://go.microsoft.com/fwlink/p/?linkid=321194.

  2. Microsoft UEFI CA 2023

    • Hash del certificato SHA-1: b5 ee b4 a6 70 60 48 07 3f 0e d2 96 e7 f5 80 a7 90 b5 9e aa.
    • SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Microsoft fornirà il certificato ai partner e può essere aggiunto come EFI_CERT_X509_GUID firma di tipo o EFI_CERT_RSA2048_GUID .
    • Microsoft UEFI CA 2023 può essere scaricato da qui: https://go.microsoft.com/fwlink/?linkid=2239872.

  • 1.4.2 DbDefault: il fornitore della piattaforma deve fornire un set predefinito di voci per il database della firma nella variabile dbDefault. Per altre informazioni, vedere la sezione 27.5.3 nella specifica UEFI.

  • 1.4.3 Database delle firme non consentite (dbx)

    Il contenuto di dbx deve essere controllato durante la verifica delle immagini prima di EFI_IMAGE_SIGNATURE_DATABASE1 controllare il database e le eventuali corrispondenze devono impedire l'esecuzione dell'immagine. Il database può contenere più certificati, chiavi e hash per identificare le immagini non consentite. I requisiti di certificazione hardware Windows dichiarano che un dbx deve essere presente, pertanto qualsiasi valore fittizio, ad esempio l'hash SHA-256 di 0, può essere usato come segnaposto sicuro fino a quando Microsoft inizia a recapitare gli aggiornamenti dbx. Fare clic qui per scaricare l'elenco di revoche UEFI più recente da Microsoft.

  • 1.4.4 DbxDefault: il fornitore della piattaforma può fornire un set predefinito di voci per il database della firma nella variabile dbxDefault. Per altre informazioni, vedere la sezione 27.5.3 nella specifica UEFI.

1.5 Chiavi necessarie per l'avvio protetto in tutti i PC

Nota

Gli OEM dei dispositivi, le aziende e i clienti possono trovare i file binari PK, KEK, DB e DBX consigliati da Microsoft nel repository open source di avvio protetto di Microsoft. I file binari vengono formattati nel formato EDKII previsto per integrarsi facilmente nel firmware.

Nome chiave/database Variabile Proprietario Note

PKpub

PK

OEM

PK : solo 1. Deve essere RSA 2048 o più forte.

https://go.microsoft.com/fwlink/?linkid=2255361

Microsoft Corporation KEK CA 2011

Microsoft Corporation KEK 2K CA 2023

KEK

Microsoft

Consente gli aggiornamenti a db e dbx:

https://go.microsoft.com/fwlink/p/?linkid=321185

https://go.microsoft.com/fwlink/p/?linkid=2239775.

Microsoft Windows Production CA 2011

WINDOWS UEFI CA 2023

db

Microsoft

Questa CA nel database di firma (db) consente a Windows di avviare: https://go.microsoft.com/fwlink/?LinkId=321192

https://go.microsoft.com/fwlink/p/?linkid=2239776.

Database delle firme non consentite

Dbx

Microsoft

Elenco di chiavi, ca o immagini non note da Microsoft

Proteggere la chiave di aggiornamento del firmware

OEM

È consigliabile che questa chiave sia diversa dall'infrastruttura a chiave pubblica

Tabella 1: Chiavi/database necessarie per l'avvio protetto

2. Soluzioni di gestione delle chiavi

Di seguito sono riportate alcune delle metriche usate per il confronto.

2.1 Metriche usate

Le metriche seguenti consentono di selezionare un PC HSM in base ai requisiti della specifica UEFI 2.3.1 Errata C e alle proprie esigenze.

  • Supporta RSA 2048 o versione successiva? - La specifica UEFI 2.3.1 Errata C consiglia le chiavi per essere RSA-2048 o superiore.
  • Ha la possibilità di generare chiavi e firmare?
  • Quante chiavi possono archiviare? Archivia le chiavi nel modulo di protezione hardware o in un server collegato?
  • Metodo di autenticazione per il recupero delle chiavi. Alcuni PC supportano più entità di autenticazione da presentare per il recupero delle chiavi.

Prezzi

  • Qual è il punto di prezzo? I moduli di protezione hardware possono variare nel prezzo da $ 1.500 a $ 70.000 a seconda delle funzionalità disponibili.

Ambiente di produzione

  • Velocità operativa sul pavimento della fabbrica. I processori di crittografia possono velocizzare la creazione e l'accesso delle chiavi.
  • Facilità di installazione, distribuzione, manutenzione.
  • Set di competenze e formazione necessari?
  • Accesso alla rete per il backup e la disponibilità elevata

Standard e conformità

  • Quale livello di conformità FIPS ha? È resistente alle manomissioni?
  • Supporto per altri standard, ad esempio api di crittografia MS.
  • Soddisfa i requisiti di governo e di altri enti?

Affidabilità e ripristino di emergenza

  • Consente il backup delle chiavi?

    I backup possono essere archiviati sia in loco in una posizione sicura che sia un percorso fisico diverso rispetto al computer CA e al modulo di protezione hardware e /o in una posizione esterna.

  • Consente la disponibilità elevata per il ripristino di emergenza?

2.2 Opzioni di gestione delle chiavi

  • 2.2.1 Modulo di protezione hardware

    In base ai criteri precedenti, questa è probabilmente la soluzione più adatta e sicura. La maggior parte del modulo di protezione hardware ha conformità FIPS 140-2 livello 3. La conformità FIPS 140-2 livello 3 è rigorosa per l'autenticazione e richiede che le chiavi non vengano esportate o importate dal modulo di protezione hardware.

    Supportano più modi di archiviazione delle chiavi. Possono essere archiviati localmente nel modulo di protezione hardware stesso o nel server collegato al modulo di protezione hardware. Nel server le chiavi vengono crittografate e archiviate ed è preferibile per le soluzioni che richiedono l'archiviazione di molte chiavi.

    I criteri di sicurezza del modulo di crittografia specificano criteri di sicurezza fisica, inclusi i meccanismi di sicurezza fisica implementati in un modulo di crittografia, ad esempio, sigilli evidenti delle manomissioni, blocchi, risposta manomissione e interruttori di zeroizzazione e allarmi. Consente inoltre di specificare le azioni richieste dagli operatori per garantire che la sicurezza fisica venga mantenuta, ad esempio l'ispezione periodica di sigilli antimanomissione o test di risposta manomissione e interruttori di zeroizzazione.

    • 2.2.1.1 Modulo di protezione hardware di rete

      Questa soluzione è la migliore nella sua classe in termini di sicurezza, conformità agli standard, generazione delle chiavi, archiviazione e recupero. La maggior parte di questi PC supporta la disponibilità elevata e ha la possibilità di eseguire il backup delle chiavi.

      I costi di questi prodotti possono essere in decine di migliaia di dollari in base ai servizi extra offerti.

    • 2.2.1.2 Modulo di protezione hardware autonomo

      Queste funzionino bene con i server autonomi. È possibile usare Microsoft CAPI e CNG o qualsiasi altra API protetta supportata da HSM. Questi moduli di protezione hardware sono disponibili in diversi fattori di forma che supportano bus USB, PCIe e PCMCIA.

      Facoltativamente, supportano il backup delle chiavi e la disponibilità elevata.

  • 2.2.2 Provider di soluzioni personalizzate

    La crittografia a chiave pubblica può essere complessa e richiedere la comprensione dei concetti crittografici che potrebbero essere nuovi. Esistono provider di soluzioni personalizzati che potrebbero aiutare a lavorare con l'avvio protetto nell'ambiente di produzione.

    Esistono diverse varietà di soluzioni personalizzate offerte dai fornitori di BIOS, dalle aziende HSM e dalle società di consulenza PKI per ottenere l'infrastruttura PKI di avvio protetto nell'ambiente di produzione.

    Di seguito sono elencati alcuni provider:

    • 2.2.2.1 Fornitori di BIOS

      Esistono alcuni fornitori di BIOS che possono essere in grado di fornire soluzioni personalizzate.

    • 2.2.2.2 Fornitori di moduli di protezione hardware

      Alcuni fornitori di moduli di protezione hardware possono essere in grado di fornire consulenza personalizzata. Per altre informazioni, vedi Generazione e firma della chiave di avvio protetto con HSM (esempio).

  • 2.2.3 Trusted Platform Module (TPM)

    Un TPM (Trusted Platform Module) è un chip hardware nella scheda madre che archivia le chiavi crittografiche usate per la crittografia. Molti computer includono un TPM, ma se il PC non lo include, non è possibile aggiungerne uno. Dopo l'abilitazione, trusted platform module consente di proteggere i prodotti di crittografia dei dischi completi, ad esempio le funzionalità di Microsoft BitLocker. Mantiene i dischi rigidi bloccati, o sealed, fino a quando il PC non completa un processo di verifica o autenticazione del sistema.

    Il TPM può generare, archiviare e proteggere le chiavi usate nel processo di crittografia e decrittografia.

    Gli svantaggi dei TPM sono che potrebbero non avere processori di crittografia veloci per velocizzare l'elaborazione nell'ambiente di produzione. Non sono adatti anche per l'archiviazione di un numero elevato di chiavi. La conformità di backup e disponibilità elevata e standard a FIPS 140-2 livello 3 potrebbe non essere disponibile.

  • 2.2.4 Smart Card

    Una smart card può generare e archiviare le chiavi. Condividono alcune funzionalità supportate dal modulo di protezione hardware, ad esempio l'autenticazione e la correzione delle manomissioni, ma non includono molte risorse di archiviazione o backup delle chiavi. Richiedono un intervento manuale e potrebbero non essere adatti per l'automazione e l'uso nell'ambiente di produzione, perché le prestazioni potrebbero essere ridotte.

    Gli svantaggi delle smart card sono simili ai TPM. Potrebbero non avere processori di crittografia veloci per velocizzare l'elaborazione nell'ambiente di produzione. Non sono adatti anche per l'archiviazione di un numero elevato di chiavi. La conformità di backup e disponibilità elevata e standard a FIPS 140-2 livello 3 potrebbe non essere disponibile.

  • 2.2.5 Certificato di convalida estesa

    I certificati EV sono certificati a garanzia elevata le cui chiavi private vengono archiviate nei token hardware. Ciò consente di stabilire procedure di gestione delle chiavi più avanzate. I certificati EV hanno gli stessi svantaggi delle smart card.

  • 2.2.6 Approcci incentrati sul software (NON CONSIGLIATO)

    Usare le API di crittografia per la gestione delle chiavi. Ciò può comportare l'archiviazione di una chiave in un contenitore di chiavi in un disco rigido crittografato ed è possibile per un uso aggiuntivo della sandbox e della sicurezza di una macchina virtuale.

    Queste soluzioni non sono sicure come l'uso di un modulo di protezione hardware ed espongono un vettore di attacco superiore.

    2.2.6.1 Makecert (NON CONSIGLIATO)

    Makecert è uno strumento Microsoft e può essere usato come segue per la generazione di chiavi. Per assicurarsi che la superficie di attacco sia ridotta al minimo, potrebbe essere necessario "spazio d'aria" il PC. Il PC con PKpriv su non deve essere connesso alla rete. Dovrebbe trovarsi in una posizione sicura e idealmente dovrebbe usare almeno un lettore di smart card se non un modulo di protezione hardware reale.

    makecert -pe -ss MY -$ individual -n "CN=your name here" -len 2048 -r

    Per altre info, vedi Strumento di creazione certificati (Makecert.exe).

    Questa soluzione non è consigliata.

2.3 Generazione e archiviazione della chiave HSM per le chiavi di avvio protetto

  • 2.3.1 Archiviazione di chiavi private

    Il requisito di spazio per ogni chiave RSA-2048 è a 2048 bit. La posizione effettiva dell'archiviazione delle chiavi dipende dalla soluzione scelta. Il modulo di protezione hardware è un buon modo per archiviare le chiavi.

    La posizione fisica dei PC sul pavimento della fabbrica deve essere un'area protetta con accesso limitato degli utenti come una gabbia sicura.

    A seconda dei requisiti, queste chiavi possono anche essere archiviate in una posizione geografica diversa o sottoposte a backup in una posizione diversa.

    I requisiti di reimpostazione della chiave per queste chiavi possono variare in base al cliente (vedere Appendice A per le linee guida per la reimpostazione della chiave dell'autorità di certificazione bridge federale).

    Questi potrebbero essere fatti una volta all'anno. Potrebbe essere necessario avere accesso a queste chiavi per un massimo di 30 anni (a seconda dei requisiti di reimpostazione e così via).

  • 2.3.2 Recupero delle chiavi private

    Le chiavi possono essere recuperate per molti motivi.

    1. Potrebbe essere necessario recuperare l'infrastruttura a chiave pubblica per rilasciare un'infrastruttura a chiave pubblica aggiornata a causa di una compromissione o per rispettare le normative governative /altre normative dell'agenzia.
    2. KEKpri verrà usato per aggiornare il database e dbx.
    3. La chiave di aggiornamento del firmware sicura -pri verrà usata per firmare gli aggiornamenti più recenti.

  • 2.3.3 Autenticazione

    In base all'autenticazione FIPS 140-2 si basa sul livello di accesso.

    Livello 2

    Il livello di sicurezza 2 richiede, almeno, l'autenticazione basata su ruoli in cui un modulo di crittografia autentica l'autorizzazione di un operatore per assumere un ruolo specifico ed eseguire un set corrispondente di servizi.

    Livello 3

    Il livello di sicurezza 3 richiede meccanismi di autenticazione basati sull'identità, migliorando la sicurezza fornita dai meccanismi di autenticazione basati sui ruoli specificati per il livello di sicurezza 2. Un modulo di crittografia autentica l'identità di un operatore e verifica che l'operatore identificato sia autorizzato a assumere un ruolo specifico ed eseguire un set di servizi corrispondente.

    I PC come il modulo di protezione hardware supportano il livello di sicurezza 3, che richiede l'autenticazione "k di m" basata sull'identità. Ciò significa che alle k entità viene concesso l'accesso al modulo di protezione hardware con un token, ma in un determinato punto almeno k dei token m deve essere presente per consentire l'autenticazione per ottenere l'accesso alle chiavi private dal modulo di protezione hardware.

    Ad esempio, è possibile avere 3 token su 5 devono essere autenticati per accedere al modulo di protezione hardware. Questi membri possono essere i responsabili della sicurezza, il responsabile delle transazioni e/o i membri della direzione executive.

    Token HSM

    È possibile avere un criterio nel modulo di protezione hardware che richiede che il token sia presente:

    • Locale

    • Remoto

    • Configurato per l'automazione

    Come procedura consigliata, usare una combinazione di token e password per token.

2.4 Avvio protetto e firma di terze parti

  • 2.4.1 Firma del driver UEFI

    I driver UEFI devono essere firmati da una CA o da una chiave nel database come descritto altrove nel documento oppure avere l'hash dell'immagine del driver inclusa nel database. Microsoft fornirà un servizio di firma del driver UEFI simile al servizio di firma del driver WHQL usando Microsoft Corporation UEFI CA 2011. Tutti i driver firmati da questo verranno eseguiti senza problemi su qualsiasi PC che includa la CA UEFI Microsoft. È anche possibile che un OEM firmi driver attendibili e includa la CA OEM nel database o includere hash dei driver nel database. In tutti i casi, un driver UEFI (Option ROM) non verrà eseguito se non è attendibile nel database.

    Tutti i driver inclusi nell'immagine del firmware di sistema non devono essere verificati nuovamente. Essere parte dell'immagine complessiva del sistema fornisce una garanzia sufficiente che il driver sia considerato attendibile nel PC.

    Microsoft ha reso disponibile a chiunque voglia firmare i driver UEFI. Questo certificato fa parte dei test di avvio protetto di Windows HCK. Seguire [questo blog]((https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/) per altre informazioni sui criteri di firma e sugli aggiornamenti della CA UEFI.

  • 2.4.2 Caricatori di avvio

    Il certificato di firma del driver UEFI Microsoft può essere usato per firmare altri sistemi operativi. Ad esempio, il caricatore di avvio Linux di Fedora verrà firmato da esso.

    Questa soluzione non richiede l'aggiunta di altri certificati al database della chiave. Oltre a essere conveniente, può essere usato per qualsiasi distribuzione Linux. Questa soluzione funziona per qualsiasi hardware che supporta Windows, quindi è utile per un'ampia gamma di hardware.

    La CA UEFI può essere scaricata da qui: https://go.microsoft.com/fwlink/p/?LinkID=321194. I collegamenti seguenti contengono altre informazioni sulla firma e l'invio ueFI di Windows HCK:

3. Riepilogo e risorse

Questa sezione intende riepilogare le sezioni precedenti e mostrare un approccio dettagliato:

  1. Stabilire una CA sicura o identificare un partner per generare e archiviare le chiavi in modo sicuro

    Se non si usa una soluzione di terze parti:

    1. Installare e configurare il software HSM nel server HSM. Controllare il manuale di riferimento del modulo di protezione hardware per istruzioni di installazione. Il server verrà connesso a un modulo di protezione hardware autonomo o di rete.

      Per informazioni sulla configurazione del modulo di protezione hardware, vedere la sezione 2.2.1, 2.3 e Appendice C.

      La maggior parte dei moduli di protezione hardware offre conformità FIPS 140-2 livello 2 e 3. Configurare il modulo di protezione hardware per la conformità di livello 2 o di livello 3. La conformità di livello 3 ha requisiti più rigorosi per l'autenticazione e l'accesso alle chiavi e quindi è più sicuro. È consigliabile il livello 3.

    2. Configurare HSM per disponibilità elevata, backup e autenticazione. Controllare il manuale di riferimento del modulo di protezione hardware.

      Seguire le linee guida per il provider di moduli di protezione hardware per la configurazione del modulo di protezione hardware per la disponibilità elevata e il backup.

      Inoltre, i moduli di protezione hardware di rete hanno in genere più porte di rete per separare il traffico; consentire a un server di comunicare con i moduli di protezione hardware di rete in una rete separata dalla normale rete di produzione.

      Dopo che i membri del team che fanno parte del team di sicurezza sono stati identificati e i token assegnati. Sarà necessario configurare l'hardware HSM per l'autenticazione k-of-m.

    3. Proteggere le chiavi di avvio e la pre-generazione del certificato. Vedere le sezioni da 1.3 a 1.5

      Usare le API del modulo di protezione hardware per pre-generare (generare in anticipo) la chiave e i certificati di aggiornamento pk e firmware.

      Obbligatorio - PK (consigliato 1 per modello), Chiave di aggiornamento del firmware (raccomandazione 1 per modello), Microsoft KEK, DbxNOTE: Microsoft KEK, db e dbx non devono essere generati dall'OEM e sono indicati per completezza. Facoltativo- DB KEK OEM/3rd party, dbx e qualsiasi altra chiave che verrebbe inserita nel database OEM.

  2. Applicare un'immagine di Windows al PC.

  3. Installare Microsoft db e dbx. Vedere la sezione 1.3.6 e l'Appendice B - API di avvio protetto.

    1. Installare microsoft Windows Production PCA 2011 nel database.

    2. Installare un dbx vuoto se Microsoft non ne fornisce uno. Windows aggiornerà automaticamente DBX alla versione più recente di DBX tramite Windows Update al primo riavvio.

    Nota

    Usare i cmdlet di PowerShell che fanno parte dei test HCK di Windows o usano metodi forniti dal fornitore del BIOS.

  4. Installare Microsoft KEK. Vedere la sezione 1.3.3.

    Installare Microsoft KEK nel database KEK UEFI

    Attenzione

    Usare i cmdlet di PowerShell che fanno parte dei test HCK di Windows o usano metodi forniti dal fornitore del BIOS.

  5. Passaggio facoltativo: componenti di avvio sicuro OEM/3rd party. Vedere la sezione 1.3.4 e 1.4.

    1. Identificare se è necessario creare una chiave kek oem/terza parte, db e dbx.

    2. Firmare db e dbx OEM/3rd party con KEK oem/3rd party (generato in precedenza) usando l'API HSM.

    3. Installare la chiave kek oem/terza parte, db e dbx.

  6. Firma del driver UEFI: vedere la sezione 2.4.

    Se supporta le schede del componente aggiuntivo o altri driver UEFI/apps/bootloaders, installare Microsoft Corporation UEFI CA 2011 nel database UEFI.

  7. Chiave di aggiornamento del firmware di avvio protetto: vedere la sezione 1.3.5.

    1. Solo PC Non Windows RT: installare la chiave pubblica di aggiornamento del firmware protetto o il relativo hash per risparmiare spazio.

    2. Solo in SoC potrebbe essere necessario eseguire un'operazione diversa, ad esempio masterizzare la chiave di aggiornamento del firmware protetto: public o il relativo hash.

  8. Abilitazione dell'avvio protetto. Vedere Appendice B - API di avvio protetto.

    1. Installare OEM/ODM PKpub (certificato preferito, ma la chiave è ok) nell'infrastruttura PK UEFI.

    2. Registrare l'infrastruttura a chiave pubblica usando l'API di avvio protetto. Il PC dovrebbe ora essere abilitato per l'avvio protetto.

    Nota

    Se si installa la chiave pubblica alla fine, ms kek, dbx non deve essere firmato. Non è necessario che sia presente SignerInfo. Si tratta di un collegamento.

  9. Test dell'avvio protetto: eseguire tutti i test proprietari e i test HCK di Windows in base alle istruzioni. Vedere Appendice B - API di avvio protetto.

  10. Piattaforma di spedizione: il PKpriv probabilmente non verrà mai usato di nuovo, mantenendolo al sicuro.

  11. Manutenzione: gli aggiornamenti futuri del firmware vengono firmati in modo sicuro con la chiave "privata" di aggiornamento del firmware sicuro usando il servizio di firma.

3.1 Risorse

White paper sulle strategie di sicurezza - https://go.microsoft.com/fwlink/p/?linkid=321288

Invio di Windows HCK -https://go.microsoft.com/fwlink/p/?linkid=321287

Appendice A - Elenco di controllo pki di avvio protetto per la produzione

Di seguito è riportato un elenco di controllo generale che riepiloga i passaggi necessari per abilitare l'avvio protetto in PC non Windows RT.

Configurazione dell'avvio protetto

  1. Definire la strategia di sicurezza (identificare le minacce, definire una strategia proattiva e reattiva) in base al white paper nella sezione 4.

  2. Identificare il team di sicurezza in base al white paper nella sezione 4.

  3. Stabilire una CA sicura o identificare un partner (soluzione consigliata) per generare e archiviare le chiavi in modo sicuro.

  4. Identificare i criteri per la frequenza di reimpostazione delle chiavi. Questo può dipendere da se si dispone di requisiti speciali per i clienti, ad esempio governi o altre agenzie.

  5. Avere un piano di emergenza nel caso in cui la chiave di avvio sicura sia compromessa.

  6. Identificare il numero di chiavi PK e altre che verranno generati in base alla sezione 1.3.3 e 1.5.

    Questo sarà basato sulla base dei clienti, sulla soluzione di archiviazione delle chiavi e sulla sicurezza dei PC.

    È possibile ignorare i passaggi da 7 a 8 se si usa la soluzione consigliata di usare una terza parte per la gestione delle chiavi.

  7. Procurarsi il server e l'hardware per la gestione delle chiavi. : modulo di protezione hardware autonomo o di rete per sezione 2.2.1. Valutare se sono necessari uno o più moduli di protezione hardware per la disponibilità elevata e la strategia di backup chiave.

  8. Identificare almeno 3-4 membri del team che avranno un token di autenticazione per l'autenticazione nel modulo di protezione hardware.

  9. Usare HSM o terze parti per pre-generare chiavi e certificati correlati all'avvio protetto. Le chiavi dipendono dal tipo di PC: SoC, Windows RT o non Windows RT. Per altre info, vedi Sezioni da 1.3 a 1.5.

  10. Popolare il firmware con le chiavi appropriate.

  11. Registrare la chiave della piattaforma di avvio protetto per abilitare l'avvio protetto. Per altri dettagli, vedere Appendice B.

  12. Eseguire tutti i test proprietari e i test di avvio protetto HCK in base alle istruzioni. Per altri dettagli, vedere Appendice B.

  13. Spedire il PC. Il PKpriv probabilmente non verrà mai usato di nuovo, mantenendolo al sicuro.

Manutenzione (aggiornamento del firmware)

Potrebbe essere necessario aggiornare il firmware per diversi motivi, ad esempio l'aggiornamento di un componente UEFI o la correzione della compromissione della chiave di avvio protetto o la reimpostazione periodica delle chiavi di avvio protetto.

Per altre info, vedi Sezione 1.3.5 e sezione 1.3.6.

Appendice B : API di avvio protetto

  1. API di avvio protetto

    Le API seguenti sono correlate all'avvio UEFI/Protetto:

    1. GetFirmwareEnvironmentVariableEx: recupera il valore della variabile di ambiente del firmware specificata.

    2. SetFirmwareEnvironmentVariableEx: imposta il valore della variabile di ambiente del firmware specificata.

    3. GetFirmwareType: recupera il tipo di firmware.

  2. Impostazione dell'infrastruttura a chiave pubblica

    Usare il cmdlet Set-SecureBootUEFI per attivare l'avvio protetto. Dopo che il codice imposta l'infrastruttura a chiave pubblica, l'applicazione del sistema di avvio protetto non avrà effetto fino al successivo riavvio. Prima del riavvio, il codice potrebbe chiamare GetFirmwareEnvironmentVariableEx() o il cmdlet di PowerShell Get-SecureBootUEFI per confermare il contenuto dei database di avvio protetto.

  3. Verifica

    È possibile usare Msinfo32.exe o cmdlet di PowerShell per controllare lo stato della variabile di avvio protetto. Non esiste un'interfaccia WMI. È anche possibile verificare se qualcuno inserisce una chiavetta USB con firma non corretta (ad esempio, dal test del logo manuale dell'avvio protetto windows HCK) e verificare che l'avvio non riesca.

  4. Cmdlet di PowerShell per l'avvio protetto

    • Confirm-SecureBootUEFI: l'avvio protetto UEFI è "ON", True o False?

      SetupMode == 0 && SecureBoot == 1

    • Set-SecureBootUEFI: impostare o aggiungere variabili UEFI secureboot autenticate

    • Get-SecureBootUEFI: Ottenere i valori delle variabili UEFI di SecureBoot autenticati

    • Format-SecureBootUEFI: crea EFI_SIGNATURE_LISTs e serializzazioni EFI_VARIABLE_AUTHENTICATION_2

  5. Istruzioni di avvio protetto e Windows HCK

    I passaggi seguenti si applicano ai test di sistema e ai test PC driver non di classe.

    1. Disabilitare le protezioni di avvio protetto.

      Immettere la configurazione del BIOS e disabilitare l'avvio protetto.

    2. Installare il software client HCK.

    3. Eseguire tutti i test HCK di Windows, ad eccezione dei seguenti:

      • Test della password TPM e ripristino di BitLocker con PCR[7]
      • Test della password TPM e ripristino di BitLocker per i PC Arm con avvio protetto
      • Test del logo di avvio protetto
      • Test del logo manuale di avvio protetto

    4. Immettere la configurazione del BIOS, abilitare Avvio protetto e ripristinare l'avvio protetto nella configurazione predefinita.

    5. Eseguire i test di avvio sicuro e BitLocker seguenti:

      • Test della password TPM e ripristino di BitLocker con PCR[7]
      • Test della password TPM e ripristino di BitLocker per i PC Arm con avvio protetto
      • Test del logo di avvio protetto (automatizzato)

    6. Immettere la configurazione del BIOS e deselezionare la configurazione di avvio protetto. In questo modo il PC viene ripristinato in modalità di installazione eliminando PK e altre chiavi.

      Nota

      Il supporto per la cancellazione è necessario per i PC x86/x64.

    7. Eseguire il test del logo manuale di avvio protetto.

      Nota

      L'avvio protetto richiede driver Windows HCK firmati o VeriSign in PC non Windows RT

  6. Test del logo di avvio protetto di Windows HCK (automatizzato)

    Questo test verificherà la corretta configurazione predefinita dell'avvio protetto. Valuta gli ambiti seguenti:

    • L'avvio protetto è Abilitato.
    • L'infrastruttura a chiave pubblica non è nota, testare l'infrastruttura a chiave pubblica.
    • KEK contiene la chiave di produzione Microsoft KEK.
    • db contiene la CA Windows di produzione.
    • dbx presente.
    • Vengono create/eliminate molte variabili 1kB.
    • Viene creata/eliminata una variabile 32kB.

  7. Layout della cartella di test manuale di avvio protetto di Windows HCK

    Il layout della cartella di test del logo manuale di avvio protetto di Windows HCK è descritto di seguito:

    • "\Test" la cartella include quanto segue:

      • Test di produzione e manutenzione
      • Abilitare l'avvio protetto a livello di codice nella configurazione di test
      • Test di manutenzione
      • Aggiungere un certificato al database, verificare la funzione
      • Aggiungere un hash a dbx, verificare la funzione
      • Aggiungere un certificato a dbx, verificare la funzione
      • Aggiungere 600+ hash a dbx, verificare le dimensioni
      • Modificare a livello di codice l'infrastruttura a chiave pubblica

    • "\Generate" la cartella include script che mostrano quanto segue:

      • Come sono stati creati i certificati di test

      • Sono inclusi i certificati di test e le chiavi private

      • Come sono stati creati tutti i test

      • Trasformazione di certificati e hash in pacchetti firmati

      • È possibile eseguire questa operazione manualmente, sostituire i propri certificati

    • "\certs" la cartella include tutti i certificati necessari per avviare Windows:

      Nota

      Non usare la metodologia usata in "ManualTests\generate\TestCerts" per generare chiavi e certificati. Questo è destinato solo a scopi di test HCK di Windows. Usa chiavi archiviate su disco che sono molto non sicure e non consigliate. Questo non è destinato all'uso in un ambiente di produzione.

  • "ManualTests\example\OutOfBox" la cartella include script che è possibile sfruttare per l'installazione di Avvio protetto nei PC di produzione.

    "ManualTests\generate\tests\subcreate_outofbox_example.ps1" Illustra come questi esempi sono stati generati e hanno sezioni "TODO" quando un partner può sostituire la chiave pubblica e altri metadati.

  1. Firma e invio UEFI di Windows HCK

    Per altre informazioni, vedere i collegamenti seguenti:

Appendice C - Mapping dei criteri di controllo dei criteri di certificazione dell'autorità di certificazione Federal Bridge

  1. Rudimentale

    Questo livello garantisce il grado più basso di garanzia relativo all'identità dell'individuo. Una delle funzioni principali di questo livello consiste nel fornire l'integrità dei dati alle informazioni firmate. Questo livello è rilevante per gli ambienti in cui il rischio di attività dannose è considerato basso. Non è adatto per le transazioni che richiedono l'autenticazione e in genere non è sufficiente per le transazioni che richiedono riservatezza, ma può essere usato per quest'ultimo, in cui i certificati con livelli di garanzia più elevati non sono disponibili.

  2. Base

    Questo livello fornisce un livello di garanzia di base rilevante per gli ambienti in cui ci sono rischi e conseguenze di compromissione dei dati, ma non sono considerati importanti. Ciò può includere l'accesso a informazioni private in cui la probabilità di accesso dannoso non è elevata. Si presuppone che a questo livello di sicurezza gli utenti non siano probabilmente dannosi.

  3. Medium

    Questo livello è rilevante per gli ambienti in cui i rischi e le conseguenze della compromissione dei dati sono moderati. Ciò può includere transazioni con un notevole valore monetario o rischio di frode o l'accesso a informazioni private in cui la probabilità di accesso dannoso è sostanziale.

  4. Alto

    Questo livello è appropriato per l'uso in cui le minacce ai dati sono elevate o le conseguenze dell'errore dei servizi di sicurezza sono elevate. Ciò può includere transazioni di valore molto elevato o elevati livelli di rischio di frode.

Generazione e firma della chiave di avvio protetto con HSM (esempio)

Linee guida per la convalida ROM dell'opzione di convalida UEFI

Panoramica dell'avvio protetto