Secure Boot fait partie de l’écosystème PC depuis 2011, mais 2023-2025 l’a finalement mis sous les projecteurs, et pas d’une manière que Microsoft, les OEM ou les fournisseurs de micrologiciels auraient pu souhaiter. Ce qui était autrefois un dispositif de sécurité discret et discret est soudainement devenu la une des journaux. En effet, au fur et à mesure de son déploiement, le certificat CA‑2023 a révélé des incohérences de longue date dans les implémentations de micrologiciels, la gestion des certificats et les pipelines de mise à jour dans l’ensemble de l’industrie informatique. Pour être à la fois bref et brutal : ce n’était ni joli ni amusant.
Pour les utilisateurs de Windows, le résultat était un mélange déroutant de choses dérangeantes. Cela incluait des avertissements de démarrage, des chaînes de démarrage cassées et des conseils incohérents ou incohérents du fournisseur. Le sentiment général dominant était que le démarrage sécurisé, introduit pour accroître la confiance et la fiabilité, était devenu une source d’incertitude et de confusion.
Cet article présente ce qu’est Secure Boot, comment il fonctionne, pourquoi CA‑2023 est important, comment les fournisseurs ont trébuché et ce que les utilisateurs peuvent faire en cas d’échec des mises à jour de Secure Boot. En cours de route, j’expliquerai chaque acronyme, parcourirai la chaîne de confiance étape par étape et proposerai des conseils pratiques basés sur le dépannage du monde réel. Je viens de terminer un voyage épuisant, voire épique, pour que ma petite flotte de PC (dont la taille varie de 10 à 15) soit entièrement sécurisée, compatible avec le démarrage et fonctionnant à partir des certificats de démarrage CA 2023. Ce fut tout un voyage et m’a appris bien plus que ce que j’aurais jamais voulu savoir.
Qu’est-ce que le démarrage sécurisé et pourquoi est-il important ?
Secure Boot est une fonctionnalité définie par l’UEFI (Unified Extensible Firmware Interface), le remplacement moderne d’Intel du BIOS existant. Son objectif est de garantir que seuls les chargeurs de démarrage et les composants du système d’exploitation approuvés et signés peuvent s’exécuter au démarrage du système.
Pour ce faire, Secure Boot s’appuie sur un ensemble de clés cryptographiques stockées dans le micrologiciel. Ces clés définissent ce qui est fiable, ce qui est autorisé et ce qui est explicitement interdit.
Voici les éléments clés :
Clé de plateforme (PK)
La clé de plate-forme établit le propriétaire du système. Celui qui contrôle le PK contrôle la configuration de Secure Boot. En règle générale, les constructeurs OEM installent leur propre PK en usine.
Clé d’échange de clé (KEK)
La clé Key Exchange autorise les mises à jour des bases de données Secure Boot. Microsoft, les OEM et parfois les administrateurs d’entreprise gèrent les KEK. Une KEK valide est un ticket qui permet à un tiers d’appliquer des mises à jour aux certificats et aux bases de données gérés dans l’UEFI.
Base de données de signatures autorisée (DB)
Cette base de données contient des hachages et des certificats pour les chargeurs de démarrage et les composants du système d’exploitation approuvés. Si quelque chose invoque une signature présente dans la base de données, le firmware lui permet de s’exécuter.
Base de données de signatures interdites (DBX)
Il s’agit de la « liste de révocation ». Tout ce qui se trouve dans le DBX est explicitement bloqué, même s’il était autrefois approuvé. Les mises à jour DBX permettent à l’industrie de révoquer les chargeurs de démarrage compromis. Le CA-2011 original a lancé tout le processus de démarrage sécurisé ; MS prévoit de révoquer cela plus tard en 2026. Le CA-2023 le remplacera et se déploie lentement mais sûrement via Windows Update et les mises à jour OEM UEFI.
Pourquoi le démarrage sécurisé est-il important ?
Secure Boot est conçu pour arrêter les rootkits, les bootkits et autres logiciels malveillants pré-OS. Si les attaquants parviennent à compromettre la chaîne de démarrage, ils peuvent se cacher du système d’exploitation, échapper à la détection et maintenir la persistance indéfiniment. Ils reviendront car ils opèrent en dehors et indépendamment du système d’exploitation. Secure Boot met un terme à de telles manigances.
En théorie, Secure Boot est une solution propre et élégante. En pratique, l’écosystème Secure Boot est désordonné, fragmenté et rempli de cas extrêmes.
Cependant, Secure Boot est à la fois plus important et plus binaire que jamais. Du côté positif, quand ça marche, ça marche bien. Par contre, lorsque des problèmes surviennent, ils peuvent être difficiles, frustrants et prendre beaucoup de temps.
Le compromis Secure Boot qui a déclenché CA-2023
Début 2023, Microsoft a annoncé un problème de sécurité majeur dans lequel les anciens fichiers binaires du gestionnaire de démarrage Windows avaient été compromis de manière à permettre de contourner le démarrage sécurisé. Pour atténuer ce problème, la société a publié une nouvelle mise à jour DBX appelée révocation CA‑2023. Cette mise à jour a ajouté les chargeurs de démarrage vulnérables à la liste interdite et a fourni un nouveau chargeur de démarrage signé avec un certificat correspondant qui était immunisé contre de telles attaques et problèmes.
Pourquoi était-ce nécessaire ?
Les attaquants avaient découvert des moyens d’exploiter les anciens chargeurs de démarrage pour désactiver les protections Secure Boot. La révocation de ces binaires s’est avérée essentielle au maintien de l’intégrité de l’écosystème.
Pourquoi cela a-t-il cassé les systèmes ?
De nombreux constructeurs OEM avaient :
- firmware obsolète
- Gestion DB/DBX incohérente
- pipelines de mise à jour cassés
- Implémentations de démarrage sécurisé non standard
- jeux de clés incomplets ou incorrects
- firmware qui ignorait silencieusement les mises à jour DBX
- firmware qui briquait les systèmes lorsque les mises à jour DBX étaient appliquées
En d’autres termes, la révocation a révélé des années de dette technique. Dans de nombreux cas, il suffisait de tenter des mises à jour pour avoir un impact sur les PC. Dans le meilleur des cas, les PC concernés pourraient ne pas pouvoir redémarrer (démarrage à chaud via les sélections Alimentation > Redémarrer dans le menu Démarrer). Dans le pire des cas, les PC concernés pourraient ne pas pouvoir démarrer, ou même accéder à l’UEFI après la mise sous tension. Mauvaise nouvelle !
Résultats post-CA-2023
Des millions de systèmes se sont retrouvés dans l’un de ces états :
- Secure Boot est activé mais n’applique pas réellement les révocations
- Secure Boot désactivé car les mises à jour ont échoué
- Démarrage sécurisé bloqué en « Mode utilisateur » avec des clés incompatibles
- Systèmes incapables de démarrer après les mises à jour DBX
- Micrologiciel qui a refusé du tout d’appliquer la mise à jour CA‑2023
Il ne s’agissait pas d’un problème propre à Microsoft. Ce fut un échec à l’échelle de l’écosystème. De toute évidence, cela a transformé le démarrage sécurisé en un problème pour les utilisateurs dont les systèmes présentaient un ou plusieurs de ces problèmes. Pour ma part, l’un de mes PC Ryzen 5 basés sur ASRock B550 Extreme4 présentait la plupart, sinon la totalité, de ces défauts. Finalement, j’ai dû remplacer la carte mère pour les surmonter.
Comment fonctionne la « chaîne de démarrage sécurisée » ?
Pour comprendre pourquoi le CA‑2023 a causé tant de problèmes, il est utile de parcourir étape par étape la chaîne de confiance.
Étape 1 : Le micrologiciel valide le PK
Si le PK est valide, le système sait à qui appartient la plateforme.
Étape 2 : Le micrologiciel valide les KEK
Ces clés autorisent les mises à jour de DB et DBX.
Étape 3 : Le micrologiciel charge DB et DBX
Ceux-ci définissent ce qui est autorisé et ce qui est interdit.
Étape 4 : Le micrologiciel valide le chargeur de démarrage
Si la signature du chargeur de démarrage correspond à une entrée dans DB et n’est pas dans DBX, il s’exécute.
Étape 5 : le chargeur de démarrage valide les composants du système d’exploitation
Le Gestionnaire de démarrage Windows vérifie les signatures sur winload.efi, les pilotes et autres composants de démarrage anticipé.
Étape 6 : le système d’exploitation démarre avec une confiance intacte
Si tout se passe bien, Windows se charge normalement.
Hélas, de nombreuses étapes offrent de nombreuses opportunités pour que les choses tournent mal. C’est ce qui rend cette approche quelque peu fragile et parfois sujette à des blocages ou à des échecs purs et simples. Les choses peuvent se briser ou échouer si l’un des cas suivants se présente :
- Il manque une signature requise dans la base de données
- Les KEK sont obsolètes
*PK est incorrect
- Le micrologiciel gère mal les mises à jour
- Les chargeurs de démarrage ne correspondent pas (Windows conserve une copie distincte dans la hiérarchie des dossiers C:\Windows, tandis qu’une autre instance est utilisée à partir de la partition EFI)
Si un tel élément se présente, Secure Boot peut échouer ou tomber. Il se peut également qu’elle échoue silencieusement à faire respecter son régime de sécurité. Ainsi, par exemple, je me suis retrouvé dans une situation où chaque démarrage présentait un message signalant (à tort) un « changement de processeur » et demandant de confirmer les paramètres de sécurité actuels ou de revenir aux paramètres de sécurité TPM précédents. Voici à quoi cela ressemblait :
C’est une bizarrerie connue de l’ASRock B550 Extreme4 UEFI qu’il signale un changement de processeur même lorsque des modifications ou des mises à jour de Secure Boot se produisent. Pendant environ deux semaines, en fait, j’ai dû saisir « N » sur cet écran à chaque fois que je redémarrais mon système pour accéder au bureau Windows. Cela faisait que chaque redémarrage prenait au moins 2 à 3 minutes et me dérangait sans fin.
Problèmes de démarrage sécurisé courants chez différents fournisseurs de cartes mères
Le déploiement du CA‑2023 a révélé que les différents fournisseurs avaient des niveaux très différents de discipline en matière de micrologiciels. Certains ordinateurs de bureau et portables ont navigué sans problème ; d’autres ont connu des revers mineurs, des problèmes majeurs, voire des systèmes impossibles à démarrer. Jetons un coup d’œil à la manière dont les différents fournisseurs se sont comportés dans cette situation.
ASUS
Certaines cartes ASUS refusaient d’appliquer les mises à jour DBX à moins que Secure Boot ne soit temporairement désactivé – une exigence paradoxale. D’autres ont appliqué des mises à jour mais ont laissé les systèmes dans un état « à moitié révoqué ». Le certificat CA-2011 peut toujours être utilisé (ou non) même si le certificat CA-2023 était présent.
MSI
- Certaines cartes MSI (mais pas toutes) étaient connues pour :
- Gestion DBX incohérente
- firmware qui ignorait silencieusement les mises à jour
- Modes de démarrage sécurisé qui ne correspondent pas aux étiquettes de l’interface utilisateur
- systèmes qui sont revenus aux clés d’usine de manière inattendue
ASRock
Les cartes ASRock nécessitaient souvent une intervention manuelle pour des choses telles que :
- Effacement des clés
- réinstallation des paramètres d’usine
- réinscription des clés Microsoft
- application manuelle des mises à jour DBX
Leur documentation était rare et de nombreux utilisateurs restaient dans l’incertitude. Dans mon propre cas, j’avais deux cartes mères soi-disant identiques, toutes deux des modèles B550 Extreme4. L’un d’eux s’est rendu au manuel et Microsoft WU a fourni des mises à jour. L’autre n’a jamais pu concilier les mises à jour en attente du système d’exploitation (à la fois WU et appliquées manuellement) avec le contenu des différentes bases de données du micrologiciel. En effet, c’est ce qui a provoqué la série continue d’avertissements de « changement de processeur » décrits dans la section précédente de cette histoire.
Dell, HP, Lenovo (et autres OEM…)
Les fournisseurs de PC et d’ordinateurs portables destinés aux entreprises et aux consommateurs (notamment Acer, ASUS, Dynabook, etc.) ont généralement fait mieux, mais même eux ont obtenu :
- déploiements échelonnés
- timing de mise à jour BIOS/UEFI incohérent
- certains systèmes nécessitant plusieurs redémarrages pour appliquer les modifications DBX
En parcourant les messages du forum sur Answers.microsoft.com, TenForums.com, ElevenForum.com et TechPowerUp.com, j’ai vu des centaines et des centaines de fils de discussion qui cherchaient de l’aide pour résoudre les problèmes de démarrage sécurisé. Beaucoup impliquaient des ordinateurs portables, et bien d’autres impliquaient des ordinateurs de bureau, en particulier des constructions maison ou celles de constructeurs de boutiques qui assemblent les meilleures pièces commerciales pour construire des PC sur mesure pour des acheteurs bien nantis (voir la section suivante).
PC sur mesure
Les cartes mères du même fournisseur peuvent se comporter différemment selon :
- chipsets réellement installés
- branche du firmware
*année de sortie
- SKU OEM vs Retail
Dans l’ensemble, le manque de standardisation est évident. Les problèmes de démarrage sécurisé rencontrés par les utilisateurs sont omniprésents. Certains ont finalement cédé à Windows Update ou à des modifications manuelles. D’autres ont obstinément résisté à toute tentative de réparation ou de correction. J’ai personnellement parcouru cet espace problématique, avec des échecs récemment dépassés par des succès (mais des échecs néanmoins).
Ce que les utilisateurs peuvent faire en cas d’échec des mises à jour de démarrage sécurisé
Le démarrage sécurisé peut échouer de toutes sortes. La mise à jour Windows peut signaler un succès, mais la DBX (liste de révocations) ne change jamais. Le micrologiciel peut signaler que Secure Boot est « activé », mais il n’est pas appliqué (le confirm-SecureBootUEFI de PowerShell signalera faux dans ce cas).
Les systèmes peuvent démarrer mais échouer aux contrôles de conformité (voir la section Scripts Garlin plus loin dans cette histoire pour plus de détails). Les chargeurs de démarrage peuvent ne pas correspondre aux entrées de la base de données, ou les systèmes peuvent démarrer à contrecœur ou pas du tout après les mises à jour (comme cela s’est produit sur mon système ASRock B550 Extreme4). Il se passe beaucoup de choses ici, donc il y a beaucoup de choses à essayer si l’on a besoin de les réparer. Passons en revue une liste de causes potentiellement poignantes et de correctifs associés.
Clés incompatibles (PK/KEK/DB/DBX)
Si le PK ou le KEK est obsolète, le micrologiciel peut rejeter les mises à jour de la base de données dans la liste des informations d’identification et des valeurs valides (DB) ou dans sa liste des éléments révoqués (DBX). Si cela se produit, cela vaut la peine d’essayer un ou plusieurs de ces correctifs :
- Réinitialisation aux clés d’usine ou par défaut (généralement disponible sous forme d’action sélectionnable dans UEFI, lorsque Secure Boot est en mode personnalisé)
- Réinscrire les clés Microsoft (nécessite généralement de réappliquer une mise à jour Microsoft, ce qui implique une manœuvre de désinstallation/réinstallation, éventuellement via DISM — WU propose une restauration limitée dans le temps)
Le micrologiciel ignore les mises à jour DB ou DBX
Sur certains PC et ordinateurs portables, l’UEFI n’appliquera pas les mises à jour DB ou DBX, sauf sous certaines conditions. Le démarrage sécurisé devra peut-être être désactivé. Le module de support de compatibilité (CSM, qui permet le « double démarrage » en mode BIOS ou UEFI ; les PC modernes sont uniquement équipés de l’UEFI, mais les modèles plus anciens vont souvent dans les deux sens) doit être désactivé. Parfois, les clés de démarrage sécurisé doivent être effacées (une autre option UEFI) avant que les mises à jour ne soient effectuées. Une expérimentation peut être nécessaire pour voir de quoi il s’agit ; si vous avez de la chance, vous trouverez des informations auprès d’autres explorateurs intrépides qui ont déjà vu et résolu votre problème particulier.
Chargeurs de démarrage obsolètes
Les anciens supports d’installation Windows ou les disques de réparation/récupération peuvent intégrer des chargeurs de démarrage trop anciens pour fonctionner avec Secure Boot. En effet, cette inadéquation s’accélérera plus tard en 2026 après que Microsoft s’engagera plus profondément dans la révocation de CA-2011 (ce que la plupart des anciens chargeurs de démarrage intègrent). Si un chargeur de démarrage est trop ancien, DBX peut le bloquer. Les correctifs sont assez simples car les chargeurs de démarrage n’interagissent pas avec le micrologiciel (UEFI). Essayez l’une des réparations suivantes dans ce cas :
- Exécutez Windows Update : il peut remplacer un chargeur de démarrage obsolète par un chargeur actuel
- Reconstruisez les fichiers de démarrage à l’aide de l’utilitaire bcdboot
- Assurez-vous que la partition EFI est saine (et reconstruisez-la si ce n’est pas le cas)
Bogues ou bizarreries du micrologiciel
Surtout sur les PC plus anciens, c’est une bonne idée de mettre à jour (flasher) l’UEFI avant de passer au démarrage sécurisé. Cependant, pour les PC suffisamment anciens, les mises à jour vers 2023 et plus récentes peuvent tout simplement ne pas exister. Mais pour les systèmes qui nécessitent plusieurs redémarrages, des versions de micrologiciel spécifiques ou des importations manuelles de bases de données de démarrage sécurisé (DB, DBX), quelques techniques seront utiles :
- Mettez à jour le firmware vers la dernière version stable (envisagez les versions bêta uniquement si toutes les autres options ont échoué : vous ne voulez pas échanger une cause d’instabilité contre une autre)
- Dans la mesure du possible, utilisez les capsules ou les mises à jour fournies par le fournisseur pour appliquer les modifications de la base de données Secure Boot (par exemple, mon MSI MAG Tomahawk ne fonctionnait pas correctement jusqu’à ce que je flashe son UEFI, qui incluait les éléments Secure Boot et CA-2023 intégrés)
- Laissez Windows Update faire son travail seulement APRÈS que le micrologiciel soit à jour : les nouvelles mises à jour et les anciens micrologiciels créent un environnement volatil et sujet aux problèmes, comme je l’ai appris sur la version ASRock B550 Extreme4.
Dans l’ensemble, si les utilisateurs tentent de se conformer au démarrage sécurisé, depuis les mises à jour du micrologiciel jusqu’aux mises à jour Windows, et n’effectuent des opérations UEFI manuelles que si nécessaire, ils sont beaucoup moins susceptibles de se retrouver coincés dans un nid-de-poule le long de cette route.
Comment les scripts aident à résoudre les problèmes de mise à jour du démarrage sécurisé
Certains des développements les plus intéressants lors du déploiement de CA-2023 ont été l’émergence d’outils et de diagnostics pilotés par la communauté. En particulier, Garlin, utilisateur VIP et Guru d’Eleven Forum, a fourni un fil de discussion de plus de 50 pages avec des scripts PowerShell utiles et les a sauvegardés avec une assistance et des discussions incroyablement utiles. Ses scripts font ce qui suit :
- énumérer les clés de démarrage sécurisé
- valider les entrées DB/DBX
- détecter les discordances
- identifier les chargeurs de démarrage obsolètes
- vérifier le statut d’application
- générer des rapports détaillés
Pour de nombreux utilisateurs, les scripts de Garlin constituaient la première fenêtre claire sur ce que faisait réellement leur micrologiciel. Pour illustrer ce que les scripts Garlin éclairent, la figure 1 montre la sortie de son script nommé Check_UEFI-CA2023.ps1 , capturée à partir de mon bureau MSI MAG Tomahawk B550 récemment reconstruit :
Un examen attentif de la capture d’écran ci-dessus montre que le PC est équipé de clés d’échange de clés (KEK) CA 2011 et CA 2023, avec des certificats DB pour UEFI CA 2011, Windows PCA 2011 et trois versions de CA 2023. La liste des certificats DBX est vide (si vous regardez ci-dessous, vous verrez que CA 2011 n’a pas encore été révoqué ; une fois que cela se produit, ces entrées devraient être déplacées. ici).
Les fichiers EFI montrent que le gestionnaire de démarrage autorise UEFI CA 2023, tout comme le registre, et que la dernière politique d’intégrité du code de démarrage sécurisé est en place. MS utilise cette politique pour bloquer les binaires critiques au démarrage vulnérables ou susceptibles d’être restaurés, en particulier pour la sécurité basée sur la virtualisation (VBS, comme mentionné dans le deuxième élément de la sortie globale du script).
Enfin, le résultat du script montre que l’ancienne certification CA-2011 n’a pas encore été révoquée. C’est délibéré : j’attends de voir comment et quand Microsoft gérera cela via Windows Update, comme ils ont promis de le faire au cours du second semestre 2026. Nous verrons comment cela se passera…
Pourquoi ces scripts sont importants
Les fournisseurs exposent rarement l’état complet du démarrage sécurisé d’un PC. Windows ne fait apparaître qu’une partie de cette image. Les interfaces utilisateur du micrologiciel sont incohérentes et appellent souvent les mêmes choses sous des noms différents. Les scripts de Garlin nous montrent ce qui se passe dans la sphère Secure Boot et nous indiquent quelles actions pourraient devoir être entreprises pour terminer le processus global de mise à jour et de rattrapage.
Que faire lorsque Secure Boot n’applique pas les mises à jour
Voici un flux de travail de récupération pratique, étape par étape.
Étape 1 : vérifier l’état actuel
Utilisez PowerShell ou les scripts de Garlin pour vérifier :
*PK
*KEK
- Base de données
*DBX
- Statut d’application
- Versions du chargeur de démarrage
Étape 2 : mettre à jour le micrologiciel
Installez la dernière mise à jour du BIOS/UEFI.
Étape 3 : Réinitialiser les clés aux paramètres d’usine
Désactivez le démarrage sécurisé, définissez le mode sur Personnalisé, puis réinitialisez ou installez les clés par défaut d’usine (différents UEFI utilisent une terminologie variable). Quel que soit le nom qu’on lui donne, cela élimine souvent les discordances.
Étape 4 : réactiver le démarrage sécurisé
Assurez-vous que CSM est désactivé (il est souvent activé lorsque l’UEFI est mis à jour ; il doit être désactivé pour que le démarrage sécurisé soit activé).
Étape 5 : Appliquer les mises à jour DBX
Utilisez Windows Update ou les capsules du fournisseur, selon leur disponibilité. Consultez les pages d’assistance du fournisseur du système (ou de la carte mère) pour rechercher l’UEFI et les mises à jour associées. C’est ce qui a fait l’affaire pour ma carte mère MSI MAG Tomahawk B550.
Étape 6 : Reconstruire les fichiers de démarrage (si nécessaire)
Vous pouvez utiliser des commandes intégrées pour recréer vos fichiers de démarrage en exécutant la commande bcdboot C:\Windows/f UEFI. Parfois, il peut être nécessaire de démarrer sur un disque de réparation ou de secours et de l’exécuter à partir de l’environnement de récupération Windows (WinRE). Il est toujours plus sûr d’adopter cette approche, et elle vous permettra de surmonter les problèmes de démarrage ou les blocages de politique de démarrage sécurisé si et quand ils doivent apparaître.
Étape 7 : Revérifier l’état
Confirmez que DBX contient des entrées CA 2023. En effet, ce serait le bon moment pour exécuter le script Check_UEFI-CA2023.ps1 de Garlin. (Remarque : si vous regardez dans la fenêtre Propriétés du fichier et cochez l’option Débloquer, vous pouvez exécuter ce script dans PowerShell sans modifier ni contourner la politique d’exécution locale. Ceci est illustré dans la capture d’écran ci-dessous)
OMI, l’écosystème de démarrage sécurisé doit être réformé
Le déploiement progressif de CA 2023 et les efforts récents pour mettre les systèmes à la conformité actuelle avec Secure Boot ont été intéressants. Mais cela a également mis en lumière un large éventail de problèmes systémiques. D’une part, les fournisseurs de micrologiciels manquent d’implémentations et de terminologie cohérentes, il incombe donc aux professionnels de l’informatique et aux autres installateurs de faire fonctionner les choses. Pour aggraver les choses, la documentation est souvent médiocre et ne parvient pas à apporter des solutions lorsque les choses tombent en panne ou ne fonctionnent pas correctement.
À l’heure actuelle, les pipelines de mises à jour sont fragiles. Un faux pas (par exemple, ne pas définir le démarrage sécurisé en mode personnalisé avant de chercher à réinstaller les clés par défaut) peut bloquer le processus de mise à jour et interférer avec les comportements de démarrage normaux. Sur l’un de mes ordinateurs de bureau ASRock, je ne pouvais pas redémarrer ce PC normalement et je ne pouvais utiliser qu’un démarrage profond et à froid pour accéder à l’UEFI ou exécuter le cycle de démarrage (cela a duré deux semaines avant de changer de carte mère pour que les choses fonctionnent à nouveau normalement). Cela motive également mon observation selon laquelle les constructeurs OEM et les fournisseurs de cartes mères varient considérablement en termes de qualité de mise en œuvre et de gestion du démarrage sécurisé. En même temps que le mobo ASRock me rendait dingue, je n’avais aucun problème avec aucun de mes systèmes Lenovo (certains remontant à 2018), ni avec mon mini-PC Dell ou un ordinateur portable ASUS Snapdragon.
Ce que j’ai appris au cours de ce processus, c’est que le démarrage sécurisé est aussi puissant que son maillon le plus faible. Certains systèmes ont, hélas, des maillons faibles. Beaucoup de ces maillons faibles transforment ce qui devrait être une mise à jour de routine en un véritable combat. Certains d’entre eux peuvent nécessiter des mesures encore plus drastiques, comme le remplacement du système ou l’échange de la carte mère.
Ce que Microsoft, les OEM et les utilisateurs doivent faire
Tous les enfants de ce terrain de jeu doivent faire certaines choses pour améliorer le bourbier actuel du Secure Boot. À mon avis, voici comment cela se répercute sur Microsoft, les constructeurs OEM et la communauté des utilisateurs. Pour commencer, Microsoft devrait appliquer une certification plus stricte, avec des diagnostics améliorés et de meilleurs outils (les scripts de Garlin sont assez simples avec le recul ; il n’y a aucune raison pour que MS ne puisse pas proposer des implémentations plus perfectionnées pour faciliter les choses).
Ensuite, les constructeurs OEM pourraient faire beaucoup pour standardiser le comportement des micrologiciels et adopter une terminologie cohérente. Ils peuvent tester leur mise à jour de base de données de plus en plus minutieusement et fournir plus d’informations et de clarté sur l’état et les valeurs du démarrage sécurisé dans leurs interfaces UEFI. Un outil de restauration robuste et automatisé aiderait également à annuler les choix incorrects ou mauvais.
Et enfin, les utilisateurs devraient prendre la sécurité plus au sérieux. Cela signifie mettre à jour le micrologiciel à mesure que de nouvelles mises à jour apparaissent et décider d’utiliser (et non de désactiver) le démarrage sécurisé, sauf lorsque des installations, des modifications de configuration ou des mises à jour exigent qu’il soit désactivé (temporairement). Les utilisateurs doivent également vérifier périodiquement leurs bases de données de démarrage sécurisé pour s’assurer qu’elles sont à jour et correctes, et s’assurer que leurs partitions EFI sont saines et à jour.
Si tout le monde fait sa part, Secure Boot peut faire son travail en protégeant les systèmes contre les compromissions et les attaques au niveau du démarrage et de la racine. C’est assez important, donc je pense que ça vaut la peine de le faire.
Le démarrage sécurisé est toujours important, mais il doit être amélioré
Le démarrage sécurisé reste un mécanisme de défense important dans le modèle de sécurité Windows. Mais la saga CA 2023 montre que cet écosystème est fragile, incohérent et qu’il est grand temps de le moderniser. La bonne nouvelle est que l’industrie apprend. Les fournisseurs de micrologiciels s’améliorent. Microsoft renforce les exigences. Les outils communautaires comblent les lacunes. Mais la leçon est claire : la confiance n’est pas une chose qu’on fixe et qu’on oublie. La confiance doit être maintenue, vérifiée et parfois réparée. Le démarrage sécurisé ne fait pas exception.
Mon conseil final est de surveiller le temps qui passe pendant que vous travaillez pour résoudre les problèmes de démarrage sécurisé, s’ils se présentent. Si un problème prend une demi-journée à résoudre, c’est tolérable. Plus longtemps que cela, et il est temps de commencer à réfléchir à des alternatives, des solutions de contournement et des remplacements. Pendant que vous réfléchissez, vous pouvez désactiver le démarrage sécurisé : Windows fonctionne toujours sans lui. Mais vous pouvez, comme je l’ai fait, décider de remplacer des composants matériels hésitants et bloqués plutôt que de continuer à vous battre, sans aucune solution certaine en vue. C’est à vous!
Accueil
Partager
Bulletin
Bulletin WL
Newsletter WL !
Gardez une longueur d’avance grâce aux dernières mises à jour Windows, informatiques et IA. Approuvé par plus de 50 000 abonnés.
Nom
Courriel
Inscrivez-vous gratuitement
*️⃣ Lien source :
Déploiement du certificat CA‑2023, fil de discussion de plus de 50 pages , Accueil , Newsletter ,