Secure Boot : à quoi bon ?

MISC

n°

126

mars 2023

Par

Maury Florian

Sécurité système

Tag(s)

Secure Boot

UEFI

TPM

Secure Boot est un composant important de la chaîne de sécurité du démarrage d'un ordinateur. Il vise à assurer que seul du code autorisé s'exécute dans les premiers instants du démarrage. L'ANSSI recommande son utilisation pour tous les systèmes Linux de niveau de sécurité intermédiaire ou plus [1]. Mais à quoi bon ? Cet article propose de rationaliser l'usage de cette technologie, et en évoque ses limites.

Secure Boot est une technologie faisant partie de la spécification UEFI. UEFI est une interface implémentée par le logiciel embarqué (firmware), ce dernier étant en charge de l'initialisation de la machine. Il s'agit d'un remplacement de l'antique BIOS, auquel de nombreuses additions ont été apportées. En particulier, UEFI est extensible, comme son nom l'indique : Unified Extensible Firmware Interface.

Le rôle de Secure Boot est de vérifier l'authenticité de tout code pouvant s'exécuter dans le cadre du mode privilégié d’UEFI. On parle alors de « démarrage vérifié » (verified boot). Parmi les éléments vérifiés, on peut citer, par exemple, certaines mises à jour UEFI, les différents pilotes pour des périphériques pouvant être mis en œuvre dans le cadre d'UEFI, mais aussi le chargeur de démarrage (boot loader), ou le noyau du système d'exploitation. Une fois le noyau lancé, il est en charge de quitter le mode privilégié d’UEFI, mettant fin au périmètre de responsabilité de Secure Boot. Le noyau, dont l’authenticité a été vérifiée, peut prolonger ou non cette sécurité au reste du système d'exploitation.

1. Le démarrage vérifié : comment ça marche ?

La figure 1 fournit une vue synthétique de l’ensemble des éléments de la chaîne d’un démarrage vérifié abordés dans cette section.

Fig. 1 : Représentation synthétique des éléments impliqués dans la vérification de la chaîne de démarrage évoqués dans l’article. Dans cette illustration, le chargeur de démarrage vérifie le noyau grâce à une clé GnuPG ajoutée à la compilation. C’est le mode opératoire de GRUB2, mais il en existe d’autres.

1.1 Secure Boot

Secure Boot fonctionne à l'aide d'une validation cryptographique du code avant son exécution. Cette vérification s'effectue grâce à du matériel cryptographique contenu dans des bases de données. La première, appelée sobrement « db », contient :

des condensats cryptographiques du code autorisé, qui sont simplement comparés au condensat du code candidat à l'exécution ;
des certificats contenant des clés publiques utilisées afin de contrôler des signatures cryptographiques du code candidat à l'exécution.

La seconde, appelée « dbx », contient le matériel permettant la révocation de signatures ou de clés, afin de prévenir l'exécution de certains programmes. Cette base sert notamment pour prévenir l'exécution de code vulnérable dans des programmes authentiques.

Ces bases de données sont protégées en intégrité par une signature cryptographique, vérifiable grâce à une clé nommée KEK (Key Exchange Key). La KEK est, à son tour, signée par une clé nommée PK (Platform Key).

L'existence de ces différentes clés permet une séparation des responsabilités et des privilèges. La clé privée associée à la PK est mise en œuvre par le constructeur du matériel. La plupart des constructeurs signent la KEK de Microsoft, par défaut. Microsoft signe alors des bases de données contenant notamment les certificats permettant la vérification de Windows, et un certificat « tierces parties » pour les autres exécutables autorisés. Celui-ci permet de vérifier notamment un programme appelé « shim », qui permet de lancer Linux lorsque Secure Boot est activé.

Il convient de noter que certains constructeurs permettent de remplacer la PK et la KEK. Cette opération permet, à son tour, le remplacement du contenu des bases de données db et dbx, et ainsi de définir ses propres règles de validation de ce qui est autorisé à être exécuté dans le mode privilégié d'UEFI. Ce remplacement des clés PK et KEK n'est cependant recommandé par l'ANSSI qu'à partir des systèmes requérant un niveau de sécurité élevé (le niveau maximum présenté dans leur guide).

