Fedora 18 Guide UEFI Secure Boot - Josh Boyer Kevin Fenzi Peter Jones Josh Bressers Florian Weimer - Fedora Docs
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Fedora 18
Guide UEFI Secure Boot
Josh Boyer
Kevin Fenzi
Peter Jones
Josh Bressers
Florian WeimerGuide UEFI Secure Boot Brouillon
Fedora 18 Guide UEFI Secure Boot
Édition 18.4
Auteur Josh Boyer jwboyer@redhat.com
Auteur Kevin Fenzi kevin@fedoraproject.org
Auteur Peter Jones pjones@redhat.com
Auteur Josh Bressers bressers@redhat.com
Auteur Florian Weimer fweimer@redhat.com
Éditeur Eric Christensen sparks@redhat.com
Copyright © 2012-2013 Fedora Project Contributors.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons
Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available
at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document, and Red Hat,
designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with
CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the
original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert,
Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity
Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
For guidelines on the permitted uses of the Fedora trademarks, refer to https://fedoraproject.org/wiki/
Legal:Trademark_guidelines.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States
and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other
countries.
All other trademarks are the property of their respective owners.Brouillon Brouillon
Preface v
1. Conventions d'écriture ..................................................................................................... v
1.1. Conventions typographiques ................................................................................. v
1.2. Conventions pour citations mises en avant ........................................................... vii
1.3. Notes et avertissements ...................................................................................... vii
2. Vos commentaires sont importants ! ............................................................................... viii
1. Qu'est-ce que UEFI Secure Boot ? 1
1.1. Secure Boot UEFI ........................................................................................................ 1
1.2. Prérequis de Microsoft pour Secure Boot ...................................................................... 2
1.2.1. Détails de l'implémentation ................................................................................. 3
1.3. Secure Boot Fedora ..................................................................................................... 7
1.4. De quoi vous protège Secure Boot ? ............................................................................. 7
1.5. Risques potentiels Secure Boot .................................................................................... 8
1.5.1. Fonctionnalités obligatoirement exclues en mode Secure Boot ............................. 8
1.5.2. Transformations du système en dehors de Secure Boot ....................................... 9
1.5.3. Pas d'infrastructure d'allocation derrière Microsoft Windows ................................. 9
1.5.4. Procédures de révocation supposées ................................................................. 9
2. System Configuration 11
2.1. Entering the UEFI firmware ......................................................................................... 11
2.2. Disabling UEFI Secure Boot ....................................................................................... 12
2.3. Enabling Microsoft Secure Boot .................................................................................. 14
2.4. Known issues ............................................................................................................. 16
3. Implémentation de Secure Boot UEFI 17
3.1. Clés ........................................................................................................................... 17
3.2. Shim .......................................................................................................................... 19
3.3. GRUB ........................................................................................................................ 20
3.4. Noyau ........................................................................................................................ 20
3.4.1. Restrictions ..................................................................................................... 20
4. Outils 23
4.1. Shim .......................................................................................................................... 23
4.2. Pesign ....................................................................................................................... 23
4.3. EFIKeyGen ................................................................................................................ 23
4.4. sign-file ...................................................................................................................... 23
5. Utilisation de vos propres clés 25
5.1. Création des clés ....................................................................................................... 25
5.2. Fabrication des clés pour la construction de shim ......................................................... 25
5.3. Paquets nécessitant une reconstruction ....................................................................... 25
5.4. Enregistrement de vos clés dans le micrologiciel .......................................................... 25
A. Historique de modification 27
Index 29
iiiiv
Brouillon Brouillon
Preface
1. Conventions d'écriture
Ce manuel utilise plusieurs conventions pour souligner l'importance de certains mots ou expressions,
mais aussi en vue d'attirer l'attention sur certains passages d'informations précis.
Pour les éditions sur support papier et numérique (PDF), ce manuel utilise des caractères issus
1
de Liberation Fonts . La police de caractères Liberation Fonts est également utilisée pour les
éditions HTML si elle est installée sur votre système. Sinon, des polices de caractères alternatives
équivalentes sont utilisées. Notez que Red Hat Enterprise Linux 5 et versions supérieures contiennent
la police Liberation Fonts par défaut.
1.1. Conventions typographiques
Quatre conventions typographiques sont utilisées pour attirer l'attention sur certains mots et
expressions. Ces conventions et les circonstances auxquelles elles s'appliquent sont les suivantes.
Caractères gras à espacement fixe
Utilisée pour surligner certaines entrées du système, comme les commandes de console, les noms de
fichiers et les chemins d'accès. Également utilisé pour surligner les touches et les combinaisons de
touches. Par exemple :
Pour consulter le contenu du fichier mon_nouvel_ouvrage_littéraire
qui se situe dans votre dossier courant, saisissez la commande cat
mon_nouvel_ouvrage_littéraire à la demande du terminal et appuyez sur
Entrée pour exécuter la commande.
L'exemple ci-dessus contient un nom de fichier, une commande-console et un nom de touche, tous
présentés sous forme de caractères gras à espacement fixe et tous bien distincts grâce au contexte.
Les combinaisons de touches sont différenciées des noms de touches par le caractère « plus » (« + »)
qui fait partie de chaque combinaison de touches. Ainsi :
Appuyez sur Entrée pour exécuter la commande.
Appuyez sur Ctrl+Alt+F2 pour passer au premier terminal virtuel. Appuyer sur
Ctrl+Alt+F1 pour retournez à votre session X-Windows.
Le premier paragraphe surligne la touche précise sur laquelle il faut appuyer. Le second surligne deux
combinaisons de touches (chacun étant un ensemble de trois touches à presser simultanément).
Si le code source est mentionné, les noms de classes, les méthodes, les fonctions, les noms de
variables et les valeurs de retour citées dans un paragraphe seront présentées comme ci-dessus, en
caractères gras à espacement fixe. Par exemple :
Les classes de fichiers comprennent le nom de classe filesystem pour les noms
de fichier, file pour les fichiers et dir pour les dossiers. Chaque classe correspond
à un ensemble de permissions associées.
1
https://fedorahosted.org/liberation-fonts/
vPreface Brouillon
Caractères gras proportionnels
Cette convention marque le surlignage des mots ou phrases que l'on rencontre sur un système,
comprenant des noms d'application, des boîtes de dialogue textuelles, des boutons étiquettés, des
cases à cocher et des boutons d'options mais aussi des intitulés de menus et de sous-menus. Par
exemple :
Sélectionnez Système��� Préférences��� Souris à partir de la barre du menu
principal pour lancer les Préférences de la souris. À partir de l'onglet Boutons,
cliquez sur la case à cocher Pour gaucher puis cliquez sur Fermer pour faire passer
le bouton principal de la souris de la gauche vers la droite (ce qui permet l'utilisation
de la souris par la main gauche).
Pour insérer un caractère spécial dans un fichier gedit, choisissez Applications
�� Accessoires��� Table de caractères à partir de la barre du menu principal.
Ensuite, sélectionnez Rechercher��� Rechercher… à partir de la barre de menu
de Table de caractères, saisissez le nom du caractère dans le champ Rechercher
puis cliquez sur Suivant. Le caractère que vous recherchez sera surligné dans la
Table de caractères. Double-cliquez sur le caractère surligné pour l'insérer dans le
champ Texte à copier, puis cliquez sur le bouton Copier. Maintenant, revenez à votre
document et sélectionnez Édition��� Coller à partir de la barre de menu de gedit.
Le texte ci-dessus contient des noms d'applications, des noms de menus et d'autres éléments
s'appliquant à l'ensemble du système, des boutons et textes que l'on trouve dans une interface
graphique. Ils sont tous présentés sous la forme gras proportionnel et identifiables en fonction du
contexte.
Italique gras à espacement fixe ou Italique gras proportionnel
Qu'ils soient en caractères gras à espacement fixe ou à caractères gras proportionnels, l'ajout de
l'italique indique la présence de texte remplaçable ou variable. Les caractères en italique indiquent la
présence de texte que vous ne saisissez pas littéralement ou de texte affiché qui change en fonction
des circonstances. Par exemple :
Pour se connecter à une machine distante en utilisant ssh, saisissez ssh nom
d'utilisateur@domain.name (nom.domaine) après l'invite de commande de
la console. Si la machine distante est exemple.com et que votre nom d'utilisateur
pour cette machine est john, saisissez ssh john@example.com.
La commande mount -o remount système de fichiers monte le système de
fichiers nommé. Ainsi, pour monter /home dans le système de fichiers, la commande
est mount -o remount /home.
Pour connaître la version d'un paquet actuellement installé, utilisez la commande rpm
-q paquet. Elle vous permettra de retourner le résultat suivant : version-de-
paquet.
Notez les mots en caractères italiques et gras au dessus de — nom d'utilisateur, domain.name,
système fichier, paquet, version et mise à jour. Chaque mot est un paramètre substituable de la ligne
de commande, soit pour le texte que vous saisissez suite à l'activation d'une commande, soit pour le
texte affiché par le système.
Mis à part l'utilisation habituelle de présentation du titre d'un ouvrage, les caractères italiques
indiquent l'utilisation initiale d'un terme nouveau et important. Ainsi :
Publican est un système de publication DocBook.
viBrouillon Conventions pour citations mises en avant
1.2. Conventions pour citations mises en avant
Les sorties de terminaux et les citations de code source sont mis en avant par rapport au texte
avoisinant.
Les sorties envoyées vers un terminal sont en caractères Romains à espacement fixe et
présentées ainsi :
books Desktop documentation drafts mss photos stuff svn
books_tests Desktop1 downloads images notes scripts svgs
Les citations de code source sont également présentées en romains à espacement fixe mais
sont présentés et surlignés comme suit :
package org.jboss.book.jca.ex1;
import javax.naming.InitialContext;
public class ExClient
{
public static void main(String args[])
throws Exception
{
InitialContext iniCtx = new InitialContext();
Object ref = iniCtx.lookup("EchoBean");
EchoHome home = (EchoHome) ref;
Echo echo = home.create();
System.out.println("Created Echo");
System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
}
}
1.3. Notes et avertissements
Enfin, nous utilisons trois styles visuels pour attirer l'attention sur des informations qui auraient pu être
normalement négligées :
Remarque
Une remarque est une forme de conseil, un raccourci ou une approche alternative par rapport à
une tâche à entreprendre. L'ignorer ne devrait pas provoquer de conséquences négatives, mais
vous pourriez passer à côté d'une astuce qui vous aurait simplifiée la vie.
viiPreface Brouillon
Important
Les blocs d'informations importantes détaillent des éléments qui pourraient être facilement
négligés : des modifications de configurations qui s'appliquent uniquement à la session actuelle
ou des services qui ont besoin d'être redémarrés avant toute mise à jour. Si vous ignorez une
case étiquetée « Important », vous ne perdrez aucunes données mais cela pourrait être source
de frustration et d'irritation.
Avertissement
Un avertissement ne devrait pas être ignoré. Ignorer des avertissements risque fortement
d'entrainer des pertes de données.
2. Vos commentaires sont importants !
Si vous trouvez des fautes de frappe ou si vous avez des suggestions pour améliorer ce manuel,
n'hésitez surtout pas à nous en faire part ! Veuillez envoyer vos remarques par l'entremise de Bugzilla
(http://bugzilla.redhat.com/bugzilla/) pour le produit Fedora.
Lorsque vous soumettez un rapport d'erreurs, veuillez indiquer clairement les références du manuel :
UEFI_Secure_Boot_Guide
Si vous avez des suggestions pour améliorer la documentation, essayez de les décrire le plus
précisément possible. Si vous avez trouvé une erreur, veuillez non seulement indiquer le numéro
de section où elle se trouve mais également ajouter un extrait du texte qui l'entoure, afin que nous
puissions la retrouver facilement.
viiiBrouillon Chapitre 1. Brouillon
Qu'est-ce que UEFI Secure Boot ?
Secure Boot est une technologie dans laquelle le micrologiciel système vérifie que le chargeur de
démarrage du système est signé avec une clé chiffrée autorisée par une base de donnée contenue
dans le micrologiciel. Avec des vérifications de conformité de signature dans les phases suivantes
de l'exécution du ou des chargeurs de démarrage, dans le noyau et, peut-être même, dans l'espace
utilisateur, il est possible d'empêcher l'exécution de code non signé.
Secure Boot est une forme de démarrage sous contrôle. La validation du processus de démarrage fait
également partie d'autres techniques, comme le démarrage sécurisé. La validation du processus de
démarrage diffère d'un stockage sécurisé des clés de chiffrement ou d'une authentification à distance.
1.1. Secure Boot UEFI
Secure Boot UEFI est le composant « validation du processus de démarrage » de la directive UEFI
(Unified Extensible Firmware Interface) dans sa version 2.3. Grosso modo, elle précise les points
suivants :
• une interface de programmation pour des variables UEFI protégées par chiffrement dans un
stockage non-volatile,
• la façon dont les certificats racine de confiance X.509 sont stockés dans les variables UEFI,
• une validation des applications UEFI (chargeurs de démarrage et pilotes) en utilisant des signatures
« AuthentiCode » incorporées dans ces applications, et
• des procédures pour révoquer des certificats et des signatures d'applications reconnus comme
mauvais.
Secure Boot UEFI ne nécessite pas de matériel spécialisé, sauf un stockage (flash) non volatil
pouvant être basculé du mode lecture-écriture au mode lecture seule pendant le démarrage du
système. Ce stockage est utilisé pour stocker l'implémentation de UEFI lui-même et quelques unes
des variables protégées UEFI (y compris le certificat racine de confiance).
Du point de vue de l'utilisateur, un système, qui a activé Secure Boot UEFI et qui est confronté à un
processus de démarrage trafiqué, s'arrête simplement de fonctionner jusqu'à ce que Secure Boot
UEFI soit désactivé ou qu'une phase suivante correctement signée dans le chargeur de démarrage
soit disponible sur le média de lancement (la Figure 1.1, « Message d'erreur type Secure Boot UEFI »
montre un message d'erreur typique). De la même manière, des installeurs de systèmes d'exploitation
sans signature chiffrée valide ne s'exécutent pas et se terminent par un message d'erreur. Aucun
moyen n'est offert à l'utilisateur pour contourner la décision de rejet de signature du chargeur de
démarrage, contrairement au scénario similaire avec les certificats des serveurs Web. Aucune
information sur l'émetteur du certificat n'est fournie à l'utilisateur.
┌────────── Secure Boot Violation ──────────┐
│ │
├───────────────────────────────────────────┤
│ Invalid signature detected. Check Secure │
│ Boot Policy in Setup │
│ │
│ │
│ [OK] │
└───────────────────────────────────────────┘
Figure 1.1. Message d'erreur type Secure Boot UEFI
1Chapitre 1. Qu'est-ce que UEFI Secure Boot ? Brouillon
Secure Boot UEFI n'empêche ni la mise en place ou l'enlèvement des logiciels exécutant la phase
2 des chargeurs de démarrage, ni l'obligation d'une confirmation explicite de l'utilisateur pour de
telles modifications. Les signatures sont vérifiées pendant le démarrage, et non quand le chargeur de
démarrage est installé ou mis à jour. Ainsi, Secure Boot UEFI n'empêche pas les manipulations du
processus de démarrage. Il empêche uniquement le système d'exécuter un processus de démarrage
modifié après qu'un tel changement est intervenu ; en outre, il simplifie leur détection.
Technologie client
Secure Boot UEFI est actuellement uniquement activé sur des périphériques client, et n'est pas
recommandé pour un déploiement sur des serveurs. Il est prévu que les technologies serveur
activent Secure Boot dans le futur.
1.2. Prérequis de Microsoft pour Secure Boot
Microsoft n'a pas publié beaucoup de détails à propos de leur implémentation de Secure Boot, fondé
sur UEFI.
Microsoft ne prend en charge Secure Boot UEFI qu'avec Windows 8, mais il n'est pas indispensable
pour le faire fonctionner. Les systèmes dans un environnement Secure Boot UEFI démarrent encore
si la prise en charge de Secure Boot est supprimée de l'environnement UEFI. Les consommateurs qui
souhaitent utiliser les précédentes versions de Windows doivent désactiver Secure Boot, étant donné
que Microsoft ne met pas à disposition des chargeurs de démarrage signés pour elles.
Se fondant sur des informations publiques, les objectifs de sécurité ci-après avec Secure Boot
Microsoft semblent être :
• une protection de l'intégrité des médias d'installation stockés sur des supports inscriptibles (comme
les partitions de récupération de disque durs),
• une protection du processus de démarrage jusqu'à ce que des contre-mesures heuristiques
(comme des logiciels noyau en mode antivirus) puissent être chargées dès le début du démarrage,
et
• une restauration automatique du processus originel de démarrage, parfois après que le système
a été compromis par un logiciel malveillant, sans complète réinstallation de la totalité du système
d'exploitation.
Il est moins évident qu'il n'y ait pas des intentions de restreindre l'accès à certains contenus (en
ligne) aux systèmes ayant activé Secure Boot UEFI, systèmes dont le chiffrement du processus de
démarrage est valide. Ceci impliquerait un aspect d'attestation à distance qui ne fait pas partie des
directives Secure Boot UEFI et qui ne pourrait pas être implémenté en toute sécurité sans une prise
en charge matérielle supplémentaire. Cela impliquerait également que Secure Boot UEFI ne soit plus
réellement optionnel.
Il n'est pas évident que Microsoft ait l'intention d'expulser quiconque avec leur implémentation de
Secure Boot. Toutefois, la restauration automatique du processus originel de démarrage est beaucoup
plus complexe à partir du moment où plusieurs chargeurs de démarrage coexistent sur un même
système.
2Brouillon Détails de l'implémentation
1.2.1. Détails de l'implémentation
Microsoft exige que les PC clients portant le logo Windows 8 activent Secure Boot UEFI et installent
la clé matérielle fournie par Microsoft. Le certificat X.509 est affiché sur la Figure 1.2, « Certificat de
confiance Microsoft X.509 pour leur implémentation de Secure Boot ». Les vendeurs de systèmes
sont incités à inclure les autres certificats racine selon nécessité, mais il n'est pas obligatoire qu'ils
soient présents.
3Chapitre 1. Qu'est-ce que UEFI Secure Boot ? Brouillon
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
61:07:76:56:00:00:00:00:00:08
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
CN=Microsoft Root Certificate Authority 2010
Validity
Not Before: Oct 19 18:41:42 2011 GMT
Not After : Oct 19 18:51:42 2026 GMT
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
CN=Microsoft Windows Production PCA 2011
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:dd:0c:bb:a2:e4:2e:09:e3:e7:c5:f7:96:69:bc:
[…]
87:65:b4:43:18:a8:b2:e0:6d:19:77:ec:5a:24:fa:
48:03
Exponent: 65537 (0x10001)
X509v3 extensions:
1.3.6.1.4.1.311.21.1:
02:01:00
X509v3 Subject Key Identifier:
A9:29:02:39:8E:16:C4:97:78:CD:90:F9:9E:4F:9A:E1:7C:55:AF:53
1.3.6.1.4.1.311.20.2:
1E:0A:00:53:00:75:00:62:00:43:00:41
X509v3 Key Usage:
Digital Signature, Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Authority Key Identifier:
keyid:D5:F6:56:CB:8F:E8:A2:5C:62:68:D1:3D:94:90:5B:D7:CE:9A:18:C4
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.microsoft.com/pki/crl/products/MicRooCerAut_2010-06-23.crl
Authority Information Access:
CA Issuers - URI:http://www.microsoft.com/pki/certs/
MicRooCerAut_2010-06-23.crt
Signature Algorithm: sha256WithRSAEncryption
14:fc:7c:71:51:a5:79:c2:6e:b2:ef:39:3e:bc:3c:52:0f:6e:
[…]
04:cf:77:a4:62:1c:59:7e
-----BEGIN CERTIFICATE-----
MIIF1zCCA7+gAwIBAgIKYQd2VgAAAAAACDANBgkqhkiG9w0BAQsFADCBiDELMAkG
A1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQx
HjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEyMDAGA1UEAxMpTWljcm9z
b2Z0IFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IDIwMTAwHhcNMTExMDE5MTg0
MTQyWhcNMjYxMDE5MTg1MTQyWjCBhDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldh
c2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBD
b3Jwb3JhdGlvbjEuMCwGA1UEAxMlTWljcm9zb2Z0IFdpbmRvd3MgUHJvZHVjdGlv
biBQQ0EgMjAxMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN0Mu6Lk
Lgnj58X3lmm8ACG9aTMz760Ey1SA7gaDu8UghNn30ovzOLCrpK0tfGJ5Bf/jSj8E
NSBw48Tna+CcwDZ16Yox3Y1w5dw3tXRGlihbh2AjLL/cR6Vn91EnnnLrB6bJuR47
UzV85dPsJ7mHHP65ySMJb6hGkcFuljxB08ujP10Cak3saR8lKFw2//1DFQqU4Bm0
z9/CEuLCWyfuJ3gwi1sqCWsiiVNgFizAaB1TuuxJ851hjIVoCXNEXX2iVCvdefcV
zzVdbBwrXM68nCOLb261Jtk2E8NP1ieuuTI7QZIs4cfNd+iqVE73XAsEh2W0Qxio
suBtGXfsWiT6SAMCAwEAAaOCAUMwggE/MBAGCSsGAQQBgjcVAQQDAgEAMB0GA1Ud
Figure 1.2. Certificat de confiance Microsoft X.509 pour leur implémentation
DgQWBBSpKQI5jhbEl3jNkPmeT5rhfFWvUzAZBgkrBgEEAYI3FAIEDB4KAFMAdQBi de Secure Boot
AEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBTV
4 9lbLj+iiXGJo0T2UkFvXzpoYxDBWBgNVHR8ETzBNMEugSaBHhkVodHRwOi8vY3Js
Lm1pY3Jvc29mdC5jb20vcGtpL2NybC9wcm9kdWN0cy9NaWNSb29DZXJBdXRfMjAx
MC0wNi0yMy5jcmwwWgYIKwYBBQUHAQEETjBMMEoGCCsGAQUFBzAChj5odHRwOi8v
d3d3Lm1pY3Jvc29mdC5jb20vcGtpL2NlcnRzL01pY1Jvb0NlckF1dF8yMDEwLTA2
LTIzLmNydDANBgkqhkiG9w0BAQsFAAOCAgEAFPx8cVGlecJusu85Prw8Ug9uKz8QBrouillon Détails de l'implémentation
On s'attend à ce que Microsoft joigne, éventuellement, des demandes de révocation signées dans
les mises à jour de Windows. Ces requêtes en révocation seraient installées dans les variables de
configuration Secure Boot UEFI lors du démarrage système suivant, après leur validation vis à vis de
la clé Microsoft. Au moment de l'écriture de ce guide, une telle liste noire n'existe pas encore.
Les chargeurs de démarrage tierce-partie n'ont actuellement pas accès au certificat Microsoft
Windows Production PCA 2011 que Microsoft utilise pour ses propres produits. Au lieu de cela,
Microsoft met à disposition un service de signature initialement conçu pour les pilotes UEFI. Ce
service a été également étendu aux chargeurs de démarrage tierce-partie. Microsoft revoit les
applications à soumettre à UEFI, fournit une signature « AuthentiCode » en utilisant sa propre clé,
et renvoie le résultat à leur auteur. Cette signature n'identifie pas l'auteur de l'application (c'est
un pseudonyme), mais, plus important, elle est chaînée via le certificat intermédiaire Microsoft
Corporation UEFI CA 2011 (voir la Figure 1.3, « Certificat X.509 Microsoft pour application UEFI tierce
partie ») au certificat racine Microsoft Corporation Third Party Marketplace Root.
Avertissement
Les chargeurs de démarrage UEFI tierce-partie ne sont pas assurés de fonctionner sur les
systèmes Secure Boot Microsoft étant donné que les certificats nécessaires ne font pas partie de
la spécification Secure Boot Microsoft.
5Chapitre 1. Qu'est-ce que UEFI Secure Boot ? Brouillon
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
61:08:d3:c4:00:00:00:00:00:04
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
CN=Microsoft Corporation Third Party Marketplace Root
Validity
Not Before: Jun 27 21:22:45 2011 GMT
Not After : Jun 27 21:32:45 2026 GMT
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
CN=Microsoft Corporation UEFI CA 2011
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a5:08:6c:4c:c7:45:09:6a:4b:0c:a4:c0:87:7f:
06:75:0c:43:01:54:64:e0:16:7f:07:ed:92:7d:0b:
b2:73:bf:0c:0a:c6:4a:45:61:a0:c5:16:2d:96:d3:
f5:2b:a0:fb:4d:49:9b:41:80:90:3c:b9:54:fd:e6:
bc:d1:9d:c4:a4:18:8a:7f:41:8a:5c:59:83:68:32:
bb:8c:47:c9:ee:71:bc:21:4f:9a:8a:7c:ff:44:3f:
8d:8f:32:b2:26:48:ae:75:b5:ee:c9:4c:1e:4a:19:
7e:e4:82:9a:1d:78:77:4d:0c:b0:bd:f6:0f:d3:16:
d3:bc:fa:2b:a5:51:38:5d:f5:fb:ba:db:78:02:db:
ff:ec:0a:1b:96:d5:83:b8:19:13:e9:b6:c0:7b:40:
7b:e1:1f:28:27:c9:fa:ef:56:5e:1c:e6:7e:94:7e:
c0:f0:44:b2:79:39:e5:da:b2:62:8b:4d:bf:38:70:
e2:68:24:14:c9:33:a4:08:37:d5:58:69:5e:d3:7c:
ed:c1:04:53:08:e7:4e:b0:2a:87:63:08:61:6f:63:
15:59:ea:b2:2b:79:d7:0c:61:67:8a:5b:fd:5e:ad:
87:7f:ba:86:67:4f:71:58:12:22:04:22:22:ce:8b:
ef:54:71:00:ce:50:35:58:76:95:08:ee:6a:b1:a2:
01:d5
Exponent: 65537 (0x10001)
X509v3 extensions:
1.3.6.1.4.1.311.21.1:
02:03:01:00:01
1.3.6.1.4.1.311.21.2:
04:14:F8:C1:6B:B7:7F:77:53:4A:F3:25:37:1D:4E:A1:26:7B:0F:20:70:80
X509v3 Subject Key Identifier:
13:AD:BF:43:09:BD:82:70:9C:8C:D5:4F:31:6E:D5:22:98:8A:1B:D4
1.3.6.1.4.1.311.20.2:
1E:0A:00:53:00:75:00:62:00:43:00:41
X509v3 Key Usage:
Digital Signature, Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Authority Key Identifier:
keyid:45:66:52:43:E1:7E:58:11:BF:D6:4E:9E:23:55:08:3B:3A:22:6A:A8
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.microsoft.com/pki/crl/products/
MicCorThiParMarRoo_2010-10-05.crl
Authority Information Access:
CA Issuers - URI:http://www.microsoft.com/pki/certs/
MicCorThiParMarRoo_2010-10-05.crt
Signature Algorithm: sha256WithRSAEncryption
35:08:42:ff:30:cc:ce:f7:76:0c:ad:10:68:58:35:29:46:32:
[…]
Figure 1.3. 92:9b:f5:a6:bc:59:83:58
Certificat X.509 Microsoft pour application UEFI tierce partie
6 -----BEGINCERTIFICATE-----
MIIGEDCCA/igAwIBAgIKYQjTxAAAAAAABDANBgkqhkiG9w0BAQsFADCBkTELMAkG
A1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQx
HjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjE7MDkGA1UEAxMyTWljcm9z
b2Z0IENvcnBvcmF0aW9uIFRoaXJkIFBhcnR5IE1hcmtldHBsYWNlIFJvb3QwHhcNBrouillon Secure Boot Fedora
Un certificat signant du code régulier n'est pas suffisant pour garantir un démarrage sur un système
Secure Boot Microsoft. Microsoft exige un certificat de signature du code quand il communique
avec les auteurs d'une application UEFI, mais, de toute manière, c'est un détail interne invisible à
l'utilisateur final.
Dans le système d'exploitation démarré, Microsoft Windows 8 prend en charge la validation
AuthentiCode ainsi que le chargement des modules noyau signés pour une tierce partie. Windows
dispose ainsi de l'infrastructure pour une validation des programmes dans l'espace utilisateur, à
nouveau fondée sur AuthentiCode.
1.3. Secure Boot Fedora
L'implémentation Secure Boot pour Fedora n'a qu'un seul objectif de sécurité : empêcher l'exécution
de code non signé en mode noyau.
Fedora peut s'exécuter sur des systèmes ayant Secure Boot Microsoft activé, pourvu que le certificat
Microsoft pour les applications UEFI tierce-partie soit installé. Ce mode opératoire est essentiel si on
veut installer Fedora sur des machines préparées pour Windows 8. Les autres matériels ne sont pas
susceptibles de fournir un environnement Secure Boot Microsoft.
Avertissement
Les chargeurs de démarrage tierce-partie UEFI (comme le chargeur de démarrage de Fedora)
n'ont aucune garantie de fonctionnement sur les systèmes Secure Boot Microsoft car les
certificats nécessaires ne font pas partie des exigences de certification du matériel pour
Windows 8. Si votre matériel entre dans cette catégorie, vous devez désactiver Secure Boot
UEFI, enregistrer le certificat Microsoft manquant ou bien celui de Fedora.
Fedora démarre, également, sur les systèmes UEFI qui ne prennent pas en charge ou ont désactivé
Secure Boot. Ceci fonctionne avec tous les chargeurs de démarrage UEFI. Ces chargeurs de
démarrage s'exécutent aussi dans un environnement réalisant la validation du processus de
démarrage par des moyens autres (non-UEFI). Dans ce mode, il n'y aucun restriction pour exécuter
du code en mode noyau.
Des détails à propos de l'implémentation de Secure Boot Fedora sont donnés dans le Chapitre 3,
Implémentation de Secure Boot UEFI. Des restrictions sur l'exécution de code en mode noyau
désactivent certaines fonctionnalités, voir la Section 3.4.1, « Restrictions ».
1.4. De quoi vous protège Secure Boot ?
Au niveau le plus élémentaire, Secure Boot UEFI empêche le lancement de chargeurs de démarrage
non signés. L'effet du lancement du chargeur de démarrage dépend bien évidemment de ce dernier.
Ce qui suit se rapporte à l'implémentation Fedora de Secure Boot. L'implémentation Microsoft est
différente, voir la Section 1.2, « Prérequis de Microsoft pour Secure Boot ».
Fedora a étendu la chaîne de confiance de l'environnement UEFI au noyau. Une vérification intervient
avant le chargement des modules du noyau, mais il n'est pas poursuivi jusqu'aux applications de
l'espace utilisateur. Nous pouvons être certains qu'aucun code exécutable non signé n'est présent
jusqu'au moment où est chargé en mémoire le disque virtuel initial (initrd). Étant donné que les
contenus de initrd ne sont pas signés avec chiffrement et contiennent du code exécutable, démarrer
avec un chargeur de démarrage signé Fedora peut éventuellement causer des effets imprévisibles.
7Chapitre 1. Qu'est-ce que UEFI Secure Boot ? Brouillon L'implémentation Secure Boot Fedora simplifie la vérification du processus de démarrage dans le cadre d'investigations informatiques. Le démarrage traditionnel du BIOS exécute du code potentiellement malveillant chargé à partir du disque dans les toutes premières phases de lancement, ce qui ne permet pas d'exclure que le système d'exploitation ait été trafiqué à très bas niveau. (Le bénéfice réside pour partie dans la nature plus déclarative de la configuration de démarrage UEFI sur le disque). 1.5. Risques potentiels Secure Boot Secure Boot ne préserve pas votre PC de la plupart des logiciels ou personnes malveillantes. Secure Boot, lui-même, protège la phase de démarrage du système, mais ne défend pas contre les attaques sur votre système en cours de fonctionnement ou sur vos données. Dans Fedora si vous utilisez Secure Boot, vous pourrez restreindre le chargement dans le noyau de certains modules, mais aucune autre protection n'est mise en place vis à vis d'attaques par des logiciels malveillants dans l'espace utilisateur. L'image du disque virtuel (initrd) utilisée au cours du démarrage n'est pas protégée par cette fonctionnalité ; le disque virtuel peut contenir du code malveillant. 1.5.1. Fonctionnalités obligatoirement exclues en mode Secure Boot L'approche pour désactiver des fonctionnalités noyau connues pour être peu sûres consiste à les inscrire dans une liste noire. Dans certains cas, des fonctionnalités spécifiques ont été supprimées ; dans d'autres, leur rôle est obscur et elles sont rarement utilisées. Actuellement, la liste des fonctions consignées comprend : • la modification des cartographies d'adresses mémoire de périphériques par l'intermédiaire de "setpci", et l'écriture dans ces zones mémoire à partir de l'espace utilisateur avec sysfs, • l'hibernation (également connue sous le nom de suspension sur disque), • l'utilisation de kexec et kdump (la correction de ce problème est en cours), • l'écriture dans des registres machine particuliers à l'aide du module noyau « msr », • l'option en ligne de commande acpi_rspd, utilisée pour définir des données ACPI personnalisées, • des opérations d'E/S sur /dev/kmem. En outre, l'utilisation des modules systemtap est limitée aux modules signés avec un certificat approprié. Il est recommandé qu'un tel certificat soit généré sur site, en faisant attention aux pratiques de sécurité éprouvées pour le stockage et l'utilisation d'un certificat de signature. En utilisant un certificat propre au site, il peut être enregistré dans la base de données locale de la machine avec l'utilitaire mokutil ; un redémarrage est nécessaire pour que cela prenne effet. Après redémarrage, shim exécute MokManager qui vous présentera une interface pour inscrire le certificat. 8
Brouillon Transformations du système en dehors de Secure Boot
Avertissement
Il est essentiel, voire crucial, que des précautions appropriées soient prises lors de l'utilisation
de certificats propres au site, de façon à ce qu'ils ne soient pas trouvés par une personne
malveillante pour saboter la sécurité du module. Traitez ces certificats comme vous le feriez pour
tout secret primordial et suivez les pratiques recommandées dans l'industrie pour les clés de
chiffrement et les certificats.
1.5.2. Transformations du système en dehors de Secure Boot
Une mise à jour du BIOS ou le remplacement d'une carte mère peut désactiver Secure Boot sur un
système où il était précédemment activé. Un matériel supplémentaire installé sur une machine peut
avoir des exigences incompatibles avec Secure Boot (DMA dans l'espace utilisateur, prise en charge
de SystemTap, modules de noyau ne provenant pas de Red Hat). Ceci signifie que Secure Boot ne
peut être un prérequis aux fonctionnalités du système ; il serait même extrêmement mal venu d'en
faire une politique obligatoire.
1.5.3. Pas d'infrastructure d'allocation derrière Microsoft Windows
Quelques fournisseurs de systèmes, selon certaines sources, obligeraient à installer Windows 8 pour
activer Secure Boot. Les acheteurs de ces systèmes qui voudraient faire fonctionner Secure Boot
devraient donc obtenir une licence client Windows 8, personnalisée par leur fournisseur système. Ce
scénario ne peut pas être pertinent, si Red Hat compte sur une racine de confiance séparée sous
notre contrôle, fournie en coopération avec des marchands de matériel.
1.5.4. Procédures de révocation supposées
Nous ne savons actuellement pas si les processus des fonctions concernant la révocation
fonctionnent vraiment. Les révocations sont complexes parce qu'elles doivent être synchronisées
entre fournisseurs de système d'exploitation pour prendre en charge des configurations à double
amorçage. Sans une telle coordination, une signature sur processus de démarrage peut être révoquée
avant que le système d'exploitation sous-jacent ait une chance de la mettre à jour. Ce qui laisserait le
système impossible à démarrer.
Il n'est pas évident de dire en quelles circonstances Microsoft émettrait une révocation non sollicitée.
Les raisons possibles d'une révocation sont l'impossibilité d'atteindre l'objectif de sécurité (c'est à dire,
une exécution de code non signé en mode noyau est possible dans des conditions de laboratoire)
ou bien l'exploitation réelle d'une telle faille compromettant le processus de démarrage des systèmes
Windows 8 en dehors des laboratoires. Le dernier cas recouvre également les contournements de
Secure Boot qui permettraient de charger du code non signé sur intervention de l'utilisateur.
910
Brouillon Chapitre 2. Brouillon
System Configuration
This chapter describes how to configure systems for use with UEFI Secure Boot. The required
steps vary from system to system because they depend on how the firmware implements the UEFI
specification, but the descriptions should give you an idea where to look.
System can become unbootable
If the operating systems installed on your machine do not provide UEFI boot loaders, or if those
boot loaders are not accepted by the new Secure Boot configuration because the signatures are
not recognized, your system will no longer boot after switching on Secure Boot.
2.1. Entering the UEFI firmware
When the system is booting, try pressing the Enter, Del, F1 or Esc keys. Usually, instructions will
appear telling you how to enter the firmware, similar to Figure 2.1, « Firmware activation instructions »
(which still refers to the UEFI firmware as BIOS Setup Utility, so you are expected to press F1).
┌───────────────────────────────────────────────────────────┐
│ Startup Interrupt Menu │
│───────────────────────────────────────────────────────────│
│ Press one of the following keys to continue: │
│ │
│ ESC to resume normal startup │
│ F1 to enter the BIOS Setup Utility │
│ F12 to choose a temporary startup device │
│ │
│ Press ENTER to continue │
│ │
└─────────────────────────────9─────────────────────────────┘
Figure 2.1. Firmware activation instructions
You may want to insert a USB stick to prevent a full operating system from booting, so that you can
reboot more quickly and try out different keys faster.
If the firmware is protected by a password and you do not know this password, you need to check your
system or mainboard manual for password reset instructions.
Once you have entered the firmware, a screen similar to Figure 2.2, « UEFI firmware start screen »
will be shown.
11Chapitre 2. System Configuration Brouillon
Lenovo BIOS Setup Utility
Main Devices Advanced Power Security Startup Exit
┌────────────────────────────────────────────────────────────────────────────────────────┐
│ │
│► System Summary │
│► System Time & Date │
│ │
│ Machine Type and Model 0896A9G │
│ System Brand ID Lenovo Product │
│ System Serial Number RUYWEQZ │
│ Asset Tag INVALID │
│ System UUID 1846F489-64F1-4714-83D8-A02FD2C79AD1 │
│ Ethernet MAC address D5-3D-7E-60-29-2C │
│ BIOS Revision Level F1KT44AUS │
│ Boot Block Revision Level F144A │
│ BIOS Date (MM/DD/YY) 12/21/2012 │
│ License Status │
│ Language [English] │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
└────────────────────────────────────────────────────────────────────────────────────────┘
F1 Help ↑↓ Select Item +/- Change Values F9 Setup Defaults
ESC Exit ←→ Select Menu Enter Select►Sub-Menu F10 Save and Exit
Figure 2.2. UEFI firmware start screen
2.2. Disabling UEFI Secure Boot
Systems which come with Microsoft Windows 8 pre-installed typically have enabled UEFI Secure
Boot, and ship the Microsoft keys in the firmware.
The Lenovo desktop system we use as an example makes disabling Secure Boot fairly
straightforward. First, enter the firmware as described in Section 2.1, « Entering the UEFI firmware ».
Press the → key until you reach the Security tab, as shown in Figure 2.3, « UEFI firmware Security
tab ».
12Brouillon Disabling UEFI Secure Boot
Lenovo BIOS Setup Utility
Main Devices Advanced Power Security Startup Exit
┌────────────────────────────────────────────────────────┬───────────────────────────────┐
│ │ Help Message │
│ Hardware Password Manager [Enabled] │───────────────────────────────│
│ Secure Boot Status [Enabled] │Select whether to enable or │
│ │disable Secure Boot │
│ Adminstrator Password Not Installed │[Enabled] Enable Secure │
│ Power-On Password Not Installed │Boot,BIOS will prevent │
│ │un-authorised OS be loaded. │
│ Set Administrator Password Enter │[Disable] Disables Secure │
│ Set Power-On Password Enter │Boot. │
│ │ │
│ Allow Flashing BIOS to a Previous [Yes] │ │
│ Version │ │
│ │ │
│ Require Admin. Pass. when Flashing [No] │ │
│ Require POP on Restart [No] │ │
│ │ │
│► Fingerprint Setup │ │
│► Hard Disk Password │ │
│► System Event Log │ │
│► Secure Boot │ │
│ │ │
│ Configuration Change Detection [Disabled] │ │
│ │ │
└────────────────────────────────────────────────────────┴───────────────────────────────┘
F1 Help ↑↓ Select Item +/- Change Values F9 Setup Defaults
ESC Exit ←→ Select Menu Enter Select►Sub-Menu F10 Save and Exit
Figure 2.3. UEFI firmware Security tab
Press ↓ until you reach the Secure Boot item and hit Enter. The Image Execution Policy screen
appears (Figure 2.4, « UEFI firmware Secure Boot settings »).
13Chapitre 2. System Configuration Brouillon
Lenovo BIOS Setup Utility
Main Devices Advanced Power Security Startup Exit
┌────────────────────────────────────────────────────────┬───────────────────────────────┐
│ Image Execution Policy │ Help Message │
│────────────────────────────────────────────────────────│───────────────────────────────│
│ Secure Boot Status User Mode │Select whether to enable or │
│ Secure Boot [Enabled] │disable Secure Boot │
│ │[Enabled] Enable Secure │
│ Reset to Setup Mode │Boot,BIOS will prevent │
│ │un-authorised OS be loaded. │
│ │[Disable] Disables Secure │
│ │Boot. │
│ │ │
│ │ . │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
└────────────────────────────────────────────────────────┴───────────────────────────────┘
F1 Help ↑↓ Select Item +/- Change Values F9 Setup Defaults
ESC Exit ←→ Select Menu Enter Select►Sub-Menu F10 Save and Exit
Figure 2.4. UEFI firmware Secure Boot settings
Make sure that Secure Boot is selected, and press Enter, hit ↑ to choose Disabled, and press Enter
again.
The previous step only disables verification of cryptographic signatures, it does not remove some
restrictions Microsoft imposes on firmware settings. If you want to boot non-UEFI operating systems, it
is necessary to disable the OS Optimized Defaults.
2.3. Enabling Microsoft Secure Boot
Systems which do not ship with Microsoft Windows 8 typically do not enable UEFI Secure Boot (or its
Microsoft variant). However, many of these systems still contain the Microsoft keys in the firmware,
and enabling Microsoft Secure Boot is relatively straightforward.
For example, on a Lenovo desktop system, you need to enter the firmware as described in
Section 2.1, « Entering the UEFI firmware ». Then press the → key until you reach the Exit tab, as
shown in Figure 2.5, « UEFI firmware Exit tab ».
14Brouillon Enabling Microsoft Secure Boot
Lenovo BIOS Setup Utility
Main Devices Advanced Power Security Startup Exit
┌────────────────────────────────────────────────────────┬───────────────────────────────┐
│ │ Help Message │
│ Save Changes and Exit │───────────────────────────────│
│ Discard Changes and Exit │Some settings below are │
│ │changed accordingly. Select │
│ Load Optimal Defaults │"Enabled" to meet Microsoft(R) │
│ OS Optimized Defaults [Disabled] │Windows 8 (R) Certification │
│ │Requirement. │
│ │Affected settings are CSM │
│ │Support, Boot mode, Boot │
│ │Priority, Secure Boot, Secure │
│ │RollBack Prevention. │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
└────────────────────────────────────────────────────────┴───────────────────────────────┘
F1 Help ↑↓ Select Item +/- Change Values F9 Setup Defaults
ESC Exit ←→ Select Menu Enter Select►Sub-Menu F10 Save and Exit
Figure 2.5. UEFI firmware Exit tab
Press ↓ to select the OS Optimized Defaults entry. Press Enter to change the settings. A confirmation
dialog will appear, and need to choose Yes. (See Figure 2.6, « UEFI firmware confirmation for OS
Optimized Defaults »).
15Chapitre 2. System Configuration Brouillon
Lenovo BIOS Setup Utility
Main Devices Advanced Power Security Startup Exit
┌────────────────────────────────────────────────────────┬───────────────────────────────┐
│ │ Help Message │
│ Save Changes and Exit │───────────────────────────────│
│ Discard Changes and Exit │Some settings below are │
│ │changed accordingly. Select │
│ Load Optimal Defaults │"Enabled" to meet Microsoft(R) │
│ OS Optimized Defaults ┌───────────────────────────────────────────┐Certification │
│ │ Attention! │ │
│ ├───────────────────────────────────────────┤ngs are CSM │
│ │ If OS Optimized Defaults is changed to │mode, Boot │
│ │ Enable, some settings including Secure │re Boot, Secure │
│ │ Boot,CSM,IPV4 and IPV6 will be changed. │ntion. │
│ │ Do you really want to continue? │ │
│ │ Select Yes to continue to Enable the OS │ │
│ │ Optimized Defaults. │ │
│ │ Select No to discontinue the operation. │ │
│ │ │ │
│ │ │ │
│ │ [Yes] [No] │ │
│ └───────────────────────────────────────────┘ │
│ │ │
│ │ │
│ │ │
│ │ │
└────────────────────────────────────────────────────────┴───────────────────────────────┘
F1 Help ↑↓ Select Item +/- Change Values F9 Setup Defaults
ESC Exit ←→ Select Menu Enter Select►Sub-Menu F10 Save and Exit
Figure 2.6. UEFI firmware confirmation for OS Optimized Defaults
Afterwards, check that OS Optimized Defaults has changed to Enabled. Press ← several times until
you reach the Security tab (Figure 2.3, « UEFI firmware Security tab »), press ↓ to select Secure Boot,
hit Enter, and check that Secure Boot is enabled, as in Figure 2.4, « UEFI firmware Secure Boot
settings ».
Return to the Exit tab, choose Save Changes and Exit, and press Enter. Confirm saving the settings,
and reboot. Microsoft Secure Boot is now enabled.
2.4. Known issues
When Fedora is installed on an UEFI system, existing boot loaders (for example, the code found in
the Master Boot Record) are not overwritten. Therefore, Fedora has considerably less control over the
boot process. In some cases, systems cannot dual-boot between Fedora and other operating systems.
Even if Fedora is selected manually in the firmware boot loader selection dialog (choose a temporary
startup device in Figure 2.1, « Firmware activation instructions »), the other operating system is
started. This is not a problem with UEFI Secure Boot; on the affected systems, it also happens with
Secure Boot disabled.
UEFI Secure Boot (and its Microsoft variant) require secure firmware updates. Typically, this is
implemented by writing a signed update to a staging area, where the firmware picks it up during the
next boot, verifies it, and then proceeds to overwrite the actual firmware. However, this process is
still far from foolproof and firmware updates still can make devices unusable, requiring a firmware
replacement.
16Brouillon Chapitre 3. Brouillon
Implémentation de Secure Boot UEFI
L'implémentation de Secure Boot dans Fedora met en œuvre deux méthodes pour un démarrage
sous ce mécanisme. La première méthode utilise le service d'homologation hébergé par Microsoft
pour fournir une copie du chargeur de démarrage shim signé avec les clés Microsoft. La deuxième
méthode est une généralisation de la première, dans laquelle un site ou un utilisateur peut créer ses
propres clés, les implanter dans le micrologiciel système et signer ses propres binaires.
3.1. Clés
La méthode faisant appel au service de signature de Microsoft est la plus simple. La clé utilisée par
Microsoft est embarquée sur tout matériel connu ; en conséquence, Fedora sera susceptible de
démarrer sur ce matériel sans problème. Il y a bien entendu des risques à devoir se fier à une tierce-
partie pour ce service. Fedora Project s'engage à suivre de près toute action dans ce domaine et à
répondre de manière appropriée à toute innovation.
L'utilisation de la clé dans l'implémentation Fedora peut se révéler déroutante eu égard à sa
complexité. Voici comment les divers composants sont signés.
Shim : il est signé par le service d'homologation UEFI. Nous n'avons pas de contrôle sur cette clé.
Le logiciel de calage (shim) contient la clé publique de démarrage de l'autorité de certification (CA)
Fedora.
GRUB : il est signé avec la clé « Fedora Boot Signer », en enchaînement de la clé de démarrage CA
de Fedora. GRUB ne contient aucune clé, il fait appel au logiciel de calage (shim) pour sa vérification.
Noyau : il est également signé avec « Fedora Boot Signer ». Le noyau contient la clé publique
utilisée pour signer les modules de noyau.
Modules de noyau : ils sont signés avec une clé privée générée lors de la construction. Cette clé n'est
pas enregistrée, une nouvelle clé est utilisée à chaque construction du noyau.
La clé publique de démarrage de l'autorité de certification (CA) Fedora est utilisée pour vérifier
l'intégrité de GRUB et du noyau. Vous pouvez actuellement trouver cette clé publique dans le paquet
source du logiciel de calage (shim). La voici en détail :
17Vous pouvez aussi lire
