Product SiteDocumentation Site

Fedora 18

Guide UEFI Secure Boot

Édition 18.4

Josh Boyer

Projet Fedora

Kevin Fenzi

Projet Fedora

Peter Jones

Red Hat Équipe Installation

Josh Bressers

Red Hat Équipe Sécurité Produits

Florian Weimer

Red Hat Équipe Sécurité Produits

Publié par

Eric Christensen

Red Hat Équipe Sécurité Produits

Note légale

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.
Résumé

Preface
1. Conventions d'écriture
1.1. Conventions typographiques
1.2. Conventions pour citations mises en avant
1.3. Notes et avertissements
2. Vos commentaires sont importants !
1. Qu'est-ce que UEFI Secure Boot ?
1.1. Secure Boot UEFI
1.2. Prérequis de Microsoft pour Secure Boot
1.2.1. Détails de l'implémentation
1.3. Secure Boot Fedora
1.4. De quoi vous protège Secure Boot ?
1.5. Risques potentiels Secure Boot
1.5.1. Fonctionnalités obligatoirement exclues en mode Secure Boot
1.5.2. Transformations du système en dehors de Secure Boot
1.5.3. Pas d'infrastructure d'allocation derrière Microsoft Windows
1.5.4. Procédures de révocation supposées
2. System Configuration
2.1. Entering the UEFI firmware
2.2. Disabling UEFI Secure Boot
2.3. Enabling Microsoft Secure Boot
2.4. Known issues
3. Implémentation de Secure Boot UEFI
3.1. Clés
3.2. Shim
3.3. GRUB
3.4. Noyau
3.4.1. Restrictions
4. Outils
4.1. Shim
4.2. Pesign
4.3. EFIKeyGen
4.4. sign-file
5. Utilisation de vos propres clés
5.1. Création des clés
5.2. Fabrication des clés pour la construction de shim
5.3. Paquets nécessitant une reconstruction
5.4. Enregistrement de vos clés dans le micrologiciel
A. Historique de modification
Index

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 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.
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èmePréférencesSouris à 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 ApplicationsAccessoiresTable 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 ÉditionColler à 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.

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.

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.

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

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.

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.
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
DgQWBBSpKQI5jhbEl3jNkPmeT5rhfFWvUzAZBgkrBgEEAYI3FAIEDB4KAFMAdQBi
AEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBTV
9lbLj+iiXGJo0T2UkFvXzpoYxDBWBgNVHR8ETzBNMEugSaBHhkVodHRwOi8vY3Js
Lm1pY3Jvc29mdC5jb20vcGtpL2NybC9wcm9kdWN0cy9NaWNSb29DZXJBdXRfMjAx
MC0wNi0yMy5jcmwwWgYIKwYBBQUHAQEETjBMMEoGCCsGAQUFBzAChj5odHRwOi8v
d3d3Lm1pY3Jvc29mdC5jb20vcGtpL2NlcnRzL01pY1Jvb0NlckF1dF8yMDEwLTA2
LTIzLmNydDANBgkqhkiG9w0BAQsFAAOCAgEAFPx8cVGlecJusu85Prw8Ug9uKz8Q
E3P+qGjQSKY0TYqWBSbuMUaQYXnW/zguRWv0wOUouNodj4rbCdcax0wKNmZqjOwb
1wSQqBgXpJu54kAyNnbEwVrGv+QEwOoW06zDaO9irN1UbFAwWKbrfP6Up06O9Ox8
hnNXwlIhczRa86OKVsgE2gcJ7fiL4870fo6u8PYLigj7P8kdcn9TuOu+Y+DjPTFl
sIHl8qzNFqSfPaixm8JC0JCEX1Qd/4nquh1HkG+wc05Bn0CfX+WhKrIRkXOKISjw
zt5zOV8+q1xg7N8DEKjTCen09paFtn9RiGZHGY2isBI9gSpoBXe7kUxie7bBB8e6
eoc0Aw5LYnqZ6cr8zko3yS2kV3wc/j3cuA9a+tbEswKFAjrqs9lu5GkhN96B0fZ1
GQVn05NXXikbOcjuLeHN5EVzW9DSznqrFhmCRljQXp2Bs2evbDXyvOU/JOI1ogp1
BvYYVpnUeCzRBRvr0IgBnaoQ8QXfun4sY7cGmyMhxPl4bOJYFwY2K5ESA8yk2fIt
uvmUnUDtGEXxzopcaz6rA9NwGCoKauBfR9HVYwoy8q/XNh8qcFrlQlkIcUtXun6D
gfAhPPQcwcW5kJMOiEWThumxIJm+mMvFlaRdYtagYwggvXUQd30980W5n5efy1eA
bzOpBM93pGIcWX4=
-----END CERTIFICATE-----
Figure 1.2. Certificat de confiance Microsoft X.509 pour leur implémentation de Secure Boot

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.
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:
         […]
         92:9b:f5:a6:bc:59:83:58

