Démarrage sécurisé

  • Article

Le démarrage sécurisé est une norme de sécurité développée par des membres du secteur de fabrication de PC pour s’assurer qu’un appareil démarre en utilisant uniquement des logiciels approuvés par le fabricant d’ordinateurs OEM (Original Equipment Manufacturer). Au démarrage du PC, le microprogramme vérifie la signature de chaque logiciel de démarrage, y compris les pilotes de microprogramme UEFI (également appelés options ROM), les applications EFI et le système d’exploitation. Si les signatures sont valides, le PC démarre et le microprogramme donne le contrôle au système d’exploitation.

L’OEM peut utiliser les instructions du fabricant du microprogramme pour créer des clés de démarrage sécurisé et les stocker dans le microprogramme du PC. Lorsque vous ajoutez des pilotes UEFI, vous devez également vous assurer qu’ils sont signés et inclus dans la base de données de démarrage sécurisé.

Pour plus d’informations sur le fonctionnement du processus de démarrage sécurisé, notamment le démarrage approuvé et le démarrage mesuré, consultez Sécuriser le processus de démarrage Windows 10.

Configuration requise pour le démarrage sécurisé

Pour prendre en charge le démarrage sécurisé, vous devez fournir les éléments suivants.

Configuration matérielle Détails
Variables Errata C UEFI version 2.3.1 Les variables doivent être définies sur SecureBoot=1 et SetupMode=0 avec une base de données de signatures (EFI_IMAGE_SECURITY_DATABASE) nécessaire pour démarrer l’ordinateur en toute sécurité préprovisionnée, et inclure une PK définie dans une base de données KEK valide. Pour plus d’informations, recherchez la configuration système requise pour System.Fundamentals.Firmware.UEFISecureBoot dans le téléchargement PDF des spécifications et stratégies du programme de compatibilité matérielle Windows.
UEFI v2.3.1 Section 27 La plateforme doit exposer une interface qui respecte le profil d’UEFI v2.3.1 Section 27.
Base de données de signatures UEFI La plateforme doit être approvisionnée avec les clés appropriées dans la base de données de signature UEFI (db) pour permettre à Windows de démarrer. Il doit également prendre en charge les mises à jour authentifiées sécurisées des bases de données. Le stockage des variables sécurisées doit être isolé du système d’exploitation en cours d’exécution afin qu’elles ne puissent pas être modifiées sans détection.
Signature du microprogramme Tous les composants du microprogramme doivent être signés à l’aide d’au moins RSA-2048 avec SHA-256.
Gestionnaire de démarrage Lorsque l’alimentation est activée, le système doit commencer à exécuter du code dans le microprogramme et utiliser le chiffrement à clé publique conformément à la stratégie d’algorithme pour vérifier les signatures de toutes les images dans la séquence de démarrage, jusqu’au Gestionnaire de démarrage Windows inclus.
Restaurer la protection Le système doit se protéger contre la restauration du microprogramme vers des versions antérieures.
EFI_HASH_PROTOCOL La plateforme fournit la EFI_HASH_PROTOCOL (par UEFI v2.3.1) pour le déchargement des opérations de hachage de chiffrement et la EFI_RNG_PROTOCOL (définie par Microsoft) pour accéder à l’entropie de plateforme.

Bases de données et clés de signature

Avant le déploiement du PC, en tant qu’OEM, vous stockez les bases de données de démarrage sécurisé sur le PC. Cela inclut la base de données de signatures (db), la base de données de signatures révoquée (dbx) et la base de données de clé d’inscription de clé (KEK). Ces bases de données sont stockées sur la RAM non volatile (NV-RAM) du microprogramme au moment de la fabrication.

La base de données de signatures (db) et la base de données de signatures révoquée (dbx) répertorient les signataires ou les hachages d’images des applications UEFI, des chargeurs de système d’exploitation (tels que le chargeur du système d’exploitation ou le Gestionnaire de démarrage de Microsoft) et des pilotes UEFI qui peuvent être chargés sur l’appareil. La liste révoquée contient des éléments qui ne sont plus approuvés et qui peuvent ne pas être chargés. Si un hachage d’image se trouve dans les deux bases de données, la base de données de signatures révoquée (dbx) prévaut.

La base de données de clé d’inscription de clé (KEK) est une base de données distincte de clés de signature qui peut être utilisée pour mettre à jour la base de données de signatures et la base de données de signatures révoquées. Microsoft exige qu’une clé spécifiée soit incluse dans la base de données KEK afin que Microsoft puisse à l’avenir ajouter de nouveaux systèmes d’exploitation à la base de données de signatures ou ajouter des images incorrectes connues à la base de données de signatures révoquées.

Une fois ces bases de données ajoutées, et après la validation et le test finals du microprogramme, l’OEM empêche la modification du microprogramme, à l’exception des mises à jour signées avec la clé correcte ou des mises à jour effectuées par un utilisateur physiquement présent qui utilise les menus du microprogramme, puis génère une clé de plateforme (PK). La PK peut être utilisée pour signer des mises à jour de la KEK ou pour désactiver le démarrage sécurisé.

Vous devez contacter le fabricant de votre microprogramme pour obtenir des outils et de l’aide pour créer ces bases de données.

Séquence de démarrage

  1. Une fois le PC activé, les bases de données de signature sont chacune vérifiées par rapport à la clé de plateforme.
  2. Si le microprogramme n’est pas approuvé, le microprogramme UEFI doit lancer une récupération spécifique à l’OEM pour restaurer le microprogramme approuvé.
  3. En cas de problème avec le Gestionnaire de démarrage Windows, le microprogramme tente de démarrer une copie de sauvegarde du Gestionnaire de démarrage Windows. Si cela échoue également, le microprogramme doit lancer une correction spécifique à l’OEM.
  4. Une fois l’exécution du Gestionnaire de démarrage Windows démarrée, en cas de problème avec les pilotes ou le noyau NTOS, l’environnement de récupération Windows (Windows RE) est chargé afin que ces pilotes ou l’image du noyau puissent être récupérés.
  5. Windows charge le logiciel anti-programme malveillant.
  6. Windows charge d’autres pilotes de noyau et initialise les processus en mode utilisateur.