Qu’est-ce que le démarrage sécurisé UEFI ?

Le démarrage sécurisé UEFI est un mécanisme de vérification permettant de s’assurer que le code lancé par le micrologiciel est approuvé.

Une utilisation correcte et sécurisée du démarrage sécurisé UEFI nécessite que chaque binaire chargé au démarrage soit validé par rapport à des clés connues, situées dans le micrologiciel, qui désignent des fournisseurs et des sources de confiance pour les binaires, ou des binaires spécifiques de confiance pouvant être identifiés via un hachage cryptographique.

La plupart du matériel x86 provient de l’usine préchargée avec des clés Microsoft. Cela signifie que nous pouvons généralement compter sur le firmware de ces systèmes pour faire confiance aux binaires signés par Microsoft, et la communauté Linux s’appuie fortement sur cette hypothèse pour que le démarrage sécurisé fonctionne. C’est le même processus utilisé par Red Hat et SUSE, par exemple.

De nombreuses architectures ARM et autres prennent également en charge le démarrage sécurisé UEFI, mais peuvent ne pas précharger les clés dans le firmware. Sur ces architectures, il peut être nécessaire de re-signer des images de démarrage avec un certificat chargé dans le micrologiciel par le propriétaire du matériel.

Plan de mise en œuvre initial : Plan de mise en œuvre.

Architectures prises en charge

• amd64 : Un binaire shim signé par Microsoft et un binaire grub signé par Canonical sont fournis dans l’archive principale d’Ubuntu en tant que shim-signed ou grub-efi-amd64-signed.

• arm64: À partir du 20.04 (‘focal’), un binaire shim signé par Microsoft et un binaire grub signé par Canonical sont fournis dans l’archive principale d’Ubuntu en tant que shim-signed ou grub-efi-arm64-signed. Il y a un bogue GRUB en cours d’enquête qui doit être résolu avant que cela ne fonctionne de bout en bout.

Test du démarrage sécurisé UEFI

Si vous souhaitez tester le démarrage sécurisé sur votre système, consultez le mode d’emploi ici : UEFI/SecureBoot/Testing.

Comment fonctionne le démarrage sécurisé UEFI sur Ubuntu

Sur Ubuntu, tous les binaires pré-construits destinés à être chargés dans le cadre du processus de démarrage, à l’exception de l’image initrd, sont signés par le certificat UEFI de Canonical, qui lui-même est implicitement approuvé en étant intégré dans le chargeur de cale, lui-même signé par Microsoft.

Sur les architectures ou les systèmes où les certificats de signature préchargés de Microsoft ne sont pas disponibles ou chargés dans le micrologiciel, les utilisateurs peuvent remplacer les signatures existantes sur shim ou grub et les charger comme ils le souhaitent, en vérifiant par rapport à leurs propres certificats importés dans le micrologiciel du système.

Au démarrage du système, le micrologiciel charge le binaire de cale comme spécifié dans les variables de démarrage du micrologiciel. Ubuntu installe son propre Boottry au moment de l’installation et peut le mettre à jour à chaque mise à jour du chargeur de démarrage GRUB. Puisque le binaire shim est signé par Microsoft; il est validé et accepté par le firmware lors de la vérification par rapport aux certificats déjà présents dans le firmware. Étant donné que le binaire shim intègre un certificat Canonique ainsi que sa propre base de données de confiance, d’autres éléments de l’environnement de démarrage peuvent, en plus d’être signés par l’un des certificats acceptables préchargés dans le firmware, être signés par la clé UEFI de Canonical.

La prochaine chose chargée par shim est l’image de deuxième étape. Cela peut être l’une des deux choses suivantes : soit GRUB, si le système démarre normalement; ou MokManager, si la gestion des clés est requise, telle que configurée par les variables du micrologiciel (généralement modifiées lorsque le système était précédemment en cours d’exécution).

Si vous démarrez normalement ; le binaire GRUB (grub*.efi) est chargé et sa validation est tentée par rapport à toutes les sources de confiance précédemment connues. Le binaire GRUB pour Ubuntu est signé par la clé UEFI canonique, il est donc validé avec succès et le processus de démarrage se poursuit.

