Partager via

Instructions pour la création et la gestion des clés de démarrage sécurisé Windows

Ce document aide à guider les fabricants OEM et les ODM dans la création et la gestion des clés et certificats de démarrage sécurisé dans un environnement de fabrication. Il répond aux questions relatives à la création, au stockage et à la récupération de clés de plateforme (PK), aux clés de mise à jour de microprogramme sécurisées et aux clés d’échange de clés (KEK) tierces.

Remarque

Les OEM d’appareils, les entreprises et les clients trouveront les fichiers binaires des PK Microsoft, des KEK, des bases données et des DBX recommandés dans le référentiel open source de démarrage sécurisé de Microsoft. Les fichiers binaires sont mis en forme au format EDKII attendu pour s’intégrer facilement dans le microprogramme.

Remarque

L'autorité de certification KEK 2011 de Microsoft Corporation est défini pour expirer en 2026, et tous les OEM doivent créer, signer et envoyer des mises à jour à Microsoft pour la nouvelle autorité de certification KEK 2023 de Microsoft Corporation. Cela permettra à Microsoft de mettre à jour des appareils sur le marché avec la nouvelle autorité de certification KEK Microsoft, les systèmes pourront donc continuer à recevoir des mises à jour de base de données et de DBX après 2026. Pour obtenir des instructions et outils de test annexes, visitez https://aka.ms/KEKUpdatePackage

La configuration requise pour l'UEFI et le démarrage sécurisé se trouve dans les exigences de certification matérielle Windows. Ce document n’introduit pas de nouvelles exigences ni ne représente un programme Windows officiel. Il est destiné à fournir des conseils au-delà des exigences de certification, afin d’aider à créer et sécuriser des processus efficaces et sécurisés pour créer et gérer des clés de démarrage sécurisées. Cela est important, car le démarrage sécurisé UEFI est basé sur l’utilisation de l’infrastructure à clé publique en vue d'authentifier le code avant d’être autorisé à s’exécuter.

