BitLocker marcar após atualização de firmware
Este teste determina se o dispositivo atingiu a recuperação durante o processo de atualização de firmware. O BitLocker deve ser habilitado antes de uma atualização de firmware e o teste deve ser executado após uma atualização.
Detalhes do teste
| Especificações |
|
| Plataformas |
|
| Versões com suporte |
|
| Tempo de execução esperado (em minutos) | 5 |
| Categoria | Cenário |
| Tempo limite (em minutos) | 300 |
| Requer reinicialização | false |
| Requer configuração especial | false |
| Tipo | automático |
Documentação adicional
Os testes nessa área de recursos podem ter documentação adicional, incluindo pré-requisitos, configuração e informações de solução de problemas, que podem ser encontrados nos tópicos a seguir:
Executando o teste
O teste retorna Pass ou Fail.
Solucionando problemas
Para solucionar problemas genéricos de falhas de teste do HLK, consulte Solução de problemas de falhas de teste do Windows HLK.
Se o teste falhar, isso significa que esse sistema atingiu a recuperação do BitLocker. Colete eventos do BitLocker no Visualizador de eventos em dois locais:
Logs de aplicativos e serviços > Microsoft > Windows > BitLocker-API > Management
Filtrar logs > do Windows Fontes de evento system by iniciadas com o BitLocker
Os eventos devem fornecer motivos detalhados Por que a recuperação é atingida. Depois que a causa raiz da recuperação do BitLocker for compreendida e corrigida, execute o teste em um sistema que nunca atingiu uma recuperação do BitLocker para obter um resultado aprovado.
Se o sistema usar a Inicialização Segura para marcar de integridade (PCR[7]), consulte as etapas a seguir para obter mais informações de diagnóstico.
A recuperação pode ser disparada pelo pacote de atualização de firmware.
Se o sistema tiver TPM2.0, o suporte a PCR [7] será necessário. Caso contrário, o suporte a PCR [7] é opcional. A especificação do Protocolo EFI de Árvore tem detalhes sobre o suporte a PCR [7].
Verifique se esse sistema dá suporte a PCR [7] e é usado pelo BitLocker/Device Encryption emitindo o seguinte comando de um prompt de comando com privilégios elevados:
Manage-bde -protectors -get %systemdrive%Se o perfil de validação do PCR mostrar PCR 7, 11 (usa Inicialização Segura para validação de integridade), o sistema será configurado corretamente.
Se o perfil de validação do PCR não mostrar que o BitLocker usa a Inicialização Segura para validação de integridade (por exemplo, o perfil de validação do PCR diz PCR 0, 2, 4, 11), isso indica que o BitLocker não pode usar PCR [7] e um dos eventos a seguir pode ser conectado ao log de eventos, que é encontrado nos Logs de Aplicativos e Serviços > Microsoft > Windows > BitLocker-API > Management.
O BitLocker não pode usar a Inicialização Segura para integridade porque está desabilitada.
O BitLocker não pode usar a Inicialização Segura para integridade porque a variável UEFI X necessária não está presente.
O BitLocker não pode usar a Inicialização Segura para integridade porque a variável UEFI X não pôde ser lida. Mensagem de erro: X.
O BitLocker não pode usar a Inicialização Segura para integridade porque a entrada de log TCG esperada para a variável X está ausente ou inválida.
O BitLocker não pode usar a Inicialização Segura para integridade porque a entrada de log TCG esperada para a Autoridade de Carregador do SISTEMA Operacional está ausente ou inválida.
O BitLocker não pode usar a Inicialização Segura para integridade porque a entrada de log TCG esperada para a Autoridade de Carregador do SISTEMA Operacional tem estrutura inválida. Espera-se que o evento seja um evento EV_EFI_VARIABLE_AUTHORITY. Os dados do evento devem ser formatados como uma estrutura EFI_VARIABLE_DATA com VariableName definido como EFI_IMAGE_SECURITY_DATABASEGUID e UnicodeName definido como 'db'.
O BitLocker não pode usar a Inicialização Segura para integridade porque a entrada de log TCG esperada para a Autoridade de Carregador do SISTEMA Operacional é inválida. O conteúdo do EFI_VARIABLE_DATA. O campo VariableData deve ser uma estrutura EFI_SIGNATURE_DATA com SignatureOwner definido como GUID {77fa9abd-0359-4d32-bd60-28f4e78f784b} (Microsoft).
O BitLocker não pode usar a Inicialização Segura para integridade porque a entrada de log TCG esperada para a Autoridade de Carregador do SISTEMA Operacional é inválida. Não foi possível encontrar a estrutura EFI_SIGNATURE_DATA contida no evento de autoridade do sistema operacional no banco de dados de assinatura 'db' de Inicialização Segura.
O BitLocker não pode usar a Inicialização Segura para integridade porque a assinatura do carregador de inicialização não pôde ser validada como uma assinatura do Windows encadeada a um certificado raiz confiável da Microsoft.
O BitLocker não pode usar a Inicialização Segura para integridade porque a entrada de log TCG para a Autoridade de Carregador do SISTEMA Operacional é inválida. A assinatura contida na estrutura EFI_SIGNATURE_DATA do evento de autoridade do sistema operacional não pôde ser encontrada na cadeia de certificados verificada para o carregador de inicialização.
O BitLocker não pode usar a Inicialização Segura para integridade porque a entrada do separador de log TCG esperada está ausente ou inválida.
O BitLocker não pode usar a Inicialização Segura para integridade porque o Log TCG para PCR [7] contém entradas inválidas.
Se o BitLocker/Device Encryption estiver usando PCR [7] conforme relatado pelo comando manage-bde na etapa 3 e a recuperação de ocorrência do sistema, você verá um evento BitLocker-Driver no Sistema de Logs > do Windows com a ID de Evento 24658, informando que a configuração de Inicialização Segura foi alterada inesperadamente. Para diagnosticar o problema, localize dois eventos bitlocker-api mais recentes (ID de evento 817) nos logs de aplicativos e serviços > Microsoft > Windows > BitLocker-API > Management. O carimbo de data/hora de um dos 817 eventos deve ser anterior ao do evento 24658; O carimbo de data/hora do outro evento 817 deve ser posterior. O evento 817 é registrado quando o BitLocker sela uma chave no TPM em que o PCR [7] é usado. Na guia Detalhes , você pode encontrar o valor pcr [7] para a sessão de inicialização em que esse evento é registrado. Dado que o sistema atingiu uma recuperação durante uma reinicialização, os valores de PCR [7] nessas duas sessões de inicialização devem ser diferentes. Os valores pcr [7] registrados nesses dois eventos 817 dirão a diferença. No evento 817, o log TCG dessa sessão de inicialização também é registrado. Se você tiver uma ferramenta para analisar o log TCG, isso revelará informações detalhadas sobre a extensão pcr. Se você não tiver essa ferramenta, poderá fazer o seguinte:
Copie TBSLogGenerator.exe do Controlador do Windows HLK para o computador de teste. Ele está localizado em %systemdrive%\Program Files (x86)\Windows Kits\8.1\Hardware Certification Kit\Tests\<architecture>\NTTEST\BASETEST\ngscb, em < que arquitetura> é a arquitetura do computador de teste. Isso pode ser amd64, x86 ou Arm.
TBSLogGenerator.exe despeja valores pcr e log TCG em um formato legível para a sessão de inicialização quando TBSLogGenerator.exe é executado.
Repita as etapas que disparam a recuperação do BitLocker. Para as duas sessões de inicialização na recuperação do BitLocker, use TBSLogGenerator.exe para despejar valores de PCR e logs TCG.
Analise dois conjuntos de valores pcr e logs TCG para encontrar a diferença.