Si vous démarrez pour procéder aux tâches de gestion des clés, le binaire MokManager (mm*.efi) est chargé. Ce binaire est explicitement approuvé par shim en étant signé par une clé éphémère qui n’existe que pendant la construction du binaire shim. Cela signifie que seul le binaire MokManager construit avec un binaire shim particulier sera autorisé à s’exécuter et limite les possibilités de compromis liées à l’utilisation d’outils compromis. MokManager permet à tout utilisateur présent sur la console système d’inscrire des clés, de supprimer des clés de confiance, d’inscrire des hachages binaires et de basculer la validation de démarrage sécurisé au niveau de la cale, mais la plupart des tâches nécessitent la saisie d’un mot de passe préalablement défini pour confirmer que l’utilisateur de la console est bien la personne qui a demandé des modifications. Ces mots de passe ne survivent que sur une seule exécution de shim / MokManager ; et sont effacés dès que le processus est terminé ou annulé. Une fois la gestion des clés terminée, le système est redémarré et ne se contente pas de poursuivre le démarrage, car les modifications de gestion des clés peuvent être nécessaires pour terminer le démarrage avec succès.

Une fois que le système continue à démarrer sur GRUB ; le processus GRUB charge toute configuration requise (généralement en chargeant la configuration à partir de la partition système ESP (EFI), pointant vers un autre fichier de configuration sur la partition racine ou de démarrage), ce qui le pointera vers l’image du noyau à charger.

Applications EFI jusqu’à présent ayant un accès complet au micrologiciel du système, y compris l’accès aux variables de micrologiciel approuvées, le noyau à charger doit également être validé par rapport à la base de données de confiance. Les noyaux Ubuntu officiels étant signés par la clé UEFI canonique, ils sont validés avec succès et le contrôle est remis au noyau. Les images Initrd ne sont pas validées.

Dans le cas de noyaux non officiels, ou de noyaux construits par des utilisateurs, des étapes supplémentaires doivent être prises si les utilisateurs souhaitent charger de tels noyaux tout en conservant toutes les capacités du démarrage sécurisé UEFI. Tous les noyaux doivent être signés pour pouvoir être chargés par GRUB lorsque le démarrage sécurisé UEFI est activé, l’utilisateur devra donc procéder à sa propre signature. Alternativement, les utilisateurs peuvent souhaiter désactiver la validation dans shim lors du démarrage avec Secure Boot activé sur un noyau officiel en utilisant ‘sudo mokutil –disable-validation’, en fournissant un mot de passe lorsque vous y êtes invité et en redémarrant; ou pour désactiver complètement le démarrage sécurisé dans le firmware.

Jusqu’à présent, tout échec de validation d’une image à charger est rencontré avec une erreur critique qui arrête le processus de démarrage. Le système ne poursuivra pas le démarrage et peut redémarrer automatiquement après un certain temps étant donné que d’autres variables de démarrage peuvent contenir des chemins de démarrage valides et approuvés.

Une fois chargés, les noyaux validés désactiveront les services de démarrage du micrologiciel, supprimant ainsi les privilèges et passant efficacement en mode utilisateur ; où l’accès aux variables de confiance est limité à la lecture seule. Compte tenu des larges autorisations accordées aux modules du noyau, tout module non intégré au noyau devra également être validé lors du chargement. Les modules construits et expédiés par Canonical avec les noyaux officiels sont signés par la clé UEFI Canonique et, en tant que tels, sont approuvés. Les modules sur mesure nécessiteront que l’utilisateur prenne les mesures nécessaires pour signer les modules avant que leur chargement ne soit autorisé par le noyau. Cela peut être réalisé en utilisant la commande ‘kmodsign’.

Les modules non signés sont simplement refusés par le noyau. Toute tentative de les insérer avec insmod ou modprobe échouera avec un message d’erreur.

