Fedora 18

Guide UEFI Secure Boot

Josh Boyer

Kevin Fenzi

Peter Jones

Josh Bressers

Florian Weimer

Guide UEFI Secure Boot Brouillon

Fedora 18 Guide UEFI Secure BootÉdition 18.4

Auteur Josh Boyer jwboyer@redhat.comAuteur Kevin Fenzi kevin@fedoraproject.orgAuteur Peter Jones pjones@redhat.comAuteur Josh Bressers bressers@redhat.comAuteur 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 CommonsAttribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is availableat 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 withCC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for theoriginal 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 InfinityLogo, 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 Statesand/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and othercountries.

All other trademarks are the property of their respective owners.

Brouillon Brouillon

iii

Preface v1. Conventions d'écriture ..................................................................................................... v

1.1. Conventions typographiques ................................................................................. v1.2. Conventions pour citations mises en avant ........................................................... vii1.3. Notes et avertissements ...................................................................................... vii

2. Vos commentaires sont importants ! ............................................................................... viii

1. Qu'est-ce que UEFI Secure Boot ? 11.1. Secure Boot UEFI ........................................................................................................ 11.2. Prérequis de Microsoft pour Secure Boot ...................................................................... 2

1.2.1. Détails de l'implémentation ................................................................................. 31.3. Secure Boot Fedora ..................................................................................................... 71.4. De quoi vous protège Secure Boot ? ............................................................................. 71.5. Risques potentiels Secure Boot .................................................................................... 8

1.5.1. Fonctionnalités obligatoirement exclues en mode Secure Boot ............................. 81.5.2. Transformations du système en dehors de Secure Boot ....................................... 91.5.3. Pas d'infrastructure d'allocation derrière Microsoft Windows ................................. 91.5.4. Procédures de révocation supposées ................................................................. 9

2. System Configuration 112.1. Entering the UEFI firmware ......................................................................................... 112.2. Disabling UEFI Secure Boot ....................................................................................... 122.3. Enabling Microsoft Secure Boot .................................................................................. 142.4. Known issues ............................................................................................................. 16

3. Implémentation de Secure Boot UEFI 173.1. Clés ........................................................................................................................... 173.2. Shim .......................................................................................................................... 193.3. GRUB ........................................................................................................................ 203.4. Noyau ........................................................................................................................ 20

3.4.1. Restrictions ..................................................................................................... 20

4. Outils 234.1. Shim .......................................................................................................................... 234.2. Pesign ....................................................................................................................... 234.3. EFIKeyGen ................................................................................................................ 234.4. sign-file ...................................................................................................................... 23

5. Utilisation de vos propres clés 255.1. Création des clés ....................................................................................................... 255.2. Fabrication des clés pour la construction de shim ......................................................... 255.3. Paquets nécessitant une reconstruction ....................................................................... 255.4. Enregistrement de vos clés dans le micrologiciel .......................................................... 25

A. Historique de modification 27

Index 29

iv

Brouillon Brouillon

v

Preface

1. Conventions d'écritureCe 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 issusde Liberation Fonts1. 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 contiennentla police Liberation Fonts par défaut.

1.1. Conventions typographiquesQuatre conventions typographiques sont utilisées pour attirer l'attention sur certains mots etexpressions. 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 defichiers et les chemins d'accès. Également utilisé pour surligner les touches et les combinaisons detouches. Par exemple :

Pour consulter le contenu du fichier mon_nouvel_ouvrage_littérairequi se situe dans votre dossier courant, saisissez la commande catmon_nouvel_ouvrage_littéraire à la demande du terminal et appuyez surEntrée pour exécuter la commande.

L'exemple ci-dessus contient un nom de fichier, une commande-console et un nom de touche, touspré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 surCtrl+Alt+F1 pour retournez à votre session X-Windows.

Le premier paragraphe surligne la touche précise sur laquelle il faut appuyer. Le second surligne deuxcombinaisons 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 devariables et les valeurs de retour citées dans un paragraphe seront présentées comme ci-dessus, encaractères gras à espacement fixe. Par exemple :

Les classes de fichiers comprennent le nom de classe filesystem pour les nomsde 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/

Preface Brouillon

vi

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, descases à cocher et des boutons d'options mais aussi des intitulés de menus et de sous-menus. Parexemple :