Le lecteur est censé connaître les principes fondamentaux de l’UEFI, la compréhension de base du Démarrage sécurisé (chapitre 27 de la spécification UEFI, et le modèle de sécurité PKI.

Les exigences, les tests et les outils qui valident le démarrage sécurisé sur Windows sont disponibles aujourd’hui via le Kit de certification matérielle Windows (HCK). Toutefois, ces ressources HCK n’abordent pas la création et la gestion des clés pour les déploiements Windows. Ce document abordent la gestion des clés en tant que ressource pour aider les partenaires à déployer les clés utilisées par le microprogramme. Il n’est pas destiné à des instructions prescriptives et n’inclut aucune nouvelle exigence.

Sur cette page :

Ce document sert de point de départ au développement de PC prêts pour les clients, d’outils de déploiement d’usine et de meilleures pratiques de sécurité clés.

1. Démarrage sécurisé, Windows et gestion des clés

La spécification UEFI (Unified Extensible Firmware Interface) définit un processus d’authentification d’exécution du microprogramme appelé Démarrage sécurisé. En tant que norme du secteur, le Démarrage sécurisé définit la façon dont le microprogramme de plateforme gère les certificats, authentifie le microprogramme et comment le système d’exploitation fait interface avec ce processus.

Le démarrage sécurisé est basé sur le processus PKI (Public Key Infrastructure) pour authentifier les modules avant qu’ils ne soient autorisés à s’exécuter. Ces modules peuvent inclure des pilotes de microprogramme, des ROM optionnelles, des pilotes UEFI sur disque, des applications UEFI ou des chargeurs de démarrage UEFI. Grâce à l’authentification d’image avant l’exécution, le Démarrage sécurisé réduit le risque d’attaques de programmes malveillants de pré-démarrage tels que les rootkits. Microsoft s’appuie sur le démarrage sécurisé UEFI dans Windows 8 et versions ultérieures dans le cadre de son architecture de sécurité de démarrage approuvée afin d’améliorer la sécurité de la plateforme pour nos clients. Le démarrage sécurisé est requis pour les PC clients Windows 8 et versions ultérieures, et pour Windows Server 2016, tel que défini dans la configuration requise pour la compatibilité matérielle Windows.

Le processus de démarrage sécurisé fonctionne comme suit et comme illustré dans la Figure 1 :

  1. Composants de démarrage du microprogramme : le microprogramme vérifie que le chargeur du système d’exploitation est approuvé (Windows ou un autre système d’exploitation approuvé).
  2. Composants de démarrage Windows : BootMgr, WinLoad, Démarrage du noyau Windows. Les composants de démarrage Windows vérifient la signature sur chaque composant. Tous les composants non approuvés ne sont pas chargés et déclenchent à la place la correction du démarrage sécurisé.
    • Initialisation de logiciels antivirus et anti-programme malveillant : une vérification de la signature spéciale émise par Microsoft est effectuée dans ce logiciel et indique qu'il s'agit d'un pilote critique de démarrage approuvé, il se lancera alors au début du processus de démarrage.
    • Initialisation du pilote de démarrage critique : les signatures sur tous les pilotes critiques de démarrage sont vérifiées dans le cadre de la vérification de démarrage sécurisé dans WinLoad.
  3. Initialisation supplémentaire du système d’exploitation
  4. Écran d’ouverture de session Windows

image de l’architecture d’intégrité de la plateforme

Figure 1 : Architecture de démarrage approuvé Windows

L’implémentation du démarrage sécurisé UEFI fait partie de l’architecture de démarrage approuvé de Microsoft, introduite dans Windows 8.1. Une tendance croissante dans l’évolution des attaques de programmes malveillants : le chemin d’amorçage est ciblé comme vecteur d’attaque préféré. Cette classe d’attaque a été difficile à protéger, car les produits anti-programme malveillant peuvent être désactivés par des logiciels malveillants qui les empêchent de se charger entièrement. Avec l’architecture de démarrage approuvé Windows et sa création d’une racine de confiance avec le Démarrage sécurisé, le client est protégé contre le code malveillant s’exécutant dans le chemin de démarrage en s’assurant que seul le code « connu » signé et les chargeurs de démarrage certifiés peuvent s’exécuter avant le chargement du système d’exploitation lui-même.

1.1 Infrastructure à clé publique (PKI) et démarrage sécurisé

L’infrastructure à clé publique établit l’authenticité et la confiance dans un système. Le démarrage sécurisé tire parti de l’infrastructure à clé publique en raison de deux objectifs généraux :

  1. Pendant le démarrage pour déterminer si les modules de démarrage précoces sont approuvés pour l’exécution.
  2. Pour authentifier les demandes de service, citons la modification des bases de données de démarrage sécurisé et les mises à jour du microprogramme de la plateforme.

Un PKI se compose des éléments suivants :

  • Autorité de certification (CA) qui émet les certificats numériques.
  • Une autorité d’inscription qui vérifie l’identité des utilisateurs demandant un certificat auprès de l’autorité de certification.
  • Répertoire central dans lequel stocker et indexer des clés.
  • Un système de gestion des certificats.

1.2 Cryptographie à clé publique

Le chiffrement à clé publique utilise une paire de clés de chiffrement mathématiquement associées, appelées clé publique et privée. Si vous connaissez l’une des clés, vous ne pouvez pas facilement calculer ce que l’autre est. Si une clé est utilisée pour chiffrer les informations, seule la clé correspondante peut déchiffrer ces informations. Pour le démarrage sécurisé, la clé privée est utilisée pour signer numériquement le code, la clé publique est utilisée pour vérifier la signature de ce code pour prouver son authenticité. Lorsqu'une clé privée est compromise, les systèmes dotés de clés publiques correspondantes ne sont plus sécurisés. Cela peut entraîner des attaques de kit de démarrage et endommagera la réputation de l’entité chargée d'assurer la sécurité de la clé privée.

Dans un système de clés publiques de démarrage sécurisé, vous disposez des éléments suivants :

  • 1.2.1 Chiffrement RSA 2048

    RSA 2048 est un algorithme de chiffrement asymétrique. L’espace nécessaire pour stocker un module RSA 2048 sous forme brute est de 2 048 bits.

  • 1.2.2 Certificat auto-signé

    Un certificat signé par la clé privée qui correspond à la clé publique du certificat est appelé certificat auto-signé. Les certificats d’autorité de certification (CA) racine appartiennent à cette catégorie.

  • 1.2.3 Autorité de certification

    L’autorité de certification émet des certificats signés qui affirment l’identité de l’objet du certificat et lient cette identité à la clé publique contenue dans le certificat. L’autorité de certification signe le certificat à l’aide de sa clé privée. Elle émet la clé publique correspondante à toutes les parties intéressées dans un certificat d’autorité de certification racine auto-signé.

    Dans le démarrage sécurisé, les autorités de certification (AUTORITÉS de certification) incluent l’OEM (ou leurs délégués) et Microsoft. Les autorités de certification génèrent les paires de clés formant la racine de confiance, puis utilisent les clés privées pour signer des opérations légitimes comme les modules EFI de démarrage précoce autorisés ainsi que les demandes de maintenance du microprogramme. Les clés publiques correspondantes sont incorporées dans le microprogramme UEFI sur les PC avec démarrage sécurisé, elles y sont utilisées pour vérifier ces opérations.

    (Vous trouverez facilement d'autres informations sur l’utilisation des autorités de certification et des échanges clés sur Internet, celles-ci abordent le modèle de démarrage sécurisé.)

  • 1.2.4 Clé publique

    La clé de plateforme publique est fournie sur le PC, elle est accessible ou « publique ». Dans ce document, nous allons utiliser le suffixe « pub » pour désigner la clé publique. Par exemple, PKpub désigne la moitié publique de la PK.

  • 1.2.5 Clé privée

    Pour que l’infrastructure à clé publique fonctionne, la clé privée doit être gérée en toute sécurité. Elle doit être accessible à quelques personnes hautement approuvées dans une organisation et situées dans un emplacement physiquement sécurisé, soumis à des restrictions de stratégie d’accès fortes en place. Dans ce document, nous allons utiliser le suffixe « priv » pour désigner la clé privée. Par exemple, la PKpriv indique la moitié privée de la PK.

  • 1.2.6 Certificats

    L’utilisation principale pour les certificats numériques consiste à vérifier l’origine des données signées comme les fichiers binaires. Une utilisation courante des certificats est destinée à la sécurité des messages Internet à l’aide du protocole TLS (Transport Layer Security) ou SSL (Secure Sockets Layer). La vérification des données signées avec un certificat permet au destinataire de connaître l’origine des données et s’il elles ont été modifiées en transit.

    Un certificat numérique en général contient, à un niveau élevé, un nom unique (DN), une clé publique et une signature. Le nom de domaine identifie une entité (une entreprise, par exemple) qui contient la clé privée correspondant à la clé publique du certificat. Signer le certificat avec une clé privée et placer la signature dans le certificat lie la clé privée à la clé publique.

    Les certificats peuvent contenir d'autres types de données. Par exemple, un certificat X.509 inclut le format du certificat, le numéro de série du certificat, l'algorithme utilisé pour signer le certificat, le nom de l'autorité de certification qui a publié le certificat, le nom et la clé publique de l'entité qui demande le certificat, et la signature de l'autorité de certification.

  • 1.2.7 Certificats de chaînage

    De : Chaînes de certificats :

    l'autorité de certification racine est auto-signée, d’autres éléments signés par l’autorité de certification racine

    Figure 2 : Chaîne à trois certificats

    Les certificats utilisateur sont souvent signés par une clé privée différente, comme une clé privée de l’autorité de certification. Il s’agit d’une chaîne à deux certificats. Vérifier qu’un certificat utilisateur est authentique implique de vérifier sa signature, ce qui nécessite la clé publique de l’autorité de certification à partir de son certificat. Toutefois, avant de pouvoir valider la clé publique de l’autorité de certification, le certificat d’autorité de certification englobant doit être vérifié. Étant donné que le certificat d’autorité de certification est auto-signé, la clé publique de l’autorité de certification est utilisée pour vérifier le certificat.

    Un certificat utilisateur n’a pas besoin d’être signé par la clé privée de l’autorité de certification racine. Il peut être signé par la clé privée d’un intermédiaire dont le certificat est signé par la clé privée de l’autorité de certification. Il s’agit d’une instance d’une chaîne de trois certificats : certificat utilisateur, certificat intermédiaire et certificat d’autorité de certification. Plusieurs intermédiaires peuvent cependant faire partie de la chaîne, de sorte que les chaînes de certificats peuvent être de toute longueur.

1.3 Configuration requise pour l'infrastructure de clé publique sécurisée

La racine de confiance définie par l'UEFI se compose de la clé de plateforme et de toutes les clés qu’un OEM ou ODM inclut dans le cœur du microprogramme. La sécurité pré-UEFI et la racine de confiance ne sont pas traitées par le processus de démarrage sécurisé UEFI, mais plutôt par les publications du National Institute of Standards and Technology (NIST) ainsi que les publications du Trusted Computing Group (TCG) référencées dans ce document.

  • 1.3.1 Démarrage sécurisé

    Vous devez prendre en compte les paramètres suivants pour implémenter le démarrage sécurisé :

    • Spécifications du client
    • Configuration requise pour la compatibilité matérielle Windows
    • Exigences de génération et de gestion des clés.

    Vous devrez choisir du matériel pour la gestion des clés de démarrage sécurisé, il peut s'agit de Modules de sécurité matériel (HSM), envisagez des exigences particulières sur les PC à expédier aux membres du gouvernement et à d’autres organismes, et enfin le processus de création, de remplissage et de gestion du cycle de vie de différentes clés de démarrage sécurisé.

  • 1.3.2 Clés liées au démarrage sécurisé

    Les clés utilisées pour le démarrage sécurisé sont les suivantes :

    pk, kek, base de données, dbx et clé de microprogramme, clé winrt

    Figure 3 : Clés liées au démarrage sécurisé

    La Figure 3 ci-dessus représente les signatures et les clés d’un PC avec démarrage sécurisé. La plateforme est sécurisée par le biais d’une clé de plateforme que l’OEM installe dans le microprogramme pendant la fabrication. D’autres clés sont utilisées par le démarrage sécurisé pour protéger l’accès aux bases de données qui stockent les clés pour autoriser ou interdire l’exécution du microprogramme.

    La base de données autorisée (db) contient des clés publiques et des certificats représentant des composants de microprogramme et des chargeurs de système d’exploitation de confiance. La base de données de signature interdite (dbx) contient des hachages de composants malveillants et vulnérables, ainsi que des clés et des certificats compromis et bloque l’exécution de ces composants malveillants. La force de ces stratégies se base sur la signature du microprogramme à l’aide d’Authenticode et de l’infrastructure à clé publique (PKI). L’infrastructure à clé publique est un processus bien établi pour la création, la gestion et la révocation de certificats établissant l’approbation lors de l’échange d’informations. L’infrastructure à clé publique est au cœur du modèle de sécurité pour le démarrage sécurisé.

    Vous trouverez ci-dessous davantage d’informations sur ces clés.

  • 1.3.3 Clé de plateforme (PK)

    Conformément à la section 27.5.1 de l’UEFI 2.3.1 Errata C, la clé de plateforme établit une relation d’approbation entre le propriétaire de la plateforme et le microprogramme de la plateforme. Le propriétaire de la plateforme inscrit la moitié publique de la clé (PKpub) dans le microprogramme de la plateforme, comme spécifié dans la Section 7.2.1 de l’UEFI 2.3.1 Errata C. Cette étape déplace la plateforme en mode utilisateur à partir du mode d’installation. Microsoft recommande que la clé de plateforme soit de type EFI_CERT_X509_GUID avec l’algorithme de clé publique RSA, la longueur de clé publique de 2 048 bits et l’algorithme de signature sha256RSA. Le propriétaire de la plateforme peut utiliser le type EFI_CERT_RSA2048_GUID lorsque l’espace de stockage est un problème. Les clés publiques sont utilisées pour vérifier les signatures, comme décrit précédemment dans ce document. Le propriétaire de la plateforme peut ensuite utiliser la moitié privée de la clé (PKpriv) :

    • Pour modifier la propriété de la plateforme, vous devez placer le microprogramme en mode d’installation défini par l'UEFI, ce qui désactive le démarrage sécurisé. Rétablissez le mode d’installation uniquement s’il est nécessaire de le faire pendant la fabrication.
    • Pour les appareils de bureau et de serveurs, les OEM peuvent gérer les PK et l’infrastructure PKI nécessaire associées, ou choisir d’utiliser la PK gérée par Microsoft pour les OEM. La PK gérée par Microsoft est protégée par les modules HSM Microsoft et gérée dans le cadre des meilleures pratiques de PKI. Il s’agit de la PK préférée pour l’écosystème Windows.

    1.3.3.1 Pour inscrire ou mettre à jour une clé d’échange de clés (KEK) en inscrivant la clé de plateforme

    Le propriétaire de la plateforme inscrit la moitié publique de la clé de plateforme (PKpub) en appelant le service de démarrage UEFI SetVariable() comme spécifié dans la section 7.2.1 de la spécification UEFI 2.3.1 errata C et en réinitialisant la plateforme. Si la plateforme est en mode d’installation, la nouvelle PKpub doit être signée avec sa PKpriv équivalente. Si la plateforme est en mode utilisateur, la nouvelle PKpub doit être signée avec la PKpriv actuelle. Si la PK est de type EFI_CERT_X509_GUID, elle doit être signée par la PKpriv immédiate, et non par une clé privée d’un certificat émis sous la PK.

    1.3.3.2 Effacer la clé de plateforme

    Le propriétaire de la plateforme efface la moitié publique de la clé de plateforme (PKpub) en appelant le programme UEFI Boot Service SetVariable() avec une taille variable de 0 et en réinitialisant la plateforme. Si la plateforme est en mode d’installation, la variable vide ne nécessite pas d’authentification. Si la plateforme est en mode utilisateur, la variable vide doit être signée avec la PKpriv actuelle ; pour plus d’informations, consultez la section 7.2 (Services de variables) sous les Spécifications de l'UEFI, section 2.3.1 Errata C. Il est fortement recommandé que la PKpriv de production ne soit jamais utilisée pour signer un package de réinitialisation de la plateforme, car cela permet au démarrage sécurisé d’être désactivé par programmation. Il s’agit principalement d’un scénario de test de préproduction.

    La clé de plateforme peut également être effacée à l’aide d’une méthode sécurisée spécifique à la plateforme. Dans ce cas, le mode d’installation de variable globale doit également être remplacé par 1.

    image : la PK détermine le mode d’installation ou le mode utilisateur

    Figure 4 : Diagramme d’état de clé de plateforme

    1.3.3.3 Génération de la PK

    Conformément aux recommandations de l'UEFI, la clé publique doit être stockée dans un stockage non volatile qui est résistant à la falsification et à la suppression sur le PC. Les clés privées restent sécurisées au niveau du partenaire ou dans le Bureau de sécurité de l’OEM, seule la clé publique est par ailleurs chargée sur la plateforme. Davantage de détails se trouvent dans les sections 2.2.1 et 2.3.

    Microsoft fournit une PK pour les OEM afin d’éliminer toute responsabilité liée à la maintenance et la sécurisation du certificat de PK. La PK est protégée par les HSM Microsoft et gérée dans le cadre de nos opérations PKI Microsoft.

    Le nombre de PK générées est à la discrétion du propriétaire de la plateforme (OEM). Ces clés peuvent être les suivantes :

    1. Une par PC. Disposer d'une clé unique pour chaque appareil. Cela peut être nécessaire pour les agences gouvernementales, les institutions financières ou d’autres clients serveurs ayant des besoins de sécurité élevés. Il peut nécessiter une puissance de stockage et de traitement de chiffrement supplémentaire pour la génération de privées et publiques pour un grand nombre de PC. Cela ajoute la complexité du mappage des appareils avec leur PK correspondantes lors de l’envoi de mises à jour du microprogramme aux appareils à l’avenir. Il existe quelques solutions HSM différentes pour gérer un grand nombre de clés en fonction du fournisseur HSM. Pour plus d’informations, consultez Génération de clés de démarrage sécurisé à l’aide du HSM.

    2. Une par modèle. Avoir une clé par modèle de PC. Le compromis ici est que si une clé est compromise, toutes les machines au sein du même modèle deviendraient vulnérables. Il est recommandé par Microsoft pour les PC de bureau.

    3. Une par ligne de produit. Si une clé est compromise, toute une gamme de produits deviendrait vulnérable.

    4. Une par OEM. Bien que ce soit le plus simple à configurer, si la clé est compromise, chaque PC que vous fabriquez serait vulnérable. Pour accélérer l’opération au niveau de l’usine, la PK et potentiellement d’autres clés peuvent être générées et stockées dans un emplacement sûr. Celles-ci peuvent être récupérées et utilisées ultérieurement dans la ligne d’assemblage. Les chapitres 2 et 3 apportent davantage de détails.

    1.3.3.4 Renouvellement de PK

    Cela peut être nécessaire si la PK est compromise ou en tant que condition requise par un client qui, pour des raisons de sécurité, peut décider d’inscrire sa propre PK.

    La génération de nouvelles clés peut être effectuée pour un modèle ou un PC en fonction de la méthode sélectionnée pour créer la PK. Tous les PC plus récents seront signés avec la nouvelle PK créée.

    La mise à jour de la PK sur un PC de production nécessite une mise à jour de variable signée avec la PK existante qui remplace la PK ou un package de mise à jour du microprogramme. Un OEM peut également créer un package SetVariable() et le distribuer avec une application simple telle que PowerShell, qui modifie simplement la PK. Le package de mise à jour du microprogramme est signé par la clé de mise à jour du microprogramme sécurisée, il est par ailleurs vérifié par microprogramme. Si vous effectuez une mise à jour du microprogramme pour mettre à jour la PK, veillez à ce que la clé KEK, la base de données et la dbx soient conservées.

    Sur tous les PC, il est recommandé de ne pas utiliser la PK comme clé de mise à jour de microprogramme sécurisée. Si la PKpriv est compromise, il en est de même pour la clé de mise à jour du microprogramme sécurisée (car elles sont identiques). Dans ce cas, la mise à jour pour inscrire une nouvelle PKpub peut ne pas être possible, car le processus de mise à jour a également été compromis.

    Sur les PC de SOC, il existe une autre raison de ne pas utiliser la PK comme clé de mise à jour de microprogramme sécurisée. Cela est dû au fait que la clé de mise à jour du microprogramme sécurisée est définitivement brûlée dans des fusibles sur les PC qui répondent aux exigences de certification matérielle Windows.

  • 1.3.4 Clés d’échange de clés (KEK) établissent une relation d’approbation entre le système d’exploitation et le microprogramme de la plateforme. Chaque système d’exploitation (et potentiellement chaque application tierce qui doit communiquer avec le microprogramme de plateforme) inscrit une clé publique (KEKpub) dans le microprogramme de la plateforme.

    1.3.4.1 Inscription de clés d’échange de clés

    Les clés d’échange de clés sont stockées dans une base de données de signature, comme décrit dans 1.4 Bases de données de signatures (base de données et dbx)). La base de données de signatures est stockée en tant que variable UEFI authentifiée.

    Le propriétaire de la plateforme inscrit les clés d’échange de clés en appelant SetVariable() comme spécifié dans la section 7.2 (Services de variables) sous les spécifications UEFI 2.3.1 Errata C. avec le jeu d'attributs EFI_VARIABLE_APPEND_WRITE et le paramètre Données contenant les nouvelles clés ou en lisant la base de données à l’aide de GetVariable(), en ajoutant la nouvelle clé d’échange de clé aux clés existantes, puis en écrivant la base de données à l’aide de SetVariable() comme spécifié dans la section 7.2 (Services de variables) sous les spécifications UEFI 2.3.1 Errata C sans le jeu d’attributs EFI_VARIABLE_APPEND_WRITE.

    Si la plateforme est en mode d’installation, la variable de base de données de signature n’a pas besoin d’être signée, mais les paramètres de l’appel SetVariable() doivent toujours être préparés de la façon spécifiée pour les variables authentifiées dans la section 7.2.1. Si la plateforme est en mode utilisateur, la nouvelle base de données de signatures doit être signée avec la PKpriv actuelle.

    1.3.4.2 Effacer la clé KEK

    Il est possible d'« effacer » (supprimer) la clé KEK. Notez que si la PK n’est pas installée sur la plateforme, les requêtes « effacer » ne nécessitent pas une signature. Si elles sont signées, pour effacer la clé KEK, il faut un package signé par PK, et pour effacer la base de données ou dbx, un package signé par n’importe quelle entité présente dans la clé KEK.

    1.3.4.3 KEK Microsoft

    Le certificat Microsoft KEK suivant est requis pour activer la révocation d’images incorrectes en mettant à jour dbx et potentiellement pour mettre à jour la base de données afin de préparer les images signées Windows plus récentes.

  1. Autorité de certification KEK 2K 2023 de Microsoft Corporation

    • Hachage de certificat SHA-1 : 459AB6FB5E284D272D5E3E6ABC8ED663829D632B.
    • GUID SignatureOwner : {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Microsoft fournira le certificat aux partenaires et peut être ajouté en tant que signature de type EFI_CERT_X509_GUID ou EFI_CERT_RSA2048_GUID.
    • Le certificat KEK Microsoft peut être téléchargé à partir de l'adresse https://go.microsoft.com/fwlink/?linkid=2239775.

1.3.4.4 KEKDefault Le fournisseur de la plateforme doit fournir un ensemble de clés d'échange de clés par défaut dans la variable KEKDefault. Pour plus d’informations, reportez-vous aux spécifications UEFI de la section 27.3.3.

1.3.4.5 Clé d'échange de clés OEM/tierce - ajout de plusieurs KEK

Les clients et les propriétaires de plateforme n’ont pas besoin d’avoir leur propre clé KEK. Sur les PC non Windows RT, l’OEM peut avoir des clés KEK supplémentaires pour autoriser un autre OEM ou un contrôle tiers approuvé de la base de données et dbx.

  • 1.3.5 Clé de mise à jour du microprogramme de démarrage sécuriséLa clé de mise à jour du microprogramme sécurisé permet de signer le microprogramme lorsqu’il doit être mis à jour. Cette clé doit avoir une puissance de clé minimale de RSA 2048. Toutes les mises à jour du microprogramme doivent être signées en toute sécurité par l’OEM, leur délégué approuvé tel que ODM ou IBV (fournisseur de BIOS indépendant) ou par un service de signature sécurisé.

    Conformément à la publication NIST 800-147, la mise à jour de micrologiciel de champ doit prendre en charge tous les éléments des instructions :

    Toute mise à jour du magasin flash du microprogramme doit être signée par le créateur.

    Le microprogramme doit vérifier la signature de la mise à jour.

  • 1.3.6 Création de clés pour la mise à jour sécurisée du microprogramme

    La même clé sera utilisée pour signer toutes les mises à jour du microprogramme, car la moitié publique résidera sur le PC. Vous pouvez également signer la mise à jour du microprogramme avec une clé qui se chaîne à la clé de mise à jour du microprogramme sécurisée.

    Il peut y avoir une clé par PC, comme une PK, ou une par modèle ou un par ligne de produit. S’il existe une clé par PC, ce qui signifierait que des millions de packages de mise à jour uniques devront être générés. Tenez compte de la disponibilité des ressources selon la méthode qui vous convient. Avoir une clé par modèle ou ligne de produit est un bon compromis.

    La clé publique de mise à jour du microprogramme sécurisée (ou son hachage pour économiser de l’espace) serait stockée dans un stockage protégé sur la plateforme, il s'agit généralement d'un flash protégé (PC) ou des fusibles programmables à usage unique (SOC).

    Si seul le hachage de cette clé est stocké (pour économiser de l’espace), la mise à jour du microprogramme inclut la clé et la première étape du processus de mise à jour vérifie que la clé publique dans la mise à jour correspond au hachage stocké sur la plateforme.

    Les capsules sont un moyen par lequel le système d’exploitation peut transmettre des données à l’environnement UEFI au cours d’un redémarrage. Windows appelle l’UEFI UpdateCapsule() pour fournir des mises à jour du microprogramme système et PC. Au moment du démarrage, avant d’appeler ExitBootServices(), Windows transmet toutes les nouvelles mises à jour de microprogramme trouvées dans le Windows Driver Store dans UpdateCapsule(). Le microprogramme système UEFI peut utiliser ce processus pour mettre à jour le microprogramme système et PC. En tirant parti de cette prise en charge du microprogramme Windows, un OEM peut s’appuyer sur le même format commun et le même processus de mise à jour du microprogramme pour le microprogramme système et PC. Le microprogramme doit implémenter la table ACPI ESRT pour prendre en charge UEFI UpdateCapsule() pour Windows.

    Pour plus d’informations sur l’implémentation de la prise en charge de la plateforme de mise à jour du microprogramme UEFI WINDOWS, consultez la documentation suivante : Plateforme de mise à jour du microprogramme UEFI WINDOWS.

    La mise à jour des capsules peut se faire en mémoire ou sur le disque. Windows prend en charge les mises à jour en mémoire.

    1.3.6.1 Capsule (Capsule en mémoire)

    Voici le flux d’événements nécessaire pour qu’une capsule de mise à jour en mémoire fonctionne.

    1. Une capsule est mise en mémoire par une application dans le système d’exploitation
    2. L’événement de boîte aux lettres est défini pour informer le BIOS de la mise à jour en attente
    3. Le PC redémarre, vérifie l’image de capsule, la mise à jour est effectuée par le BIOS

  • 1.3.7 Flux de travail d’une mise à jour de microprogramme classique

    1. Téléchargez et installez la dernière version du microprogramme.
    2. Redémarrage.
    3. Le chargeur de système d’exploitation détecte et vérifie le microprogramme.
    4. Le chargeur de système d’exploitation transmet un objet blob binaire à UEFI.
    5. UEFI effectue la mise à jour du microprogramme (ce processus appartient au fournisseur de silicium).
    6. La détection du chargeur de système d’exploitation se termine correctement.
    7. Le système d’exploitation termine le démarrage.

1.4 Bases de données de signature (base de données et dbx)

  • 1.4.1 Base de données de signatures autorisées (db)

    Le contenu de la base de données EFI _IMAGE_SECURITY_DATABASE contrôle les images approuvées lors de la vérification des images chargées. La base de données peut contenir plusieurs certificats, clés et hachages afin d’identifier les images autorisées.

    Le certificat suivant doit être inclus dans la base de données pour permettre au chargeur de système d’exploitation Windows de charger :

  1. Autorité de certification UEFI Windows 2023
    • Hachage de certificat SHA-1 : 45A0FA32604773C82433C3B7D59E7466B3AC0C67.
    • GUID SignatureOwner : {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Microsoft fournira le certificat aux partenaires et peut être ajouté en tant que signature de type EFI_CERT_X509_GUID ou EFI_CERT_RSA2048_GUID.
    • L'autorité de certification UEFI Windows 2023 peut être téléchargée ici : https://go.microsoft.com/fwlink/?linkid=2239776.

À l’exception des systèmes verrouillés pour démarrer Windows uniquement, l’OEM doit envisager d’inclure les autorités de certification UEFI tierces Microsoft et Microsoft option ROM pour autoriser les pilotes UEFI et les applications ROM des tiers à s’exécuter sur le PC sans nécessiter de procédure supplémentaire pour l’utilisateur.

  1. Autorité de certification UEFI 2011 de Microsoft Corporation

    • Hachage de certificat SHA-1 : 46DEF63B5CE61CF8BA0DE2E6639C1019D0ED14F3.
    • GUID SignatureOwner : {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Microsoft fournira le certificat aux partenaires et peut être ajouté en tant que signature de type EFI_CERT_X509_GUID ou EFI_CERT_RSA2048_GUID.
    • L'autorité de certification UEFI 2011 Microsoft Corporation peut être téléchargé ici : https://go.microsoft.com/fwlink/p/?linkid=321194.

  2. Autorité de certification UEFI 2023 Microsoft

    • Hachage de certificat SHA-1 : B5EEB4A6706048073F0ED296E7F580A790B59EAA.
    • GUID SignatureOwner : {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Microsoft fournira le certificat aux partenaires et peut être ajouté en tant que signature de type EFI_CERT_X509_GUID ou EFI_CERT_RSA2048_GUID.
    • L'autorité de certification UEFI 2023 Microsoft peut être téléchargée ici : https://go.microsoft.com/fwlink/?linkid=2239872.

  3. Autorité de certification UEFI Microsoft 2023 option ROM

    • Hachage de certificat SHA-1 : 3FB39E2B8BD183BF9E4594E72183CA60AFCD4277.
    • GUID SignatureOwner : {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
    • Microsoft fournira le certificat aux partenaires et peut être ajouté en tant que signature de type EFI_CERT_X509_GUID ou EFI_CERT_RSA2048_GUID.
    • L'autorité de certification Microsoft Option ROM UEFI 2023 peut être téléchargée à partir d'ici :https://go.microsoft.com/fwlink/?linkid=2284009.

  • 1.4.2 DbDefault : le fournisseur de la plateforme doit fournir un ensemble d’entrées par défaut pour la base de données de signatures dans la variable dbDefault. Pour plus d’informations, consultez la section 27.5.3 des spécifications de l'UEFI.

  • 1.4.3 Base de données de signatures interdites (dbx)

    Le contenu de la dbx EFI_IMAGE_SIGNATURE_DATABASE1 doit être vérifiée lors de la vérification des images avant d'effectuer la vérification de la base de données et les correspondances doivent empêcher l’exécution de l’image. La base de données peut contenir plusieurs certificats, clés et hachages afin d’identifier les images interdites. La configuration requise pour la certification matérielle Windows indique qu’une dbx doit être présente, donc toute valeur factice, telle que le hachage SHA-256 de 0, peut être utilisée comme espace réservé sécurisé jusqu’à ce que Microsoft commence à fournir des mises à jour de la dbx. Cliquez ici pour télécharger la dernière liste de révocations UEFI à partir de Microsoft.

  • 1.4.4 DbxDefault : le fournisseur de la plateforme peut fournir un ensemble d’entrées par défaut pour la base de données de signatures dans la variable dbxDefault. Pour plus d’informations, consultez la section 27.5.3 des spécifications de l'UEFI.

1.5 Clés requises pour le démarrage sécurisé sur tous les PC

Remarque

Les OEM d’appareils, les entreprises et les clients trouveront les fichiers binaires des PK Microsoft, des KEK, des bases données et des DBX recommandés dans le référentiel open source de démarrage sécurisé de Microsoft. Les fichiers binaires sont mis en forme au format EDKII attendu pour s’intégrer facilement dans le microprogramme.

Nom de clé/base de données Variable Propriétaire Remarques

PKpub

PK

OEM (Fabricant d'équipement d'origine)

PK – 1 uniquement. Doit comporter un chiffrement RSA 2048 ou plus robuste.

https://go.microsoft.com/fwlink/?linkid=2255361

Autorité de certification KEK 2K 2023 de Microsoft Corporation

KEK

Microsoft

Autorise les mises à jour de la base de données et de la dbx :

https://go.microsoft.com/fwlink/p/?linkid=2239775.

Autorité de certification UEFI Windows 2023

Db

Microsoft

Cette autorité de certification dans la Base de données de signatures (db) permet à Windows de démarrer : https://go.microsoft.com/fwlink/?LinkId=2239776

Base de données de signatures interdites

Dbx

Microsoft

Liste des clés, autorités de certification ou images connues de Microsoft

Clé de mise à jour sécurisée du microprogramme

OEM (Fabricant d'équipement d'origine)

La recommandation est de faire en sorte que cette clé soit différente de la PK

Tableau 1 : Clés/base de données nécessaires pour le démarrage sécurisé

2. Solutions de gestion des clés

Vous trouverez ci-dessous quelques-unes des métriques que nous avons utilisées pour la comparaison.

2.1 Métriques utilisées

Les métriques suivantes peuvent vous aider à sélectionner un PC HSM en fonction des exigences des spécifications UEFI de la section 2.3.1 Errata C et de vos besoins.

  • Prend-il en charge le chiffrement RSA 2048 ou une version ultérieure ? - Les spécifications UEFI de la section 2.3.1 Errata C recommande que les clés soient au chiffrement RSA 2048 ou versions supérieures.
  • Est-ce qu’il a la possibilité de générer des clés et de signer ?
  • Combien de clés peut-il stocker ? Stocke-t-il des clés sur un HSM ou un serveur attaché ?
  • Méthode d’authentification pour la récupération de clés. Certains PC prennent en charge plusieurs entités d’authentification pour la récupération de clés.

Tarification

  • Qu’est-ce que le niveau de prix ? Les modules HSM peuvent varier de 1 500 $ à 70 000 $ selon les fonctionnalités disponibles.

Environnement de fabrication

  • Vitesse des opérations au niveau de l’usine. Les processeurs de chiffrement peuvent accélérer la création et l’accès des clés.
  • Facilité d’installation, de déploiement et de maintenance.
  • Ensemble de compétences et formation requis ?
  • Accès réseau pour la sauvegarde et la haute disponibilité

Conformité et normes

  • Quel niveau de conformité FIPS dispose-t-il ? Est-ce qu’il est résistant aux falsifications ?
  • Prise en charge d’autres normes, par exemple, des API de chiffrement MS.
  • Est-ce qu’il répond aux exigences du gouvernement et d’autres organismes ?

Fiabilité et récupération d’urgence

  • Autorise-t-il la sauvegarde de clés ?

    Les sauvegardes peuvent être stockées à la fois sur site dans un emplacement sécurisé : un emplacement physique différent de l’ordinateur de l’autorité de certification et du HSM et/ou à un emplacement hors site.

  • Autorise-t-il la haute disponibilité pour la reprise d’activité après sinistre ?

2.2 Options de gestion des clés

  • 2.2.1 Module de sécurité matériel (HSM)

    En fonction des critères ci-dessus, il s’agit probablement de la solution la plus appropriée et la plus sécurisée. La plupart des HSM ont une conformité FIPS 140-2 de niveau 3. La conformité FIPS 140-2 niveau 3 est stricte sur l’authentification et exige que les clés ne soient pas exportées ou importées à partir du HSM.

    Ils prennent en charge plusieurs façons de stocker les clés. Elles peuvent être stockées localement sur le HSM lui-même ou sur le serveur attaché au HSM. Sur le serveur, les clés sont chiffrées et stockées, cela est préférable pour les solutions qui nécessitent me stockage d'un grand nombre de clés.

    La stratégie de sécurité du module de chiffrement doit spécifier une stratégie de sécurité physique, y compris les mécanismes de sécurité physiques implémentés dans un module de chiffrement, tels que les seaux inviolables, les verrous, la réaction aux altérations et les commutateurs de remise à zéro ainsi que les alarmes. Il permet également de spécifier les actions requises par les opérateurs pour s’assurer que la sécurité physique est maintenue, comme l’inspection périodique des seaux inviolables ou le test des changements de réaction aux altérations et de remise à zéro.

    • 2.2.1.1 HSM réseau

      Cette solution est la meilleure de sa catégorie en termes de sécurité, d’adhésion aux normes, de génération de clés, de stockage et de récupération. La plupart de ces PC prennent en charge la haute disponibilité et ont la possibilité de sauvegarder des clés.

      Les coûts de ces produits peuvent représenter des dizaines de milliers de dollars en fonction des services supplémentaires qu’ils offrent.

    • 2.2.1.2 HSM mode autonome

      Ils fonctionnent très bien avec les serveurs autonomes. Vous pouvez utiliser Microsoft CAPI et CNG ou toute autre API sécurisée prise en charge par le HSM. Ces HSM sont fournis dans divers facteurs de forme prenant en charge les bus USB, PCIe et PCMCIA.

      Ils prennent éventuellement en charge la sauvegarde de clés et la haute disponibilité.

  • 2.2.2 Fournisseurs de solutions personnalisées

    Le chiffrement à clé publique peut être difficile et nécessiter une compréhension des concepts de chiffrement qui peuvent être nouveaux. Il existe des fournisseurs de solutions personnalisés qui peuvent aider à intégrer le démarrage sécurisé dans l’environnement de fabrication.

    Il existe des variétés de solutions personnalisées offertes par les fournisseurs de BIOS, les sociétés HSM et les sociétés de conseil PKI pour obtenir l’infrastructure PKI de démarrage sécurisé pouvant fonctionner dans l’environnement de fabrication.

    Certaines de ceux-ci sont répertoriés ci-dessous :

  • 2.2.3 Module de plateforme sécurisée (TPM)

    Un module de plateforme sécurisée (TPM) est une puce matérielle sur la carte mère qui stocke les clés de chiffrement utilisées pour le chiffrement. De nombreux ordinateurs incluent un module TPM, mais si le PC ne l’inclut pas, il n’est pas possible d’en ajouter un. Une fois activé, le module de plateforme sécurisée peut vous aider à sécuriser des produits de chiffrement de disque complet, tels que les fonctionnalités de Microsoft BitLocker. Il conserve les disques durs verrouillés ou scellés jusqu’à ce que le PC termine un processus de vérification ou d’authentification système.

    Le module TPM peut générer, stocker et protéger les clés utilisées dans le processus de chiffrement et de déchiffrement.

    Les inconvénients des TPM sont qu’il peut ne pas avoir de processeurs de chiffrement rapides pour accélérer le traitement dans l’environnement de fabrication. Ils ne conviennent pas également au stockage d’un grand nombre de clés. La conformité des sauvegardes et des normes à FIPS 140-2 niveau 3 peut ne pas être disponible.

  • 2.2.4 Cartes à puce

    Une carte à puce peut générer et stocker des clés. Elles partagent certaines fonctionnalités prises en charge par le HSM, telles que l’authentification et la vérification des altérations, mais elles n’incluent pas beaucoup de stockage ou de sauvegarde de clés. Elles nécessitent une intervention manuelle et peuvent ne pas convenir à l’automatisation et à l’utilisation dans l’environnement de production, car les performances peuvent être faibles.

    Les inconvénients des cartes à puce sont similaires aux TPM. Elles peuvent ne pas disposer de processeurs de chiffrement rapides pour accélérer le traitement dans l’environnement de fabrication. Ils ne conviennent pas également au stockage d’un grand nombre de clés. La conformité des sauvegardes et des normes à FIPS 140-2 niveau 3 peut ne pas être disponible.

  • 2.2.5 Certificat EV (à validation étendue)

    Les certificats EV sont des certificats de garantie élevée dont les clés privées sont stockées dans des jetons matériels. Cela permet d’établir des pratiques de gestion clés plus fortes. Les certificats EV présentent les mêmes inconvénients que les cartes à puce.

  • 2.2.6 Approches centrées sur les logiciels (NON RECOMMANDÉES)

    Utilisez des API de chiffrement pour la gestion des clés. Cela peut impliquer le stockage d’une clé dans un conteneur de clés sur un disque dur chiffré, cela est par ailleurs possible pour un sandboxing et une sécurité supplémentaires à l’aide d’une machine virtuelle.

    Ces solutions ne sont pas aussi sécurisées que l’utilisation d’un HSM et présentent un vecteur d’attaque plus élevé.

    2.2.6.1 Makecert (NON RECOMMANDÉ)

    Makecert est un outil Microsoft et peut être utilisé comme suit pour la génération de clés. Pour vous assurer que la surface d’attaque est réduite, vous devrez peut-être réaliser un « airgap » sur le PC. Le PC sur lequel la PKpriv est activée ne doit pas être connecté au réseau. Il doit se trouver dans un emplacement sécurisé et idéalement utiliser au moins un lecteur de cartes à puce s’il n’est pas un HSM réel.

    makecert -pe -ss MY -$ individual -n "CN=your name here" -len 2048 -r

    Pour plus d’informations, consultez l’outil de création de certificats (Makecert.exe).

    Cette solution n’est pas recommandée.

2.3 Génération et stockage de clés HSM pour les clés de démarrage sécurisées

  • 2.3.1 Stockage des clés privées

    L’espace requis pour chaque clé RSA 2048 est de 2 048 bits. L’emplacement réel du stockage des clés dépend de la solution choisie. Le HSM constitue un bon moyen de stocker des clés.

    L’emplacement physique des PC au niveau de la fabrique doit être une zone protégée avec un accès limité à l’utilisateur, comme une cage sécurisée.

    En fonction de vos besoins, ces clés peuvent également être stockées dans un emplacement géographique diversifié ou sauvegardées dans un autre emplacement.

    Les exigences en matière de renouvellement de clés peuvent varier en fonction du client (voir l’annexe A pour les directives de renouvellement de clés de l’autorité de certification de pont fédéral).

    Ces opérations pourraient être effectuées une fois par an. Vous devrez peut-être avoir accès à ces clés pendant jusqu’à 30 ans (en fonction des exigences de renouvellement des clés, etc.).

  • 2.3.2 Récupération des clés privées

    Les clés peuvent nécessiter une récupération pour de nombreuses raisons.

    1. La PK peut avoir besoin d’être récupéré pour émettre une PK mise à jour en raison de sa compromission ou de l’adhésion aux réglementations gouvernementales/autres organismes.
    2. La KEKpri sera utilisée pour mettre à jour la base de données et la dbx.
    3. Clé de mise à jour sécurisée du microprogramme : la clé privée sera utilisée pour signer des mises à jour plus récentes.

  • 2.3.3 Authentification

    Conformément à l’authentification FIPS 140-2, elle est basée sur le niveau d’accès.

    Niveau 2

    Le niveau de sécurité 2 nécessite, au minimum, l’authentification basée sur les rôles dans laquelle un module de chiffrement authentifie l’autorisation d’un opérateur pour assumer un rôle spécifique et effectuer un ensemble de services correspondant.

    Niveau 3

    Le niveau de sécurité 3 nécessite des mécanismes d’authentification basés sur l’identité, ce qui améliore la sécurité fournie par les mécanismes d’authentification en fonction du rôle spécifiés pour le niveau de sécurité 2. Un module de chiffrement authentifie l’identité d’un opérateur et vérifie que l’opérateur identifié est autorisé à assumer un rôle spécifique et à effectuer un ensemble de services correspondant.

    Les PC comme un HSM prennent en charge le niveau de sécurité 3, ce qui nécessite l’authentification « k de l'authentification m » basée sur l’identité. Cela signifie que les entités k ont accès au HSM avec un jeton, mais au moins k des jetons m doivent être présents pour que l’authentification fonctionne pour obtenir l’accès aux clés privées à partir du HSM.

    Par exemple, vous pouvez avoir 3 jetons sur 5 doivent être authentifiés pour accéder au HSM. Ces membres peuvent être les agents de sécurité, la personne autorisant la transaction et/ou les membres de la direction.

    Jetons HSM

    Vous pouvez avoir une stratégie sur le HSM qui nécessite que le jeton soit présent :

    • Localement

    • À distance

    • Configuré pour fonctionner automatiquement

    Il est recommandé d'utiliser une combinaison de jetons et par mot de passe de jeton.

2.4 Démarrage sécurisé et signature tierce

  • 2.4.1 Signature du pilote UEFI

    Les pilotes UEFI doivent être signés par une autorité de certification ou une clé dans la base de données, comme décrit ailleurs dans le document, ou comporter le hachage de l’image de pilote dans la base de données. Microsoft fournira un service de signature de pilotes UEFI, similaire au service de signature de pilotes WHQL, en utilisant le Microsoft UEFI CA 2023. Tous les pilotes signés s’exécutent en toute transparence sur tous les PC qui incluent l’autorité de certification UEFI Microsoft. Il est également possible pour un OEM de signer des pilotes approuvés et d’inclure l’autorité de certification OEM dans la base de données ou d’inclure des hachages des pilotes dans la base de données. Dans tous les cas, un pilote UEFI (ROM optionnelle) ne s’exécute pas s’il n’est pas approuvé dans la base de données.

    Les pilotes inclus dans l’image du microprogramme système n’ont pas besoin d’être vérifiés à nouveau. Faire partie de l’image système globale fournit une assurance suffisante que le pilote est approuvé sur le PC.

    Microsoft a mis cela à la disposition de toute personne qui souhaite signer des pilotes UEFI. Ce certificat fait partie des tests de démarrage sécurisé Windows HCK. Suivez [ce blog]((https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/) pour en savoir plus sur la stratégie et les mises à jour de signature d’autorité de certification UEFI.

  • 2.4.2 Chargeurs de démarrage

    Le certificat de signature de pilote Microsoft UEFI peut être utilisé pour signer d’autres systèmes d’exploitation. Par exemple, le chargeur de démarrage Linux de Fedora sera signé par celui-ci.

    Cette solution ne nécessite plus d’ajout de certificats à la base de données de clés. En plus d’être rentable, elle peut être utilisée pour n’importe quelle distribution Linux. Cette solution fonctionne avec tout matériel prenant en charge Windows afin qu’il soit utile pour un large éventail de matériels.

    L'autorité de certification UEFI peut être téléchargé ici : https://go.microsoft.com/fwlink/p/?LinkID=321194. Les liens suivants comportent plus d’informations sur la signature et la soumission UEFI Windows HCK :

3. Résumé et ressources

Cette section vise à résumer les sections ci-dessus et présenter une approche pas à pas :

  1. Établir une autorité de certification sécurisée ou identifier un partenaire pour générer et stocker des clés en toute sécurité

    Si vous n’utilisez pas de solution tierce :

    1. Installez et configurez le logiciel HSM sur le serveur HSM. Consultez votre manuel de référence du HSM pour obtenir des instructions d’installation. Le serveur sera connecté à un HSM autonome ou réseau.

      Pour plus d’informations sur la configuration du HSM, consultez la section 2.2.1, 2.3 et l’annexe C.

      La plupart des HSM offrent une conformité FIPS 140-2 de niveau 2 et 3. Configurez le HSM pour la conformité de niveau 2 ou de niveau 3. La conformité au niveau 3 a des exigences plus strictes en matière d’authentification et d’accès à la clé, elle est donc plus sécurisée. Le niveau 3 est recommandé.

    2. Configurez le HSM pour la haute disponibilité, la sauvegarde et l’authentification. Vérifiez votre manuel de référence du HSM.

      Suivez les instructions du fournisseur du HSM sur la configuration du HSM pour la haute disponibilité et la sauvegarde.

      En outre, les HSM réseau ont généralement plusieurs ports réseau pour séparer le trafic ; permettant à un serveur de communiquer avec des HSM réseau sur un réseau distinct du réseau de production standard.

      Une fois que les membres de l’équipe qui font partie de l’équipe de sécurité ont été identifiés et que des jetons leur ont été attribués. Vous devez configurer le matériel HSM pour l’authentification k-de-m.

    3. Clés de démarrage sécurisées et prégénération de certificats. Voir les sections 1.3 à 1.5

      Utilisez les API des HSM pour prégénérer (générer à l’avance) la clé et les certificats de mise à jour du microprogramme et les PK.

      Obligatoire - la PK (1 par modèle recommandé), la clé de mise à jour du microprogramme (1 par modèle recommandé), la KEK Microsoft, la base de données, la DbxREMARQUE : les KEK Microsoft, la base de données et la dbx n’ont pas besoin d’être générées par l’OEM et sont mentionnées pour la complétion. Facultatif : la base de données de KEK OEM/tierce, la dbx et toutes les autres clés qui seraient stockées dans la base de données OEM.

  2. Appliquez une image Windows au PC.

  3. Installez la base de données Microsoft et la dbx. Consultez la section 1.3.6 et l'Annexe B – API de démarrage sécurisé.

    1. Installez l’autorité de certification Windows UEFI 2023 dans la base de données.

    2. Installez une dbx vide si Microsoft n’en fournit pas une. Windows met automatiquement à jour la DBX vers la dernière version de la DBX via Windows Update lors du premier redémarrage.

    Remarque

    Utilisez des applets de commande PowerShell qui font partie des tests Windows HCK ou utilisez des méthodes fournies par le fournisseur du BIOS.

  4. Installez les KEK Microsoft. Voir la section 1.3.3.

    Installer les KEK Microsoft dans la base de données KEK de l'UEFI

    Attention

    Utilisez des applets de commande PowerShell qui font partie des tests Windows HCK ou utilisez des méthodes fournies par le fournisseur du BIOS.

  5. Étape facultative : composants de démarrage sécurisé OEM/tiers. Voir les sections 1.3.4 et 1.4.

    1. Identifiez si vous avez besoin de créer une KEK tierce OEM/tierce, une base de données et une dbx.

    2. Signez la base de données et la dbx OEM/tierces avec des KEK tierces (générées précédemment) à l’aide de l’API du HSM.

    3. Installez les KEK, la base de données et la dbx OEM/tierces.

  6. Signature du pilote UEFI : consultez la section 2.4.

    Si vous prenez en charge les cartes de complément ou d'autres pilotes, applications, ou chargeurs de démarrage UEFI, installez Microsoft UEFI CA 2023 et Microsoft Corporation UEFI CA 2011 dans la base de données UEFI.

  7. Clé de mise à jour du microprogramme de démarrage sécurisé - Consultez la section 1.3.5.

    1. PC non Windows RT uniquement : installez la clé publique de mise à jour du microprogramme sécurisée ou son hachage pour économiser de l’espace.

    2. Sur SoC uniquement, vous devrez peut-être procéder différemment, par exemple, brûler la clé de mise à jour du microprogramme sécurisé : la clé publique ou son hachage.

  8. Activation du démarrage sécurisé. Consultez l’Annexe B : API de démarrage sécurisée.

    1. Installez la PKpub OEM/ODM (il est préférable d'utiliser un certificat, mais vous pouvez aussi utiliser la clé) dans la PK de l'UEFI.

    2. Inscrivez la PK à l’aide de l’API de démarrage sécurisé. Le PC doit maintenant pouvoir réaliser un démarrage sécurisé.

    Remarque

    Si vous installez la PK à la fin, la clé MS KEK, la base de données et la dbx n’ont pas besoin d’être signées, aucun SignerInfo ne doit être présent. Il s’agit d’une méthode plus rapide.

  9. Test du démarrage sécurisé : exécutez tous les tests propriétaires et les tests Windows HCK conformément aux instructions. Consultez l’Annexe B : API de démarrage sécurisée.

  10. Plate-forme d’expédition : la PKpriv ne sera probablement jamais utilisée à nouveau, gardez-la en sécurité.

  11. Maintenance : les futures mises à jour du microprogramme sont signées en toute sécurité avec la clé « privée » de mise à jour du microprogramme sécurisée à l’aide du service de signature.

3.1 Ressources

Livre blanc sur les stratégies de sécurité - https://go.microsoft.com/fwlink/p/?linkid=321288

Soumission sous Windows HCK -https://go.microsoft.com/fwlink/p/?linkid=321287

Annexe A : liste de contrôle des PKI de démarrage sécurisé pour la fabrication

Vous trouverez ci-dessous une liste de contrôle de haut niveau récapitulant les étapes nécessaires à l’activation du démarrage sécurisé sur des PC non Windows RT.

Configuration du démarrage sécurisé

  1. Définissez une stratégie de sécurité (identifier les menaces, définir une stratégie proactive et réactive) conformément au livre blanc de la section 4.

  2. Identifiez l’équipe de sécurité conformément au livre blanc de la section 4.

  3. Établissez une autorité de certification sécurisée ou identifiez un partenaire (solution recommandée) pour générer et stocker des clés en toute sécurité.

  4. Identifiez la stratégie pour la fréquence à laquelle vous allez régénérer des clés. Cela peut dépendre selon que vous avez des exigences particulières de clients comme des gouvernements ou d’autres organismes.

  5. Disposez d’un plan d’urgence à utiliser au cas où la clé de démarrage sécurisée deviendrait compromise.

  6. Identifiez le nombre de clés PK et les autres clés que vous générerez en fonction des sections 1.3.3 et 1.5.

    Cela dépendra de la clientèle, de la solution de stockage de clés et de la sécurité des PC.

    Vous pouvez ignorer les étapes 7 à 8 si vous utilisez la solution recommandée de faire appel à un tiers pour la gestion des clés.

  7. Fournissez le serveur et le matériel pour la gestion des clés. – HSM réseau ou autonome conforme à la section 2.2.1. Déterminez si vous aurez besoin d’un ou plusieurs modules HSM pour la haute disponibilité et votre stratégie de sauvegarde des clés.

  8. Identifiez au moins 3 à 4 membres de l’équipe qui auront un jeton d’authentification pour l’authentification sur le HSM.

  9. Utilisez le HSM ou un tiers pour prégénérer les clés et certificats liés au démarrage sécurisé. Les clés dépendent du type de PC : SoC, Windows RT ou non Windows RT. Pour plus d’informations, consultez les sections 1.3 à 1.5.

  10. Remplissez le microprogramme avec les clés appropriées.

  11. Inscrivez la clé de plateforme de démarrage sécurisé pour activer le démarrage sécurisé. Voir l’annexe B pour plus de détails.

  12. Exécutez tous les tests propriétaires et les tests de démarrage sécurisé HCK conformément aux instructions. Voir l’annexe B pour plus de détails.

  13. Expédiez le PC. La PK privée ne sera probablement plus jamais utilisée, gardez-la en sécurité.

Maintenance (mise à jour du microprogramme)

Vous devrez peut-être mettre à jour le microprogramme pour plusieurs raisons, telles que la mise à jour d’un composant UEFI ou la résolution de la compromission de la clé de démarrage sécurisé, ou encore la régénération périodique des clés de démarrage sécurisé.

Pour plus d’informations, consultez les sections 1.3.5 et 1.3.6.

Annexe B – API de démarrage sécurisée.

  1. API de démarrage sécurisé

    Les API suivantes sont liées à l'UEFI / au démarrage sécurisé :

    1. GetFirmwareEnvironmentVariableEx : récupère la valeur de la variable d’environnement du microprogramme spécifié.

    2. SetFirmwareEnvironmentVariableEx : définit la valeur de la variable d’environnement du microprogramme spécifié.

    3. GetFirmwareType : récupère le type de microprogramme.

  2. Définition de la PK

    Utilisez l’applet de commande Set-SecureBootUEFI pour activer le démarrage sécurisé. Une fois que votre code définit la PK, l’application du système du démarrage sécurisé ne prend effet qu’au prochain redémarrage. Avant le redémarrage, votre code peut appeler GetFirmwareEnvironmentVariableEx() ou l’applet de commande PowerShell : Get-SecureBootUEFI pour confirmer le contenu des bases de données de démarrage sécurisé.

  3. Vérification

    Vous pouvez utiliser des applets de commande Msinfo32.exe ou PowerShell pour vérifier l’état de variable de démarrage sécurisé. Il n’existe aucune interface WMI. Vous pouvez également effectuer le test en insérant une clé USB démarrable incorrectement signée (par exemple, à partir du test du logo manuel de démarrage sécurisé de Windows HCK) et vérifier qu’elle ne parvient pas à démarrer.

  4. Applets de commande PowerShell de démarrage sécurisé

    • Confirm-SecureBootUEFI : le démarrage sécurisé UEFI est-il « ON », True ou False ?

      SetupMode == 0 et SecureBoot == 1

    • Set-SecureBootUEFI : définir ou ajouter des variables UEFI SecureBoot authentifiées

    • Get-SecureBootUEFI : obtenir les valeurs de variable UEFI SecureBoot authentifiées

    • Format-SecureBootUEFI : crée des sérialisations EFI_SIGNATURE_LISTs & EFI_VARIABLE_AUTHENTICATION_2

  5. Instructions de démarrage sécurisé et HCK Windows

    Les étapes suivantes s’appliquent aux tests système et aux tests PC de pilotes sans classe.

    1. Désactivez les protections de démarrage sécurisé.

      Entrez votre configuration BIOS et désactivez le démarrage sécurisé.

    2. Installez le logiciel client HCK.

    3. Exécutez tous les tests Windows HCK, à l’exception des éléments suivants :

      • Tests tpm et mot de passe de récupération BitLocker avec PCR[7]
      • Tests tpm et mot de passe de récupération BitLocker pour les PC Arm avec démarrage sécurisé
      • Test du logo de démarrage sécurisé
      • Test du logo manuel de démarrage sécurisé

    4. Entrez votre configuration BIOS, activez le démarrage sécurisé et restaurez le démarrage sécurisé dans la configuration par défaut.

    5. Exécutez les tests BitLocker et Démarrage sécurisé suivants :

      • Tests tpm et mot de passe de récupération BitLocker avec PCR[7]
      • Tests tpm et mot de passe de récupération BitLocker pour les PC Arm avec démarrage sécurisé
      • Test du logo de démarrage sécurisé (automatisé)

    6. Entrez la configuration du BIOS et effacez la configuration de démarrage sécurisé. Cela restaure le PC en mode d’installation en supprimant la PK et d’autres clés.

      Remarque

      La prise en charge de l’effacement est requise pour les PC x86/x64.

    7. Exécutez le test de logo du manuel de démarrage sécurisé.

      Remarque

      Le démarrage sécurisé nécessite des pilotes Windows HCK signés ou VeriSign sur des PC non Windows RT

  6. Test du logo de démarrage sécurisé Windows HCK (automatisé)

    Ce test vérifie la configuration adéquate du démarrage sécurisé prêt à l’emploi. notamment :

    • Le démarrage sécurisé est activé
    • La PK n’est pas une PK de test connue.
    • La KEK contient la KEK de production Microsoft.
    • La base de données contient l’autorité de certification Windows de production.
    • La dbx est présente.
    • De nombreuses variables 1kB sont créées/supprimées.
    • Une variable 32kB est créée/supprimée.

  7. Disposition manuelle du dossier de test de démarrage sécurisé Windows HCK

    La disposition du dossier de test manuel de démarrage sécurisé Windows HCK est décrite ci-dessous :

    • "\Test" le dossier contient les éléments suivants :

      • Test de fabrication et de maintenance
      • Activer le démarrage sécurisé par programmation dans la configuration de test
      • Tests d’entretien
      • Ajouter un certificat à la base de données, vérifier la fonction
      • Ajouter un hachage à la dbx, vérifier la fonction
      • Ajouter un certificat à la dbx, vérifier la fonction
      • Ajouter plus de 600 hachages à la dbx, vérifier la taille
      • Modifier par programmation la PK

    • Le dossier "\Generate" comporte des scripts qui montrent les éléments suivants :

      • Création de certificats de test

      • Les certificats de test et les clés privées sont inclus

      • Comment tous les tests ont été créés

      • Transformer des certificats et des hachages en packages signés

      • Vous pouvez exécuter cela vous-même, remplacez vos propres certificats

    • Le dossier "\certs" contient tous les certificats dont vous avez besoin pour démarrer Windows :

      Remarque

      N’utilisez pas la méthodologie utilisée pour "ManualTests\generate\TestCerts" générer des clés et des certificats. Celle-ci est destiné uniquement à des fins de test sur Windows HCK. Elle utilise des clés stockées sur le disque qui sont très dangereuses et non recommandées. Elle n'est pas destinée à être utilisée dans un environnement de production.

  • Le dossier "ManualTests\example\OutOfBox" contient des scripts dont vous pouvez tirer parti dans l’installation du démarrage sécurisé sur les PC de production.

    La section "ManualTests\generate\tests\subcreate_outofbox_example.ps1" montre comment ces exemples ont été générés et comportent des sections « TODO » lorsqu'un partenaire peut remplacer ses PK et d’autres métadonnées.

  1. Signature et soumission UEFI sous Windows HCK

    Pour plus d’informations, voir les liens suivants :

Annexe C – Mappages de l’assurance des stratégies de certification de l’autorité de certification fédérale

  1. Rudimentaire

    Ce niveau fournit le plus bas degré d’assurance concernant l’identité de l’individu. L’une des principales fonctions de ce niveau consiste à fournir l’intégrité des données aux informations signées. Ce niveau est pertinent pour les environnements dans lesquels le risque d’activité malveillante est considéré comme faible. Il ne convient pas aux transactions nécessitant une authentification et est généralement insuffisant pour les transactions nécessitant de la confidentialité, mais peut être utilisé pour cette dernière où les certificats ayant des niveaux d’assurance plus élevés ne sont pas disponibles.

  2. De base

    Ce niveau fournit un niveau d’assurance de base pertinent pour les environnements comportant des risques et des conséquences de compromission des données, ils ne sont toutefois pas considérés comme importants. Cela peut inclure l’accès à des informations privées où la probabilité d’un accès malveillant n’est pas élevée. Il est supposé que les utilisateurs ne sont pas susceptibles d’être malveillants à ce niveau de sécurité.

  3. Moyenne

    Ce niveau est pertinent pour les environnements où les risques et les conséquences de la compromission des données sont modérés. Cela peut inclure des transactions ayant une valeur monétaire substantielle ou un risque de fraude, ou impliquant l’accès à des informations privées où la probabilité d’accès malveillant est importante.

  4. Activité

    Ce niveau est approprié pour une utilisation comportant un haut niveau de menaces aux données, ou lorsque les conséquences de l’échec des services de sécurité sont élevées. Cela peut inclure des transactions très importantes ou des niveaux élevés de risque de fraude.

Génération et signature de clé de démarrage sécurisé à l’aide de HSM (exemple)

Conseils de validation de l’option ROM de validation UEFI

Vue d’ensemble du démarrage sécurisé