Mettre à jour les certificats KEK et de base de données

Ce document explique comment mettre à jour les variables de la base de données de signatures autorisées (db) et de la clé d'échange de clés (KEK) sur les instances de calcul que vous avez créées avant le 7 novembre 2025 pour qu'elles fassent confiance aux certificats mis à jour pour le démarrage sécurisé.

La mise à jour de la KEK et de la base de données est une alternative pour les clients qui ne recréent pas leurs instances de calcul concernées.

Avant de commencer

Avant de mettre à jour vos certificats KEK et db Secure Boot, vérifiez si vos instances nécessitent une mise à jour et effectuez les préparatifs suivants pour éviter d'éventuels problèmes de démarrage ou de déchiffrement :

• Vérification des prérequis : vérifiez que vos instances nécessitent une mise à jour des certificats de démarrage sécurisé.
• Intégrité des données et récupération des clés : localisez vos clés de récupération de chiffrement de disque (BitLocker ou LUKS FDE) et sauvegardez les données critiques. Si la configuration est incorrecte, la modification des variables de sécurité peut bloquer l'accès aux disques.
• Recommandation concernant l'ordre de mise à jour de Linux : pour les instances Linux, nous vous recommandons de mettre à jour la variable UEFI db vers Microsoft UEFI CA 2023 avant de passer aux nouveaux shims. Cette séquence permet d'éviter un éventuel scénario d'incompatibilité de l'autorité de certification si une mise à jour du shim signée uniquement avec l'autorité de certification Microsoft UEFI 2023 est appliquée alors que la base de données ne contient que le certificat de 2011.
• Configurations personnalisées de clé publique ou de KEK clé : si votre instance utilise des variables Secure Boot personnalisées (telles qu'un PK ou un KEK personnalisés), ou si vous exécutez un système en dehors de Compute Engine, les fichiers de mise à jour standards (DBUpdate3P2023.bin ou kek2023update.bin) fournis dans ce document ne s'appliqueront pas directement. Le micrologiciel UEFI exige que les fichiers de mise à jour soient signés avec la clé privée de KEK ou PK enregistrée sur le système, et kek2023update.bin est signé spécifiquement par le PK Compute Engine par défaut. Si vous utilisez des clés personnalisées, vous devez signer les binaires de mise à jour avec vos propres clés privées ou gérer les mises à jour via votre autorité de certification personnalisée. Pour en savoir plus, consultez Résoudre les erreurs de mise à jour des clés de chiffrement de clé.
• Cloud de Confiance by S3NS  Dispositifs Backup and DR : il s'agit de dispositifs gérés. Vous n'avez pas besoin de mettre à jour manuellement les certificats Secure Boot sur ces appliances. Cloud de Confiance by S3NS gère automatiquement toutes les mises à jour.

Mettre à jour la base de données et la KEK sur Linux

Pour mettre à jour la base de données des signatures autorisées (db) et la clé d'échange de clés (KEK), sélectionnez l'option correspondant à votre système d'exploitation :

sudo fwupdmgr refresh
sudo fwupdmgr update 5bc922b7bd1adb5b6f99592611404036bd9f42d0
sudo fwupdmgr update b7a1d3d90faa1f6275d9a98da4fb3be7118e61c7

sudo apt update && sudo apt install sbsigntool gcab -y

sudo SUSEConnect -p PackageHub/15.5/x86_64
sudo zypper install sbsigntools cabextract -y

Mettre à jour la base de données et la KEK sur Windows

Vous n'avez pas besoin d'appliquer ces mises à jour de certificat si vous n'utilisez pas ou ne prévoyez pas d'utiliser le démarrage sécurisé sur cette instance. Les systèmes d'exploitation Windows ignorent généralement les tentatives d'application de ces mises à jour de certificats de démarrage sécurisé si le démarrage sécurisé n'est pas activé, car la mise à jour n'est pas nécessaire.

Si vous prévoyez d'utiliser le démarrage sécurisé ultérieurement, vous devez d'abord l'activer sur l'instance pour mettre à jour les certificats de démarrage sécurisé.

Sur les instances Windows, les paramètres de registre et les tâches planifiées déclenchent les mises à jour sur les versions compatibles :

1. Assurez-vous que les mises à jour mensuelles récentes ont été appliquées à vos instances Windows.

2. En tant qu'administrateur dans PowerShell, exécutez :

   Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value 0x5944
   Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
   

3. Redémarrez l'instance pour autoriser les opérations sur les variables du micrologiciel. Certains environnements nécessitent un double redémarrage si les fonctionnalités de sécurité de la virtualisation sont actives.

Vérifier la mise à jour

Après avoir appliqué les mises à jour à l'aide de fwupd, efitools, sbsigntool ou PowerShell, vérifiez que les certificats 2023 sont présents dans les variables UEFI de votre instance.

Linux

Quel que soit l'outil utilisé pour appliquer la mise à jour, les certificats sont écrits dans les variables NVRAM UEFI de l'instance. Vous pouvez les valider directement à l'aide de mokutil (recommandé) ou de efi-readvar :

• Utiliser mokutil (recommandé) : mokutil est installé par défaut sur la plupart des distributions Linux.

  sudo mokutil --kek | grep "KEK 2K CA 2023"
  sudo mokutil --db | grep "UEFI CA 2023"
  

• Utilisation de efi-readvar : si efitools est installé, exécutez la commande suivante :

  sudo efi-readvar -v KEK | grep "KEK 2K CA 2023"
  sudo efi-readvar -v db | grep "UEFI CA 2023"
  

Si les variables KEK et db affichent les certificats de 2023, la mise à jour a été appliquée avec succès et aucune autre action n'est requise.

Windows

Dans une invite PowerShell d'administrateur, exécutez la commande suivante :

# Check for Microsoft KEK 2K CA 2023
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

# Check for UEFI CA 2023
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'UEFI CA 2023'

# Confirm general Secure Boot enrollment state
Confirm-SecureBootUEFI

Résoudre les problèmes de mise à jour de la clé de chiffrement de clé

Lorsque vous mettez à jour la variable KEK sur Linux, la mise à jour de db (DBUpdate3P2023.bin) peut réussir, tandis que celle de KEK (kek2023update.bin) échoue avec l'une des erreurs suivantes :

• Lorsque vous utilisez sbkeysync :

  Inserting key update /etc/secureboot/keys/KEK/kek2023update.bin into KEK
  Error writing key update: Invalid argument
  Error syncing keystore file /etc/secureboot/keys/KEK/kek2023update.bin
  

• Lorsque vous utilisez efi-updatevar :

  Cannot write to KEK, wrong filesystem permissions
  

Cause

Dans le démarrage sécurisé UEFI, les mises à jour db (DBUpdate3P2023.bin) sont signées par l'autorité de certification KEK 2011 de Microsoft Corporation, qui est enregistrée par défaut sur la plupart des systèmes de démarrage sécurisé UEFI. Toutefois, les mises à jour KEK doivent être signées par la clé de plate-forme (PK) enregistrée dans le micrologiciel du système. Lorsque le micrologiciel rejette la signature sur kek2023update.bin ou empêche l'écriture dans la variable UEFI, le noyau Linux renvoie une erreur.

Cette erreur se produit pour l'une des raisons suivantes :

• La variable UEFI KEK est toujours marquée comme immuable : la commande chattr -i n'a pas été exécutée avant la tentative d'opération d'écriture.
• L'instance utilise un PK personnalisé : l'archive 1953fae13600a35944e93cd244476a6f6ce5fdbf620709b2f6f378fac2ae3bef-KEK-google_compute_engine.cab contient un binaire kek2023update.bin signé exclusivement par le PK Compute Engine par défaut. Si votre instance Compute Engine ou votre image personnalisée est associée à un PK personnalisé, le micrologiciel rejette kek2023update.bin.
• Le système n'est pas une instance Compute Engine : si vous exécutez ces commandes sur du matériel physique ou une machine virtuelle en dehors de Compute Engine, le PK du système appartient au fabricant du matériel ou au fournisseur de l'hyperviseur plutôt qu'à Compute Engine, ce qui entraîne le rejet de kek2023update.bin par le micrologiciel.

Solution

Pour diagnostiquer et résoudre l'erreur, procédez comme suit :

1. Assurez-vous de supprimer l'attribut immuable de la variable KEK immédiatement avant d'exécuter sbkeysync ou efi-updatevar :

   sudo chattr -i /sys/firmware/efi/efivars/KEK-*
   

2. Inspectez le PK enregistré sur votre instance :

   sudo mokutil --pk
   

3. Selon le résultat de sudo mokutil --pk, effectuez l'une des actions suivantes :

   • Si l'instance utilise un PK personnalisé : signez le binaire de mise à jour KEK avec la clé privée correspondant à votre PK personnalisé, ou recréez l'instance de calcul à partir d'un instantané de disque en utilisant une image qui s'appuie sur les certificats de démarrage sécurisé Compute Engine par défaut.
   • Si vous mettez à jour une machine autre que Compute Engine : supprimez /etc/secureboot/keys/KEK/kek2023update.bin et obtenez la mise à jour KEK auprès du fabricant de votre matériel ou du fournisseur de votre plate-forme (par exemple, en exécutant sudo fwupdmgr update si votre fournisseur le prend en charge).