BitLocker case activée après la mise à jour du microprogramme
Ce test détermine si l’appareil a atteint la récupération pendant le processus de mise à jour du microprogramme. BitLocker doit être activé avant une mise à jour du microprogramme, et le test doit être exécuté après une mise à jour.
Détails du test
| Spécifications |
|
| Plateformes |
|
| Versions prises en charge |
|
| Durée d’exécution attendue (en minutes) | 5 |
| Catégorie | Scénario |
| Délai d’expiration (en minutes) | 300 |
| Nécessite un redémarrage | false |
| Nécessite une configuration spéciale | false |
| Type | automatique |
Documentation supplémentaire
Les tests de cette zone de fonctionnalité peuvent avoir une documentation supplémentaire, y compris les conditions préalables, l’installation et les informations de résolution des problèmes, que vous trouverez dans les rubriques suivantes :
Exécution du test
Le test retourne Réussite ou Échec.
Dépannage
Pour la résolution des problèmes génériques des échecs de test HLK, consultez Résolution des échecs de test HLK Windows.
Si le test échoue, cela signifie que ce système a atteint la récupération BitLocker. Collectez les événements BitLocker dans l’Observateur d’événements à deux emplacements :
Journaux > d’application et de services Gestion des API > Microsoft > Windows > BitLocker
Filtrer les journaux > Windows Sources d’événements system by démarrées avec BitLocker
Les événements doivent fournir des raisons détaillées pour lesquelles la récupération est atteinte. Une fois la cause racine de la récupération BitLocker comprise et corrigée, exécutez le test sur un système qui n’a jamais atteint une récupération BitLocker pour obtenir un résultat réussi.
Si le système utilise le démarrage sécurisé pour l’intégrité case activée (PCR[7]), consultez les étapes suivantes pour plus d’informations sur le diagnostic.
La récupération peut être déclenchée par le package de mise à jour du microprogramme.
Si le système a TPM2.0, la prise en charge de LA PCR [7] est requise. Sinon, la prise en charge de LA PCR [7] est facultative. La spécification du protocole EFI de l’arborescence contient des détails sur la prise en charge de LA PCR [7].
Vérifiez si ce système prend en charge LA PCR [7] et est utilisé par BitLocker/Device Encryption en émettant la commande suivante à partir d’une invite de commandes avec élévation de privilèges :
Manage-bde -protectors -get %systemdrive%Si le profil de validation PCR affiche pcr 7, 11 (utilise le démarrage sécurisé pour la validation de l’intégrité), le système est configuré correctement.
Si le profil de validation PCR n’indique pas que BitLocker utilise le démarrage sécurisé pour la validation de l’intégrité (par exemple, le profil de validation PCR indique PCR 0, 2, 4, 11), cela indique que BitLocker ne peut pas utiliser pcr [7] et que l’un des événements suivants peut être connecté au journal des événements, qui se trouve dans La gestion des applications > et des services Microsoft > Windows > BitLocker-API>.
BitLocker ne peut pas utiliser le démarrage sécurisé pour l’intégrité, car il est désactivé.
BitLocker ne peut pas utiliser le démarrage sécurisé pour l’intégrité, car la variable UEFI X requise n’est pas présente.
BitLocker ne peut pas utiliser le démarrage sécurisé pour l’intégrité, car la variable UEFI X n’a pas pu être lue. Message d’erreur : X.
BitLocker ne peut pas utiliser le démarrage sécurisé pour l’intégrité, car l’entrée de journal TCG attendue pour la variable X est manquante ou non valide.
BitLocker ne peut pas utiliser le démarrage sécurisé pour l’intégrité, car l’entrée de journal TCG attendue pour l’autorité du chargeur de système d’exploitation est manquante ou non valide.
BitLocker ne peut pas utiliser le démarrage sécurisé pour l’intégrité, car l’entrée de journal TCG attendue pour l’autorité du chargeur de système d’exploitation a une structure non valide. L’événement est censé être un événement EV_EFI_VARIABLE_AUTHORITY. Les données d’événement doivent être mises en forme en tant que structure EFI_VARIABLE_DATA avec VariableName défini sur EFI_IMAGE_SECURITY_DATABASEGUID et UnicodeName défini sur « db ».
BitLocker ne peut pas utiliser le démarrage sécurisé pour l’intégrité, car l’entrée de journal TCG attendue pour l’autorité du chargeur de système d’exploitation n’est pas valide. Contenu du EFI_VARIABLE_DATA. Le champ VariableData doit être une structure EFI_SIGNATURE_DATA avec SignatureOwner défini sur le GUID {77fa9abd-0359-4d32-bd60-28f4e78f784b} (Microsoft).
BitLocker ne peut pas utiliser le démarrage sécurisé pour l’intégrité, car l’entrée de journal TCG attendue pour l’autorité du chargeur de système d’exploitation n’est pas valide. La structure EFI_SIGNATURE_DATA contenue dans l’événement d’autorité du système d’exploitation est introuvable dans la base de données de signature « db » de démarrage sécurisé.
BitLocker ne peut pas utiliser le démarrage sécurisé pour l’intégrité, car la signature du chargeur de démarrage n’a pas pu être validée en tant que signature Windows chaînée à un certificat racine Microsoft approuvé.
BitLocker ne peut pas utiliser le démarrage sécurisé pour l’intégrité, car l’entrée du journal TCG pour l’autorité du chargeur de système d’exploitation n’est pas valide. La signature contenue dans la structure EFI_SIGNATURE_DATA de l’événement d’autorité du système d’exploitation est introuvable dans la chaîne de certificats vérifiée pour le chargeur de démarrage.
BitLocker ne peut pas utiliser le démarrage sécurisé pour l’intégrité, car l’entrée de séparateur de journal TCG attendue est manquante ou non valide.
BitLocker ne peut pas utiliser le démarrage sécurisé pour l’intégrité, car le journal TCG pour PCR [7] contient des entrées non valides.
Si BitLocker/Device Encryption utilise le protocole PCR [7] comme indiqué par la commande manage-bde à l’étape 3 et que le système a atteint la récupération, vous verrez un événement BitLocker-Driver dans le système journaux > Windows avec l’ID d’événement 24658, indiquant que la configuration du démarrage sécurisé a changé de manière inattendue. Pour diagnostiquer le problème, recherchez deux événements d’API BitLocker les plus récents (ID d’événement 817) dans Les journaux > d’application et de services Microsoft > Windows > BitLocker-API > Management. L’horodatage de l’un des 817 événements doit être antérieur à celui de l’événement 24658 ; l’horodatage de l’autre événement 817 doit être plus tard. L’événement 817 est journalisé lorsque BitLocker scelle une clé au module de plateforme sécurisée où la pcr [7] est utilisée. Sous l’onglet Détails , vous pouvez trouver la valeur PCR [7] pour la session de démarrage où cet événement est journalisé. Étant donné que le système a atteint une récupération lors d’un redémarrage, les valeurs DE PCR [7] pour ces deux sessions de démarrage doivent être différentes. Les valeurs PCR [7] enregistrées dans ces deux événements 817 indiquent la différence. Dans l’événement 817, le journal TCG de cette session de démarrage est également journalisé. Si vous disposez d’un outil pour analyser le journal TCG, cela révélera des informations détaillées sur l’extension PCR. Si vous ne disposez pas d’un tel outil, vous pouvez effectuer les opérations suivantes :
Copiez TBSLogGenerator.exe du contrôleur Windows HLK sur votre ordinateur de test. Il se trouve dans %systemdrive%\Program Files (x86)\Windows Kits\8.1\Hardware Certification Kit\Tests\<architecture>\NTTEST\BASETEST\ngscb, où <architecture> est l’architecture de votre machine de test. Il peut s’agir d’amd64, x86 ou Arm.
TBSLogGenerator.exe vide les valeurs PCR et le journal TCG dans un format lisible par l’utilisateur pour la session de démarrage quand TBSLogGenerator.exe est exécuté.
Répétez les étapes qui déclenchent la récupération BitLocker. Pour les deux sessions de démarrage lors de la récupération BitLocker, utilisez TBSLogGenerator.exe pour vider les valeurs PCR et les journaux TCG.
Analysez deux ensembles de valeurs PCR et de journaux TCG pour trouver la différence.