Sélectionnez Système��� Préférences��� Souris à partir de la barre du menuprincipal 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 passerle bouton principal de la souris de la gauche vers la droite (ce qui permet l'utilisationde 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 menude Table de caractères, saisissez le nom du caractère dans le champ Rechercherpuis cliquez sur Suivant. Le caractère que vous recherchez sera surligné dans laTable de caractères. Double-cliquez sur le caractère surligné pour l'insérer dans lechamp Texte à copier, puis cliquez sur le bouton Copier. Maintenant, revenez à votredocument 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émentss'appliquant à l'ensemble du système, des boutons et textes que l'on trouve dans une interfacegraphique. Ils sont tous présentés sous la forme gras proportionnel et identifiables en fonction ducontexte.

Italique gras à espacement fixe ou Italique gras proportionnel

Qu'ils soient en caractères gras à espacement fixe ou à caractères gras proportionnels, l'ajout del'italique indique la présence de texte remplaçable ou variable. Les caractères en italique indiquent laprésence de texte que vous ne saisissez pas littéralement ou de texte affiché qui change en fonctiondes circonstances. Par exemple :

Pour se connecter à une machine distante en utilisant ssh, saisissez ssh nomd'utilisateur@domain.name (nom.domaine) après l'invite de commande dela console. Si la machine distante est exemple.com et que votre nom d'utilisateurpour cette machine est john, saisissez ssh john@example.com.

La commande mount -o remount système de fichiers monte le système defichiers nommé. Ainsi, pour monter /home dans le système de fichiers, la commandeest 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 lignede commande, soit pour le texte que vous saisissez suite à l'activation d'une commande, soit pour letexte affiché par le système.

Mis à part l'utilisation habituelle de présentation du titre d'un ouvrage, les caractères italiquesindiquent l'utilisation initiale d'un terme nouveau et important. Ainsi :

Publican est un système de publication DocBook.

Brouillon Conventions pour citations mises en avant

vii

1.2. Conventions pour citations mises en avantLes sorties de terminaux et les citations de code source sont mis en avant par rapport au texteavoisinant.

Les sorties envoyées vers un terminal sont en caractères Romains à espacement fixe etprésentées ainsi :

books Desktop documentation drafts mss photos stuff svnbooks_tests Desktop1 downloads images notes scripts svgs

Les citations de code source sont également présentées en romains à espacement fixe maissont 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 avertissementsEnfin, nous utilisons trois styles visuels pour attirer l'attention sur des informations qui auraient pu êtrenormalement 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, maisvous pourriez passer à côté d'une astuce qui vous aurait simplifiée la vie.

Preface Brouillon

viii

Important

Les blocs d'informations importantes détaillent des éléments qui pourraient être facilementnégligés : des modifications de configurations qui s'appliquent uniquement à la session actuelleou des services qui ont besoin d'être redémarrés avant toute mise à jour. Si vous ignorez unecase étiquetée « Important », vous ne perdrez aucunes données mais cela pourrait être sourcede frustration et d'irritation.

Avertissement

Un avertissement ne devrait pas être ignoré. Ignorer des avertissements risque fortementd'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 plusprécisément possible. Si vous avez trouvé une erreur, veuillez non seulement indiquer le numérode section où elle se trouve mais également ajouter un extrait du texte qui l'entoure, afin que nouspuissions la retrouver facilement.

Brouillon Chapitre 1. Brouillon

1

Qu'est-ce que UEFI Secure Boot ?Secure Boot est une technologie dans laquelle le micrologiciel système vérifie que le chargeur dedémarrage du système est signé avec une clé chiffrée autorisée par une base de donnée contenuedans le micrologiciel. Avec des vérifications de conformité de signature dans les phases suivantesde l'exécution du ou des chargeurs de démarrage, dans le noyau et, peut-être même, dans l'espaceutilisateur, 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 dedémarrage diffère d'un stockage sécurisé des clés de chiffrement ou d'une authentification à distance.

1.1. Secure Boot UEFISecure 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 pointssuivants :

• une interface de programmation pour des variables UEFI protégées par chiffrement dans unstockage 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 commemauvais.

Secure Boot UEFI ne nécessite pas de matériel spécialisé, sauf un stockage (flash) non volatilpouvant être basculé du mode lecture-écriture au mode lecture seule pendant le démarrage dusystème. Ce stockage est utilisé pour stocker l'implémentation de UEFI lui-même et quelques unesdes 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é à unprocessus de démarrage trafiqué, s'arrête simplement de fonctionner jusqu'à ce que Secure BootUEFI soit désactivé ou qu'une phase suivante correctement signée dans le chargeur de démarragesoit 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'exploitationsans signature chiffrée valide ne s'exécutent pas et se terminent par un message d'erreur. Aucunmoyen n'est offert à l'utilisateur pour contourner la décision de rejet de signature du chargeur dedémarrage, contrairement au scénario similaire avec les certificats des serveurs Web. Aucuneinformation 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

Chapitre 1. Qu'est-ce que UEFI Secure Boot ? Brouillon

2

Secure Boot UEFI n'empêche ni la mise en place ou l'enlèvement des logiciels exécutant la phase2 des chargeurs de démarrage, ni l'obligation d'une confirmation explicite de l'utilisateur pour detelles modifications. Les signatures sont vérifiées pendant le démarrage, et non quand le chargeur dedémarrage est installé ou mis à jour. Ainsi, Secure Boot UEFI n'empêche pas les manipulations duprocessus de démarrage. Il empêche uniquement le système d'exécuter un processus de démarragemodifié 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 pasrecommandé pour un déploiement sur des serveurs. Il est prévu que les technologies serveuractivent Secure Boot dans le futur.

1.2. Prérequis de Microsoft pour Secure BootMicrosoft 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 indispensablepour le faire fonctionner. Les systèmes dans un environnement Secure Boot UEFI démarrent encoresi la prise en charge de Secure Boot est supprimée de l'environnement UEFI. Les consommateurs quisouhaitent 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 BootMicrosoft semblent être :

• une protection de l'intégrité des médias d'installation stockés sur des supports inscriptibles (commeles 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èmea été compromis par un logiciel malveillant, sans complète réinstallation de la totalité du systèmed'exploitation.

Il est moins évident qu'il n'y ait pas des intentions de restreindre l'accès à certains contenus (enligne) aux systèmes ayant activé Secure Boot UEFI, systèmes dont le chiffrement du processus dedémarrage est valide. Ceci impliquerait un aspect d'attestation à distance qui ne fait pas partie desdirectives Secure Boot UEFI et qui ne pourrait pas être implémenté en toute sécurité sans une priseen charge matérielle supplémentaire. Cela impliquerait également que Secure Boot UEFI ne soit plusréellement optionnel.

Il n'est pas évident que Microsoft ait l'intention d'expulser quiconque avec leur implémentation deSecure Boot. Toutefois, la restauration automatique du processus originel de démarrage est beaucoupplus complexe à partir du moment où plusieurs chargeurs de démarrage coexistent sur un mêmesystème.

Brouillon Détails de l'implémentation

3

1.2.1. Détails de l'implémentationMicrosoft exige que les PC clients portant le logo Windows 8 activent Secure Boot UEFI et installentla clé matérielle fournie par Microsoft. Le certificat X.509 est affiché sur la Figure 1.2, « Certificat deconfiance Microsoft X.509 pour leur implémentation de Secure Boot ». Les vendeurs de systèmessont incités à inclure les autres certificats racine selon nécessité, mais il n'est pas obligatoire qu'ilssoient présents.

Chapitre 1. Qu'est-ce que UEFI Secure Boot ? Brouillon

4

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+gAwIBAgIKYQd2VgAAAAAACDANBgkqhkiG9w0BAQsFADCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEyMDAGA1UEAxMpTWljcm9zb2Z0IFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IDIwMTAwHhcNMTExMDE5MTg0MTQyWhcNMjYxMDE5MTg1MTQyWjCBhDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEuMCwGA1UEAxMlTWljcm9zb2Z0IFdpbmRvd3MgUHJvZHVjdGlvbiBQQ0EgMjAxMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN0Mu6LkLgnj58X3lmm8ACG9aTMz760Ey1SA7gaDu8UghNn30ovzOLCrpK0tfGJ5Bf/jSj8ENSBw48Tna+CcwDZ16Yox3Y1w5dw3tXRGlihbh2AjLL/cR6Vn91EnnnLrB6bJuR47UzV85dPsJ7mHHP65ySMJb6hGkcFuljxB08ujP10Cak3saR8lKFw2//1DFQqU4Bm0z9/CEuLCWyfuJ3gwi1sqCWsiiVNgFizAaB1TuuxJ851hjIVoCXNEXX2iVCvdefcVzzVdbBwrXM68nCOLb261Jtk2E8NP1ieuuTI7QZIs4cfNd+iqVE73XAsEh2W0QxiosuBtGXfsWiT6SAMCAwEAAaOCAUMwggE/MBAGCSsGAQQBgjcVAQQDAgEAMB0GA1UdDgQWBBSpKQI5jhbEl3jNkPmeT5rhfFWvUzAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBTV9lbLj+iiXGJo0T2UkFvXzpoYxDBWBgNVHR8ETzBNMEugSaBHhkVodHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL2NybC9wcm9kdWN0cy9NaWNSb29DZXJBdXRfMjAxMC0wNi0yMy5jcmwwWgYIKwYBBQUHAQEETjBMMEoGCCsGAQUFBzAChj5odHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL2NlcnRzL01pY1Jvb0NlckF1dF8yMDEwLTA2LTIzLmNydDANBgkqhkiG9w0BAQsFAAOCAgEAFPx8cVGlecJusu85Prw8Ug9uKz8QE3P+qGjQSKY0TYqWBSbuMUaQYXnW/zguRWv0wOUouNodj4rbCdcax0wKNmZqjOwb1wSQqBgXpJu54kAyNnbEwVrGv+QEwOoW06zDaO9irN1UbFAwWKbrfP6Up06O9Ox8hnNXwlIhczRa86OKVsgE2gcJ7fiL4870fo6u8PYLigj7P8kdcn9TuOu+Y+DjPTFlsIHl8qzNFqSfPaixm8JC0JCEX1Qd/4nquh1HkG+wc05Bn0CfX+WhKrIRkXOKISjwzt5zOV8+q1xg7N8DEKjTCen09paFtn9RiGZHGY2isBI9gSpoBXe7kUxie7bBB8e6eoc0Aw5LYnqZ6cr8zko3yS2kV3wc/j3cuA9a+tbEswKFAjrqs9lu5GkhN96B0fZ1GQVn05NXXikbOcjuLeHN5EVzW9DSznqrFhmCRljQXp2Bs2evbDXyvOU/JOI1ogp1BvYYVpnUeCzRBRvr0IgBnaoQ8QXfun4sY7cGmyMhxPl4bOJYFwY2K5ESA8yk2fItuvmUnUDtGEXxzopcaz6rA9NwGCoKauBfR9HVYwoy8q/XNh8qcFrlQlkIcUtXun6DgfAhPPQcwcW5kJMOiEWThumxIJm+mMvFlaRdYtagYwggvXUQd30980W5n5efy1eAbzOpBM93pGIcWX4=-----END CERTIFICATE-----

Figure 1.2. Certificat de confiance Microsoft X.509 pour leur implémentation de Secure Boot

Brouillon Détails de l'implémentation

5

On s'attend à ce que Microsoft joigne, éventuellement, des demandes de révocation signées dansles mises à jour de Windows. Ces requêtes en révocation seraient installées dans les variables deconfiguration Secure Boot UEFI lors du démarrage système suivant, après leur validation vis à vis dela 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 MicrosoftWindows 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. Ceservice a été également étendu aux chargeurs de démarrage tierce-partie. Microsoft revoit lesapplications à 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'estun pseudonyme), mais, plus important, elle est chaînée via le certificat intermédiaire MicrosoftCorporation UEFI CA 2011 (voir la Figure 1.3, « Certificat X.509 Microsoft pour application UEFI tiercepartie ») 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 lessystèmes Secure Boot Microsoft étant donné que les certificats nécessaires ne font pas partie dela spécification Secure Boot Microsoft.

Chapitre 1. Qu'est-ce que UEFI Secure Boot ? Brouillon

6

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/igAwIBAgIKYQjTxAAAAAAABDANBgkqhkiG9w0BAQsFADCBkTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjE7MDkGA1UEAxMyTWljcm9zb2Z0IENvcnBvcmF0aW9uIFRoaXJkIFBhcnR5IE1hcmtldHBsYWNlIFJvb3QwHhcNMTEwNjI3MjEyMjQ1WhcNMjYwNjI3MjEzMjQ1WjCBgTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjErMCkGA1UEAxMiTWljcm9zb2Z0IENvcnBvcmF0aW9uIFVFRkkgQ0EgMjAxMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKUIbEzHRQlqSwykwId/BnUMQwFUZOAWfwftkn0LsnO/DArGSkVhoMUWLZbT9Sug+01Jm0GAkDy5VP3mvNGdxKQYin9BilxZg2gyu4xHye5xvCFPmop8/0Q/jY8ysiZIrnW17slMHkoZfuSCmh14d00MsL32D9MW07z6K6VROF31+7rbeALb/+wKG5bVg7gZE+m2wHtAe+EfKCfJ+u9WXhzmfpR+wPBEsnk55dqyYotNvzhw4mgkFMkzpAg31VhpXtN87cEEUwjnTrAqh2MIYW9jFVnqsit51wxhZ4pb/V6th3+6hmdPcVgSIgQiIs6L71RxAM5QNVh2lQjuarGiAdUCAwEAAaOCAXYwggFyMBIGCSsGAQQBgjcVAQQFAgMBAAEwIwYJKwYBBAGCNxUCBBYEFPjBa7d/d1NK8yU3HU6hJnsPIHCAMB0GA1UdDgQWBBQTrb9DCb2CcJyM1U8xbtUimIob1DAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRFZlJD4X5YEb/WTp4jVQg7OiJqqDBcBgNVHR8EVTBTMFGgT6BNhktodHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL2NybC9wcm9kdWN0cy9NaWNDb3JUaGlQYXJNYXJSb29fMjAxMC0xMC0wNS5jcmwwYAYIKwYBBQUHAQEEVDBSMFAGCCsGAQUFBzAChkRodHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL2NlcnRzL01pY0NvclRoaVBhck1hclJvb18yMDEwLTEwLTA1LmNydDANBgkqhkiG9w0BAQsFAAOCAgEANQhC/zDMzvd2DK0QaFg1KUYydid87xJBJ0IbSqptgThIWRNV8+lYNKYWC4KqXa2C2oCDQQaPtB3yA7nzGl0b8VCQ+bNVhEIoHCC9sq5RFMXArJeVIRyQ2w/8d56Vc5GIyr29UrkFUA3fV56gYe0N5W0l2UAPF0DIzqNKwk2vmhIdCFSPvce8uSs9SSsfMvxqIWlPm8h+QjT8NgYXi48gQMCzmiV1J83JA6P2XdHnNlR6uVC10xLRB7+7dN/cHo+A1e0Y9C8UFmsv3maMsCPlx4TY7erBM4KtVksYLfFolQfNz/By8K673YaFmCwhTDMr8A9K8GiHtZJVMnWhaoJqPKMlEaTtrdcErsvYQFmghNGVTGKRIhp0HYw9Rw5EpuSwmzQ1sfq2U6gsgeykBXHInbi66BtEZuRHVA6OVn+znxaYsobQaD6QI7UvXo9QhY3GjYJfQaH0Lg3gmdJsdeS2abUhhvoH0fbiTdHarSx3Ux4lMjfHbFJylYaw8TVhahn1sjuBUFamMi3+oon5QoYnGFWhgspam/gwmFQUpkeWJS/IJuRBlBpcAj/lluOFWzw+P7tHFnJV4iUisdl75wMGKqP3HpBGwwAN1hmJ4w41J2IDcRWm79AnoKBZN2D4OJS44Hhw+LpMhoeU9uCuAkXuZcK2o35pFnUHkpv1prxZg1g=-----END CERTIFICATE-----

Figure 1.3. Certificat X.509 Microsoft pour application UEFI tierce partie

Brouillon Secure Boot Fedora

7

Un certificat signant du code régulier n'est pas suffisant pour garantir un démarrage sur un systèmeSecure Boot Microsoft. Microsoft exige un certificat de signature du code quand il communiqueavec 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 validationAuthentiCode ainsi que le chargement des modules noyau signés pour une tierce partie. Windowsdispose ainsi de l'infrastructure pour une validation des programmes dans l'espace utilisateur, ànouveau fondée sur AuthentiCode.

1.3. Secure Boot FedoraL'implémentation Secure Boot pour Fedora n'a qu'un seul objectif de sécurité : empêcher l'exécutionde code non signé en mode noyau.

Fedora peut s'exécuter sur des systèmes ayant Secure Boot Microsoft activé, pourvu que le certificatMicrosoft pour les applications UEFI tierce-partie soit installé. Ce mode opératoire est essentiel si onveut installer Fedora sur des machines préparées pour Windows 8. Les autres matériels ne sont passusceptibles 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 lescertificats nécessaires ne font pas partie des exigences de certification du matériel pourWindows 8. Si votre matériel entre dans cette catégorie, vous devez désactiver Secure BootUEFI, 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 dedémarrage s'exécutent aussi dans un environnement réalisant la validation du processus dedémarrage par des moyens autres (non-UEFI). Dans ce mode, il n'y aucun restriction pour exécuterdu 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 noyaudé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émarragenon 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 estdiffé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 intervientavant le chargement des modules du noyau, mais il n'est pas poursuivi jusqu'aux applications del'espace utilisateur. Nous pouvons être certains qu'aucun code exécutable non signé n'est présentjusqu'au moment où est chargé en mémoire le disque virtuel initial (initrd). Étant donné que lescontenus de initrd ne sont pas signés avec chiffrement et contiennent du code exécutable, démarreravec un chargeur de démarrage signé Fedora peut éventuellement causer des effets imprévisibles.

Chapitre 1. Qu'est-ce que UEFI Secure Boot ? Brouillon

8

L'implémentation Secure Boot Fedora simplifie la vérification du processus de démarrage dansle cadre d'investigations informatiques. Le démarrage traditionnel du BIOS exécute du codepotentiellement 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. (Lebénéfice réside pour partie dans la nature plus déclarative de la configuration de démarrage UEFI surle disque).

1.5. Risques potentiels Secure BootSecure Boot ne préserve pas votre PC de la plupart des logiciels ou personnes malveillantes. SecureBoot, lui-même, protège la phase de démarrage du système, mais ne défend pas contre les attaquessur votre système en cours de fonctionnement ou sur vos données. Dans Fedora si vous utilisezSecure Boot, vous pourrez restreindre le chargement dans le noyau de certains modules, maisaucune autre protection n'est mise en place vis à vis d'attaques par des logiciels malveillants dansl'espace utilisateur. L'image du disque virtuel (initrd) utilisée au cours du démarrage n'est pas protégéepar cette fonctionnalité ; le disque virtuel peut contenir du code malveillant.

1.5.1. Fonctionnalités obligatoirement exclues en mode SecureBootL'approche pour désactiver des fonctionnalités noyau connues pour être peu sûres consiste à lesinscrire 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 fonctionsconsigné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 certificatapproprié. Il est recommandé qu'un tel certificat soit généré sur site, en faisant attention aux pratiquesde sécurité éprouvées pour le stockage et l'utilisation d'un certificat de signature. En utilisant uncertificat propre au site, il peut être enregistré dans la base de données locale de la machine avecl'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.

Brouillon Transformations du système en dehors de Secure Boot

9

Avertissement

Il est essentiel, voire crucial, que des précautions appropriées soient prises lors de l'utilisationde certificats propres au site, de façon à ce qu'ils ne soient pas trouvés par une personnemalveillante pour saboter la sécurité du module. Traitez ces certificats comme vous le feriez pourtout secret primordial et suivez les pratiques recommandées dans l'industrie pour les clés dechiffrement et les certificats.

1.5.2. Transformations du système en dehors de Secure BootUne mise à jour du BIOS ou le remplacement d'une carte mère peut désactiver Secure Boot sur unsystème où il était précédemment activé. Un matériel supplémentaire installé sur une machine peutavoir des exigences incompatibles avec Secure Boot (DMA dans l'espace utilisateur, prise en chargede SystemTap, modules de noyau ne provenant pas de Red Hat). Ceci signifie que Secure Boot nepeut être un prérequis aux fonctionnalités du système ; il serait même extrêmement mal venu d'enfaire une politique obligatoire.