1.2 Shim

Shim est un programme initialement développé par Red Hat et dont des dérivés sont maintenus par plusieurs distributions Linux. Ces différentes versions de shim sont signées par Microsoft, et servent de pivot de confiance entre Microsoft et les distributions Linux. En effet, le rôle de shim est un peu celui d'un cheval de Troie. Une fois vérifié par Secure Boot et exécuté, il est en charge de lancer d'autres programmes qui ne sont pas validés par Secure Boot. Généralement, il exécute un chargeur de démarrage (boot loader), comme Grub, qui lui-même lancera le noyau Linux de la distribution. Shim permet ainsi aux distributions d'avoir une certaine liberté d'action sur le chargeur de démarrage et sur leur noyau, sans avoir à demander une revalidation et une nouvelle signature par Microsoft à chaque fois.

Shim peut vérifier l'authenticité des exécutables qu'il lance, grâce à des clés publiques spécifiées lors de sa compilation et grâce à des bases de données fonctionnellement très semblables à celles de Secure Boot (nommées MokList et MokListX). Par défaut, ces bases de données sont vides, et seuls les exécutables signés par les clés publiques spécifiées lors de la compilation sont utilisés.

Le guide de l'ANSSI ne donne aucune recommandation vis-à-vis de shim.

1.3 Intel Boot Guard et AMD PSB

Secure Boot est implémenté par le logiciel embarqué (firmware) du constructeur. Il est donc possible de compromettre son intégrité à l'aune d'une mise à jour de ce logiciel embarqué.

Ces mises à jour s'effectuent dans le cadre du mode privilégié d'UEFI. Certaines sont donc signées par Microsoft de manière à pouvoir être validées par Secure Boot avant d'être lancées. D'autres nécessitent la désactivation de Secure Boot, faute d'être vérifiables par les éléments cryptographiques contenus dans les bases de données de Secure Boot.

Lorsque Secure Boot est désactivé, n'importe quel code peut être exécuté dans le mode privilégié, ce qui peut résulter en la compromission à long terme de la fiabilité de Secure Boot. En effet, une mise à jour frauduleuse pourrait altérer le logiciel embarqué pour mentir et indiquer que Secure Boot est implémenté et activé, tout en permettant d'exécuter n'importe quel logiciel de l'attaquant.

Afin de prévenir ce type de compromission à long terme, Secure Boot a été amélioré grâce à des mécanismes matériels complémentaires. Ces mécanismes permettent de ne plus avoir besoin de faire confiance en l'intégrité logicielle de l'implémentation de Secure Boot. En effet, l'authenticité du logiciel embarqué est vérifiée avant qu'il ne soit lancé, et l'origine de la confiance est ainsi déplacée dans le matériel. Le matériel ne pouvant être altéré que par un attaquant ayant un accès physique à la machine, bon nombre d'attaques sont ainsi prévenues, et celles résiduelles demandent des compétences accrues.

Ces mécanismes matériels sont implémentés notamment par Intel avec Boot Guard [2] et par AMD avec PSB (Platform Secure Boot). Le détail de ces technologies est hors du champ de cet article et leur spectre est suffisamment large pour mériter des articles complets pour les traiter.

2. Problèmes de sécurité

Bien que Secure Boot soit une fonctionnalité de sécurité intéressante, il convient d'en comprendre les limitations, qui sont nombreuses. D'aucuns, dont l'auteur de cet article, pourraient même considérer que ces limitations sont tellement significatives que l’utilisation de Secure Boot devrait être considérée comme un objectif très optionnel pour les administrateurs et administratrices déjà bien occupés. Cette section énumère certaines de ces limitations.

2.1 Surface d'attaque des exécutables vérifiables

Par défaut, la plupart des constructeurs utilisent la KEK de Microsoft pour vérifier les bases de données db et dbx. Microsoft dispose d'une procédure permettant, sous certaines conditions, de demander la signature d'un programme par leur autorité de certification des tierces parties [3].