-----BEGIN CERTIFICATE-----
MIIGEDCCA/igAwIBAgIKYQjTxAAAAAAABDANBgkqhkiG9w0BAQsFADCBkTELMAkG
A1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQx
HjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjE7MDkGA1UEAxMyTWljcm9z
b2Z0IENvcnBvcmF0aW9uIFRoaXJkIFBhcnR5IE1hcmtldHBsYWNlIFJvb3QwHhcN
MTEwNjI3MjEyMjQ1WhcNMjYwNjI3MjEzMjQ1WjCBgTELMAkGA1UEBhMCVVMxEzAR
BgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1p
Y3Jvc29mdCBDb3Jwb3JhdGlvbjErMCkGA1UEAxMiTWljcm9zb2Z0IENvcnBvcmF0
aW9uIFVFRkkgQ0EgMjAxMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AKUIbEzHRQlqSwykwId/BnUMQwFUZOAWfwftkn0LsnO/DArGSkVhoMUWLZbT9Sug
+01Jm0GAkDy5VP3mvNGdxKQYin9BilxZg2gyu4xHye5xvCFPmop8/0Q/jY8ysiZI
rnW17slMHkoZfuSCmh14d00MsL32D9MW07z6K6VROF31+7rbeALb/+wKG5bVg7gZ
E+m2wHtAe+EfKCfJ+u9WXhzmfpR+wPBEsnk55dqyYotNvzhw4mgkFMkzpAg31Vhp
XtN87cEEUwjnTrAqh2MIYW9jFVnqsit51wxhZ4pb/V6th3+6hmdPcVgSIgQiIs6L
71RxAM5QNVh2lQjuarGiAdUCAwEAAaOCAXYwggFyMBIGCSsGAQQBgjcVAQQFAgMB
AAEwIwYJKwYBBAGCNxUCBBYEFPjBa7d/d1NK8yU3HU6hJnsPIHCAMB0GA1UdDgQW
BBQTrb9DCb2CcJyM1U8xbtUimIob1DAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMA
QTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRFZlJD
4X5YEb/WTp4jVQg7OiJqqDBcBgNVHR8EVTBTMFGgT6BNhktodHRwOi8vY3JsLm1p
Y3Jvc29mdC5jb20vcGtpL2NybC9wcm9kdWN0cy9NaWNDb3JUaGlQYXJNYXJSb29f
MjAxMC0xMC0wNS5jcmwwYAYIKwYBBQUHAQEEVDBSMFAGCCsGAQUFBzAChkRodHRw
Oi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL2NlcnRzL01pY0NvclRoaVBhck1hclJv
b18yMDEwLTEwLTA1LmNydDANBgkqhkiG9w0BAQsFAAOCAgEANQhC/zDMzvd2DK0Q
aFg1KUYydid87xJBJ0IbSqptgThIWRNV8+lYNKYWC4KqXa2C2oCDQQaPtB3yA7nz
Gl0b8VCQ+bNVhEIoHCC9sq5RFMXArJeVIRyQ2w/8d56Vc5GIyr29UrkFUA3fV56g
Ye0N5W0l2UAPF0DIzqNKwk2vmhIdCFSPvce8uSs9SSsfMvxqIWlPm8h+QjT8NgYX
i48gQMCzmiV1J83JA6P2XdHnNlR6uVC10xLRB7+7dN/cHo+A1e0Y9C8UFmsv3maM
sCPlx4TY7erBM4KtVksYLfFolQfNz/By8K673YaFmCwhTDMr8A9K8GiHtZJVMnWh
aoJqPKMlEaTtrdcErsvYQFmghNGVTGKRIhp0HYw9Rw5EpuSwmzQ1sfq2U6gsgeyk
BXHInbi66BtEZuRHVA6OVn+znxaYsobQaD6QI7UvXo9QhY3GjYJfQaH0Lg3gmdJs
deS2abUhhvoH0fbiTdHarSx3Ux4lMjfHbFJylYaw8TVhahn1sjuBUFamMi3+oon5
QoYnGFWhgspam/gwmFQUpkeWJS/IJuRBlBpcAj/lluOFWzw+P7tHFnJV4iUisdl7
5wMGKqP3HpBGwwAN1hmJ4w41J2IDcRWm79AnoKBZN2D4OJS44Hhw+LpMhoeU9uCu
AkXuZcK2o35pFnUHkpv1prxZg1g=
-----END CERTIFICATE-----
Figure 1.3. Certificat X.509 Microsoft pour application UEFI tierce partie

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

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.

