# Secure Boot n’est pas simple

#### Publié par HugoPoi le 6 janvier 20196 janvier 2019

## 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>

<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.

  OVMF UEFI

  Secure Boot Menu OVMF

  Custom Mode Secure Boot Configuration Menu OVMF

  OVMF UEFI Shell test loading some non signed stuff

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

#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

Catégories : Aventure PC Logiciels

### 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.

### Laisser un commentaire Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nom *
E-mail *
Site internet
Qu’avez vous à l’esprit ?

Δ

## Articles similaires

###### Bidouille

#### Linky opendata my ass

Pour résumer la seule API utilisable en production est l’API Enedis qui est accèssible uniquement aux société (personne morale) ayant montré pate blanche auprès d’Enedis. Si vous voulez la version longue c’est ici. De ce Lire la suite…

###### Aventure Serveur

#### Le cloud maison

Voilà un petit moment que je me devais de faire cet article pour vous en dire un peu plus sur comment je gère mes données numériques au quotidien. Et après plusieurs essais et échecs, je Lire la suite…

###### Aventure PC

#### Niquer les DRMs d’Amazon AKA convertir vos ebook vers EPUB sans DRM

Comment j’en suis arrivé là Un jour dans une contrée de la blogosphère version 0.666 d’Internet, je voulais acheter un livre numérique car moins cher et puis ça pollue moins ça équivaut à un aller-retour Lire la suite…