Secure Boot n’est pas simple

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

1. Une installation qui démarre avec UEFI est un pré-requis.
2. 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)
3. Sinon vous pouvez vérifier que vous avez les paquets shim-signed grub-efi-amd64-signed d’installés à l’aide de la commande apt 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.
4. 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

   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

5. 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.
6. 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:

1. Lancer apt reinstall nvidia-dkms-390 et renseigner un mot de passe MOK.
2. Reboot
3. Au redémarrage MokManager devrait se lancer
4. Sélectionner Enroll MOK
5. Il vous présente la clé à ajouter
6. 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.

Schéma de confiance des signatures pour Ubuntu et dérivés en utilisant Shim-signed

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 &gt; 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