Chapitre 2. 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.
                                     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 ».
                                     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 »).
                                     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 ».
                                     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 »).
                                     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.

Chapitre 3. 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 :
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2574709492 (0x9976f2f4)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Fedora Secure Boot CA
        Validity
            Not Before: Dec  7 16:25:54 2012 GMT
            Not After : Dec  5 16:25:54 2022 GMT
        Subject: CN=Fedora Secure Boot CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ae:f5:f7:52:81:a9:5c:3e:2b:f7:1d:55:f4:5a:
                    68:84:2d:bc:8b:76:96:85:0d:27:b8:18:a5:cd:c1:
                    83:b2:8c:27:5d:23:0a:d1:12:0a:75:98:a2:e6:5d:
                    01:8a:f4:d9:9f:fc:70:bc:c3:c4:17:7b:02:b5:13:
                    c4:51:92:e0:c0:05:74:b9:2e:3d:24:78:a0:79:73:
                    94:c0:c2:2b:b2:82:a7:f4:ab:67:4a:22:f3:64:cd:
                    c3:f9:0c:26:01:bf:1b:d5:3d:39:bf:c9:fa:fb:5e:
                    52:b9:a4:48:fb:13:bf:87:29:0a:64:ef:21:7b:bc:
                    1e:16:7b:88:4f:f1:40:2b:d9:22:15:47:4e:84:f6:
                    24:1c:4d:53:16:5a:b1:29:bb:5e:7d:7f:c0:d4:e2:
                    d5:79:af:59:73:02:dc:b7:48:bf:ae:2b:70:c1:fa:
                    74:7f:79:f5:ee:23:d0:03:05:b1:79:18:4f:fd:4f:
                    2f:e2:63:19:4d:77:ba:c1:2c:8b:b3:d9:05:2e:d9:
                    d8:b6:51:13:bf:ce:36:67:97:e4:ad:58:56:07:ab:
                    d0:8c:66:12:49:dc:91:68:b4:c8:ea:dd:9c:c0:81:
                    c6:91:5b:db:12:78:db:ff:c1:af:08:16:fc:70:13:
                    97:5b:57:ad:6b:44:98:7e:1f:ec:ed:46:66:95:0f:
                    05:55
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            Authority Information Access:
                CA Issuers -
