La fin des certificats Secure Boot en 2026 : tout savoir et préparer son PC

Pause Café
#41

Non j’ai aussi le mien (anonymisé):

~# mokutil --list-enrolled --short
****** Debian Secure Boot CA
****** mon_certificat

Un peu plus en fait :slight_smile:

~# find /boot/efi/EFI -name '*.efi' -type f
/boot/efi/EFI/systemd/systemd-bootx64.efi
/boot/efi/EFI/BOOT/BOOTX64.efi
/boot/efi/EFI/BOOT/fbx64.efi
/boot/efi/EFI/Linux/debian.efi
/boot/efi/EFI/debian/shimx64.efi
/boot/efi/EFI/debian/fbx64.efi
/boot/efi/EFI/debian/mmx64.efi

J’utilise systemd-boot et UKI

j’ai utilisé le shim existant auquel j’ai ajouté ma propre signature et j’ai ensuite supprimé la signature Microsoft avec sbattach --signum 1 --remove

Pour ce qui est de la partie KEK c’est plus compliqué. Il faut que je vois avec la partie PK. Car KEK est nécessaire aux mises à jour de l’UEFI et du BIOS. Donc c’est plus compliqué de bien valider le fait de supprimer Microsoft.

Mon PK etant celui du fournisseur de la carte-mère, je vais garder celui là.
En plus je dois attendre la prochaine version de VirtualBox afin d’avoir la mise à jour du matériel pour voir si ça marche.
Ou bien d’utiliser une machine secure boot de test physique. Ce qui n’est pas évident.
Cela étant il est possible de sauvegarder une base secure boot existante pour la restaurer ensuite.

#42

Pas que 2023, pendant plusieurs années, ce sera signé avec les clefs 2011 et les clefs 2023. Donc tout ira bien. 2011 pour assurer la comptabilité avec les «vieilles» machines pendant plusierus années et 2023 pour passer sur les toutes nouvelles machines. Donc tu n’as strictement rien à faire pendant plusieurs années. Encore une fois ça n’est pas comme une expiration d’un certificat HTTPS.
En clair il ne faut rien faire.
Après Zargos lui signe ses propres noyaux, c’est différent.

#43

Ok merci pour l’info.

#44

C’est mort pour les 2011 à fin 2026 quelle que soit les clefs.

~# mokutil --db | egrep -E 'Subject:|Not After :'
            Not After : Dec 26 23:35:04 2031 GMT
        Subject: CN=ASUSTeK MotherBoard SW Key Certificate
            Not After : Dec 27 00:18:52 2031 GMT
        Subject: CN=ASUSTeK Notebook SW Key Certificate
            Not After : Jun 27 21:32:45 2026 GMT
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011
            Not After : Oct 19 18:51:42 2026 GMT
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011
            Not After : Jun 13 19:31:47 2038 GMT
        Subject: C=US, O=Microsoft Corporation, CN=Microsoft UEFI CA 2023
            Not After : Jun 13 19:08:29 2035 GMT
        Subject: C=US, O=Microsoft Corporation, CN=Windows UEFI CA 2023

La date précède le certificat.

#45

Il y a la signature des binaires et ce que reconnait shim.
De ce que je lis et de ce que j’ai compris:
→ À partir du 27 juin 2026, il n’y aura plus aucun binaires signés avec les clefs 2011
→ Les machines neuves vont contenir pendant quelques temps (durée) les deux certificats 2011 et 2023 puis après uniquement 2023
→ shim sera doublement signé avec les certificats 2011 et 2023 (si j’ai bien compris ces shim sont fait actuellement en avance afin que microsoft les signe avant juin 2026)

En tout cas, même après juin 2026, les binaires signés avec les certificats 2011 seront acceptés. Ce sont les nouveaux binaires qui seront signés avec le certificat 2023. Ce n’est que dans quelques années que les machines neuves n’accepteront plus les binaires certifiés 2011. La date est une date de signature, on ne pourra plus signer quoi que ce soit après le 27 juin 2026 avec le certificat 2011 mais on pourra toujours bouter des binaires signés avec ce certificat 2011.
[heureusement, il faut imaginer le bazar si tout s’arrêtait ce 27 juin :slight_smile: ]

#46

En fait, les certificat Microsoft pour shim on s’en fout complètement. On en a pas besoin.
Par contre les certificats Microsoft sont important pour la base KEK (shim dépend de MOK et DB).

#47

En fait @Zargos tu as deux certificats perso, le toto UEFI qui est dans les DB, et le toto Secure Boot qui est dans les MOK, si je lis bien ? Quelle est l’utilité d’avoir fait deux certificats distincts, dans ton cas de figure ?

#48

dans la DB c’est pour le shim (entre autre). Ne sert qu’au lancement du bootloader et la validation du démarrage sécurisé.
Le MOK lui sert pour signer les modules du noyau et vmlinuz/initrd, en plus du debian.efi de l’UKI.
Il y a deux étape dans un démarrage UEFI.

#49