Cette autorité de certification signe de nombreux exécutables, dont les différentes variantes de shim, mais aussi différents pilotes et autres « option ROM » nécessaires pour initialiser des équipements utilisables par le logiciel embarqué. Avec chaque signature supplémentaire, la surface d'attaque du code authentique et vérifié par Secure Boot s'agrandit. Avec l'accroissement de la surface d'attaque, le risque de vulnérabilités grandit lui aussi. Si une vulnérabilité de type exécution de code arbitraire affecte un programme vérifié par Secure Boot, un attaquant pourra malgré tout exécuter du code non vérifié.

Comme l'on peut s'y attendre, plusieurs exécutables se sont déjà révélés vulnérables par le passé. On peut notamment citer la vulnérabilité BootHole de GRUB2 [4]. Cette vulnérabilité a d'ailleurs été à l'origine de réflexions sur le système de révocation de Secure Boot. En effet, il semblait trop lourd de révoquer l'autorité de certification de Microsoft, compte tenu de la masse de signatures qu'il aurait fallu réémettre. Simultanément, la liste des condensats cryptographiques des programmes vulnérables et à révoquer était si longue qu'elle a montré qu'il serait assez aisé d'atteindre la taille maximale de la base de données dbx, celle-ci étant déjà pleine à 50 %, dont 30 % sont attribuables uniquement à BootHole. Des réflexions sont en cours pour améliorer la situation au niveau de shim [5].

En outre, plusieurs versions de logiciels vulnérables et signés par Microsoft n'ont jamais été révoquées [6][7], compte tenu des conséquences de ces révocations sur l'écosystème, tant au niveau de la taille de base de révocations que sur la perte de fonctionnalité des utilisateurs qui verraient soudainement leur système cesser de fonctionner.

En l'absence d'un système de révocation réellement utilisé, efficace, et dont la base de révocation est régulièrement mise à jour sur toutes les machines protégées par Secure Boot, et en présence d'une surface d'attaque toujours plus grande, il semble que les garanties offertes par Secure Boot avec les autorités de certification autorisées par la KEK de Microsoft soient maigres.

Malgré cela, l'ANSSI ne recommande de remplacer la KEK que pour les systèmes de niveau de sécurité élevé.

2.2 Sécurité de la configuration UEFI

Pour que Secure Boot soit employé, il doit être activé dans la console d'administration d'UEFI. Toute personne ayant un accès physique en console ou via une carte d'administration à distance (iDrac, iLo ou autre) peut désactiver Secure Boot et autoriser n'importe quel logiciel à s'exécuter. Pour contrecarrer ce risque, il est indispensable de protéger la console d'administration UEFI avec un mécanisme d'authentification (généralement un mot de passe).

L'ANSSI adresse bien une recommandation dans ce sens dans son guide de recommandations pour Linux, par l'intermédiaire d'un renvoi au guide sur la sécurité du BIOS.

2.3 Shim

Chaque distribution compile sa propre version de shim, dans laquelle est intégrée une clé publique spécifique à chacune d'elles. Ces clés publiques signent les éléments spécifiques de la chaîne de démarrage de ces distributions.

Les administrateurs recompilant leur noyau, ou souhaitant utiliser un autre chargeur de démarrage (p. ex. systemd-boot) ne peuvent cependant pas utiliser les clés privées des distributions pour ce faire. Ils peuvent alors :

désactiver Secure Boot et ainsi lancer les exécutables et noyaux de leur choix (et ceux du choix de tout attaquant pouvant altérer le système de fichiers utilisé par UEFI) ;
remplacer les clés publiques PK et KEK de Secure Boot ;
enregistrer leurs propres clés dans shim.

Pour enregistrer leurs propres clés dans shim, les administrateurs ne peuvent pas recompiler cet exécutable en y insérant leurs clés, comme le font les distributions Linux. En effet, il faudrait alors faire signer par Microsoft cette variante, différente de celles des distributions, après avoir reçu l'approbation du comité d'approbation de shim [8].