URI:https://fedoraproject.org/wiki/Features/SecureBoot

            X509v3 Authority Key Identifier:
                keyid:FD:E3:25:99:C2:D6:1D:B1:BF:58:07:33:5D:7B:20:E4:CD:96:3B:42

            X509v3 Extended Key Usage:
                Code Signing
            X509v3 Subject Key Identifier:
                FD:E3:25:99:C2:D6:1D:B1:BF:58:07:33:5D:7B:20:E4:CD:96:3B:42
    Signature Algorithm: sha256WithRSAEncryption
         37:77:f0:3a:41:a2:1c:9f:71:3b:d6:9b:95:b5:15:df:4a:b6:
         f4:d1:51:ba:0d:04:da:9c:b2:23:f0:f3:34:59:8d:b8:d4:9a:
         75:74:65:80:17:61:3a:c1:96:7f:a7:c1:2b:d3:1a:d6:60:3c:
         71:3a:a4:c4:e3:39:03:02:15:12:08:1f:4e:cd:97:50:f8:ff:
         50:cc:b6:3e:03:7d:7a:e7:82:7a:c2:67:be:c9:0e:11:0f:16:
         2e:1e:a9:f2:6e:fe:04:bd:ea:9e:f4:a9:b3:d9:d4:61:57:08:
         87:c4:98:d8:a2:99:64:de:15:54:8d:57:79:14:1f:fa:0d:4d:
         6b:cd:98:35:f5:0c:06:bd:f3:31:d6:fe:05:1f:60:90:b6:1e:
         10:f7:24:e0:3c:f6:33:50:cd:44:c2:71:18:51:bd:18:31:81:
         1e:32:e1:e6:9f:f9:9c:02:53:b4:e5:6a:41:d6:65:b4:2e:f1:
         cf:b3:b8:82:b0:a3:96:e2:24:d8:83:ae:06:5b:b3:24:74:4d:
         d1:a4:0a:1d:0a:32:1b:75:a2:96:d1:0e:3e:e1:30:c3:18:e8:
         cb:53:c4:0b:00:ad:7e:ad:c8:49:41:ef:97:69:bd:13:5f:ef:
         ef:3c:da:60:05:d8:92:fc:da:6a:ea:48:3f:0e:3e:73:77:fd:
         a6:89:e9:3f
Figure 3.1. Certificat X.509 Fedora signant le noyau et GRUB

3.2. Shim

Fedora utilise en phase 1 du démarrage un logiciel de calage appelé « shim ». Il incorpore un certificat CA auto-certifié, qui est ensuite utilisé pour vérifier le chargeur de démarrage GRUB 2 (version UEFI, un programme PE/COFF signé avec AuthentiCode). Avant de charger le noyau, GRUB 2 fait à nouveau appel à « shim » pour vérifier la signature AuthentiCode du noyau.
Outre la clé Microsoft, « shim » prend également en charge des certificats de confiance supplémentaires fournis par le propriétaire ainsi qu'un mécanisme pour désactiver la vérification de signature. L'information est gardée dans des variables UEFI ne pouvant pas être modifiées une fois le système d'exploitation démarré. « Shim » comporte une vérification de présence physique ; il interroge pour confirmation avant de mettre à jour les réglages stockés dans ces variables UEFI.
Dans Fedora, le logiciel de calage (shim) est constitué de deux paquets. Le paquet nommé « shim » est le résultat de la compilation du code source le constituant. Le logiciel de ce paquet ne peut pas démarrer le système : il n'est pas signé. Les résultats de la construction du paquet « shim » sont signés, puis incorporés dans le paquet « shim » signé. Ce dernier contient le binaire signé capable de démarrer le système.
Le paquet « shim » contient également une liste noire des mauvaises clés connues ou des binaires non autorisés à s'exécuter. La liste noire est dans le fichier nommé dbx.esl du le paquet « shim ». Elle est, à l'heure actuelle, incorporée dans le binaire de « shim » à sa construction : ceci empêche une version qui exploiterait des failles connues de GRUB de démarrer. Des développements ultérieurs verront peut-être l'intégration de cette liste noire dans la mémoire UEFI. Sous sa forme actuelle, une mise à jour de la liste noire ne procure aucune sécurité supplémentaire étant donné qu'il est possible de déclasser le paquet « shim » pour éviter la mise à jour de la liste noire. Si la liste noire est stockée dans le BIOS, une mise à jour de cette dernière survivra à un déclassement de « shim ».
En plus, il y a une liste noire maintenue et signée par Microsoft ; elle est stockée dans le BIOS pour vérification. Microsoft fournit cette liste à Fedora Project pour incorporation. Ceci peut avoir comme conséquence la création de mises à jour périodiques pour le paquet signé « shim » qui ne modifient pas le binaire réel de « shim ». Cette liste noire n'existe actuellement pas étant donné que rien n'y a été inscrit. La liste noire a été incorporée au paquet en tant que telle pour éviter d'avoir à mettre à jour le paquet signé « shim ».
Les détails à propos de cette liste noire proviennent de Microsoft ; Fedora Project n'est pas habilité pour la mettre à jour. La signature des données avec une clé Microsoft empêche toute mise à jour non autorisée de cette liste. Microsoft suggère que cette liste noire soit utilisée pour empêcher le démarrage de l'ordinateur avec des clés compromises ou des vulnérabilités connues.
Avec l'une ou l'autre méthode de démarrage, « shim », GRUB et le noyau détectent qu'ils ont été lancés dans ce que UEFI décrit comme étant un « mode utilisateur » avec Secure Boot activé. Une fois ce mode détecté, ils vont valider la phase suivante, avant son démarrage, à l'aide d'une clé publique de chiffrement spécifique à Fedora. La validation de GRUB s'effectue par l'intermédiaire de « shim » ; GRUB rappelle également « shim » pour valider le noyau. Une fois le noyau démarré, GRUB détecte qu'il est en mode Secure Boot, et en conséquence :
il valide la ligne de commande de démarrage pour n'autoriser que des réglages du noyau bien déterminés,
il vérifie les signatures des modules au moment de leur chargement ; il refuse de charger ceux non signés ou signés d'une signature non répertoriée dans les variables du magasin des clés UEFI (voir la note),
il refuse toute opération en provenance du domaine utilisateur qui tente, à partir de ce domaine, un accès direct à la mémoire.
Des informations complémentaires à propos de « shim » peuvent être consultées sur le dépôt développement de « shim ».

