Rémy

Posted on Feb 8

Secure Boot et Linux : l'état de l'art en 2026

#security #linux #secureboot

Le Secure Boot avec les distributions Linux, ça n'a visiblement jamais été simple. Je suis sans doute trop jeune pour avoir un historique complet, mais je travaille actuellement sur le renforcement de la sécurité des environnements Linux, dont les travaux ont pour finalité d'être intégrés sur le projet Secureblue. Ce projet est une distribution renforcée sur le plan de la sécurité, construite avec Bluebuild, distribuée avec bootc (conteneurs OCI) et basé sur Fedora Atomic. Il reprend un certain nombre d'éléments intégrés dans GrapheneOS (sans lien administratif avec eux) appliqué à un usage bureau/serveur, conçu donc pour fonctionner sur la plupart des systèmes.

Dans cet article, je voudrais rapidement revenir sur l'historique qui a mené à l'état de l'art actuel pour la configuration du Secure Boot avec les distributions Linux. Je terminerai sur la mise en place technique envisagée pour Secureblue dans les prochains mois. Certaines notions sont vulgarisées et donc légèrement simplifiées pour rendre ce contenu plus lisible y compris pour les moins techniques.

UEFI au Secure Boot

Le Secure Boot est une fonctionnalité intrinsèque à l'architecture UEFI, qui remplace elle-même le BIOS. Le BIOS possédait un certain nombre de contraintes, notamment l'absence quasi totale de sécurité. L'UEFI, tout comme le BIOS, se situe entre le matériel et l'OS, et permet donc avec le Secure Boot de valider l'exécution de binaires .efi situés sur des partitions FAT32.

Contrairement à ce que l'on pourrait penser, l'UEFI n'est pas un logiciel unique mais bien une spécification. C'est le consortium UEFI Forum constitué d'une multitude de grandes entreprises qui publie un document massif définissant comment l'UEFI fonctionne et doit se comporter. Peu importe la carte mère utilisée, les règles du Secure Boot sont donc standardisées par cette documentation. Enfin bon, en théorie parce qu'il peut avoir des surprises.

Un petit point de détail important : l'UEFI dispose de fonctions qui sont disponibles même une fois que l'OS est démarré. Ce sont les Runtime Services qui permettent par exemple de modifier certaines variables (efibootmgr) ou mettre à jour l'UEFI (avec fwupd).

L'UEFI stocke des variables UEFI (de bêtes clés/valeurs). On y retrouve par exemple l'ordre de démarrage, l'état du Secure Boot, ou encore les clés PK, KEK, db et dbx (nous y reviendrons plus tard).

Dernier élément important : le binaire .efi est au format PE/COFF, en grande partie à cause de l'hégémonie de Windows qui a poussé Intel à s'orienter sur ce format. Le Secure Boot utilise la structure de l'entête PE/COFF pour y insérer une signature. L'UEFI lit ainsi l'entête du fichier et vérifie la signature avec les clés stockées.

La chaine de confiance

Le Secure Boot repose sur une chaine de confiance, l'objectif étant de ne pas faire confiance à un composant s'il n'a pas été lui même validé par un composant déjà approuvé.

Merci le paradoxe de l'oeuf et de la poule, on ne peut pas indéfiniment valider le logiciel par le logiciel ; une clé publique (généralement son empreinte) est gravée dans le silicium du processeur et du chipset. Les intégrations disponibles comme Intel Boot Guard et AMD Platform Secure Boot utilisent cette empreinte pour valider l'intégrité de l'UEFI.

Attention, ce système n'empêche en rien la possibiilté de manuellement flasher un UEFI valide et signé, mais avec des paramètres de sécurité entièrement désactivés. C'est tout à fait possible de réaliser cette opération en quelques minutes sur un matériel d'une dizaine d'euro vendu en ligne (par exemple, un EEPROM CH341A).