À la place, shim dispose de bases de données similaires, mais distinctes à db et dbx de Secure Boot. Ce mécanisme de bases de données est appelé MOK (Machine Owner Keys) et il sert à enregistrer les clés publiques sous le contrôle des administrateurs système d'une machine. Ces bases de données sont stockées dans des variables UEFI et sont modifiables qu’à l’aide d’un utilitaire appelé MOKManager, qui est lui aussi signé par Microsoft.

Pour enregistrer une nouvelle clé publique avec MOKManager, il faut d'abord initier une demande, depuis un système d'exploitation, par exemple à l'aide de l'utilitaire mokutil. Lors de l'exécution de mokutil, il est demandé à l'utilisateur de saisir un mot de passe. Ce mot de passe n'est pas utilisé dans l'objectif d'un contrôle d'accès. Il a juste besoin d'être connu de l'utilisateur pour l'étape suivante du processus d'enregistrement. Une fois mokutil appelé, et un mot de passe saisi, l'utilisateur redémarre la machine.

Lors du démarrage, shim détecte l'appel à mokutil et lance MOKManager. MOKManager demande alors à l'utilisateur en console (soit en console physique, soit en console via une carte d'administration à distance) de confirmer l'opération. Il demande également de prouver son intention d'effectuer cette modification en démontrant la connaissance du mot de passe saisi dans l'étape précédente, lors de l'appel à mokutil. La machine est alors redémarrée afin que soient prises en compte les modifications aux bases de données MOK.

Cette procédure n'a requis aucune authentification, le mot de passe ne servant qu'à confirmer l'intention de l'utilisateur. Sans cette confirmation, il serait impossible de vérifier si la demande provient d’un utilisateur ou d'un programme compromis du système d'exploitation.

Outre l'enregistrement de clés par n'importe quel utilisateur capable de se connecter au système d'exploitation et de prouver son intention en console, MOKManager permet également de désactiver totalement la vérification de signature effectuée par shim ! Si cette configuration est appliquée, toujours sans contrôle d'accès, alors Secure Boot ne sert à rien, puisque l'authenticité de shim sera bien vérifiée par Secure Boot, mais ce dernier acceptera de lancer n'importe quel programme non signé !

Il convient de noter qu'il existe bien la possibilité d'implémenter un contrôle d'accès par mot de passe pour lancer MOKManager, mais aucune distribution ne l'active, aucun tutoriel ne semble l'évoquer, pas plus que le guide de recommandations de l'ANSSI.

Pour les lecteurs intéressés, la commande à saisir est mokutil --password. Il faut alors redémarrer la machine et confirmer la définition d'un contrôle d'accès. De manière peu intuitive, cette recommandation est d’intérêt également pour les administrateurs de machines sous Windows, si le certificat « tierces parties » de Microsoft est dans la db.

Également, il convient de considérer tous les noyaux Linux dont la signature est vérifiable par les clés publiques compilées dans n'importe quel shim de n'importe quelle distribution, et qui ont été signés par l'autorité de certification de Microsoft. Ces noyaux doivent être ajoutés à la surface d'attaque, à moins qu'ils n'aient été ajoutés dans la base de données de shim des objets dont la signature a été révoquée. Cette liste est vide, par défaut.

Un attaquant cherchant à attaquer un système protégé par Secure Boot et shim peut alors remplacer le shim, le chargeur de démarrage et le noyau à jour de l'administrateur système par des alternatives signées, mais datées et contenant une vulnérabilité qu'il sait exploiter et permettant l'exécution de code arbitraire en espace noyau. Cet attaquant est alors en mesure de contourner la vérification de sécurité pourtant bien effectuée par Secure Boot.

2.4 Secure Boot n'est qu'un maillon

La responsabilité de Secure Boot est de s'assurer que seul du code signé et vérifié est exécuté. Il est de la responsabilité du système d'exploitation de prolonger ou non cette vérification d'intégrité des programmes exécutés. La racine de la confiance du système d'exploitation est le noyau, qui a été vérifié par Secure Boot lors des précédentes étapes du démarrage.

Le noyau, dans le cas de Linux, peut prolonger ces vérifications d'intégrité aux applications de l'espace utilisateur. Ces vérifications peuvent prendre plusieurs formes. Les plus connues sont dm-verity, fs-verity et Linux IMA (Integrity Measurement Architecture).

dm-verity, par exemple, permet de s'assurer de l'intégrité cryptographique d'un périphérique de blocs (p. ex. un disque dur). Le périphérique ainsi protégé est en lecture seule et de surcroît, chaque tentative d'accès à un bloc est interceptée et son intégrité est vérifiée avant d'être utilisable par le noyau ou les applicatifs de l'espace utilisateur.

fs-verity effectue le même type de vérification, mais à l'échelle du système de fichiers. Cette protection requiert un support spécifique de la part du système de fichiers, qui est loin d'être universel. Néanmoins, ext4 et f2fs le prennent en charge, ce qui convient à de nombreux cas d'usages classiques. fs-verity donne l'avantage d'être plus fin que dm-verity, en permettant de protéger seulement les fichiers sensibles. Hélas, il convient de lui ajouter quelques béquilles, comme l'usage d'un HIDS (Host-based Intrusion Detection System) comme Aide, afin de prévenir des substitutions de fichiers. En effet, fs-verity assure l'intégrité au sein d'un fichier, mais ne protège en rien contre la suppression d'un fichier, et son remplacement par un fichier différent. Il existe néanmoins un mécanisme de vérification par signature cryptographique, pour contrer certains risques liés à ces substitutions arbitraires.

Linux IMA permet également d'assurer une intégrité au niveau des fichiers, en comparant leur contenu lors d'une lecture à un condensat cryptographique stocké en métadonnées du fichier. Son mécanisme est très comparable et pourtant subtilement différent à ce que fs-verity offre. Ces distinctions sont néanmoins hors champ de cet article.

Aucune distribution Linux grand public, à l'exception de systèmes d'exploitation dérivés comme Chrome OS et Android, n'utilise à ce jour ces technologies. En conséquence, un attaquant ayant accès au système de fichiers d'une machine, par exemple par l'extraction des disques durs ou en démarrant sur un système d'exploitation alternatif, peut parfaitement remplacer n'importe quel utilitaire ou même le disque d'initialisation initramfs et les options passées au noyau par le chargeur de démarrage. La protection offerte par Secure Boot aura donc servi à protéger les premières phases du démarrage. Hélas, la chaine de confiance est généralement brisée par l'utilisation qui est faite de Linux, celle-ci ne se prolongeant pas à l'espace utilisateur.

Dans ces conditions, l'intérêt réel de Secure Boot est assez discutable. Certes, le noyau est intègre et peut mettre en œuvre des mesures de protection comme des LSM (Linux Security Modules). Néanmoins, avec un espace utilisateur pouvant être totalement compromis, il devient intéressant de se questionner sur la pertinence et l’effectivité de ces protections.

3. TPM

Jusqu'alors, cet article a discuté de la notion de démarrage vérifié (verified boot), et de ses limites. Il convient de noter que ce n'est cependant pas l'unique manière de protéger le démarrage. Il existe, en effet, une autre manière de protéger cette étape : le démarrage contrôlé (measured boot).

Le démarrage contrôlé s'effectue à l'aide d'un TPM (Trusted Platform Module). Le TPM est un composant cryptographique physique (on dit qu'il est discret) ou logiciel (p. ex. vTPM, Intel PTT (Platform Trust Technology)).