Note

D'autres distributions ont choisi de ne pas recourir à des modules noyau signés pour leur implémentation de Secure Boot. Fedora pense ce prérequis nécessaire pour une prise en charge complète de Secure Boot. Nous travaillons à limiter les impacts de ceci tout en assurant que des modules de code ne méritant pas la confiance ne soient pas autorisés à s'exécuter.

3.3. GRUB

GRUB est contenu dans le paquet grub2 et est signé avec la clé CA Fedora. Une fois le chiffrement du binaire vérifié, « shim » l'exécute. Le paquet GRUB ne contient aucune clé. Quand GRUB a besoin de vérifier l'intégrité du noyau, il refait appel à « shim » pour effectuer la vérification.

3.4. Noyau

Le noyau est signé avec la clé CA Fedora et est vérifié par « shim » avant que GRUB n'autorise l'exécution. Les modules que le noyau charge sont signés avec une clé créée au moment de la construction du noyau, puis détruite.
Le noyau importe la base de données des clés et l'utilise pour vérifier les modules noyau. Ceci signifie que des modules noyau tierce-partie, signés avec une clé authentifiée par UEFI (Microsoft), se chargeront dans le noyau, Secure Boot étant activé.

Important

Il est important de noter qu'une fois que le noyau a chargé le disque virtuel initial (initrd), l'exécution n'est plus « de confiance ». Même si initrd contient des modules noyau signés, il peut aussi contenir du code non signé de l'espace utilisateur. L'intégrité de ce code ne peut pas être garantie.

3.4.1. Restrictions

Des restrictions d'utilisation ont été mises en place pour une pleine conformité avec Secure Boot, qui exige d'empêcher toute exécution de code non vérifié au niveau superviseur. La plupart des utilisateurs ne noteront pas ces restrictions, étant donné que la plupart des paquets de l'espace utilisateur, qui faisaient usage de tels accès, ont été corrigés de manière à s'en dispenser. Il reste, toutefois, actuellement, quelques services ou fonctionnalités qui ne fonctionnent pas sur une machine ayant activé Secure Boot. Ce sont :
kexec/kdump
l'hibernation (suspension sur disque)
des modules tierce-partie non signés ou signés avec des clés inconnues
le sondage du noyau avec systemtap (et kprobes)

