Partager via

Chiffrement de lecteur BitLocker dans Windows 11 pour les fabricants d'ordinateurs OEM

  • Article

Le chiffrement de lecteur BitLocker offre une protection des données hors ligne et du système d’exploitation en garantissant que le lecteur n’est pas altéré lorsque le système d’exploitation est hors ligne. Le chiffrement de lecteur BitLocker utilise un TPM, soit discret soit intégré au firmware, qui prend en charge la Mesure de Racine de Confiance Statique comme défini par le Trusted Computing Group.

Chiffrement automatique des appareils BitLocker

Le chiffrement automatique des appareils BitLocker utilise la technologie de chiffrement de lecteur BitLocker pour chiffrer automatiquement les lecteurs internes après que l’utilisateur a terminé l’expérience de démarrage (OOBE) sur des appareils répondant aux exigences matérielles.

Remarque

Le chiffrement automatique des appareils BitLocker commence pendant l’expérience de démarrage (OOBE). Cependant, la protection est activée (armée) uniquement après que les utilisateurs se sont connectés avec un compte Microsoft ou un compte Azure Active Directory. Jusque-là, la protection est suspendue et les données ne sont pas protégées. Le chiffrement automatique des appareils BitLocker n’est pas activé avec des comptes locaux, auquel cas BitLocker peut être activé manuellement à l’aide du panneau de configuration BitLocker.

Exigences matérielles pour le chiffrement automatique des appareils BitLocker

Remarque

À partir de la version 24H2 de Windows 11, Microsoft a réduit les exigences matérielles pour le chiffrement automatique des appareils (Auto-DE) dans Windows :

  • L’Auto-DE ne dépend plus de l’interface de test de sécurité matérielle (HSTI) / de la veille moderne.

  • L’Auto-DE sera activé même si des bus / interfaces DMA non fiables sont détectés.

Cela signifie que les OEMs n’ont pas besoin d’ajouter des interfaces DMA à la clé de registre AllowedBuses : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses

Ces nouvelles exigences réduites sont automatiquement reflétées dans les tests HLK, et aucune action supplémentaire n’est requise de la part des OEMs.

Le chiffrement automatique des appareils BitLocker est activé lorsque :

  • L’appareil contient un TPM (Trusted Platform Module), soit TPM 1.2 soit TPM 2.0.
  • UEFI Secure Boot est activé. Veuillez consulter Secure Boot pour plus d’informations.
  • Platform Secure Boot est activé
  • La plateforme est Modern Standby ou conforme à HSTI (cette exigence a été supprimée depuis Windows 11 24H2)
  • Il n’y a pas d’interfaces Direct memory access (DMA) non autorisées (cette exigence a été supprimée depuis Windows 11 24H2)

Les tests suivants doivent réussir avant que Windows 11 n’active le chiffrement automatique des appareils BitLocker. Si vous souhaitez créer du matériel prenant en charge cette fonctionnalité, vous devez vérifier que votre appareil réussit ces tests.

  1. TPM : L’appareil doit inclure un TPM avec prise en charge PCR 7. Veuillez consulter System.Fundamentals.TPM20.TPM20.

    • Si la présence de cartes extensibles entraîne le chargement de pilotes UEFI OROM par le BIOS UEFI au démarrage, alors BitLocker n’utilisera PAS la liaison PCR7.
    • Si vous exécutez un appareil qui ne se lie pas à PCR7 et que BitLocker est activé, il n’y a aucun inconvénient en matière de sécurité car BitLocker est toujours sécurisé lorsqu’il utilise le profil PCR UEFI régulier (0,2,4,11).
    • Tout hachage CA supplémentaire (même Windows Prod CA) avant le bootmgr final Windows Prod CA empêchera BitLocker de choisir d’utiliser PCR7. Peu importe si le hachage ou les hachages supplémentaires proviennent de CA UEFI (alias Microsoft 3rd Party CA) ou d’une autre CA.

  2. Secure boot : UEFI Secure Boot est activé. Consultez System.Fundamentals.Firmware.UEFISecureBoot.

  3. Modern Standby exigences ou validation HSTI. (supprimé depuis Windows 11 24H2)
    Cette exigence est remplie par l’une des conditions suivantes :

    • Les exigences de veille moderne sont mises en œuvre. Celles-ci incluent les exigences pour UEFI Secure Boot et la protection contre les DMA non autorisés.
    • À partir de Windows 10, version 1703, cette exigence peut être remplie par le test HSTI :
      1. Le test de démarrage sécurisé de la plateforme (ou des auto-tests supplémentaires configurés dans le registre) doit être signalé par HSTI comme mis en œuvre et réussi.
      2. À l’exception de Thunderbolt, HSTI doit signaler qu’il n’y a pas de bus DMA non autorisés.
      3. Si Thunderbolt est présent, HSTI doit signaler que Thunderbolt est configuré de manière sécurisée (le niveau de sécurité doit être SL1 – « Autorisation utilisateur » ou supérieur).

  4. Vous devez avoir 250 Mo d’espace libre en plus de tout ce dont vous avez besoin pour démarrer (et récupérer Windows, si vous placez WinRE sur la partition système). Pour plus d’informations, veuillez consulter la section Partitions système et utilitaire.