Un des objectifs d'un TPM est de prouver à une tierce partie que la machine est dans un état connu comme étant sûr. Cette preuve se fait souvent par la capacité à démontrer la connaissance d'un secret (p. ex. une clé cryptographique). Pour accomplir cet objectif, le TPM dispose de registres, et de mécanismes permettant de déchiffrer ou de signer des données si ces registres sont à des valeurs spécifiques.

Ces registres sont alimentés tout au long de la procédure de démarrage d'une machine, avec des données directement liées aux programmes exécutés et aux fichiers de configuration utilisés [9]. Chaque programme est responsable d’alimenter les registres avec les informations des fichiers qu’il va utiliser ou des programmes qu’il va lancer. Si le moindre élément a été modifié par un attaquant, la valeur ajoutée au registre n’est pas celle attendue. Ainsi, lors du contrôle de la valeur des registres pour savoir si un déchiffrement de données est autorisé, le TPM pourra détecter la modification du système et prévenir le déchiffrement. Le système ne sera alors pas capable d'obtenir le secret et de prouver son intégrité à une tierce partie.

Il s'agit bien sûr ici d'un résumé simplifié du mode opératoire d'un TPM et des protocoles d'attestation à distance de l'intégrité d'un système, mais les grandes lignes sont là.

Contrairement à Secure Boot, le démarrage contrôlé ne prévient aucunement l'exécution de code arbitraire par un attaquant. En revanche, il permet de prouver à un tiers que le système est intègre, depuis les composants UEFI impliqués dans le démarrage, en passant par le chargeur de démarrage, le noyau, et éventuellement tous les éléments ajoutés par le noyau et l'espace utilisateur pour prouver leur intégrité (p. ex. la racine de l'arbre de Merkle d'un disque, fournie par dm-verity).