1.5.3. Pas d'infrastructure d'allocation derrière Microsoft WindowsQuelques fournisseurs de systèmes, selon certaines sources, obligeraient à installer Windows 8 pouractiver Secure Boot. Les acheteurs de ces systèmes qui voudraient faire fonctionner Secure Bootdevraient donc obtenir une licence client Windows 8, personnalisée par leur fournisseur système. Cescénario ne peut pas être pertinent, si Red Hat compte sur une racine de confiance séparée sousnotre contrôle, fournie en coopération avec des marchands de matériel.

1.5.4. Procédures de révocation supposéesNous ne savons actuellement pas si les processus des fonctions concernant la révocationfonctionnent vraiment. Les révocations sont complexes parce qu'elles doivent être synchroniséesentre fournisseurs de système d'exploitation pour prendre en charge des configurations à doubleamorçage. Sans une telle coordination, une signature sur processus de démarrage peut être révoquéeavant que le système d'exploitation sous-jacent ait une chance de la mettre à jour. Ce qui laisserait lesystè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èmesWindows 8 en dehors des laboratoires. Le dernier cas recouvre également les contournements deSecure Boot qui permettraient de charger du code non signé sur intervention de l'utilisateur.

10

Brouillon Chapitre 2. Brouillon

11

System ConfigurationThis chapter describes how to configure systems for use with UEFI Secure Boot. The requiredsteps vary from system to system because they depend on how the firmware implements the UEFIspecification, 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 thoseboot loaders are not accepted by the new Secure Boot configuration because the signatures arenot recognized, your system will no longer boot after switching on Secure Boot.