Lorsque les exigences énumérées ci-dessus sont remplies, System Information indique que le système prend en charge le chiffrement automatique des appareils BitLocker. Cette fonctionnalité est disponible dans Windows 10, version 1703 ou après. Voici comment vérifier les informations système.

  1. Cliquez sur Démarrer et tapez System information
  2. Faites un clic droit sur l’application Informations Système et cliquez sur Ouvrir en tant qu’administrateur. Autorisez l’application à apporter des modifications à votre appareil en cliquant sur Oui. Certains appareils peuvent nécessiter des autorisations élevées pour afficher les paramètres de chiffrement.
  3. Dans System Summary (Résumé système), consultez Device Encryption Support (Prise en charge du chiffrement). La valeur indiquera si l’appareil est chiffré, ou sinon, les raisons pour lesquelles il est désactivé.

Bus ou périphérique(s) capable(s) de DMA non autorisé détecté

Ce statut d’informations système dans le support de chiffrement des appareils signifie que Windows a détecté au moins un bus ou périphérique externe capable de DMA qui peut constituer une menace DMA.

Pour résoudre ce problème, contactez les IHVs pour déterminer si cet appareil n’a pas de ports DMA externes. S’il est confirmé par les IHVs que le bus ou l’appareil n’a que des DMA internes, alors l’OEM peut l’ajouter à la liste autorisée.

Pour ajouter un bus ou un appareil à la liste autorisée, vous devez ajouter une valeur à une clé de registre. Pour cela, vous devez d’abord prendre possession de la clé de registre AllowedBuses. Effectuez les étapes suivantes :

  1. Naviguez vers la clé de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses.

  2. Faites un clic droit sur la clé de registre et sélectionnez Permissions….

  3. Cliquez sur Avancé, cliquez sur le lien Modifier dans le champ Propriétaire, saisissez votre nom de compte utilisateur, cliquez sur Vérifier les noms, puis cliquez trois fois sur OK pour fermer toutes les boîtes de dialogue de permissions.

  4. Faites un clic droit sur la clé de registre et sélectionnez à nouveau Permissions….

  5. Cliquez sur le bouton Ajouter... , ajoutez votre compte utilisateur, cliquez sur Vérifier les noms, puis cliquez sur OK et cochez la case Autoriser pour Contrôle Total. Cliquez ensuite sur OK.

Ensuite, sous la clé AllowedBuses, ajoutez des paires nom/valeur de chaîne (REG_SZ) pour chaque bus capable de DMA signalé comme sûr :

  • Clé : device friendly name (nom convivial de l’appareil) /description
  • Valeur : PCI\VEN_ID&DEV_ID.

Assurez-vous que les identifiants correspondent à la sortie du test HLK. Par exemple, si vous avez un appareil sûr avec un nom convivial de « Contoso PCI Express Root Port », ID de fournisseur 1022 et ID de périphérique 157C, vous créeriez une entrée de registre nommée Contoso PCI Express Root Port comme type de données REG_SZ dans : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses

Où la valeur = « PCI\VEN_1022&DEV_157C »

Remarque : cette clé de registre est ignorée à partir de Windows 11 24H2.

