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

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

Bonsoir à tous,

Je parcours ce thread (sans forcement tout comprendre :frowning: ) vu que l’intitulé m’a interpellé.
Ca parle de secure donc ca m’interpelle encore une fois.

J’ai un windows 11 sur un Acer 8 Giga de 2017/2018.
Jusqu’à 1 semaine ou deux, j’ouvrais ma session avec le doigt.
Maintenant, les sessions remontent sans cette validation.

Est ce que ca rentrerait de pres ou de loin dans le sujet qui est débattu ici ?
Si ca n’est pas la cas, excusez moi pour le bruit.

Cdt

#66

Aucun lien à mon avis. Secure boot est là pour s’assurer que le système d’exploitation qu’on lance au démarrage est signé avec des clés auxquelles EFI fait confiance.

Ton souci vient probablement d’un paramétrage ou d’un driver qui a bougé.

#67

ok merci

je me retire sur la pointe des pieds :slight_smile:

#68

Le Secure boot vérifie qu’il n’y a pas eu de modification dans les bootloader. Pour ça il utilise des signatures dont les clefs et certificats sont stockées dans PK/KEK/db/dbx