2.1. Entering the UEFI firmwareWhen the system is booting, try pressing the Enter, Del, F1 or Esc keys. Usually, instructions willappear 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 canreboot 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 yoursystem 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.

Chapitre 2. System Configuration Brouillon

12

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 BootSystems which come with Microsoft Windows 8 pre-installed typically have enabled UEFI SecureBoot, and ship the Microsoft keys in the firmware.

The Lenovo desktop system we use as an example makes disabling Secure Boot fairlystraightforward. 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 Securitytab ».

Brouillon Disabling UEFI Secure Boot

13

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 screenappears (Figure 2.4, « UEFI firmware Secure Boot settings »).

Chapitre 2. System Configuration Brouillon

14

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

The previous step only disables verification of cryptographic signatures, it does not remove somerestrictions Microsoft imposes on firmware settings. If you want to boot non-UEFI operating systems, itis necessary to disable the OS Optimized Defaults.

2.3. Enabling Microsoft Secure BootSystems which do not ship with Microsoft Windows 8 typically do not enable UEFI Secure Boot (or itsMicrosoft 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 inSection 2.1, « Entering the UEFI firmware ». Then press the → key until you reach the Exit tab, asshown in Figure 2.5, « UEFI firmware Exit tab ».

Brouillon Enabling Microsoft Secure Boot

15

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 confirmationdialog will appear, and need to choose Yes. (See Figure 2.6, « UEFI firmware confirmation for OSOptimized Defaults »).

Chapitre 2. System Configuration Brouillon

16

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 untilyou 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 Bootsettings ».

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 issuesWhen Fedora is installed on an UEFI system, existing boot loaders (for example, the code found inthe Master Boot Record) are not overwritten. Therefore, Fedora has considerably less control over theboot 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 temporarystartup device in Figure 2.1, « Firmware activation instructions »), the other operating system isstarted. This is not a problem with UEFI Secure Boot; on the affected systems, it also happens withSecure Boot disabled.

