Secure Boot, UEFI et BIOS : comment votre PC démarre (et se protège) vraiment

Pour comprendre pourquoi, il faut remonter un peu et comprendre ce qu'il se passe exactement quand on appuie sur le bouton "Power" (et démêler quelques concepts un peu obscurs).

La chaîne de démarrage: firmware, bootloader, kernel, OS

Quand on appuie sur le bouton power, le PC s'allume (en général), mais qu'est-ce qu'il se passe exactement à ce moment-là ?

Pour faire simple, au démarrage de la machine, on peut résumer comme suit :

• L'électricité est envoyée au CPU,
• Le CPU démarre le firmware (UEFI / BIOS)
• Le firmware démarre le bootloader
• Le bootloader démarre l'OS (Windows/Linux/...) 
  

Revenons un peu sur ces termes :

• Le firmware: c'est un logiciel intégré directement sur la puce de la carte mère. C'est le premier code qui s'exécute.
• Le bootloader (comme GRUB ou Windows Boot Manager): c'est un bout de code qui fait le lien entre le firmware et l'OS. C'est lui qui sait où trouver le système d'exploitation sur le disque et qui le lance.
• L'OS (système d'exploitation): Linux, Windows, MacOS, … C'est ce qu'on a l'habitude de voir tous les jours (et l'origine de nombreux conflits chez les devs).

Ce qu'il faut comprendre, c'est que quand le CPU démarre, il commence toujours à la même adresse mémoire hardcodée dans le CPU lui-même. Cette adresse pointe vers un espace précis d'une puce de la carte mère (la puce flash SPI), là où est stocké le code de l'UEFI/BIOS. Voilà pourquoi c'est toujours lui le premier à prendre la main.

BIOS et UEFI: une évolution de trente ans

Le BIOS

Le BIOS (Basic Input/Output System) est le firmware historique des PC, apparu dans les années 1980. Conçu en 16 bits, stocké directement sur une ROM (Read Only Memory), il y avait plusieurs limitations sérieuses mais surtout un démarrage lent et aucune vérification de sécurité !

Son mécanisme de démarrage était extremement basique: Le BIOS lit simplement le tout premier secteur du disque dur, et exécute le code qu'il y trouve. Pas compliqué non ? Mais pas vraiment sécurisé..

Pour être précis, le "premier secteur du disque dur" est aussi appelé le MBR (pour Master Boot Record). Le problème, c'est qu'avec le BIOS, il n'y a aucun check de sécurité, aucune signature, aucun contrôle d'intégrité. Si un malware se glisse dans ce secteur, le BIOS le lancera ad vitam eternam à chaque démarrage. C'est ce qu'on appelle un bootkits (ex: Mebroot (découvert en 2007) ou TDL-4 (dans les années 2010)). 

L'UEFI

L'UEFI (Unified Extensible Firmware Interface) est la nouvelle génération, en 32 ou 64 bits, qui devient un standard en 2006. Mais c'est vraiment avec Windows 8 en 2012 et l'introduction obligatoire du Secure Boot que son adoption devient massive.

L'UEFI apporte avec lui trois éléments essentiels:

• Une interface graphique dans le setup du firmware (on peut cliquer avec la souris !)
• Le support du format GPT (GUID Partition Table), qui remplace le MBR et qui va nous permettre de sécuriser le démarrage
• Une architecture modulaire découpée en plusieurs phases

Ces phases UEFI s'enchaînent à chaque démarrage:

• SEC (Security): Initialise le CPU, vérifie l'intégrité du firmware (UEFI/BIOS)
• PEI (Pre-EFI Initialization): Initialise les bases du système (RAM, chipset)
• DXE (Driver Execution Environment): Phase principale: charge les drivers UEFI, gère les périphériques
• BDS (Boot Device Selection): Choisit quel périphérique booter (clé USB, disque, etc..) 
  

Le Secure Boot: une chaîne de confiance

Le problème que ça résout

Les bootkits du temps du BIOS étaient très efficaces puisqu'il n'existait aucun mécanisme pour vérifier que le code exécuté au démarrage était légitime. L'UEFI (poussé par Windows) a permi d'introduire une réponse directe: le Secure Boot.

Le principe est simple, chaque programme lancé au démarrage doit être signé numériquement avec une clé reconnue par l'UEFI. Si ce n'est pas le cas, le démarrage est bloqué !

Le système de clés

Le Secure Boot repose sur une hiérarchie de clés, installées par le constructeur dans le firmware (donc dans la puce sur la carte mère):