Disposition des partitions de chiffrement de lecteur BitLocker

Le chiffrement de lecteur BitLocker utilise une partition système distincte de la partition Windows. La partition système BitLocker doit répondre aux exigences suivantes.

  • La partition système BitLocker est configurée comme la partition active.
  • La partition système BitLocker ne doit pas être chiffrée.
  • La partition système BitLocker doit avoir au moins 250 Mo d’espace libre, en plus de tout espace utilisé par les fichiers requis. Cette partition système supplémentaire peut être utilisée pour héberger l’environnement de récupération Windows (RE) et les outils OEM (fournis par l’OEM), à condition que la partition réponde toujours à l’exigence des 250 Mo d’espace libre.

Pour plus d’informations, voir consultez Partitions système et utilitaire, disques durs et partitions.

Désactiver le chiffrement automatique des appareils BitLocker

Les OEMs peuvent choisir de désactiver le chiffrement des appareils et d’implémenter leur propre technologie de chiffrement sur un appareil. Pour désactiver le chiffrement automatique des appareils BitLocker, vous pouvez utiliser un fichier Unattend et définir PreventDeviceEncryption sur True.

Alternativement, vous pouvez mettre à jour la clé de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BitLocker :

Valeur : PreventDeviceEncryption égale à True (1).

Nous déconseillons de définir cette clé de registre sur les appareils avec la fonctionnalité Rappel. »

Dépannage des tests HLK de BitLocker

Le triage est beaucoup plus simple lorsque vous connaissez les informations suivantes sur l’appareil testé :

  1. Spécification TPM (par exemple 1.2, 2.0)
  2. Profil PCR BitLocker (par exemple 7, 11 ou 0, 2, 4, 11)
  3. Si la machine est non-AOAC ou AOAC (par exemple, les appareils Surface sont des machines AOAC)

Ces informations sont recommandées mais non requises pour effectuer le triage.

Les problèmes HLK de BitLocker sont généralement liés à l’interprétation erronée des résultats de test ou aux problèmes de liaison PCR7.

Interprétation erronée des résultats de test

Un test HLK se compose de plusieurs étapes de test. Certaines étapes de test peuvent échouer sans affecter la réussite/l’échec du test global. Voir ici pour plus d’informations sur l’interprétation de la page des résultats. Si certaines étapes de test ont échoué mais que le test global réussit (indiqué par une coche verte à côté du nom du test), arrêtez-vous ici. Le test a été exécuté avec succès et aucune autre action n’est nécessaire de votre part.

Étapes de triage :

  1. Confirmez que vous exécutez le bon test contre la machine. Faites un clic droit sur n’importe quelle étape du test en échec > Infrastructure > Journaux du Rassembleur > regardez à l’intérieur de RUNTIMEBLOCK.xml pour l’élément IsAOAC. Si IsAOAC=true et que vous exécutez un test non-AOAC, alors ignorez l’échec et n’exécutez pas ce test contre la machine. Si nécessaire, contactez l’équipe de support Microsoft pour une dérogation pour passer la liste de tests.

    Capture d’écran du test en échec. L’élément Is A O A C est sélectionné.

  2. Déterminez si un filtre est appliqué au test. HLK peut automatiquement suggérer un filtre pour un test incorrectement mappé. Un filtre apparaît comme une coche verte à l’intérieur d’un cercle à côté d’une étape de test. (Notez que certains filtres peuvent montrer que les étapes de test suivantes ont échoué ou ont été annulées.) Examinez les informations supplémentaires sur le filtre en développant l’étape de test avec l’icône spéciale. Si le filtre indique d’ignorer l’échec du test, arrêtez-vous ici.

Capture d’écran des filtres

Problèmes PCR7

Un problème courant de BitLocker spécifique aux deux tests PCR7 est l’échec de la liaison à PCR7.

