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

Pause Café
#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.

#61

2 messages ont été scindés en un nouveau sujet : Message Erreur Secure Boot

#62

Même dans un collège ou un lycée ? Tu m’intéresses.

#63

Oui, elle n’est pas sur le principe de ClefAGREG techniquement parlant (utilisation de aufs + squashfs) car les tailles des clefs sont importantes et les clefs sont plus solides. Il faut une clef USB rapide voire un SSD USB 128G (idéal pour le coup). Tu as une vidéo sur ce lien, voilà sinon la liste des logiciels actuellement installés (en plus des classiques):
image

2 J'aime
#64

En passant, n’oubliez pas que si vous avez enrollé des clefs personnelles, toute mise à jour du BIOS va probablement les supprimer. Il faut donc prévoir de re-enroller vos clefs dans le MOK après la mise à jour.

1 J'aime