Microsoft a de nouveau répondu aux questions des administrateurs sur l’échéance Secure Boot du 24 juin. Derrière le calendrier officiel, plusieurs cas restent sensibles, notamment les machines privées de cette protection et les infrastructures de démarrage réseau.
À quelques jours de l’échéance Secure Boot prévue le 24 juin prochain, Microsoft continue de déminer le terrain. L’entreprise avait déjà clarifié l’essentiel sur l’expiration des certificats hérités de 2011, mais sa dernière session de questions-réponses est venue apporter des précisions utiles sur les cas encore susceptibles de coincer. Il n’est évidemment toujours pas question d’un arrêt brutal des PC Windows au lendemain de la date limite. En revanche, la transition reste un sujet sensible pour les machines sur lesquelles Secure Boot a été désactivé, pour les parcs gérés par démarrage réseau et pour les appareils dont l’ancienne clé pourrait empêcher l’application de futurs blocages de sécurité.
Offre partenaire
Votre petite entreprise a de grandes ambitions. Protégez-là contre les pirates. Et développez sereinement votre activité !
Offre partenaire
Secure Boot désactivé, PXE mal séquencé, les cas qui peuvent bloquer au démarrage
Dans le détail, le principal risque résulte d’un décalage entre Windows et le firmware de la machine. Si Secure Boot a été désactivé dans l’UEFI, Windows peut continuer à recevoir ses mises à jour, y compris un gestionnaire de démarrage signé avec les autorités 2023. En revanche, les clés correspondantes ne sont pas forcément inscrites dans la base de confiance du firmware, ce qui ne doit théoriquement pas poser problème à moins de réactiver ensuite Secure Boot.
Dans ce cas, l’UEFI serait de nouveau chargé de vérifier les composants lancés au démarrage et, ne reconnaissant encore que les autorités héritées de 2011, pourrait refuser de valider le nouveau bootloader. La machine risquerait alors de ne plus démarrer correctement, non pas parce que la mise à jour aurait cassé Windows, mais parce que le firmware et le bootloader ne parleraient plus la même langue cryptographique. Il faudrait alors installer manuellement les certificats 2023 en suivant la procédure documentée par Microsoft, ce qui suppose d’avoir accès à la machine et de savoir exactement ce que l’on fait.
Les environnements PXE, utilisés pour lancer un PC depuis un serveur interne, déployer une image système ou dépanner une machine sans passer par un support local, obéissent à la même contrainte de compatibilité. Une image de démarrage signée avec les autorités 2011 peut encore fonctionner sur une machine qui ne connaît que cette ancienne chaîne, tant que les certificats concernés ne sont pas révoqués. En revanche, une infrastructure PXE passée trop tôt sur des bootloaders signés 2023 peut bloquer les PC qui n’ont pas encore reçu les nouveaux certificats.
Le problème peut aussi se présenter dans l’autre sens. Certains PC récents sont déjà livrés avec les certificats 2023, et peuvent donc refuser des médias d’installation ou des serveurs de déploiement encore signés selon l’ancien modèle. D’où l’importance, pour les admins, de vérifier l’ordre de migration avant de mettre à jour les bootloaders utilisés par le démarrage réseau.
Sans nouvelle KEK, pas de futures mises à jour DBX
L’autre précision concerne la partie révocation de Secure Boot. Le firmware ne se contente pas de savoir quels composants il peut lancer au démarrage. Il conserve aussi une liste de ce qu’il doit refuser, par exemple des bootloaders compromis ou vulnérables. Cette liste noire, appelée DBX, permet à Microsoft de bloquer après coup des éléments jugés dangereux, même s’ils ont pu être acceptés par le passé.
La mise à jour de cette liste repose sur la KEK, une clé chargée d’authentifier les modifications apportées aux bases Secure Boot. Si une machine conserve l’ancienne clé, certains blocages DBX publiés plus tard pourraient ne plus être appliqués. Le risque serait moins visible qu’un échec au démarrage, mais plus durable, puisque des composants vulnérables pourraient continuer à être acceptés alors que Microsoft chercherait à les exclure.
Pour rappel, Microsoft permet déjà de contrôler l’état du déploiement depuis Sécurité Windows sur les postes individuels, et via les rapports Intune dans les parcs gérés. Les admins peuvent ainsi vérifier si une machine a reçu les nouveaux certificats, si elle fait partie des appareils jugés assez sûrs pour une mise à jour automatique ou si elle nécessite encore une intervention manuelle. Le Patch Tuesday de juin devrait élargir la première catégorie, sans régler tous les cas particuliers. Les configurations rares, les machines peu connectées et les appareils bloqués par un firmware trop ancien resteront à traiter séparément.