UEFI Secure Boot (and its Microsoft variant) require secure firmware updates. Typically, this isimplemented by writing a signed update to a staging area, where the firmware picks it up during thenext boot, verifies it, and then proceeds to overwrite the actual firmware. However, this process isstill far from foolproof and firmware updates still can make devices unusable, requiring a firmwarereplacement.

Brouillon Chapitre 3. Brouillon

17

Implémentation de Secure Boot UEFIL'implémentation de Secure Boot dans Fedora met en œuvre deux méthodes pour un démarragesous ce mécanisme. La première méthode utilise le service d'homologation hébergé par Microsoftpour fournir une copie du chargeur de démarrage shim signé avec les clés Microsoft. La deuxièmeméthode est une généralisation de la première, dans laquelle un site ou un utilisateur peut créer sespropres 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 parMicrosoft est embarquée sur tout matériel connu ; en conséquence, Fedora sera susceptible dedé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 à sacomplexité. 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 CAde 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é publiqueutilisé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'estpas 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érifierl'intégrité de GRUB et du noyau. Vous pouvez actuellement trouver cette clé publique dans le paquetsource du logiciel de calage (shim). La voici en détail :

Chapitre 3. Implémentation de Secure Boot UEFI Brouillon

18

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

Brouillon Shim

19