Étant donné que de nombreux utilisateurs ont besoin de modules tiers pour que leurs systèmes fonctionnent correctement ou que certains appareils fonctionnent; et que ces modules tiers nécessitent une construction locale sur le système pour être adaptés au noyau en cours d’exécution, Ubuntu fournit des outils pour automatiser et simplifier le processus de signature.

Comment puis-je faire une signature non automatisée des pilotes?

Certains projets peuvent nécessiter l’utilisation de pilotes de noyau personnalisés qui ne sont pas configurés de manière à fonctionner avec DKMS. Dans ces cas, les utilisateurs doivent utiliser les outils inclus dans le package signé par shim : le script update-secureboot-policy est disponible pour générer un nouveau MOK (si aucun module construit par DKMS n’en a déjà déclenché un).

Utilisez la commande suivante pour inscrire une clé existante dans shim :

sudo update-secureboot-policy --enroll-key

Si aucun MOK n’existe, le script se terminera avec un message à cet effet. Si la clé est déjà inscrite, le script se terminera sans rien faire. Si la clé existe mais qu’elle n’est pas inscrite, l’utilisateur sera invité à entrer un mot de passe à utiliser après le redémarrage, afin que la clé puisse être inscrite.

On peut générer un nouveau MOK en utilisant la commande suivante :

sudo update-secureboot-policy --new-key

Puis inscrire la clé nouvellement générée dans shim avec la commande mentionnée précédemment pour cette tâche.

Les modules du noyau peuvent ensuite être signés avec la commande kmodsign (voir UEFI/SecureBoot/Signing) dans le cadre de leur processus de construction.

Implications de sécurité dans la gestion des clés du propriétaire de la machine

Le MOK généré au moment de l’installation ou lors de la mise à niveau est spécifique à la machine et n’est autorisé par le noyau ou la cale que pour signer les modules du noyau, à l’aide d’unID KeyUsage spécifique (1.3.6.1.4.1.2312.16.1.2) indiquant les limites du MOK.

Les versions récentes de shim incluent une logique pour suivre les limitations des clés de signature de module uniquement. Ces clés seront autorisées à être inscrites dans le firmware dans la base de données de confiance de shim, mais seront ignorées lorsque shim ou GRUB valideront les images à charger dans le firmware. La fonction verify() de Shim validera uniquement les images signées par des clés qui n’incluent pas l’ID KeyUsage « Signature de module uniquement » (1.3.6.1.4.1.2312.16.1.2). Les noyaux Ubuntu utilisent la base de données de confiance globale (qui comprend à la fois les cales et les micrologiciels) et acceptent l’une des clés incluses comme clés de signature lors du chargement des modules du noyau.

Compte tenu des limitations imposées au MOK généré automatiquement et du fait que les utilisateurs ayant un accès superutilisateur au système et un accès à la console système pour entrer le mot de passe requis lors de l’inscription des clés ont déjà un accès de haut niveau au système; la clé MOK générée est conservée sur le système de fichiers en tant que fichiers réguliers appartenant à root avec des autorisations en lecture seule. Ceci est jugé suffisant pour limiter l’accès au MOK pour la signature par des utilisateurs ou des scripts malveillants, d’autant plus qu’aucun MOK n’existe sur le système à moins qu’il ne nécessite des pilotes tiers. Cela limite la possibilité de compromis entre l’utilisation abusive d’une clé MOK générée et la signature d’un module de noyau malveillant. Cela équivaut à un compromis des applications de l’utilisateur qui serait déjà possible avec un accès superutilisateur au système, et la sécurisation de cela est hors de portée du démarrage sécurisé UEFI.

Les systèmes précédents avaient peut-être désactivé la validation de démarrage sécurisé dans shim. Dans le cadre du processus de mise à niveau, ces systèmes seront migrés pour réactiver la validation de démarrage sécurisé dans shim et inscrire une nouvelle clé MOK le cas échéant.

Processus de génération et de signature de MOK

Le processus de génération et de signature de clés est légèrement différent selon que nous avons affaire à une toute nouvelle installation ou à une mise à niveau du système exécutant précédemment Ubuntu; ces deux cas sont clairement indiqués ci-dessous.

