Ubuntu Wiki

Qu’est-ce que UEFI Secure Boot?

UEFI Secure boot est un mécanisme de vérification pour s’assurer que le code lancé par le firmware est de confiance.

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

La plupart des matériels x86 sortent de l’usine préchargés 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 Secure Boot fonctionne. C’est le même processus utilisé par Red Hat et SUSE, par exemple.

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

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

Architectures supportées

• 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 de 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 bug de GRUB en cours d’investigation qui doit être résolu avant que cela fonctionne de bout en bout.

Tester le démarrage sécurisé UEFI

Si vous êtes intéressé à tester le démarrage sécurisé sur votre système, consultez le how-to ici : UEFI/SecureBoot/Testing.

Comment fonctionne le Boot 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 de confiance en étant intégré dans le chargeur shim, 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 firmware, 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 firmware du système.

Lorsque le système démarre, le firmware charge le binaire shim comme spécifié dans les variables BootEntry du firmware. Ubuntu installe sa propre BootEntry au moment de l’installation et peut la mettre à jour chaque fois que le chargeur de démarrage GRUB est mis à jour. Comme le binaire de shim est signé par Microsoft, il est validé et accepté par le microprogramme lors de la vérification par rapport aux certificats déjà présents dans le microprogramme. Comme le binaire shim embarque un certificat Canonical 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 nécessaire, comme configuré par les variables du firmware (généralement changé lorsque le système était précédemment en cours d’exécution).

Si le système démarre 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 de Canonical, il est donc validé avec succès et le processus de démarrage se poursuit.

Si le démarrage doit procéder à des tâches de gestion des clés, le binaire MokManager (mm*.efi) est chargé. Ce binaire est explicitement de confiance 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 la possibilité de compromission par l’utilisation d’outils compromis. MokManager permet à tout utilisateur présent à 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 Secure Boot au niveau de la shim, mais la plupart des tâches nécessitent la saisie d’un mot de passe préalablement défini pour confirmer que l’utilisateur à la console est bien la personne qui a demandé les modifications. Ces mots de passe ne survivent qu’à une seule exécution de shim / MokManager et sont effacés dès que le processus est terminé ou annulé. Une fois que la gestion des clés est terminée, le système est redémarré et ne continue pas simplement avec le démarrage, car les changements de gestion des clés peuvent être nécessaires pour compléter avec succès le démarrage.

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

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

Dans le cas de noyaux non officiels, ou de noyaux construits par les utilisateurs, des mesures supplémentaires doivent être prises si les utilisateurs souhaitent charger ces noyaux tout en conservant toutes les capacités de l’UEFI Secure Boot. Tous les noyaux doivent être signés pour être autorisés à être chargés par GRUB lorsque l’amorçage 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 lorsqu’ils sont démarrés avec Secure Boot activé sur un noyau officiel en utilisant ‘sudo mokutil –disable-validation’, en fournissant un mot de passe lorsqu’il est demandé, et en redémarrant ; ou pour désactiver Secure Boot dans le firmware tout simplement.

Jusqu’à ce point, 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 continuera pas à démarrer, et peut redémarrer automatiquement après un certain temps étant donné que d’autres variables BootEntry peuvent contenir des chemins de démarrage qui sont valides et de confiance.

Une fois chargés, les noyaux validés désactiveront les services de démarrage du firmware, abandonnant ainsi les privilèges et passant effectivement en mode utilisateur ; où l’accès aux variables de confiance est limité à la lecture seule. Étant donné les larges permissions accordées aux modules du noyau, tout module non intégré au noyau devra également être validé au chargement. Les modules construits et livrés par Canonical avec les noyaux officiels sont signés par la clé UEFI de Canonical et sont donc fiables. Les modules personnalisés nécessitent que l’utilisateur prenne les mesures nécessaires pour signer les modules avant que leur chargement ne soit autorisé par le noyau. Ceci peut être réalisé en utilisant la commande ‘kmodsign’ .

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

Du fait que de nombreux utilisateurs ont besoin de modules tiers pour que leurs systèmes fonctionnent correctement ou pour que certains périphériques fonctionnent ; et que ces modules tiers nécessitent d’être construits localement 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 gens devraient faire usage des outils inclus dans le paquet shim-signed : le script update-secureboot-policy est disponible pour générer un nouveau MOK (si aucun module construit par DKMS n’a déjà déclenché la génération d’un MOK).

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’apparaît pas pour être enrôlée, l’utilisateur sera invité à fournir un mot de passe à utiliser après le redémarrage, afin que la clé puisse être enrôlée.

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