3.2. ShimFedora utilise en phase 1 du démarrage un logiciel de calage appelé « shim ». Il incorpore un certificatCA auto-certifié, qui est ensuite utilisé pour vérifier le chargeur de démarrage GRUB 2 (versionUEFI, 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 confiancesupplémentaires fournis par le propriétaire ainsi qu'un mécanisme pour désactiver la vérification designature. L'information est gardée dans des variables UEFI ne pouvant pas être modifiées une fois lesystème d'exploitation démarré. « Shim » comporte une vérification de présence physique ; il interrogepour 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 pasdémarrer le système : il n'est pas signé. Les résultats de la construction du paquet « shim » sontsignés, puis incorporés dans le paquet « shim » signé. Ce dernier contient le binaire signé capable dedémarrer le système.

Le paquet « shim » contient également une liste noire des mauvaises clés connues ou des binairesnon autorisés à s'exécuter. La liste noire est dans le fichier nommé dbx.esl du le paquet « shim ». Elleest, à l'heure actuelle, incorporée dans le binaire de « shim » à sa construction : ceci empêche uneversion qui exploiterait des failles connues de GRUB de démarrer. Des développements ultérieursverront peut-être l'intégration de cette liste noire dans la mémoire UEFI. Sous sa forme actuelle, unemise à jour de la liste noire ne procure aucune sécurité supplémentaire étant donné qu'il est possiblede déclasser le paquet « shim » pour éviter la mise à jour de la liste noire. Si la liste noire est stockéedans 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 pourvérification. Microsoft fournit cette liste à Fedora Project pour incorporation. Ceci peut avoir commeconséquence la création de mises à jour périodiques pour le paquet signé « shim » qui ne modifientpas 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 à jourle 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 à journon autorisée de cette liste. Microsoft suggère que cette liste noire soit utilisée pour empêcher ledé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é. Unefois 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édiairede « 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 biendéterminés,il vérifie les signatures des modules au moment de leur chargement ; il refuse de charger ceux nonsignés ou signés d'une signature non répertoriée dans les variables du magasin des clés UEFI (voir lanote),il refuse toute opération en provenance du domaine utilisateur qui tente, à partir de ce domaine, unaccès direct à la mémoire.

Chapitre 3. Implémentation de Secure Boot UEFI Brouillon

20

Des informations complémentaires à propos de « shim » peuvent être consultées sur le dépôtdéveloppement de « shim »1.

Note

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

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

3.4. NoyauLe noyau est signé avec la clé CA Fedora et est vérifié par « shim » avant que GRUB n'autorisel'exécution. Les modules que le noyau charge sont signés avec une clé créée au moment de laconstruction 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 signifieque des modules noyau tierce-partie, signés avec une clé authentifiée par UEFI (Microsoft), sechargeront 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 peutaussi contenir du code non signé de l'espace utilisateur. L'intégrité de ce code ne peut pas êtregarantie.

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 desutilisateurs ne noteront pas ces restrictions, étant donné que la plupart des paquets de l'espaceutilisateur, 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 machineayant activé Secure Boot. Ce sont :kexec/kdumpl'hibernation (suspension sur disque)des modules tierce-partie non signés ou signés avec des clés inconnuesle sondage du noyau avec systemtap (et kprobes)

1 https://github.com/mjg59/shim

Brouillon Restrictions

21

Note

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

Important

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

22

Brouillon Chapitre 4. Brouillon

23

OutilsPlusieurs outils ont été développés pour permettre à Fedora de fonctionner avec le micrologicielSecure 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 deMicrosoft), 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 noyauau moyen d'une authentification chiffrée par l'intermédiaire d'une clé de Fedora utilisée pour les signertous trois.

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