Étapes de triage :

  1. Trouvez le message d’erreur dans les journaux HLK. Développez l’étape de test en échec et examinez le journal Te.wtl. (Vous pouvez également accéder à ce journal en faisant un clic droit sur une étape de test > Journaux de tâches > Te.wtl) Continuez à suivre les étapes de triage si vous voyez cette erreur :

    Capture d’écran du message d’erreur dans les journaux H L K.

  2. Exécutez msinfo32 en tant qu’administrateur et vérifiez l’état de démarrage sécurisé / la configuration PCR7. Le test doit être exécuté avec le démarrage sécurisé activé. Si la liaison PCR7 n’est pas prise en charge, exécutez le test HLK PCR hérité approprié à la place. Si la liaison PCR7 n’est pas possible, continuez à suivre les étapes de triage.

  3. Examinez les journaux d’erreurs. Faites un clic droit sur la tâche de test > Fichiers supplémentaires. En général, le problème de liaison PCR7 est dû à des mesures incorrectes dans PCR7.

    1. Journaux d'événements. Le journal Microsoft-BitLocker-Management contient des informations d’erreur précieuses sur les raisons pour lesquelles PCR7 ne peut pas être utilisé. Le test HLK de BitLocker doit uniquement être exécuté sur une machine avec BitLocker installé. Les journaux d’événements doivent être vérifiés sur la machine qui les génère.
    2. Journaux de démarrage mesuré. Ils se trouvent également dans C:\Windows\Logs\MeasuredBoot

  4. Analysez le journal de démarrage mesuré en utilisant TBSLogGenerator.exe ou un équivalent. Sur le contrôleur HLK, TBSLogGenerator.exe se trouve dans le répertoire des tests HLK où vous avez installé HLK, par exemple C:\Program Files (x86)\Windows Kits\10\Hardware Lab Kit\Tests\amd64\nttest\BASETEST\ngscb\TBSLogGenerator.exe.

    1. TBSLogGenerator.exe -lf <chemin vers le journal de démarrage mesuré>> OutputLog.txt
    2. Dans OutputLog.txt, recherchez PCR[07] et examinez les mesures, listées dans l’ordre. La première mesure devrait ressembler à ceci :

Capture d’écran de la liste des mesures dans Output Log dot t x t.

BitLocker s’attend à certaines mesures de racine de confiance statique mesures de racine de confiance statique dans PCR7, et toute variation dans ces mesures empêche souvent la liaison à PCR7. Les valeurs suivantes doivent être mesurées (dans l’ordre, et sans mesures supplémentaires entre elles) dans PCR7 :

  • Le contenu de la variable SecureBoot
  • Le contenu de la variable PK
  • Le contenu de la variable KEK
  • Le contenu de la variable EFI_IMAGE_SECURITY_DATABASE (DB)
  • Le contenu de la variable EFI_IMAGE_SECURITY_DATABASE1 (DBX)
  • (séparateur EV optionnel mais courant)
  • Entrées dans la base de données de sécurité des images EFI qui sont utilisées pour valider les pilotes EFI ou les applications de démarrage EFI dans le chemin de démarrage. BitLocker s’attend à une seule entrée ici.

Problèmes courants avec le journal de démarrage mesuré :

  • Mode débogage UEFI activé
  • Variables PK ou KEK manquantes : la mesure PK/KEK n’a pas de données (par exemple, 4 octets de 0)
  • Signataire CA UEFI non fiable

Certains problèmes de démarrage mesuré, tels que l’exécution avec le mode débogage UEFI activé, peuvent être résolus par le testeur. D’autres problèmes peuvent nécessiter une dérogation, auquel cas vous devez contacter l’équipe de support Microsoft pour obtenir des conseils.

Application de mises à jour du firmware aux appareils

En plus de l’exécution des tests HLK, les OEMs doivent tester les mises à jour du firmware avec BitLocker activé. Pour éviter que les appareils ne commencent inutilement une récupération, suivez ces directives pour appliquer les mises à jour du firmware :

  1. Suspendez BitLocker (requis pour les appareils liés à PCR[07] uniquement si la mise à jour du firmware modifie la politique de démarrage sécurisé)
  2. Appliquez la mise à jour
  3. Redémarrer l’appareil
  4. Reprenez BitLocker

La mise à jour du firmware doit nécessiter que l’appareil suspende BitLocker seulement pour une courte période, et l’appareil doit redémarrer dès que possible. BitLocker peut être suspendu programmatiquement juste avant l’arrêt en utilisant la méthode DisableKeyProtectors dans Windows Management Instrumentation (WMI).