Note

Après de futures mises au point successives dans la prise en charge de Secure Boot, ce qui précède deviendra peut-être à nouveau possible ; toutefois des implémentations sûres n'étaient pas faisables dans le cadre de temps imparti pour Fedora 18. Si vous avez besoin de ces fonctionnalités, Secure Boot doit être désactivé.

Important

Actuellement, le logiciel de calage « shim » pour Fedora a été signé avec la date de péremption octobre 2013, antérieure à la fin de vie de Fedora 18. Nous n'avons pas connaissance d'un quelconque matériel qui honorerait cette date, mais là n'est pas la question. C'est la date fixée par Microsoft pour la signature, Fedora n'a aucun contrôle dessus. Nous enquêtons à ce propos et espérons résoudre ce problème dans un proche avenir.

Chapitre 4. Outils

Plusieurs outils ont été développés pour permettre à Fedora de fonctionner avec le micrologiciel Secure Boot UEFI.

4.1. Shim

« shim » est le logiciel signé par chiffrement qui crée la relation de confiance entre le micrologiciel, GRUB et le noyau. « shim » bénéficie d'une signature chiffrée Verisign (par l'intermédiaire de Microsoft), de sorte que le micrologiciel UEFI reconnaît la clé du système Fedora et autorise le logiciel à poursuivre le processus de démarrage. Le programme de calage « shim » valide GRUB et le noyau au moyen d'une authentification chiffrée par l'intermédiaire d'une clé de Fedora utilisée pour les signer tous trois.

4.2. Pesign

Pesign permet aux utilisateurs de créer leur propre programme de calage (shim) et d'utiliser leurs propres clés de chiffrement. Avec cet outil, quiconque peut créer son propre modèle de confiance sans passer par celui de Microsoft. Une fois que l'utilisateur a créé ses clés et signé son programme de calage et, éventuellement, signé et construit GRUB et le noyau, il peut utiliser le mode paramétrage du micrologiciel pour installer Fedora et utiliser l'outil sbsetup fourni par pesign pour enregistrer ses clés dans le micrologiciel.

4.3. EFIKeyGen

4.4. sign-file

Chapitre 5. Utilisation de vos propres clés

5.1. Création des clés

5.2. Fabrication des clés pour la construction de shim

5.3. Paquets nécessitant une reconstruction

5.4. Enregistrement de vos clés dans le micrologiciel

Historique de modification

Historique des versions
Version 18.4Tue 11 March 2013Eric Christensen
Ajout de clarifications dans certaines parties.
Version 18.3Tue 19 February 2013Eric Christensen
Incorporation d'informations du dépôt de Florian.
Ajout des figures.
Version 18.2Wed 06 February 2013Eric Christensen
Ajout de texte dans tous les chapitres pour incorporer des informations à propos des clés publiques.
Version 18.1Fri 04 January 2013Eric Christensen
Mise à jour du chapitre « Qu'est-ce que Secure Boot ». (BZ 891758)
Mise à jour du chapitre « Mise en œuvre ». (BZ 891924)
Mise à jour de l'adresse électronique de Josh Boyer. (BZ 891932)
Version 0Thu Jul 12 2012Eric Christensen
Création du livre avec publican

Index

C

clés
expiration
Fedora 18, Restrictions
Fedora Secure Boot CA
clé publique, Clés
GRUB, Clés
kernel, Clés
shim, Clés
commentaires
coordonnées pour ce manuel, Vos commentaires sont importants !

E

EFIKeyGen
définition, EFIKeyGen

F

Fedora Secure Boot CA, Clés

G

GRUB
clé, Clés
intégrité, Clés

K

kernel
clé, Clés

N

noyau
intégrité, Clés

P

pesign
définition, Pesign
sbsetup, Pesign

S

Secure Boot
clés, Clés
(voir aussi clés)
implémentation, Implémentation de Secure Boot UEFI
liste noire, Shim
restrictions, Restrictions
shim
clé, Clés
définition, Shim
explication, Shim
sign-file
définition, sign-file