sudo update-secureboot-policy --new-key

Et ensuite inscrire la clé nouvellement générée dans shim avec la commande précédemment mentionnée 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 de la clé du propriétaire de la machine

La MOK générée au moment de l’installation ou lors de la mise à niveau est spécifique à la machine, et seulement autorisée par le noyau ou la shim pour signer les modules du noyau, par l’utilisation d’un OID KeyUsage spécifique (1.3.6.1.4.1.2312.16.1.2) dénotant les limitations de la MOK.

Les versions récentes de shim incluent une logique pour suivre les limitations des clés à 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 pour charger dans le firmware. La fonction verify() de shim ne validera avec succès que les images signées par des clés qui n’incluent pas l’OID KeyUsage « Module-signing only » (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 celle de la shim et celle du firmware) et accepteront n’importe laquelle des clés incluses comme clés de signature lors du chargement des modules du noyau.

Compte tenu des limitations imposées à la MOK générée automatiquement et du fait que les utilisateurs disposant d’un accès superutilisateur au système et d’un accès à la console système pour entrer le mot de passe requis lors de l’enrôlement 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 comme des fichiers réguliers appartenant à root avec des autorisations de lecture seule. Cela est jugé suffisant pour limiter l’accès à la clé MOK pour la signature par des utilisateurs ou des scripts malveillants, d’autant plus qu’aucune clé MOK n’existe sur le système, à moins qu’elle ne nécessite des pilotes tiers. Cela limite la possibilité de compromission par l’utilisation abusive d’une clé MOK générée pour signer un module noyau malveillant. Cela équivaut à la compromission des applications userland qui serait déjà possible avec l’accès du superutilisateur au système, et la sécurisation de cela est hors de la portée de l’UEFI Secure Boot.

Les systèmes précédents peuvent avoir eu la validation Secure Boot désactivée dans shim. Dans le cadre du processus de mise à niveau, ces systèmes seront migrés vers la réactivation de la validation Secure Boot dans shim et l’inscription d’une nouvelle clé MOK le cas échéant.

Processus de génération et de signature de la clé

Le processus de génération et de signature de la clé est légèrement différent selon que l’on a affaire à une toute nouvelle installation ou à une mise à niveau du système fonctionnant précédemment sous 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 de noyau ou de génération de clé n’aura lieu.

Si Secure Boot est désactivé, la génération de MOK et l’enrôlement se produisent quand même, car l’utilisateur peut activer Secure Boot ultérieurement. Ils système devrait fonctionner correctement si c’est le cas.

L’utilisateur installe Ubuntu sur un nouveau système

L’utilisateur avance dans le programme d’installation. Au début, lors de la préparation de l’installation et seulement si le système nécessite des modules tiers pour fonctionner, l’utilisateur est invité à fournir un mot de passe système qui est clairement indiqué comme étant 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 paquet 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 que le système est 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 se voit présenter le programme MokManager (faisant partie du chargeur de cales installé), sous la forme d’un ensemble de panneaux en mode texte qui tous l’utilisateur à inscrire le MOK généré. L’utilisateur sélectionne « Enroll MOK », une empreinte digitale du certificat à enregistrer lui est présentée, et il est invité à confirmer l’enregistrement. 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 enrôlé 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é sont mis à niveau. Les tâches de post-installation du paquet shim-signé procèdent à la génération d’un nouveau MOK et demandent à l’utilisateur un mot de passe qui est clairement mentionné comme étant requis une fois le processus de mise à niveau terminé et le système redémarré.

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 procède à leur signature automatique 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 (partie du chargeur de cales installé), comme un ensemble de panneaux en mode texte qui tous l’utilisateur à inscrire le MOK généré. L’utilisateur sélectionne « Enroll MOK », une empreinte digitale du certificat à enregistrer lui est présentée et il est invité à confirmer l’enregistrement. L’utilisateur est également invité à réactiver la validation Secure Boot (dans le cas où elle a été désactivée) ; et MokManager demande à nouveau la confirmation de l’utilisateur. Une fois que toutes les étapes sont 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 enrôlé seront chargés si nécessaire.

Dans tous les cas, une fois que le système fonctionne avec UEFI Secure Boot 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 être déjà inscrite.

Si aucune MOK n’existe ou si la MOK existante n’est pas inscrite, 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 au redémarrage.