1. Pourquoi cet article
La sécurité de nos ordinateurs c’est un peu amélioré si on sait ce qu’on fait avec. Avant pour démarrer votre OS le BIOS utilisait un MBR Master Boot Record présent dans le premier secteur de votre disque-dur. Ce MBR pouvait être écrasé par n’importe quel programme ayant accès au MBR, en général il faut être root sous linux pour installer un nouveau MBR. Donc malware ou virus disposant des droits d’administration pouvait s’installer en tant que MBR gagnant ainsi en persistance. Autre attaque possible est tout simplement un media USB qui démarre et écrase le MBR par un programme malveillant. Une fois votre machine redémarrer pas de possibilité de contrôler quel boot loader a été exécuté par votre BIOS. Et ça là qu’entre en jeux SecureBoot introduit dans les machines disposant de firmware UEFI.
J’ai trouvé des articles (exemple) parlant de sécurité d’OS avec la mise en place de chiffrement de disque complet, ou de partition avec LUKS sur LVM. C’est une bonne chose de mettre en place ce genre solution surtout sur des ordinateurs portables. Problème ces articles ne parle pas de la sécurité de la machine dans son ensemble et prennent quelques raccourcis sur les bénéfices de chiffrer par exemple la partition /boot de votre linux.
Chiffrer votre partition de boot :
- NE VOUS PROTÈGE PAS DES ATTAQUES SUR LE BOOTLOADER ( écrasement du boot loader par un keylogger par exemple)
- IL NE MASQUE PAS VRAIMENT l’OS QUE VOUS UTILISEZ pour la simple et bonne raison que si votre boot loader est GRUB il y a de grande chance que ce soit du Linux derrière et uniquement avec le hash de votre bootloader on pourra identifier quel distribution vous utilisez et quel version.
Dans la pratique si on peut compromettre la chaîne de démarrage en amont de l’outil qui va déchiffrer/démarrer l’OS, vous ne pouvez quasiment rien faire contre les attaques dont vous êtes la cible. Cela vous protège au moins contre le vol physique de votre machine si vous avez une passphrase suffisamment longue.
2. Comment ça marche
SecureBoot fonctionne à l’aide de certificats X509 comme une PKI. Votre UEFI contient des clés publiques/certificats. Les chargeurs/loader/bootloader au format efi sont signés avec les clés privés correspondantes. Quand votre ordinateur démarre l’UEFI se charge de vérifier que le bootloader suivant est bien signé avec une clé publique présente dans la DB.
SecureBoot fonctionne avec 4 types de clés.
PK Platform Key sert à gérer les mise à jours de la clé KEK, c’est la clé maîtresse. En général elle est pré-configuré avec une clé fournit par le fabricant de carte mère.
KEK Key Exchange Key sert à gérer les mise à jours des clés suivantes. Peut en contenir plusieurs dont celle de Microsoft qui permet de mettre à jour les autres clés via un processus de MAJ automatique. Les clés qui sont ici vous permettent de mettre à jour la DB et la DBX.
DB contient les clés publiques de confiance. Pré-chargé avec celles de Microsoft par défaut sur la majorité des PC. C’est cette base de données qui va vérifier les signatures des bootloaders.
DBX c’est la liste noire pour les clés publiques que l’on veut blacklister.
MOK c’est la même chose que la DB sauf que ce n’est pas standard donc pas gérer/implémenté par votre UEFI mais par Shim et donc stocké dans une variable UEFI.
3. Activer SecureBoot la méthode simple
Vous avez peut-être sans le savoir, déjà SecureBoot d’activé sur votre machine. Vous pouvez vérifier avec la commande bootctl status --path /boot/efi
.
3.1. Activer Secure Boot
- Une installation qui démarre avec UEFI est un pré-requis.
- Vous pouvez normalement installer Ubuntu et dérivé avec SecureBoot d’activé cela devrait se charger de tout configurer automatiquement. ( Sous LinuxMint il demande de désactiver SecureBoot mais vous pouvez répondre non)
- Sinon vous pouvez vérifier que vous avez les paquets
shim-signed grub-efi-amd64-signed
d’installés à l’aide de la commandeapt search signed | grep ^i
, installer ces paquets permet utiliser les clés de Microsoft pré-installés dans votre BIOS pour démarrer avec SecureBoot. - Une distribution qui dispose du loader Shim signé avec la clé de Microsoft Partner’s. Normalement c’est le cas pour Ubuntu, LinuxMint, OpenSuse et généralement les distributions connexe. Si c’est le cas vous devriez avoir shimx64.efi dans le répertoire
/boot/efi/EFI/ubuntu/
. Vous pouvez vérifier qu’il est signé avec la clé de Microsoft :wget https://sourceforge.net/p/refind/code/ci/master/tree/keys/microsoft-uefica-public.der?format=raw -O microsoft-uefica-public.der openssl x509 -in microsoft-uefica-public.der -inform der -out microsoft-uefica-public.crt sudo sbverify --cert microsoft-uefica-public.crt /boot/efi/EFI/BOOT/BOOTX64.EFI sudo sbverify --cert microsoft-uefica-public.crt /boot/efi/EFI/ubuntu/shimx64.EFI
- Une fois shim-signed installé et que vous avez vérifié ça signature, vous pouvez redémarrer
sudo systemctl reboot --firmware
pour activer SecureBoot dans votre UEFI. - Une fois Secure Boot activer dans votre UEFI/BIOS il devrait réussir à démarrer sur votre Linux sans problème.
3.2. MOK
Maintenant vous avez normalement SecureBoot d’activé. Cependant il se peut que vous utilisiez des drivers qui ne sont pas encore signés par des clés de confiances. Pour cela vous allez devoir utiliser MOK. Machine Owner Key est une juste une ou plusieurs clés que nous allons générer et utiliser pour signer les drivers. Pour cela vous allez devoir installer ou ré-installer les modules kernels qui doivent être signés. Ceci va normalement déclencher le processus d’inscription d’une clé MOK qui va être ajouter dans la chaîne de confiance de boot.
apt reinstall nvidia-dkms
Cette étape devrait demander un mot de passe qui vous sera redemander une seule et unique fois au redémarrage suivant.
Le processus est assez obscure mais le mot de passe donné sert à générer une demande d’inscription. Au prochain redémarrage Shim va voir qu’il y a une demande en attente et va lancer MokManager. Votre UEFI étant encore dans un état de pré-boot il peut enregistrer des variables de boot signées dans la NVRAM de votre UEFI. MokManager va allors confirmer que c’est bien vous qui avez déclenché l’inscription et va vous demandez de confirmer avec le mot de passe l’inscription de la clé dans la base de donnée MOK qui est enregistré dans la NVRAM. La base MOK est stocké dans une variable « Boot Services Only Variables », et ne peut pas être édité une fois que Shim a lancé le bootloader suivant.
Pour résumer:
- Lancer
apt reinstall nvidia-dkms-390
et renseigner un mot de passe MOK. - Reboot
- Au redémarrage MokManager devrait se lancer
- Sélectionner Enroll MOK
- Il vous présente la clé à ajouter
- Confirmer avec le mot de passe
Sous Mint la clé MOK est généré dans /var/lib/shim-signed/mok/
au moment de l’installation même si SecureBoot n’est pas activé. Même comportement sur Ubuntu.
Vous pouvez générer une nouvelle clé MOK avec l’aide de update-secureboot-policy
. Autre point important les clés MOK ne sont PAS supprimés quand vous en importez une nouvelle donc il faut penser à faire le ménage à l’aide de mokutil
. Pensez à supprimer l’ancienne d’abord à l’aide de mokutil --delete MOK.der
. Supprimez ensuite manuellement les fichiers MOK.der et MOK.priv avant d’utiliser la commande update-secureboot-policy --new-key && update-secureboot-policy --enroll-key
. Vous devrez ensuite signer à nouveau vos drivers.
3.3. Les choses que vous DEVEZ faire avec SecureBoot activé
- Ajouter un mot de passe sur la configuration de votre UEFI. Cela empêchera un attaquant de réinitialiser les clés présente dans le UEFI et aussi de désactiver SecureBoot.
- Si possible désactiver dans votre UEFI toutes les entrées de démarrages autre que votre OS. Rend difficile le démarrage d’une attaque physique via une clé USB ou autre media amovible.
- Utiliser le chiffrement de disque pour /var au minimum car les clés MOK qui sont enroll n’ont pas de passphrase, CE QUI EST TRES CON. Je vous recommande de toute façon d’utiliser l’option LVM + LUKS à l’installation.
- Utiliser sudo ou le compte root avec attention.
3.4. Les choses que vous devez savoir quand vous utilisez cette méthode
Cela peut paraître con mais vous devez faire confiance à beaucoup de personne avec cette méthode.
Le fabricant de votre carte mère et de l’UEFI ainsi que le fabricant de votre CPU
Mise à part changer votre UEFI par une version libre (coreboot et seabios) et retirer I’Intel Management Engine vous n’avez pas trop le choix ici.
Microsoft
Votre UEFI à la clé principale de Microsoft pré-chargé donc n’importe quel bootloader signé par Microsoft peut toujours démarrer sur votre machine. Surtout que Microsoft a merdé plusieurs fois et certaines versions de bootmgr.efi permettent d’outrepassé les signatures. Ce problème peut-être palier par la méthode 2.
Verisign
La ça devient fun, oui votre UEFI vient généralement avec une deuxième clé qui est la clé « Microsoft for third-party applications and driver » cette clé sert pour signer les drivers qui se charge dans Windows ainsi que les ROM PXE par exemple. Cette clé est gérée par Verisign et de ce que j’ai lu n’importe qui peut demander à signer un programme pour la modique somme de 99$ donc LOL. C’est aussi la clé qui est utilisé pour signer Shim. Ce problème peut-être palier par la méthode 2 mais certain matériel dépende de cette clé pour fonctionner correctement.
Canonical
Sous LinuxMint et Ubuntu le loader Shim est signé par la clé « Microsoft for third-party applications and driver » et contient la clé de Canonical pour pouvoir vérifier la signature de Grub ainsi que du kernel. Si vous utilisez les dépots de Ubuntu ou dérivé vous faites déjà confiance…
Les logiciels que vous exécutez en root ou en temps que module kernel
Derniers maillon de la chaîne les drivers chargés par le kernel nécessite d’être signés. Ils sont compilés en tant que modules dkms au moment ou vous les installez. Ils seront alors signés par votre clé MOK. Toute la sécurité de la chaîne de démarrage peut-être compromise si un driver malveillant est signé avec votre clé MOK, il pourra alors lancer du code non-signé.
Et si vous êtes parano vous pouvez lire ça.
4. Activer SecureBoot la méthode compliqué
4.1. Générer ses propres clés
Générer nos clés à l’aide de openssl en utilisant le script suivant
<code>#!/bin/bash # Copyright (c) 2015 by Roderick W. Smith # Edited by Hugo P. Dec 2018 # Licensed under the terms of the GPL v3 apt-get install efitools openssl echo -n "Enter a Common Name to embed in the keys: " read NAME echo -n "Enter a password to protect the keys: " read PASSWORD openssl req -new -x509 -newkey rsa:2048 -passout pass:$PASSWORD -subj "/CN=$NAME PK/" -keyout PK.key \ -out PK.crt -days 3650 -sha256 openssl req -new -x509 -newkey rsa:2048 -passout pass:$PASSWORD -subj "/CN=$NAME KEK/" -keyout KEK.key \ -out KEK.crt -days 3650 -sha256 openssl req -new -x509 -newkey rsa:2048 -passout pass:$PASSWORD -subj "/CN=$NAME DB/" -keyout DB.key \ -out DB.crt -days 3650 -sha256 openssl x509 -in PK.crt -out PK.cer -outform DER openssl x509 -in KEK.crt -out KEK.cer -outform DER openssl x509 -in DB.crt -out DB.cer -outform DER GUID=`uuidgen` echo $GUID > myGUID.txt cert-to-efi-sig-list -g $GUID PK.crt PK.esl cert-to-efi-sig-list -g $GUID KEK.crt KEK.esl cert-to-efi-sig-list -g $GUID DB.crt DB.esl rm -f noPK.esl touch noPK.esl sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \ -k PK.key -c PK.crt PK PK.esl PK.auth sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \ -k PK.key -c PK.crt KEK KEK.esl KEK.auth sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \ -k KEK.key -c KEK.crt db DB.esl DB.auth # This file is dangerous and must be kept in a safe place it can disable SecureBoot # sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \ # -k PK.key -c PK.crt PK noPK.esl noPK.auth chmod 0600 *.key echo "" echo "" echo "For use with KeyTool, copy the *.auth and *.esl files to a FAT USB" echo "flash drive or to your EFI System Partition (ESP)." echo "For use with most UEFIs' built-in key managers, copy the *.cer files." echo "" </code> |
4.2. Signer la chaine de démarrage
Signer les trucs que l’on a besoin pour booter avec (essentiellement shim et/ou grub)
sbsign --key DB.key --cert DB.crt --output /boot/efi/EFI/ubuntu/shimx64-signed.efi /boot/efi/EFI/ubuntu/shimx64.efi
4.3. Installer les clés via l’UEFI
Le plus simple est généralement de passer par le firmware de votre carte-mère pour aller installer vos certificats.
Aller dans votre uefi et trouver le menu pour configurer SecureBoot ci-dessous le menu de OVMF. (Dans mon environnement de virtualisation)
Vous devez passer votre SecureBoot en mode Setup pour effacer les anciens certificats et installer les vôtres.
Installer dans l’ordre la DB, le KEK puis en dernier le certificat PK qui devrait suivant votre firmware passer votre SecureBoot en position « User mode » qui veut dire verrouillé.
Normalement passé cette étape votre machine peut uniquement lancer des programmes signé par votre clé DB.
Pour configurer SecureBoot sur votre machine vous avez 3 autres manières de procéder :
- Utiliser Keytool.efi présent dans le package efitools (/usr/share/efitools/efi/) vous permez de manager vos clés sans passer par votre UEFI pratique si votre UEFI est merdique à souhait cependant il vous faudra obligatoirement trouver l’option pour passer en mode « Setup » pour pouvoir enregistrer votre PK.
- Utiliser Lockdown.efi cet outils est une solution si vous voulez automatiser le processus de Setup Secure Boot sur beaucoup de machine, il vous faudra compiler le bordel pour insérer vos clés dans le binaire.
- Dernière solution utiliser efi-updatevar utilitaire systeme pour configurer Secure Boot.
#In setup mode sudo efi-updatevar -e -f DB.esl db sudo efi-updatevar -e -f KEK.esl kek sudo efi-updatevar -f PK.auth PK |
ET N’OUBLIEZ DE FAIRE LES CHOSES INDIQUEES AU POINT 3.3
5. Commandes utiles
Vérifier la configuration de démarrage
sudo bootctl status --path /boot/efi
Vérifier que SecureBoot est activé ( Il doit y avoir un 1 en dernier sur le retour de la commande)
sudo od -An -t u1 /sys/firmware/efi/efivars/SecureBoot-*
Afficher la liste des certificats installer dans l’UEFI
efi-readvar
Redémarrer dans le UEFI
systemctl reboot --firmware
Vérifier la signature d’un programme efi avec une clé publique
sbverify --cert somecert.crt /boot/efi/EFI/BOOT/BOOTX64.EFI
Convertir une certificat du format x509 vers DER (utile pour charger les certificats dans votre UEFI, vous pouvez utiliser l’extension .der ou .cer)
openssl x509 -in PK.crt -outform DER -out PK.cer
Signe un programme efi avec la clé DB
sbsign --key DB.key --cert DB.crt HelloWorld.efi --output HelloWorld-signed.efi
Affiche les clés de signatures acceptées et chargées pendant le boot dans le kernel
sudo cat /proc/keys | grep asymmetri
sudo keyctl list %:.secondary_trusted_keys
Afficher la Subject Key Identifier d’un certificat (pour vérifier quel clé est chargée)
openssl x509 -inform DER -in /var/lib/shim-signed/mok.backup/MOK.der -text | grep -A1 'Subject Key'
Afficher les logs de démarrage concernant SecureBoot
dmesg | grep 'Loaded UEFI' -C 3
Vérifier les informations du certificat MOK généré
openssl x509 -subject -dates -fingerprint -inform DER -in /var/lib/shim-signed/mok/MOK.der
Régénérer une clé MOK manuellement
sudo update-secureboot-policy --help
Gérer les clés MOK
mokutil
6. Liens / sources
- Tous ce que j’ai raconté en version anglophone introduction à SecureBoot http://www.rodsbooks.com/efi-bootloaders/secureboot.html
- Tous ce que j’ai raconté en version anglophone installer vos clés http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html
- Différentes clés publiques présentes dans les firmware UEFI https://sourceforge.net/p/refind/code/ci/master/tree/keys/
- Documentation de SecureBoot pour QEMU/KVM https://en.opensuse.org/openSUSE:UEFI_Secure_boot_using_qemu-kvm
- Article très complet sur comment marche un UEFI et SecureBoot https://www.suse.com/documentation/sles11/book_sle_admin/data/sec_uefi_secboot.html
- Comment installer ces propres clés SecureBoot https://community.linuxmint.com/tutorial/view/2360
- Bon tutorial sur comment installer LinuxMint et autres avec partition chiffré en manuel https://community.linuxmint.com/tutorial/view/2061
- Wiki de Ubuntu concernant SecureBoot ça parle un de comment c’est géré chez eux mais aucun détails très claire, c’est bof https://wiki.ubuntu.com/UEFI/SecureBoot
- Le wiki de ArchLinux concernant SecureBoot très peu d’explication juste des commandes https://wiki.archlinux.org/index.php/Secure_Boot
2 commentaires
John Doe · 24 septembre 2020 à 17 h 07 min
T’es un boss Hugo (sans jeu de mot), ya peu de doc, même en anglais qui résume aussi bien les pas pour en arriver a un truc pratiquement « secure » (les guillemets sont pas la par hasard, avec Coreboot ce serait la cerise sur le gâteau). Merci beaucoup pour ce super travail de recompilation.
Pneuneige · 18 décembre 2020 à 7 h 45 min
Excellent guide, merci beaucoup, j’ai enfin compris comment marche le secure boot. Si vous corrigez en plus les fautes d’orthographe, le guide sera plus que parfait.