Avec cette approche, tout processeur ou chipset avec une clé privée ayant fuitée est immédiatement inutile sur le plan de la sécurité. C'est exactement ce qui est arrivé à MSI en 2023 avec plus d'une centaine de modèles affectés. MSI est donc obligé de passer en mode permissif le Secure Boot sur tous ses modèles, ce qui cause évidemment des problèmes de sécurité majeurs reportés sur le projet sbctl indiquant une négligence de sécurité grave.

Revenons sur la chaine de confiance :

Matériel → UEFI : le CPU valide l'intégrité de l'UEFI.
UEFI → Shim : L'UEFI cherche le fichier .efi de démarrage sur la partition FAT32 et vérifie la signature.
Shim → Bootloader : le Shim vérifie la signature du fichier grubx64.efi.
Bootloader → Noyau : le bootloader vérifie le noyau Linux vmlinuz.
Noyau → Modules : le noyau vérifie les différents modules disponibles.

J'expliquerai les différents termes par la suite. La chaine de confiance s'arrête généralement après le chargement des modules du noyau ; le Secure Boot valide uniquement que l'OS est légitime.

Une particularité importante est le mode lockdown du noyau Linux. Ce mode rend impossible tout modification de la mémoire du noyau (/dev/*mem). Certaines particularités spécifiques comme l'hibernation ou l'utilisation de kexec sont dans le scope du Secure Boot et empêche, par exemple, le chargement d'un autre noyau ou de modules non signés. Même avec l'utilisateur root, le Secure Boot assure une sécurité significative contre les attaques à distance.

Pour garantir l'intégrité du démarrage, le Secure Boot vérifie la signature numérique de chaque binaire avant son exécution en calculant sa propre empreinte (ou checksum). Ce mécanisme s'appuie sur la cryptographie asymétrique pour valider l'authenticité et l'origine :

La clé privée signe le binaire, gardée secrète.
La clé publique vérifie la signature, distribuée à tout le monde.

Les clés publiques sont stockées dans un certificat au format X.509 contenant : la clé publique, l'identité du propriétaire, une date d'expiration et l'émetteur. Certains éléments comme la date d'expiration sont peu utiles car l'UEFI ne dispose pas d'une horloge interne fiable.

Pour référence, la dernière version de l'UEFI 2.11 publiée en décembre 2024 est compatible avec l'ECDSA et le RSA, bien que le RSA soit le seul vraiment utilisé pour des raisons de compatibilité. Pour les empreintes, SHA-2 est pleinement supporté, bien que le SHA-256 soit le plus globalement utilisé également pour des raisons de compatibilité.

Un exemple typique :

Le fournisseur calcule le hachage SHA-256 du fichier binaire .efi.
Le fournisseur chiffre ce hachage avec la clé privée et obtient une signature.
Le fournisseur place cette signature dans l'entête PE/COFF du fichier .efi.
L'UEFI charge le fichier efi et récupère la signature dans l'entête.
L'UEFI calcule le hachage SHA-256 du fichier binaire .efi et obtient le hachage actuel.
L'UEFI déchiffre la signature avec la clé publique et obtient l'hachage original.
Si le hachage du fichier actuel et l'hachage original sont identiques, l'UEFI valide l'exécution.

Le TPM et les PCRS

Le Trusted Platform Module (TPM) est une puce cryptographique intégrée au processeur (ou historiquement la carte mère). Contrairement au Secure Boot qui vérifie la signature des binaires, le TPM calcule l'intégrité de l'état du système lors du démarrage. Cette mesure est stockée dans des registres appelés Platform Configuration Registers (PCRs).

Les PCRs sont des registres protégés qui conservent les mesures cryptographiques des différents composants du processus d'amorçage. Une caractéristique fondamentale des PCRs est qu'ils fonctionnent en mode hiérarchique : chaque nouvelle mesure est combinée avec la valeur précédente du registre, créant ainsi une chaine de mesures immuable. Il est impossible de remettre un PCR à zéro ou de modifier une mesure précédente sans redémarrer complètement le système. Un registre officiel des PCRs sous Linux définit quels composants mesurent quels éléments du système (uapi-group).

Ainsi, le Secure Boot garantit que seuls des binaires signés s'exécutent, et le TPM garantit que ces binaires n'ont pas été modifiés.

Une des fonctionnalitées populaires du TPM est la capacité de pouvoir délivrer une clé de déchiffrement du disque uniquement si les registres PCRs attendus sont valides (systemd-cryptenroll). Cette sécurité repose exclusivement sur la confiance complète de la validité des PCRs, qui peuvent être altérés avec une mauvaise configuration ou une potentielle vulnérabilité.

Pour quelques dizaines d'euros, il est possible de récupérer les informations transmises par le TPM avec des PCRs valides. La meilleure protection reste d'utiliser un mot de passe tapé à la main, ou alors configurer un code PIN supplémentaire (--tpm2-with-pin).

Les bases de données de clés UEFI

Les différentes clés publiques et hachages sont stockés dans quatre variables distinctes, dont chaque niveau supérieur contrôle le niveau inférieur :

La PK : Platform Key. C'est la clé racine unique par UEFI, souvent appartenant au fabricant du matériel. La PK contrôle l'accès à la KEK. Seule la personne qui possède la clé privée associée à la PK peut modifier la variable KEK.
KEK : Key Exchange Keys. C'est une liste de certificats, pratiquement toujours Microsoft (Microsoft KEK CA). La clé privée d'une KEK présente dans cette liste permet de modifier la base de données db ou dbx.
db : Signature Database, liste blanche. C'est également une liste de certificats, pratiquement toujours Microsoft (Microsoft UEFI CA 2011 ou 2023).
dbx : Forbidden Signature Database, liste noire prioritaire sur db. L'UEFI bloque l'exécution si un binaire est signé par une clé valide contenue dans cette liste. Attention toutefois ; il n'est pas rare que cette dernière soit vide, ou non mise à jour.

Par défaut, aucune de ces clés n'est manipulée par les environnement Linux. Il existe deux modes différents pour le Secure Boot :

User Mode : la PK est installée et correspond à un mode sécurisé actif.
Setup Mode : la PK n'est pas installée et correspond à un mode de configuration car n'importe qui peut écrire une nouvelle clé. Dans ce mode, le Secure Boot ne vérifie pas les binaires.

Microsoft détient les clés, même sous Linux

Tous les OEM (Lenovo, Dell, HP, etc) ne veulent pas dépenser des ressources pour mettre à jour les bases de données de clé UEFI pour supporter chaque nouvelle distribution Linux.

Pour cela, ils ont tous (oui, tous) décider de faire confiance à Microsoft pour gérer une autorité de certification universelle. Pour qu'un autre OS démarre avec le Secure Boot d'activé, il doit être adoubé par Microsoft, car les OEM n'ont ainsi qu'un seul interlocuteur qui autorise l'ensemble des environnements disponibles sur le marché.

Vient maintenant la problématique de la clé Microsoft 3rd Party UEFI CA (ou Microsoft Corporation UEFI CA "Third Party CA"). Cette clé est ouverte et permet de signer des composants qui ne sont pas à l'origine de Microsoft, par exemple des éléments d'Ubuntu ou RedHat. Par ailleurs, Microsoft s'offre le privilège de signer différemment son OS des OS alternatifs notamment Linux grâce à sa position de monopole sur ce domaine (quoi que), ce qui est une grave atteinte à l'égalité des OS face au Secure Boot.

Cela cause évidemment des problèmes de sécurité évidents :

Un point de défaillance unique : si la clé privée des parties tierces de Microsoft fuite, le Secure Boot s'effondre immédiatement.
La signature d'un composant vulnérable : sans mise à jour de la base dbx (ce qui arrive très souvent), le Secure Boot s'effondre également.
Droit de censure : Microsoft peut (théoriquement) révoquer la signature de n'importe quel binaire.
Dépendance matérielle : certains pilotes (Option ROM, nous reviendrons sur ce terme à la fin de l'article) sont signés par Microsoft. Une suppression de ces clés peut entraîner un dysfonctionnement bloquant d'un système.

Certains BIOS notamment Dell permettent de désactiver cette clé Microsoft 3rd Party UEFI CA, ce que je vous invite à faire immédiatement si vous êtes sur des environnements Windows, qui exploitent d'autres clés séparées.

Le Shim et le MOK

Microsoft ne signe pas directement les bootloader, les noyaux et les modules (bien trop complexe et couteux). Pour cela, les distributions Linux utilisent le Shim ; c'est un composant qui ne change pas, et qui peut donc être signé une seule fois par Microsoft. Chaque distribution dispose au mieux de son propre Shim signé par Microsoft. Pour soumettre une demande de signature, le dépôt shim-review est souvent utilisé (AlmaLinux par exemple).

Le Shim fonctionne ainsi comme un pont entre le bootloader (par exemple GRUB, ou systemd-boot) et l'UEFI. Il exploite directement le Shim Lock Protocol : c'est désormais lui qui est en charge de la vérification des binaires, et plus directement l'UEFI. Voici un exemple typique d'un démarrage :

UEFI → Shim : L'UEFI cherche le fichier shimx64.efi de démarrage sur la partition FAT32 et vérifie la signature avec la clé publique Microsoft 3rd Party UEFI CA.
Shim → Bootloader (GRUB par exemple) : le Shim cherche le fichier grubx64.efi et vérifie la signature avec la clé publique intégrée au Shim (vendor certificate).

Cela permet de mettre à jour le GRUB en conservant la même version du Shim. Le Shim permet également d'aller plus loin que les bases de données de clés UEFI. Il dispose de deux moyens complémentaires pour vérifier la signature des binaires :

Utiliser le certificat intégré (vendor certificate). Il est possible de récupérer le certificat intégré avec cette commande sur Fedora (changez la localisation du shimx64.efi si vous êtes sur une autre distribution) :

$ objcopy -O binary -j .vendor_cert /boot/efi/EFI/fedora/shimx64.efi /dev/stdout | openssl x509 -inform der -text -noout

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            22:39:af:04:13:0c:44:44:b3:f3:77:ed:be:1a:f7:86
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Massachusetts, L=Cambridge, O=Red Hat, Inc., OU=Fedora Secure Boot CA 20200709, CN=fedoraca
        [...]

Exploiter le Machine Owner Key (MOK) : étant donné que chaque modification de la base de données Secure Boot db nécessite d'être dans le "Setup Mode" (et donc un redémarrage et une modification dans l'UEFI), le MOK fonctionne comme une liste locale gérée par le Shim. Deux variables existent dans le cadre du MOK : MokList et MokListX (liste noire équivalente au dbx).

Le MOK dispose également de son propre processus d'enrollement :

On génère une paire de clés éphémère.
On signe un pilote, un noyau ou un bootloader avec une clé privée.
On importe la clé publique dans le Shim pour qu'il puisse valider la signature avec mokutil --import.
On définit un mot de passe temporaire dans l'unique objectif de valider l'ajout au prochain démarrage.
On redémarre le système.
Au démarrage, avant que le bootloader se lance, le Shim détecte qu'une demande d'ajout de clé est en attente.
Le MOK Manager (mmx64.efi) se lance.
L'utilisateur doit valider l'enrollement de la clé dans la MokList avec le mot de passe temporaire défini.
Le système redémarre et le Shim pour désormais valider la signature des différents composants.

mokutil est l'outil qui permet de gérer le MOK. Il communique directement avec le Shim et permet d'avoir une interface (légèrement) plus simple et surtout standardisée contrairement à l'UEFI, permettant aux utilisateurs de mettre à jour simplement les certificats utilisés pour le Secure Boot. Cette solution n'est clairement pas parfaite et expose plusieurs problèmes importants :

Une corruption de mémoire permettant l'exécution de code UEFI (CVE-2023-40547).
La désactivation logicielle du Shim possible avec des accès root (mokutil --disable-validation)
Une erreur de logique dans l'analyse des listes de révocation permettant de charger des binaires bannis (CVE-2023-40548).
Heap Overflow lors de la vérification de l'intégrité des fichiers EFI (CVE-2022-28737).
L'injection directe de clés malveillantes dans la variable MokList pour contourner le Secure Boot (BlackLotus).
La lecture hors limites lors du parsing des métadonnées SBAT, compromettant le processus de boot (CVE-2023-40550).
Manipulation du MOK Manager lors d'un reboot pour valider une clé malveillante en l'absence de mot de passe fort.

Bref, le MOK c'est clairement une solution de contournement qui ajoute avec le Shim une couche supplémentaire d'attaque.

UKI sauve la mise

Le démarrage sous Linux dispose de plusieurs composants (exemples entre parenthèses) :

Le bootloader (grubx64.efi).
Le noyau Linux (vmlinuz).
L'initramfs (initramfs.img).
La ligne de commande du noyau (grub.cfg, aussi appelée cmdline).

Ces différents éléments s'exposent directement au Evil maid attack : par défaut, la partition /boot n'est pas chiffrée, le fichier grub.cfg peut donc être modifié à froid et obtenir un accès root sur la machine. GRUB dispose néanmoins de cette option, et supporte Argon2id depuis octobre 2025. Également par défaut, GRUB ne dispose pas de mot de passe et peut donc permettre la modification de la ligne de commande du noyau. L'initrd n'est pas signé dans le fonctionnement actuel du Secure Boot, une version alternative pouvant par exemple obtenir le mot de passe de déchiffrement du disque.

L'objectif de l'UKI est de fusionner l'ensemble de ces éléments en un seul fichier .efi. Il contient ainsi :

Le stub UEFI (simple pont entre l'UEFI et le noyau).
Le noyau.
L'initramfs.
Le cmdline.
Certains éléments complémentaires notamment un logo ou le microcode du processeur.

Dans le cas du Secure Boot, on effectue la signature du fichier UKI complet, ce qui réduit presque totalement la surface d'attaque. La modification d'un seul bit rend invalide la signature et le système refusera de démarrer.

L'UKI est inévitablement moins flexible que l'approche historique, car chaque modification d'un de ses composants nécessite une reconstruction complète et une nouvelle signature. L'avantage sécuritaire est néanmoins tellement important que quelques secondes supplémentaires lors de la mise à jour n'est généralement pas un problème.

Les UKI seraient donc parfaites et la réponse à tout ? En fait, non. Même avec l'UKI, l'utilisation du Shim est toujours obligatoire.

Prenons le contrôle des clés

Résumons :

Le Shim est un composant peu sécurisé par nature, mais obligatoire car l'UEFI ne fait confiance qu'à Microsoft par défaut, même avec l'UKI.
Les OEM et Microsoft sont intégrés par défaut dans les bases de données de Secure Boot, ce qui implique de leur faire confiance sur la sécurité de leur clé privée et la mise à jour permanente de la base dbx.

L'idéal serait donc de retirer le Shim, et retirer au passage la confiance accordée à toutes les autorités présentes par défaut. Il y a toutefois un problème majeur qui peut concerner certains systèmes : les opROMs. Ce sont des programmes intégrés à certains périphériques matériels (carte graphique, contrôleur RAID, carte réseau) qui sont par défaut signés par Microsoft. Si on installe une PK personnalisée qui supprime toutes les autres données des bases existantes (KEK et db), il est possible de rencontrer un écran noir avant le chargement de l'OS, l'absence de réseau, de détection de disques etc. Heureusement cela ne concerne clairement pas tous les modèles, mais il est important de le prendre en compte.

La première étape est de modifier la PK. Pour cela, il est nécessaire de placer le Secure Boot en mode "Setup" dans l'UEFI. Ceci permet de supprimer l'ensemble des bases de données de Secure Boot et permettre à l'utilisateur de créer sa propre PK, KEK et db. sbctl permet cela : il génère et configure les clés avec create-keys, effectue l'enrollement avec enroll-keys, et signe les différents binaires avec sign. Par défaut, enroll-keys se bloque s'il détecte que des opROMs doivent être signés pour démarrer (tpm.go) en se basant sur le journal d'évènement du TPM EV_EFI_BOOT_SERVICES_DRIVER. Cet évènement est inscrit dans la spécification TCG qui définit comment l'UEFI doit communiquer avec la puce TPM :

Platform Firmware MUST measure the event EV_EFI_RUNTIME_SERVICES_DRIVER or EV_EFI_BOOT_SERVICES_DRIVER for each UEFI Driver, non-bootable applications, Non-Manufacturer Controlled Embedded UEFI Driver, or Non-Manufacturer Controlled Embedded non-bootable applications prior to initializing the module.

L'option sbctl enroll-keys --yes-this-might-brick-my-machine permet justement de forcer l'installation même si des opROMs signés sont détectés (ne l'utilisez pas, vraiment). L'option expérimentale --tpm-eventlog permet d'inscrire dans la db (liste blanche) l'intégrité des opROMs pour contourner la vérification de la signature, ce qui affaiblit légèrement la sécurité mais permet néanmoins l'installation d'une PK personnalisée.

Une option plus sereine serait d'utiliser sbctl enroll-keys --microsoft qui permet d'inclure la clé publique de Microsoft dans les clés du Secure Boot pour éviter un problème avec les opROMs.

Voici le résultat attendu :

$ sbctl status
Installed: ✓ sbctl is installed
Owner GUID: [...]
Setup Mode: ✓ Disabled
Secure Boot: ✓ Enabled

$ sbctl verify
Verifying file database and EFI images in /boot/efi...
✓ /boot/efi/EFI/fedora/shimx64.efi is signed
✗ /boot/efi/EFI/BOOT/BOOTIA32.EFI is not signed
✗ /boot/efi/EFI/BOOT/BOOTX64.EFI is not signed
✗ /boot/efi/EFI/BOOT/fbia32.efi is not signed
✗ /boot/efi/EFI/BOOT/fbx64.efi is not signed
✗ /boot/efi/EFI/fedora/grubia32.efi is not signed
✗ /boot/efi/EFI/fedora/grubx64.efi is not signed
✗ /boot/efi/EFI/fedora/mmia32.efi is not signed
✗ /boot/efi/EFI/fedora/mmx64.efi is not signed
✗ /boot/efi/EFI/fedora/shim.efi is not signed
✗ /boot/efi/EFI/fedora/shimia32.efi is not signed

$ sbctl list-enrolled-keys
DB:
  Database Key
PK:
  Platform Key
KEK:
  Key Exchange Key

$ mokutil --pk
[key 1]
[...]
Certificate:
    Data:
        [...]
        Issuer: CN=Platform Key
        Subject: CN=Platform Key
        [...]

$ mokutil --kek
[key 1]
[...]
Certificate:
    Data:
        [...]
        Issuer: CN=Key Exchange Key
        Subject: CN=Key Exchange Key
        [...]

$ mokutil --db
[key 1]
[...]
Certificate:
    Data:
        [...]
        Issuer: CN=Database Key
        Subject: CN=Database Key
       [...]

On peut noter que la commande sbctl verify indique que seulement le fichier shimx64.efi est signé, et c'est normal ; c'est le seul composant que vérifie l'UEFI. Le Shim récupère ensuite les informations du MOK pour vérifier les différentes signatures.

Vers une suppression du Shim

Le retrait du Shim est uniquement possible si le système est configuré avec sa propre PK. C'est là que l'UKI prend tout son sens : il est beaucoup plus simple et sécurisé de signer un fichier .efi, en plus de tous les avantages sécuritaires listés précédemment.

Idéalement, Secureblue devrait baculer dans le courant de cette année sur l'UKI. Dans cette situation, le MOK ne sera plus présent et l'UKI sera le seul élément ayant besoin d'être signé (si le système autorise une PK personnalisée).

En attendant, une PR #1917 a été ouverte pour permettre à minima d'utiliser sa propre PK, idéalement avec des paramètres renforcés s'ils sont supportés (ECDSA-384, SHA-512).

Résumé des avantages sécuritaires

En résumé, voici les différents avantages sécuritaires avec le retrait du Shim et l'ajout de clés personnalisées pour le Secure Boot :

Indépendance de Microsoft : en utilisant sa propre PK, on élimine la dépendance à l'autorité de certification de Microsoft 3rd Party UEFI CA, évitant ainsi de confier la sécurité à une entité externe qui n'est pas sous notre contrôle et qui peut révoquer des signatures ou voir ses clés compromises.
Réduction significative de la surface d'attaque : le Shim, bien que pratique, introduit une couche logicielle complexe qui a historiquement été la cible de nombreuses vulnérabilités critiques (CVE-2023-40547, CVE-2023-40548, CVE-2022-28737, CVE-2023-40550, BlackLotus).
Élimination du MOK et de ses faiblesses : le MOK est une solution de contournement qui ajoute une couche de gestion de clés locale complexes et vulnérables. Avec une PK personnalisée et des UKI signés directement, le MOK devient inutile, supprimant ainsi les risques d'injection de clés malveillantes ou de manipulation du MOK Manager.
Contrôle total de la chaine de confiance : on garantit qu'aucun composant non explicitement approuvé ne peut s'exécuter pendant le processus d'amorçage. Cela permet indirectement de bloquer le démarrage sur des clés USB avec des outils comme Ventoy.
Protection contre les attaques Evil Maid : les UKI signés avec sa propre PK offrent une protection contre les attaques physiques où un attaquant tenterait de modifier le bootloader, le noyau, l'initramfs ou la ligne de commande du noyau. Toute modification invalide la signature et empêche le démarrage.
Possibilité d'utiliser des algorithmes cryptographiques renforcés : une PK personnalisée permet d'utiliser des algorithmes modernes et plus robustes comme l'ECDSA-384 et le SHA-512, offrant une meilleure sécurité que les clés RSA et SHA-256 généralement utilisées par défaut.
Prévention contre la désactivation logicielle du Secure Boot : contrairement au MOK qui peut être désactivé avec des privilèges root via mokutil --disable-validation, une PK personnalisée ne peut être modifiée que physiquement en mode Setup, rendant pratiquement impossible la désactivation logicielle du Secure Boot.
Isolation complète des écosystèmes : chaque utilisateur ou organisation dispose de son propre écosystème de confiance, isolé des autres. Une compromission des clés d'un utilisateur n'affecte pas les autres utilisateurs de PK personnalisées, contrairement à une compromission de la clé Microsoft qui affecterait l'ensemble des installations.
Simplification architecturale : sans Shim et MOK, l'architecture de démarrage devient plus simple et plus facile à auditer. L'UEFI vérifie directement l'UKI signé, sans intermédiaire complexe, réduisant ainsi le risque d'erreurs de configuration ou de bugs.
Protection contre la révocation arbitraire : Microsoft conserve le droit de révoquer des signatures. Avec sa propre PK, l'utilisateur n'est plus soumis aux décisions unilatérales de Microsoft concernant quels binaires sont autorisés à s'exécuter.
Validation directe de l'ensemble des composants critiques : avec les UKI signés, l'intégralité du noyau, de l'initramfs et de la ligne de commande est validée en une seule signature, contrairement à l'approche traditionnelle où chaque composant est vérifié séparément avec des mécanismes potentiellement différents.
Durcissement contre les attaques matérielles : bien que la PK puisse techniquement être réinitialisée physiquement (comme n'importe quelle clé UEFI), le fait de ne pas dépendre de clés tierces signifie que l'attaquant doit avoir un accès physique à la machine et connaître les détails de la configuration personnalisée pour contourner la sécurité.
Souveraineté numérique : l'utilisation d'une PK personnalisée restaure la souveraineté de l'utilisateur sur son propre matériel, en refusant de déléguer la décision de ce qui est sécurisé ou non à un tiers (Microsoft, la blague).

DEV Community