Comprobación de BitLocker después de la actualización del firmware
Esta prueba determina si el dispositivo ha alcanzado la recuperación durante el proceso de actualización de firmware. BitLocker debe estar habilitado antes de una actualización de firmware y la prueba debe ejecutarse después de una actualización.
Detalles de las pruebas
| Especificaciones |
|
| Plataformas |
|
| Versiones admitidas |
|
| Tiempo de ejecución esperado (en minutos) | 5 |
| Categoría | Escenario |
| Tiempo de espera (en minutos) | 300 |
| Requiere reinicio | false |
| Requiere una configuración especial | false |
| Tipo | automatic |
Documentación adicional
Las pruebas de esta área de características pueden tener documentación adicional, incluidos los requisitos previos, la configuración y la información de solución de problemas, que se pueden encontrar en los temas siguientes:
Ejecución de la prueba
La prueba devuelve Pass o Fail.
Solución de problemas
Para solucionar problemas genéricos de errores de prueba de HLK, consulte Solución de problemas de errores de prueba de HLK de Windows.
Si se produce un error en la prueba, significa que este sistema ha alcanzado la recuperación de BitLocker. Recopile eventos de BitLocker en el Visor de eventos en dos ubicaciones:
Registros > de aplicaciones y servicios de Microsoft > Windows > BitLocker-API > Management
Filtrar registros de > Windows Sistema por orígenes de eventos iniciados con BitLocker
Los eventos deben dar motivos detallados por los que se alcanza la recuperación. Después de comprender y corregir la causa principal de la recuperación de BitLocker, ejecute la prueba en un sistema que nunca ha alcanzado una recuperación de BitLocker para obtener un resultado de paso.
Si el sistema usa arranque seguro para la comprobación de integridad (PCR[7]), consulte los pasos siguientes para obtener más información de diagnóstico.
El paquete de actualización de firmware podría desencadenar la recuperación.
Si el sistema tiene TPM2.0, se requiere soporte de PCR [7]. De lo contrario, la compatibilidad con PCR [7] es opcional. La especificación del protocolo EFI de árbol tiene detalles sobre la compatibilidad con PCR [7].
Compruebe si este sistema admite PCR [7] y lo usa BitLocker/Device Encryption mediante la emisión del siguiente comando desde un símbolo del sistema con privilegios elevados:
Manage-bde -protectors -get %systemdrive%Si el perfil de validación de PCR muestra EL PCR 7, 11 (usa el arranque seguro para la validación de integridad), el sistema se configura correctamente.
Si el perfil de validación de PCR no muestra que BitLocker usa arranque seguro para la validación de integridad (por ejemplo, el perfil de validación de PCR dice PCR 0, 2, 4, 11), esto indica que BitLocker no puede usar PCR [7] y uno de los siguientes eventos se puede registrar en el registro de eventos, que se encuentra en Registros > de aplicaciones y servicios Microsoft > Windows > BitLocker-API > Management.
BitLocker no puede usar el arranque seguro para la integridad porque está deshabilitado.
BitLocker no puede usar el arranque seguro para la integridad porque la variable UEFI necesaria X no está presente.
BitLocker no puede usar el arranque seguro para la integridad porque no se pudo leer la variable DE UEFI X. Mensaje de error: X.
BitLocker no puede usar el arranque seguro para la integridad porque falta la entrada de registro de TCG esperada para la variable X o no es válida.
BitLocker no puede usar el arranque seguro para la integridad porque falta la entrada de registro de TCG esperada para la entidad del cargador del sistema operativo o no es válida.
BitLocker no puede usar el arranque seguro para la integridad porque la entrada de registro de TCG esperada para la entidad del cargador del sistema operativo tiene una estructura no válida. Se espera que el evento sea un evento de EV_EFI_VARIABLE_AUTHORITY. Los datos del evento deben tener formato como una estructura de EFI_VARIABLE_DATA con VariableName establecido en EFI_IMAGE_SECURITY_DATABASEGUID y UnicodeName establecido en "db".
BitLocker no puede usar el arranque seguro para la integridad porque la entrada de registro de TCG esperada para la entidad del cargador del sistema operativo no es válida. Contenido del EFI_VARIABLE_DATA. El campo VariableData debe ser una estructura de EFI_SIGNATURE_DATA con SignatureOwner establecido en el GUID {77fa9abd-0359-4d32-bd60-28f4e78f784b} (Microsoft).
BitLocker no puede usar el arranque seguro para la integridad porque la entrada de registro de TCG esperada para la entidad del cargador del sistema operativo no es válida. No se encontró la estructura de EFI_SIGNATURE_DATA contenida en el evento de autoridad del sistema operativo en la base de datos de firma "db" de arranque seguro.
BitLocker no puede usar el arranque seguro para la integridad porque la firma del cargador de arranque no se pudo validar como una firma de Windows encadenada a un certificado raíz de Microsoft de confianza.
BitLocker no puede usar el arranque seguro para la integridad porque la entrada de registro de TCG para la entidad del cargador del sistema operativo no es válida. No se encontró la firma contenida en la estructura de EFI_SIGNATURE_DATA del evento de autoridad del sistema operativo en la cadena de certificados verificada para el cargador de arranque.
BitLocker no puede usar el arranque seguro para la integridad porque falta la entrada del separador de registro de TCG esperada o no es válida.
BitLocker no puede usar el arranque seguro para la integridad porque el registro de TCG para PCR [7] contiene entradas no válidas.
Si el cifrado de dispositivo o BitLocker usa PCR [7] según lo notificado por el comando manage-bde en el paso 3 y la recuperación de aciertos del sistema, verá un evento de BitLocker-Driver en el sistema de registros > de Windows con el identificador de evento 24658, lo que indica que la configuración de arranque seguro ha cambiado inesperadamente. Para diagnosticar el problema, busque dos eventos más recientes de BitLocker-API (id. de evento 817) en Registros >> de aplicaciones y servicios microsoft Windows > BitLocker-API > Management. La marca de tiempo de uno de los 817 eventos debe ser anterior a la del evento 24658; marca de tiempo del otro evento 817 debe ser posterior. El evento 817 se registra cuando BitLocker sella una clave en TPM en la que se usa RCP [7]. En la pestaña Detalles , puede encontrar el valor de PCR [7] para la sesión de arranque donde se registra este evento. Dado que el sistema ha alcanzado una recuperación durante un reinicio, los valores de PCR [7] en estas dos sesiones de arranque deben ser diferentes. Los valores de PCR [7] registrados en estos dos eventos 817 indicarán la diferencia. En el evento 817, también se registra el registro de TCG para esa sesión de arranque. Si tiene una herramienta para analizar el registro de TCG, se mostrará información detallada sobre la extensión PCR. Si no tiene esta herramienta, puede hacer lo siguiente:
Copie TBSLogGenerator.exe del controlador HLK de Windows en la máquina de prueba. Se encuentra en %systemdrive%\Program Files (x86)\Windows Kits\8.1\Hardware Certification Kit\Tests\<architecture>\NTTEST\BASETEST\ngscb, donde <architecture> es la arquitectura de la máquina de prueba. Puede ser amd64, x86 o Arm.
TBSLogGenerator.exe volca los valores de PCR y el registro de TCG en un formato legible para la sesión de arranque cuando se ejecutaTBSLogGenerator.exe .
Repita los pasos que desencadenan la recuperación de BitLocker. Para ambas sesiones de arranque en la recuperación de BitLocker, use TBSLogGenerator.exe para volcar los valores de PCR y los registros de TCG.
Analice dos conjuntos de valores de PCR y registros de TCG para encontrar la diferencia.