• PK (Platform Key): la clé maîtresse, contrôle toute la plateforme
• KEK (Key Exchange Key): clés intermédiaires, souvent celles du constructeur et de Microsoft (on y reviendra après)
• db: la liste blanche (les binaires ou clés autorisés à démarrer)
• dbx: la liste noire (les binaires révoqués) 
  

Sur la quasi-totalité des PC du marché, on retrouve le KEK du constructeur (normal) mais aussi très, très, très souvent (pour ne pas dire toujours) le KEK de Microsoft. C'est assez pratique pour Microsoft mais cela signifie aussi qu'une vulnérabilité dans un binaire signé par Microsoft peut potentiellement impacter des centaines de millions de machines.

Et Linux dans tout ça ?

C'est là que la situation devient intéressante. Comment Linux peut-il se lancer alors que le Secure Boot est actif si le constructeur n'a pas signé Linux ? Est-ce que Microsoft signe Linux et partage ça dans sa KEK ?

Et bien non, Linux n'est pas signé directement par les clés Microsoft. Les systèmes d'exploitations Linux sont souvent lancés par un bootloader connu appelé GRUB. Mais la signature de GRUB ne se trouve pas dans la db, il ne peut donc pas être autorisé par le firmware (ce serait trop compliqué, GRUB est décliné en plusieurs versions custom selon les distributions Linux, il serait impossible de maintenir toutes les signatures à jour).

Alors comment Ubuntu, Debian ou Fedora démarrent-ils sur une machine avec Secure Boot activé ? Et qu'est-ce que Windows a à voir avec Linux ?

Shim: le messager signé par Microsoft

La solution s'appelle shim. C'est un petit bootloader intermédiaire, signé par Microsoft, dont le seul rôle est d'établir un pont de confiance entre l'UEFI et le monde Linux.

La chaîne de confiance complète ressemble à ça :

• UEFI firmware: il vérifie shim (signé Microsoft)
• shim: il vérifie GRUB (et lui précise que le Secure Boot est actif)
• GRUB: active des restrictions (pour plus de sécurité) et vérifie l'OS (ici Linux)

Voilà pourquoi il y a "du Windows dans chaque Linux": le système démarre grâce à un programme qui porte la signature de Microsoft.

MOK: reprendre le contrôle

Mais que faire si on souhaite charger notre propre kernel compilé, ou des modules non signés ? Si vous avez déjà eu affaire à HackBGRT, vous voyez sûrement de quoi je veux parler.

En fait, on ne peut pas facilement modifier la db du firmware, c'est une zone reservée au constructeur.

C'est pour ça qu'il existe la MOK (Machine Owner Key). C'est un système parallèle, contrôlé par l'utilisateur, qui permet d'ajouter nos propres clés pour autoriser nos propres binaires. 

Et voici une petite image de l'attrayante interface de MOK: 

Est-ce que le Secure Boot rend vraiment invulnérable ?

Pas vraiment. On peut noter deux malware assez connus :

• BootHole (2020): une vulnérabilité découverte dans GRUB2 permettait à un attaquant d'injecter du code malveillant en passant par un ancien bootloader valablement signé mais vulnérable. Le Secure Boot ne bloquait rien, car la signature était techniquement valide.
• LoJax (2018): ce malware ne s'attaquait pas au bootloader, mais directement à la puce flash SPI contenant le firmware UEFI. En écrivant dans cette puce, les attaquants persistaient à un niveau inférieur à tout ce que le Secure Boot peut protéger, avant même que la chaîne de confiance ne commence.

Le Secure Boot protège dans le périmètre de la chaîne de confiance. Tout ce qui est en dessous (la puce firmware) ou qui contourne cette chaîne (une signature valide mais vulnérable) reste un vecteur d'attaque.

Secure Boot : une protection solide, mais pas absolue

Le Secure Boot est une réponse directe aux bootkits inarrêtables à l'époque du BIOS. En imposant une chaîne de confiance signée cryptographiquement, le Secure Boot garantit que chaque maillon du démarrage (du firmware à l'OS) est légitime

Pour Linux, cette chaîne passe par shim, un bootloader intermédiaire signé par Microsoft. En fait, c'est une contrainte pratique car les PC du marché font confiance aux clés Microsoft, et shim est le pont qui permet à Linux de s'y intégrer sans que chaque distribution ait à négocier sa propre signature.

Le système n'est pas parfait. Si une clé est révoquée trop tard, si un firmware est directement compromis, alors la chaîne peut être contournée. Ceci dit, comparé au BIOS (qui exécutait aveuglément ce qu'il trouvait sur le disque), l'UEFI avec Secure Boot reste une avancée de sécurité importante !