4.3. EFIKeyGen

4.4. sign-file

24

Brouillon Chapitre 5. Brouillon

25

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

26

Brouillon Brouillon

27

Annexe A. Historique de modificationVersion 18.4 Tue 11 March 2013 Eric Christensen

sparks@fedoraproject.org

Ajout de clarifications dans certaines parties.

Version 18.3 Tue 19 February 2013 Eric Christensensparks@fedoraproject.org

Incorporation d'informations du dépôt de Florian.Ajout des figures.

Version 18.2 Wed 06 February 2013 Eric Christensensparks@fedoraproject.org

Ajout de texte dans tous les chapitres pour incorporer des informations à propos des cléspubliques.

Version 18.1 Fri 04 January 2013 Eric Christensensparks@fedoraproject.org

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 0 Thu Jul 12 2012 Eric Christensensparks@fedoraproject.org

Création du livre avec publican

28

Brouillon Brouillon

29

Index

Cclés

expirationFedora 18, 21

Fedora Secure Boot CAclé publique, 17

GRUB, 17kernel, 17shim, 17

commentairescoordonnées pour ce manuel, viii

EEFIKeyGen

définition, 23

FFedora Secure Boot CA, 17

GGRUB

clé, 17intégrité, 17

Kkernel

clé, 17

Nnoyau

intégrité, 17

Ppesign

définition, 23sbsetup, 23

SSecure Boot

clés, 17(voir aussi clés)

implémentation, 17liste noire, 19restrictions, 20

shimclé, 17définition, 23explication, 19

sign-file

définition, 23

30