Controllo BitLocker dopo l'aggiornamento del firmware

Questo test determina se il dispositivo ha raggiunto il ripristino durante il processo di aggiornamento del firmware. BitLocker deve essere abilitato prima di un aggiornamento del firmware e il test deve essere eseguito dopo un aggiornamento.

Dettagli del test

Specifiche	Device.DevFund.Firmware.UpdateDriverPackage
Piattaforme	Windows 10, edizioni client (x86) Windows 10, edizioni client (x64) Windows Server 2016 (x64) Windows 10, edizioni client (Arm64)
Versioni supportate	Windows 10 Windows 10 versione 1511 Windows 10 versione 1607 Windows 10 versione 1703 Windows 10, versione 1709 Windows 10, versione 1803 Windows 10, versione 1809 Windows 10, versione 1903 Aggiornamento successivo a Windows 10
Tempo di esecuzione previsto (in minuti)	5
Categoria	Scenario
Timeout (in minuti)	300
Richiede il riavvio	false
Richiede una configurazione speciale	false
Tipo	automatic

 

Documentazione aggiuntiva

I test in questa area di funzionalità potrebbero avere documentazione aggiuntiva, inclusi prerequisiti, configurazione e informazioni sulla risoluzione dei problemi, disponibili negli argomenti seguenti:

• Documentazione aggiuntiva di Device.DevFund

Esecuzione del test

Il test restituisce Pass o Fail.

Risoluzione dei problemi relativi

Per la risoluzione dei problemi generici degli errori di test HLK, vedere Risoluzione dei problemi di test di Windows HLK.

Se il test ha esito negativo, significa che questo sistema ha raggiunto il ripristino di BitLocker. Raccogliere gli eventi Di BitLocker nel visualizzatore eventi in due posizioni:

• Log > applicazioni e servizi Microsoft > Windows > BitLocker-API > Management

• Filtrare i log > di Windows Sistema per origini eventi avviate con BitLocker

Gli eventi devono fornire motivi dettagliati per cui viene raggiunto il ripristino. Dopo aver compreso e risolto la causa radice del ripristino di BitLocker, eseguire il test in un sistema che non ha mai raggiunto un ripristino di BitLocker per ottenere un risultato superato.

Se il sistema usa l'avvio sicuro per il controllo dell'integrità (PCR[7]), vedere la procedura seguente per altre informazioni sulla diagnosi.

1. Il ripristino potrebbe essere attivato dal pacchetto di aggiornamento del firmware.

2. Se il sistema ha TPM2.0, è necessario il supporto di PCR [7]. In caso contrario, il supporto di PCR [7] è facoltativo. La specifica del protocollo EFI albero include informazioni dettagliate sul supporto di PCR [7].