Dans tous les cas, si le système ne démarre pas en mode UEFI, aucune étape spéciale de signature de module du noyau ou de génération de clé ne se produira.

Si le démarrage sécurisé est désactivé, la génération et l’inscription de MOK se produisent toujours, car l’utilisateur peut ensuite activer le démarrage sécurisé. Leur système devrait fonctionner correctement si tel est le cas.

L’utilisateur installe Ubuntu sur un nouveau système

L’utilisateur parcourt le programme d’installation. Dès le début, lors de la préparation de l’installation et uniquement si le système nécessite des modules tiers pour fonctionner, l’utilisateur est invité à saisir un mot de passe système clairement indiqué comme requis une fois l’installation terminée, et pendant l’installation du système, un nouveau MOK est automatiquement généré sans autre interaction de l’utilisateur.

Les pilotes tiers ou les modules du noyau requis par le système seront automatiquement construits lorsque le package est installé, et le processus de construction comprend une étape de signature. L’étape de signature utilise automatiquement le MOK généré précédemment pour signer le module, de sorte qu’il peut être immédiatement chargé une fois le système redémarré et que le MOK est inclus dans la base de données de confiance du système.

Une fois l’installation terminée et le système redémarré, au premier démarrage, l’utilisateur est présenté avec le programme MokManager (une partie du chargeur de cale installé), sous la forme d’un ensemble de panneaux en mode texte que tout l’utilisateur doit inscrire le MOK généré. L’utilisateur sélectionne « Inscrire MOK », affiche une empreinte digitale du certificat à inscrire et est invité à confirmer l’inscription. Une fois confirmé, le nouveau MOK sera entré dans le firmware et l’utilisateur sera invité à redémarrer le système.

Lorsque le système redémarre, les pilotes tiers signés par le MOK qui vient d’être inscrit seront chargés si nécessaire.

L’utilisateur met à niveau un système Ubuntu compatible UEFI vers une nouvelle version où le système nécessite des pilotes tiers

Lors de la mise à niveau, les paquets shim et shim signés sont mis à niveau. Les tâches post-installation du paquet signé par cale génèrent un nouveau MOK et demandent à l’utilisateur un mot de passe clairement indiqué comme requis une fois le processus de mise à niveau terminé et le redémarrage du système.

Pendant la mise à niveau, les paquets du noyau et les modules tiers sont mis à niveau. Les modules tiers sont reconstruits pour les nouveaux noyaux et leur processus de post-construction se poursuit pour les signer automatiquement avec le MOK.

Après la mise à niveau, il est recommandé à l’utilisateur de redémarrer son système.

Au redémarrage, l’utilisateur est présenté avec le programme MokManager (une partie du chargeur de cale installé), comme un ensemble de panneaux en mode texte que tout l’utilisateur doit inscrire le MOK généré. L’utilisateur sélectionne « Inscrire MOK », affiche une empreinte digitale du certificat à inscrire et est invité à confirmer l’inscription. L’utilisateur reçoit également une invite pour réactiver la validation de démarrage sécurisé (dans le cas où elle a été désactivée); et MokManager nécessite à nouveau une confirmation de l’utilisateur. Une fois toutes les étapes confirmées, la validation de la cale est réactivée, le nouveau MOK sera entré dans le firmware et l’utilisateur sera invité à redémarrer le système.

Lorsque le système redémarre, les pilotes tiers signés par le MOK qui vient d’être inscrit seront chargés si nécessaire.

Dans tous les cas, une fois que le système fonctionne avec le démarrage sécurisé UEFI activé et une version récente de shim ; l’installation de tout nouveau module DKMS (pilote tiers) procédera à la signature du module construit avec le MOK. Cela se produira sans interaction de l’utilisateur si une clé MOK valide existe sur le système et semble déjà inscrite.

Si aucun MOK n’existe ou si le MOK existant n’est pas inscrit, une nouvelle clé sera automatiquement créée juste avant la signature et l’utilisateur sera invité à inscrire la clé en fournissant un mot de passe qui sera requis lors du redémarrage.