Secure Boot sous Windows et Linux : les certificats expirent le 27 juin, prudence
Prudence est mère de sûreté
Illustration : Flock
Le 19 juin à 09h09
Plusieurs certificats de sécurité utilisés par Microsoft et Linux pour Secure Boot arriveront à échéance cette année, dont une première vague le 27 juin. Nous faisons le point sur la situation, plus simple qu’il n’y paraît. Du moins si tout se passe bien.
Secure Boot sous Windows et Linux : les certificats expirent le 27 juin, prudence
Prudence est mère de sûreté
Illustration : Flock
Plusieurs certificats de sécurité utilisés par Microsoft et Linux pour Secure Boot arriveront à échéance cette année, dont une première vague le 27 juin. Nous faisons le point sur la situation, plus simple qu’il n’y paraît. Du moins si tout se passe bien.
Sécurité
Sécurité
9 min
Pour comprendre la situation, nous devons rappeler quelques points. Secure Boot est une fonctionnalité de sécurité du firmware UEFI dont l’objectif est d’empêcher l’exécution de code malveillant avant même que le système d’exploitation démarre, c’est-à-dire à un stade où les antivirus et autres protections logicielles classiques n’ont aucune visibilité. Les bootkits sont ainsi particulièrement dangereux, car ils s’exécutent avec un niveau de privilège supérieur à celui du système et survivent à une réinstallation complète de Windows ou Linux.
Le fonctionnement repose sur une chaîne de confiance cryptographique hiérarchisée :
- La PK (Platform Key), détenue par le fabricant de la carte mère ou du PC et qui contrôle l’accès au niveau inférieur
- La KEK (Key Exchange Key), utilisée pour mettre à jour les bases de signatures
- La DB (Signature Database), qui liste les certificats de confiance autorisant tel ou tel bootloader à s’exécuter
- La DBX (base de révocation), liste noire des signatures compromises qui bloque l’exécution de bootloaders connus comme vulnérables, même quand ils possèdent une signature valide
Pendant le démarrage, le bootloader vérifie chaque maillon de la chaine l’un après l’autre en comparant leur signature à celles présentes dans les bases mentionnées. Si l’une de ces signatures ne correspond pas ou fait partie de la liste de révocation, le firmware refuse le chargement du composant lié et interrompt le démarrage.
L’origine du problème
En 2011, Microsoft a établi trois certificats centraux : la Microsoft Corporation KEK CA 2011 pour la base KEK, la Microsoft Windows Production PCA 2011 pour les composants Windows signés, et la Microsoft Corporation UEFI CA 2011 pour les logiciels tiers, comme le rappelait Security Today en avril et Ars Technica le 17 juin.
Ces certificats disposaient d’une validité de 15 ans. Chacun a sa date d’expiration : les deux certificats Corporation (KEK et UEFI) expirent respectivement les 24 et 27 juin, le certificat Production court jusqu’au 19 octobre. Deux certificats vont donc expirer dans quelques jours, tandis que l’autre aura lieu dans quatre mois. Or, cette clé UEFI CA 2011, qui expire le 27 juin, est aussi utilisée pour la signature des bootloaders tiers, dont le « shim » de Linux, que les distributions peuvent utiliser pour se rendre compatibles avec Secure Boot.
Il reste 79% de l'article à découvrir.
Déjà abonné ou lecteur ? Se connecter
Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.
Accédez en illimité aux articles
Profitez d'un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
expert et sans pub.
Commentaires (34)
Le 19 juin à 09h15
Le 19 juin à 09h22
Le 19 juin à 09h46
Le 19 juin à 10h07
Le 19 juin à 10h20
Le 19 juin à 11h11
Le 19 juin à 12h00
Pour le moment, peut-être. Mais secureboot risque de devenir obligatoire pour certaines fonctionnalités à terme, et notamment pour tout ce qui sera du linux immuable (logique, il faudra qu'ils soient signés pour avoir un intérêt).
Secureboot participe du rapprochement des ordis comme appareil de diffusion de contenu de confiance (comme le sont les smartphone non rootés). Cela leur permettrait d'avoir netflix en 4K par exemple, mais cela est travaillé par Valve depuis suffisamment longtemps avec Arch pour penser que SteamOS sera validé par un secureboot, ce qui permettra alors d'avoir une sécurisation de la diffusion et de la lecture du contenu (IE: plus besoin de DRM, et validation des steam machines en tant que machine de confiance).
Bref: pour les linuxiens hardcore: effectivement ils n'ont peut-être pas le secureboot actif (ce qui simplifie la mise à jour des pilotes nvidia par exemple) - pour ceux qui auront Linux au lieu de Windows pour utiliser leur ordi: ça va vite devenir obligatoire pour certains usages à la maison.
Le 19 juin à 13h33
Par contre au boulot, suivant les versions de windows server, c'était beaucoup plus compliqué, étonnant
Mon portable pro sous ubuntu, aucun problème pour l'update en 1 clic, je me suis pas géné pour titiller un peu les collègues admins qui aiment windows
Le 19 juin à 14h36
Le 19 juin à 14h47
Le 20 juin à 00h04
Le 19 juin à 09h24
Une machine qui reçoit encore des mises à jour soit de son firmware, soit de son OS devrait récupérer les nouveaux certificats et continuer à fonctionner.
Par contre si on souhaite installer (ou peut-être utiliser) un ancien OS en secureboot, ou réinstaller une machine qui n'a pas les nouveaux certificats dans son firmware, on va avoir de gros soucis.
Si c'est le cas, ça ressemble fortement à de l'obsolescence programmé puisqu'on fixe une date de fin de fonctionnement sur un système qui est potentiellement parfaitement fonctionnel.
Le 19 juin à 12h31
Mais le reset est une habitude de base que je comprends aussi comme risquée après la lecture de l'article...
Le 19 juin à 09h32
Le 19 juin à 10h27
Pour un parc en entreprise y-a-t-il un autre moyen de voir si l’entrée « Démarrage sécurité » est verte sans passer sur chaque machine ?
Le 19 juin à 13h29
Le 19 juin à 10h33
Le 19 juin à 10h52
Le 19 juin à 11h21
Modifié le 19 juin à 23h38
Le 19 juin à 11h03
Le 19 juin à 14h53
Les mises à jour des certificats sont en fait poussées via les Cumulatives depuis mai 2023 (mises à jour de la DB) au moins, et l'ensemble des certificats (KEK + DB) sont poussées depuis mai 2025, donc si vous avez une Cumulative plus récente d'installée, vous pouvez déployer les nouveaux certificats via les étapes manuelles :
Le 19 juin à 16h00
J'ai les dernières màj disponibles, mais comme il était question du "dernier patch tuesday", j'avais un doute. ("De nouveaux certificats, signés en 2023 (pour a priori 15 ans, jusqu’en 2038 donc), ont déjà été distribués via Windows Update avec le dernier Patch Tuesday.")
Le 20 juin à 09h30
Pas bien grave si on continue avec une bonne hygiène informatique (pas cliquer tous les liens, pas télécharger n'importe où, etc...)
Le 19 juin à 11h24
Le 19 juin à 12h24
Le 19 juin à 12h06
Je suppose que lié à l'objet de l'article.
Les informations sont le logiciel Actualisateur de micrologiciel.
Le 19 juin à 15h04
Ils risquent de ne pas fonctionner ?
Que faut-il faire ?
Le 19 juin à 17h01
C'est fou, quand la communication d'importance existe côté M$ depuis le début d'année (et qu'ils ne sont pas connus pour leur proactivité).
Encore un autre sujet, d'une autre grosse boite, traité avec procrastination…
Le 19 juin à 17h57
(CM Gigabit)
Le 20 juin à 09h46
Et les explications sont ici:https://www.elevenforum.com/t/garlins-powershell-scripts-for-updating-secure-boot-ca-2023.43423/
Sur mon vieux laptop Gigabyte Aero, windows me dit qu'il devrait être compatible, mais ne procède pas à la mise à jour car pas assez de données télémétries sur ce modèle. Le script a apparemment bien installé les nouveaux certificats. On verra à l'usage.
La mise à jour de Bios n'est en principe pas nécessaire. Mais si on se retrouve un jour sans la partition UEFI (formatagee ou changement de disque), le Bios réinstallera l'image qu'il a, avec les anciens certificats expirés, ce qui désactivera SecureBoot. Bon, je suppose qu'on pourra encore installer les nouveaux, mais ça fait des manœuvres en plus.
Modifié le 21 juin à 02h42
Ces scripts s'adressent explicitement à ceux qui ne sont pas dans ce cas.
La suppression du certificat de 2011 pourrait être désastreux.
Si la mise à jour M$ n'a pas couvert une installation, c'est qu'une mise à jour BIOS est nécessaire. Forcer une installation pour ces matériels peut donc aussi s'avérer désastreux.
En résumé : la bidouille en l'absence de support du fabricant est fortement déconseillé.
Ces scripts devraient vous être inutiles (sauf à vérifier l'état, ce qui peut se faire de multiples manières).
Modifié le 21 juin à 21h59
J'ai une deuxième machine d'un modèle quasi identique sous mint et là, c'est bon, « sudo fwupdmgr update » marche.
Sur une autre machine windows, parfaitement à jour, le secure boot est activé mais la mise à jour des clefs n'a pas eu lieu pour une raison inconnue. Edit, c'était le BIOS. Il fallait effacer le TPM et remettre une config usine suite à la mise à jour du BIOS.
Edit linux:
Il semble que la version de fwupd installée change tout. C'est à partir de la version 2.0.8 que la mise à jour de la base UEFI DB est mise à jour. Mais cela n'explique pas tout
Quel bordel !
Modifié le 21 juin à 22h04
Set-ItemProperty -Path ‘HKLM:SYSTEM∖CurrentControlSet∖Control∖SecureBoot’ -Name ‘AvailableUpdates’ -Value 0x5944
Start-ScheduledTask -TaskName ‘∖Microsoft∖Windows∖PI∖Secure-Boot-Update’
Pour vérifier que la mise à jour s'est bien passée, vous pouvez refaire la manip comme dans l'article.
En cas de problème, démarrez regedit et recherchez HKEY_LOCAL_MACHINE∖SYSTEM∖CurrentControlSet∖Control∖SecureBoot∖Servicing
Les clefs UEFICA2023Status et UEFICA2023Error vont vous permettre de trouver le problème.
PS: j'ai été obligé de remplacer les antislash par le caractère 0x2216 pour qu'il s'affiche proprement. Vous ne pourrez pas juste copier coller les chemins...
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?