3. Verificare se questo sistema supporta PCR [7] e viene usato da BitLocker/Device Encryption eseguendo il comando seguente da un prompt dei comandi con privilegi elevati:

   syntax

   Manage-bde -protectors -get %systemdrive%
   

   Se il profilo di convalida PCR mostra PCR 7, 11 (usa l'avvio sicuro per la convalida dell'integrità), il sistema è configurato correttamente.

   Se il profilo di convalida PCR non mostra che BitLocker usa l'avvio sicuro per la convalida dell'integrità (ad esempio, il profilo di convalida PCR dice PCR 0, 2, 4, 11), questo indica che BitLocker non può usare PCR [7] e uno degli eventi seguenti potrebbe essere registrato nel log eventi, che si trova in Gestione api > e > applicazioni di Microsoft > Windows > BitLocker.

   • BitLocker non può usare l'avvio sicuro per l'integrità perché è disabilitato.

   • BitLocker non può usare l'avvio sicuro per l'integrità perché la variabile UEFI richiesta X non è presente.

   • BitLocker non può usare l'avvio sicuro per l'integrità perché non è stato possibile leggere la variabile UEFI X. Messaggio di errore: X.

   • BitLocker non può usare l'avvio sicuro per l'integrità perché la voce di log TCG prevista per la variabile X manca o non è valida.

   • BitLocker non può usare l'avvio sicuro per l'integrità perché la voce di log TCG prevista per l'autorità del caricatore del sistema operativo non è disponibile o non valida.

   • BitLocker non può usare l'avvio sicuro per l'integrità perché la voce di log TCG prevista per l'autorità del caricatore del sistema operativo non ha una struttura non valida. L'evento deve essere un evento EV_EFI_VARIABLE_AUTHORITY. I dati dell'evento devono essere formattati come struttura EFI_VARIABLE_DATA con VariableName impostato su EFI_IMAGE_SECURITY_DATABASEGUID e UnicodeName impostato su 'db'.

   • BitLocker non può usare l'avvio sicuro per l'integrità perché la voce di log TCG prevista per l'autorità del caricatore del sistema operativo non è valida. Contenuto della EFI_VARIABLE_DATA. Il campo VariableData deve essere una struttura EFI_SIGNATURE_DATA con SignatureOwner impostata sul GUID {77fa9abd-0359-4d32-bd60-28f4e78f784b} (Microsoft).

   • BitLocker non può usare l'avvio sicuro per l'integrità perché la voce di log TCG prevista per l'autorità del caricatore del sistema operativo non è valida. Impossibile trovare la struttura EFI_SIGNATURE_DATA contenuta nell'evento dell'autorità del sistema operativo nel database di firma di avvio sicuro 'db'.

   • BitLocker non può usare l'avvio sicuro per l'integrità perché non è stato possibile convalidare la firma del caricatore di avvio come firma di Windows concatenata a un certificato radice Microsoft attendibile.

   • BitLocker non può usare l'avvio sicuro per l'integrità perché la voce Log TCG per l'autorità del caricatore del sistema operativo non è valida. Impossibile trovare la firma contenuta nella struttura EFI_SIGNATURE_DATA dall'evento dell'autorità del sistema operativo nella catena di certificati verificata per il caricatore di avvio.

   • BitLocker non può usare l'avvio sicuro per l'integrità perché la voce del separatore di log TCG previsto non è presente o non valida.

   • BitLocker non può usare l'avvio sicuro per l'integrità perché il log TCG per PCR [7] contiene voci non valide.

4. Se BitLocker/Device Encryption usa PCR [7] come segnalato dal comando manage-bde nel passaggio 3 e il ripristino del sistema, verrà visualizzato un evento BitLocker-Driver nel sistema Log > di Windows con ID evento 24658, indicando che la configurazione di avvio sicuro è stata modificata in modo imprevisto. Per diagnosticare il problema, trovare due eventi bitLocker-API più recenti (ID evento 817) in Application and Services Log > Microsoft > Windows > BitLocker-API > Management. Il timestamp di uno degli eventi 817 deve essere precedente a quello dell'evento 24658; timestamp dell'altro evento 817 deve essere successivamente. L'evento 817 viene registrato quando BitLocker esegue il siging di una chiave a TPM in cui viene usato PCR [7]. Nella scheda Dettagli è possibile trovare il valore PCR [7] per la sessione di avvio in cui viene registrato questo evento. Dato che il sistema ha raggiunto un ripristino durante un riavvio, i valori PCR [7] in queste due sessioni di avvio devono essere diversi. I valori PCR [7] registrati in questi due eventi 817 indicano la differenza. Nel caso 817, anche il log TCG per tale sessione di avvio viene registrato. Se si dispone di uno strumento per analizzare il log TCG, che visualizzerà informazioni dettagliate sull'estensione PCR. Se non si dispone di uno strumento di questo tipo, è possibile eseguire le operazioni seguenti:

   1. Copiare TBSLogGenerator.exe dal controller HLK di Windows al computer di test. Si trova in %systemdrive%\Programmi (x86)\Windows Kits\8.1\Hardware Certification Kit\Tests<\architecture>\NTTEST\BASETEST\ngscb, dove <l'architettura> è l'architettura del computer di test. Questo può essere amd64, x86 o Arm.

      TBSLogGenerator.exe dump dei valori PCR e del log TCG in un formato leggibile per la sessione di avvio quando viene eseguitaTBSLogGenerator.exe .

   2. Ripetere i passaggi che attivano il ripristino di BitLocker. Per entrambe le sessioni di avvio nel ripristino di BitLocker, usareTBSLogGenerator.exeper eseguire il dump dei valori PCR e dei log TCG.

   3. Analizzare due set di valori PCR e log TCG per trovare la differenza.