L'emploi d'un TPM n'est cependant pas la panacée, car il existe de nombreuses attaques à considérer, notamment si le TPM n'est pas local à la machine qui l'emploie, ou si des TPM virtuels comme Intel PTT sont utilisés, car leur sécurité est moindre et en l'absence de Secure Boot, ils pourraient être altérés.

Néanmoins, dans le cas d'un TPM physique (discret) et local, un TPM pourrait être raisonnablement utilisé pour offrir un démarrage sécurisé, intègre, indépendamment de l'usage ou non de Secure Boot. Pour une sécurité maximale, Secure Boot et TPM peuvent être utilisés conjointement.

Conclusion

Dans cet article, nous avons dressé un portrait de Secure Boot et de ses limitations. Au vu de ces dernières, il apparaît que l'emploi de Secure Boot de manière sécurisée est complexe, et que l’usage des clés de Microsoft ouvre la porte à un écosystème à la surface d'attaque gigantesque, contenant encore des exécutables vulnérables, et dont le système de révocation est fragile.

Nous avons également touché du doigt les problèmes liés à l'utilisation de shim/MOKManager sans mot de passe pour effectuer des contrôles d'accès. En l'absence de ces contrôles, ce qui est le cas par défaut, et même avec Secure Boot activé, l'intégrité du démarrage ne peut être assurée contre un attaquant capable d'interagir avec la console que ce soit en étant physiquement présent, ou via une carte d'administration à distance.

Enfin, nous avons vu que l'emploi de Secure Boot sans prolonger les protections en intégrité au système d'exploitation n'apporte qu'une illusion de sécurité, sans réellement protéger les utilisateurs et leurs données.

Pour finir, nous avons évoqué une mesure substitutive ou complémentaire au démarrage vérifié (verified boot) offert par Secure Boot, grâce à l'emploi du démarrage contrôlé (measured boot), avec un TPM.

À la lumière de ces informations, le guide de l'ANSSI « Recommandations de configuration d'un système GNU/Linux » dans sa deuxième version, publiée le 3 octobre 2022 [1], semble incohérent. En effet, l'activation de Secure Boot est recommandée pour les systèmes de niveau intermédiaire, ou plus. Cependant le remplacement des clés n'est qu'une considération à partir du niveau élevé, laissant les systèmes de niveau inférieur exposés à un écosystème dangereux. De surcroît, aucun avertissement n'est donné quant au manque de contrôle d'accès à shim/MOKManager par défaut. Enfin, l’usage d’un TPM est simplement évoqué sans faire l'objet d'aucune recommandation. En l'état, la recommandation du guide de l'ANSSI d’activer Secure Boot pour tous les systèmes de niveau de sécurité intermédiaire et renforcé cause donc une charge de travail supplémentaire pour les administrateurs et administratrices voulant se mettre en conformité, sans apporter de sécurité réelle et mesurable du point de vue de l’espace utilisateur du système d’exploitation.