Le correctif était tout juste en ligne que Microsoft devait déjà reconnaître un souci BitLocker. Le dernier Patch Tuesday peut provoquer l’affichage de l’écran de récupération sur certains serveurs Windows Server 2025.
Moins de 24 heures après son déploiement, il fallait évidemment que le Patch Tuesday d’avril fasse déjà parler de lui, et pas pour les bonnes raisons. Cette nouvelle livraison de correctifs colmate pourtant quelque 165 failles de sécurité dans les produits Microsoft, dont huit vulnérabilités critiques et deux zero day, parmi lesquelles une déjà exploitée. Mais sur certains systèmes sous Windows Server 2025, le patch peut aussi faire surgir l’écran de récupération BitLocker au redémarrage, et exiger la saisie de la clé correspondante.
Un bug circonscrit, deux solutions en attendant le correctif
Le problème n’a heureusement rien de généralisé. D'après Microsoft, il viserait un nombre limité de configurations sous Windows Server 2025, dans des environnements administrés où BitLocker chiffre déjà le disque système, où une stratégie de groupe impose un profil de validation TPM incluant PCR7, alors même que Windows signale une liaison impossible entre PCR7 et Secure Boot, sur des machines déjà engagées dans la transition vers les nouveaux certificats Secure Boot, mais qui n’utilisent pas encore le Boot Manager signé en 2023. Pas de quoi transformer chaque serveur mis à jour dans la nuit en candidat automatique à l’écran BitLocker, même si les systèmes concernés risquent bien de créer la surprise au redémarrage.
L’incident a au moins le bon goût de ne pas s’installer dans la durée puisque, selon Microsoft, la clé ne devrait être demandée qu’une seule fois, au premier redémarrage après l’installation du patch.
En attendant un correctif définitif, promis dans une prochaine mise à jour, Redmond a communiqué sur deux options pour limiter la casse. La première, recommandée par Microsoft, consiste à supprimer la stratégie de groupe qui force l’inclusion de PCR7 dans le profil de validation TPM avant le déploiement du Patch Tuesday. La seconde passe par un Known Issue Rollback (KIR), à appliquer, là encore, avant l’installation de la mise à jour de sécurité, afin de bloquer le passage automatique au Boot Manager signé avec le certificat Windows UEFI CA 2023.
Le TPM (Trusted Platform Module) est une puce de sécurité qui peut stocker et « sceller » des secrets, comme la clé de protection utilisée par BitLocker. Pour décider s’il peut déverrouiller automatiquement le disque, le TPM compare l’état de démarrage de la machine à des mesures enregistrées dans des PCR (Platform Configuration Registers). PCR7 est notamment lié à l’état de Secure Boot et à certains paramètres UEFI : si ces mesures changent, le TPM considère que l’environnement n’est plus identique. Dans ce cas, BitLocker bascule en mode récupération et demande la clé pour éviter un déverrouillage dans un contexte potentiellement compromis.
Pourquoi une transition de certificats Secure Boot peut-elle déclencher un écran de récupération BitLocker après une mise à jour ?Secure Boot repose sur une chaîne de confiance : des composants de démarrage (comme le bootloader/Boot Manager) doivent être signés avec des certificats approuvés par le firmware UEFI. Quand un environnement passe à de nouveaux certificats (par exemple une nouvelle autorité de certification UEFI), les signatures et parfois les éléments chargés au démarrage changent. Ces changements peuvent modifier les mesures enregistrées dans les PCR du TPM, ce que BitLocker interprète comme une variation du « profil de démarrage ». Résultat : même si la mise à jour est légitime, BitLocker peut exiger une clé de récupération au prochain redémarrage pour valider que la machine n’a pas été altérée.
Qu’est-ce qu’un Known Issue Rollback (KIR) chez Microsoft, et dans quels cas l’utiliser ?Le Known Issue Rollback est un mécanisme qui permet à Microsoft de désactiver à distance une régression introduite par une mise à jour, sans désinstaller tout le correctif. Techniquement, il s’appuie sur une politique de configuration (souvent via Windows Update ou des stratégies en environnement géré) qui « revient » sur un changement précis de comportement. Le KIR est surtout utile quand le patch corrige des failles importantes, mais qu’un bug impacte un sous-ensemble de machines : on garde les correctifs de sécurité, tout en neutralisant la partie problématique. En entreprise, il se déploie généralement via des outils d’administration (GPO/MDM) pour cibler uniquement les postes ou serveurs concernés.
