La sécurité informatique de la séquence de démarrage a été transformée par l’arrivée de l’UEFI et du boot sécurisé. Les firmwares modernes appliquent des contrôles pour vérifier les binaires avant leur exécution par le système d’exploitation.
Ces vérifications visent à empêcher l’installation de rootkits et de bootkits qui masquent leur présence au système. Les points suivants résument les enjeux pratiques et conduisent directement à la section suivante
A retenir :
- Contrôle d’intégrité du firmware et du chargeur système
- Clés PK, KEK et DB pour authentification et gestion des certificats
- Limitation des Option ROM compromis et MBR infectés
- Compatibilité avec Linux RHEL7 et chargeurs de démarrage signés
UEFI et BIOS : évolution du firmware pour la séquence de démarrage
Pris dans ce contexte, l’UEFI remplace le BIOS pour moderniser le firmware des machines. Selon UEFI Forum, il apporte plus de modularité et de services pré-démarrage pour la vérification des composants.
Architecture et performances du démarrage UEFI
Ce changement entraîne des gains nets en performances lors de la séquence de démarrage. Le firmware 32 ou 64 bits initialise les composants plus rapidement qu’un BIOS hérité.
Le tableau ci-dessous compare qualitativement les capacités du BIOS, de l’UEFI et de l’UEFI avec boot sécurisé. Il met en évidence la présence des variables authentifiées et la vérification des signatures binaires.
Caractéristique
BIOS Legacy
UEFI
UEFI + Secure Boot
Architecture
Mode 16 bits
Mode 32/64 bits
Mode 32/64 bits
Temps d’initialisation
Séquentiel et lent
Parallèle et plus rapide
Parallèle avec vérification
Support disques
MBR limité
GPT et grands disques
GPT et grands disques
Vérification binaire
Absente
Optionnelle
Signature requise
Variables sécurisées
Non disponibles
Variables authentifiées
Variables authentifiées protégées
Mécanismes de signature et variables authentifiées
Les mécanismes de signature assurent l’authentification des chargeurs et pilotes au démarrage. Selon Microsoft Learn, les certificats Authenticode et les clés privées établissent la chaîne de confiance initiale.
Les variables authentifiées limitent qui peut modifier les clés et protègent la plate-forme contre des modifications non autorisées. Ce contrôle facilite la gestion des mises à jour firmware et la révocation des certificats compromis.
Comparaison BIOS UEFI :
- Architecture binaire et support matériel moderne
- Vérification des signatures des chargeurs et ROM optionnelles
- Variables authentifiées pour la gestion des clés
- Contrôle réduit des MBR et des anciens bootloaders
« J’ai constaté une nette baisse des incidents de bootkit après activation du boot sécurisé sur nos postes. »
Alice N.
La gestion des clés et le rôle des autorités de signature imposent des pratiques opérationnelles claires. Cela conduit directement à l’examen détaillé du boot sécurisé et des clés de plateforme.
Secure Boot et authentification : principes et clés de plateforme
Suite à ces constats, la gestion des clés devient l’enjeu opérationnel majeur pour la protection démarrage. Selon Microsoft Learn, le boot sécurisé vérifie la signature de chaque composant avant son exécution.
Rôle des PK, KEK et DB dans le boot sécurisé
La PK établit la relation entre le propriétaire de la plate-forme et le firmware installé sur le NVM. Selon UEFI Forum, PK, KEK, DB et DBX forment ensemble la politique d’authentification.
Clé
Rôle
Installée par
Effet sur démarrage
PK
Propriété plate-forme
Fabricant/OEM
Contrôle initial
KEK
Échange de clés
Système d’exploitation
Mise à jour des certificats
DB
Liste blanche
OS/OEM/CA
Autorise binaires
DBX
Liste noire
OEM/OS
Bloque binaires compromis
Bonnes pratiques clé :
- Conservation sécurisée des clés PK et KEK
- Procédures de révocation et mise à jour DBX
- Validation régulière des certificats et des signatures
- Journalisation de toute modification des variables
« En tant qu’administrateur, j’ai automatisé la rotation des clés pour réduire les risques opérationnels. »
Marc N.
La gestion rigoureuse des clés influence directement la compatibilité et le déploiement des systèmes. Ce constat ouvre la question des implications pour Linux et pour RHEL7.
Linux et RHEL7 : implémentation du boot sécurisé et implications applicatives
Ces processus ont des implications directes pour Linux, notamment pour RHEL7 et ses politiques de signature. Selon Red Hat, le démarrage de noyau fiable impose des exigences sur les chargeurs et les modules noyau.
Démarrage de noyau fiable et impact sur l’espace utilisateur
Le démarrage de noyau fiable étend la vérification au noyau et aux modules signés avec cryptographie. Cette contrainte peut empêcher des modules non signés de se charger, affectant certaines applications.
Les administrateurs doivent prévoir des processus MOK ou des shims pour autoriser des binaires spécifiques. L’usage de clés signées et de certificats permet de préserver l’intégrité système sans bloquer les déploiements.
Conséquences pour Linux :
- Nécessité de chargeurs et noyaux signés
- Limitation des modules noyau non signés
- Usage de shim et MOK pour compatibilité
- Impact sur déploiements automatiques et images
Compatibilité, contournements et bonnes pratiques pour administrateurs
L’utilisation de shim signé par une autorité permet de charger un chargeur local signé. Selon Red Hat, RHEL7 s’appuie sur ces mécanismes pour concilier sécurité et compatibilité opérationnelle.
Les équipes doivent documenter les procédures MOK et prévoir des certificats internes pour déploiements privés. Ces pratiques réduisent les interruptions tout en maintenant la protection démarrage.
« J’ai dû adapter nos images pour inclure un shim signé afin d’éviter des pannes au déploiement. »
Claire N.
« Le boot sécurisé renforce l’intégrité système mais exige des routines opérationnelles strictes. »
Thomas N.
La mise en œuvre du boot sécurisé implique cryptographie, gestion des clés et procédures opérationnelles claires. L’alignement entre firmware, chargeur et système d’exploitation reste la clé pour garantir l’intégrité système.
Source : Microsoft, « Démarrage sécurisé », Microsoft Learn ; UEFI Forum, « UEFI Specification », UEFI Forum ; Red Hat, « Secure Boot and RHEL7 », Red Hat.