Si je ne met pas un shim signé par le certificat Microsoft, ma clef ne boute pas sur un ordinateur avec le secure boot.
Au démarrage, le firmware :

  • charge shimx64.efi
  • vérifie sa signature avec les clés présentes dans :
    • db (autorisé)
    • dbx (révoqué)
      Typiquement :
  • signature Microsoft (CA 2011 ou 2023)
    Si OK → exécution de shim

shim vérifie grub ainsi que le noyau chargé à partir de sa propre base de clefs ainsi que les clefs MOK (machine owner key).
Il charge grub en testant avec le « debian secure boot CA » puis grub vérifie le noyau via shim_lock. C’est le cas standard. Il y a un autre système dit UKI que je ne connais pas.

En gros la machine fait confiance à Microsoft qui donne le quitus à shim qui fait confiance à Debian qui donne le quitus à grub qui donne quitus au noyau.

#50

En toute logique, signer tes noyaux avec le certificat DB devrait suffire à les lancer. D’où ma question de savoir quelle est l’utilité de les signer avec un second certificat dans les MOK.

Ma compréhension, c’est que shim AJOUTE des certificats MOK à la liste des signatures autorisées, mais qu’il peut lancer des efi ayant une signature de niveau supérieur (DB)…

#51

C’est normal. C’est la machine qui décide, pas ta clef. Donc si ta clef ne dispose pas des signature correspondant à ta base de données Secure Boot ou ton MOK alors elle ne pourra pas démarrer.

De quelle clef s’agit-il?
j’ai testé avec mon installation, j’arrive à monter une clef Debian netinst sans problème (car signé par le certificat Debian que j’ai conservé).
J’ai aussi démarré avec une live Debian.

Par contre, toute clef non signée avec un des certificats de ma machine ne permettra pas de démarrer une clef.
n’oubliez pas que ça fait partie de l’objectif :slight_smile:
Cependant, si c’est pour réinstaller la machine complètement, il suffit de faire un reset complet de la base secure boot.

#52

Non ce sont des bases différentes, mais qui peuvent contenir les mêmes certificats.
Tu ne peux signer un noyau ou un module que si tu dispose à la fois du certificat ET de la clef privée. Hors tu ne possèdes pas les clefs des certificats qui sont dans la base secure boot. D’où le MOK.

#53

Mais tu possèdes bien la clé privée de ton propre certificat toto DB ?

#54

Oui. Mais il n’est pas dans la base.
Le MOK est insuffisant pour le shim, il faut que le certificat soit dans la base secure boot.

MOk → je signe avec
DB → l’UEFI valide le démarrage du shim.

Et tu dois signer le shim pour qu’il démarre.

#55

Il y a encore des trucs qui m’échappent, mais ça donne matière à réfléchir pour bien comprendre, merci :+1:

#56

La séquence de démarrage est la suivante:
image

Dans l’ordre:

Shim64
    Grub, ou systemd-boot, etc..
      vmlinuz
            initrd
#57

Je rajoute, que tu ne peux pas démarrer ta clef, mais tu peux la monter sans problème et gérer les fichiers dessus.

#58

Cette clef USB est la clef APESAM destinée aux enseignants et étudiants, elle doit bouter sur n’importe quelle machine sans avoir à modifier quoi que ce soit d’où la nécessité de passer par Microsoft.
Pour mon cas personnel, sur ma machine, comme j’utilise un noyau perso, j’ai viré le secure boot mais du coup je me demande si signer mon noyau ne serait pas intéressant. Apparemment il faut privilégier le UKI (!?!) à grub. Bon. Je vais relire la démarche que tu décris, je n’ai jamais fait jusqu’à présent.

#59

UKI implique de toute façon la signature du noyau. Et c’est une bonne démarche. Par contre, l’UKI est une entrée dans le menu de démarrage.
One ne peut pas créer un démarrage UKi multi-boot.
On créé en fait une entrée de boot pour chaque système démarré en UKI.
Attention, cette démarche nécessite d’avoir une partition/boot/efi assez grande, car un noyau UKI est, par définition, assez gros.

Sur ma VM de test, il fait 68Mo. Ce qui est normal, car l’UKI intègre le vmlinuz et l’initrd.
Considérant que shiml fait environ 1Mo, systemd-boot environs 122k, etc…

Une partition d’au moins 512Mo est un minimum pour éviter toute forme de blocage.

Après il est possible de modifier un clef de ce type.
Il faut la convertir dans une iso (dd). Monter l’iso, signer les fichiers nécessaire (via un script), regénérer les checksums (sha256sum)et reconstruire l’iso (xorriso). Ensuite il suffit de la graver sur une clef (dd).

#60

Après un test avec nixos par exemple, je me suis aperçu que les fichiers .efi de l’iso ne sont pas signés. Mais avec la suppression empêche le démarrage.
De ce fait, de base on ne peut pas lancer une iso non signée avec la configuration que j’ai testé.

Avec debian netinst, l’iso est signé, donc elle demarre (car j’ai gardé le certificat Debian).

Pas pu tester l’iso PikaOS, car le squashfs est blacklisté sur mes machines.
Idem pour OPNsense.