Secure Boot pour les modules noyau personnalisés : signature, flux de travail MOK et stratégie de distribution

Secure Boot pour des modules noyau personnalisés est pour les exploitants d’infrastructures modernes Linux et Kubernetes un aspect central de sécurité et d’exploitation. Ce guide fournit des instructions orientées pratique : quelles composantes interviennent, comment signer les modules de manière sécurisée, comment opérationnaliser le workflow MOK (Machine Owner Key), quelles stratégies de distribution ont du sens pour des flottes, comment intégrer DKMS et quelles précautions spécifiques sont nécessaires pour des clusters Kubernetes. L’objectif est un fonctionnement reproductible, des étapes de vérification claires et une stratégie de repli solide.

Pourquoi les modules personnalisés sont-ils bloqués avec Secure Boot ?

UEFI Secure Boot valide l’intégrité des bootloaders et des noyaux via une chaîne de certificats. shim est un boot-stub signé par l’équipe de la distribution, autorisé à charger le noyau et fournissant en parallèle des mécanismes (par ex. MOK) permettant aux exploitants d’enregistrer leurs propres certificats sans modifier la firmware PK/KEK/db. Dès que le noyau active le mode Lockdown, il vérifie les modules noyau (.ko) chargés pour des signatures valides. Si une signature de confiance ou le certificat approprié fait défaut, le chargement est refusé et des pilotes, des plugins de stockage ou des fonctions réseau peuvent ne plus fonctionner.

Clarification des termes : PK, KEK, db et MOK

PK représente le Platform Key (clé maîtresse du firmware), KEK sont les Key Exchange Keys (pour la gestion des signatures) et db est la base de données firmware contenant les certificats de confiance. MOK (Machine Owner Key) est un mécanisme dans shim qui permet aux exploitants d’ajouter leurs propres certificats sans modifier le PK/KEK/db du firmware. Dans le noyau, les certificats acceptés sont gérés dans des keyrings — s’ils y manquent, la vérification échoue.

Contrôles système préparatoires

Avant d’adapter des processus ou des pipelines, déterminez l’état par système. Vérifiez l’état de Secure Boot, de Lockdown et des outils.

# Basischecks
sudo mokutil --sb-state 2>/dev/null || echo "mokutil fehlt oder Secure Boot nicht aktiv"
sudo mokutil --list-enrolled 2>/dev/null || echo "Keine enrolled MOKs oder mokutil nicht vorhanden"
cat /sys/kernel/security/lockdown 2>/dev/null || echo "Lockdown-Status nicht verfügbar"
dmesg | egrep -i "module verification failed|Required key not available|lockdown" | tail -n 50

Si dmesg affiche des messages comme «module verification failed», c’est un indicateur clair de problèmes de signature ou de clés.

Signature : concept, protection des clés et procédure

Un module noyau est signé avec une signature PKCS#7 que le noyau vérifie au chargement. Formellement, vous avez besoin de deux artefacts : une clé privée de signature (pour créer la signature) et le certificat accompagnant (publique), qui sera enregistré comme approuvé sur les systèmes cibles. Le principe opérationnel le plus important : la clé privée ne doit pas être dispersée sur de nombreux serveurs.

Génération de clés (exemple sécurisé)

mkdir -p /root/module-signing && cd /root/module-signing
# Privaten RSA-Schlüssel + Self-Signed-Zertifikat erzeugen
openssl req -new -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes 
  -subj "/CN=Kernel Module Signing (MOK)/" 
  -keyout MOK.priv -out MOK.pem
# Konvertieren ins DER-Format für mokutil/import
openssl x509 -in MOK.pem -outform DER -out MOK.der
chmod 600 MOK.priv
chmod 644 MOK.pem MOK.der

Remarque : le flag -nodes supprime la passphrase ; cela permet une signature automatisée, mais augmente l’exigence de protection du lieu de stockage de la clé (HSM, serveur de signature sécurisé ou coffre CI/CD).

Opérationnaliser le workflow MOK

Le flux classique : vous importez le certificat public (format DER) avec mokutil –import. Cela génère une requête d’enrôlement en attente, qui doit être confirmée au prochain démarrage dans l’interface Shim graphique/firmware. C’est le point où les déploiements échouent souvent : la confirmation nécessite une console/écran ou un accès série.

# Zertifikat importieren (erzeugt Enrollment-Request)
sudo mokutil --import /root/module-signing/MOK.der
# Nach Reboot: enrolled keys auflisten
sudo mokutil --list-enrolled

Options opérationnelles pour les grandes flottes :

• Images préconfigurées : image déjà dotée des MOKs (pour environnements VM et cloud, si le fournisseur cloud l’autorise).
• Console distante/automation série : utilisez iKVM ou les Consoleredirection-APIs pour la confirmation automatisée.
• Gestion du firmware : sur des hôtes physiques, l’OEM/le fournisseur d’hébergement peut gérer les clés de façon centralisée dans la Firmware DB.

Il n’existe pas de méthode universelle et non interactive pour l’enrôlement des MOK sur toutes les implémentations de firmware ; cela nécessite donc un inventaire précis et la conception de processus.

Signer les modules et les intégrer dans le CI/CD

La signature doit devenir une étape standard de votre pipeline de build/release. Pour cela, on peut utiliser soit un conteneur/hôte de signature dédié dans la CI, soit un service de signature avec stockage sécurisé des secrets (HSM, Vault). Principes importants :

• La signature comme dernière étape du build avant le packaging.
• Ne jamais stocker les clés de signature directement dans les packages cibles ou sur les systèmes de production.
• Vérifier les modules après signature avec modinfo (Signer, sig_key, sig_hash).

Exemple : job GitLab-CI pour la signature

stages:
  - build
  - sign

build_module:
  stage: build
  script:
    - make -C src
    - cp src/mydriver.ko artifacts/
  artifacts:
    paths:
      - artifacts/

sign_module:
  stage: sign
  dependencies:
    - build_module
  image: ubuntu:22.04
  variables:
    SIGN_KEY_PATH: /buildsecrets/MOK.priv
    SIGN_CERT_PATH: /buildsecrets/MOK.pem
  script:
    - apt-get update && apt-get install -y openssl Linux-headers-$(uname -r)
    - /usr/src/Linux-headers-$(uname -r)/scripts/sign-file sha256 "$SIGN_KEY_PATH" "$SIGN_CERT_PATH" artifacts/mydriver.ko
  artifacts:
    paths:
      - artifacts/mydriver.ko

Dans la CI, stockez la clé privée dans un coffre à secrets protégé (GitLab CI/CD Variables avec masquage ou HashiCorp Vault). Le Runner effectue la signature dans un environnement contrôlé.

Intégration DKMS : hooks et automatisation

DKMS reconstruit les modules lors des mises à jour du noyau. Sans hook, DKMS produit souvent des modules non signés, qui ne seront pas chargés après une mise à niveau du noyau. Ajoutez des scripts DKMS qui signent après chaque build.

Exemple : hook post-install DKMS

# /usr/src//2.0/dkms.conf
# In dkms.conf
POST_BUILD="/usr/src//2.0/dkms-sign.sh"

# /usr/src//2.0/dkms-sign.sh
#!/bin/bash
set -euo pipefail
MODULE_PATH="$1/$2"
SIGN_KEY="/etc/secure-signing/MOK.priv"
SIGN_CERT="/etc/secure-signing/MOK.pem"

if [ -f "$MODULE_PATH" ]; then
  /usr/src/Linux-headers-$(uname -r)/scripts/sign-file sha256 "$SIGN_KEY" "$SIGN_CERT" "$MODULE_PATH"
  echo "Signed $MODULE_PATH"
else
  echo "Module $MODULE_PATH not found"
fi

Stockez les clés de signature sur un hôte de signature dédié ou dans un chemin sécurisé à accès restreint. Sur les hôtes cibles, ne déployez que le certificat public pour la phase d’enrôlement.

Stratégie de déploiement pour les flottes

Une vision cible robuste comprend :

• Signature centralisée dans la CI/CD ou dans un service de signature dédié.
• Distribution du certificat public (MOK.der) de manière contrôlée par image, paquet ou gestion de configuration (p. ex. Ansible/AWX), mais la phase d’enrôlement nécessite encore un redémarrage et une console.
• Livraison empaquetée (DEB/RPM) plutôt que copies de fichiers individuelles ; les scripts post-installation exécutent depmod et des mises à jour d’initramfs.
• Canary-Rollouts : d’abord quelques hôtes, puis validation à grande échelle.

Évitez de diffuser la clé privée ou de désactiver Secure Boot de manière systématique.

Perspective Kubernetes : opérations des Worker-Nodes et bonnes pratiques

Dans Kubernetes, les Worker-Nodes sont des points d’exploitation directs : l’absence de modules pour CNI (réseau), CSI (stockage) ou de pilotes matériels entraîne des Pods qui ne démarrent pas ou des erreurs de stockage. Par conséquent, vous devez différencier clairement les stratégies d’infrastructure et de cluster.

Stratégies pour les opérateurs de cluster

• Images de nœud immuables : construisez des images de nœud (AMI/VM-Templates) avec des modules déjà signés — ainsi la compilation DKMS sur les nœuds de production est évitée.
• Rolling Upgrade avec pool Canary : testez d’abord les nouvelles images sur des nœuds de test exclusifs.
• Node-Batching : ne redémarrez jamais tous les Worker en même temps ; tenez compte des PodDisruptionBudgets.
• Preflight-Gates : contrôles automatisés avant redémarrage pour vérifier que des modules signés existent pour le kernel cible.

Exemple : processus de redémarrage pour un nœud

# Drain Node
kubectl drain node-01 --ignore-daemonsets --delete-emptydir-data --timeout=10m
# Reboot und Healthcheck
ssh root@node-01 'reboot'
# Nach Reboot: Node wieder in Betrieb nehmen
kubectl uncordon node-01
kubectl get nodes --selector=kubernetes.io/hostname=node-01 -o wide

DaemonSet pour la vérification preflight des modules

Vous pouvez déployer un DaemonSet privilégié qui exécute modinfo sur chaque Node et rapporte les champs de signature (Attention : implications de sécurité liées aux privilèges).

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: module-signature-check
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: module-signature-check
  template:
    metadata:
      labels:
        name: module-signature-check
    spec:
      hostPID: true
      hostNetwork: true
      containers:
      - name: checker
        image: busybox
        securityContext:
          privileged: true
        command: ["/bin/sh", "-c"]
        args:
          - for m in /lib/modules/$(uname -r)/**/*.ko; do if [ -f "$m" ]; then modinfo "$m" | egrep -i "signer|sig_key|sig_hash|vermagic" || echo "$m: no sig info"; fi; done; sleep 3600
      tolerations:
      - operator: "Exists"
      RESTartPolicy: Always

Le checker fournit des indications sur la signature des modules critiques ; il ne doit cependant pas remplacer l’instance de confiance primaire.

Rotation des clés, révocation et planification d’urgence

La rotation des clés est une tâche organisationnelle : planifiez une phase de transition durant laquelle les clés anciennes et nouvelles sont acceptées en parallèle.

1. Générez une nouvelle paire de clés et publiez le nouveau certificat (MOK) pour la phase d’enrôlement.
2. Enrôlez le nouveau certificat sur tous les hôtes (Canary → Batch).
3. Signez progressivement les nouveaux modules avec la nouvelle clé et distribuez-les.
4. Après une phase d’observation, retirez l’ancienne clé.

Pour la révocation (p. ex. clé privée compromise), vous devez vérifier les mécanismes du firmware ou du noyau pour le verrouillage (dbx ou politique locale) ; documentez les procédures Break-Glass et le protocole de communication.

Monitoring, Tests und CI-Preflight-Checks

Les tests automatisés sont essentiels : le CI doit, avant la release, vérifier qu’un module, après signature, rapporte une composante de signature avec modinfo. En production, surveillez les entrées dmesg et les métriques de readiness des nœuds. Exemple de check dans le CI :

# CI Preflight
modinfo artifacts/mydriver.ko | egrep -i "signer|sig_key|sig_hash" || (echo "ERROR: Modul nicht signiert" && exit 1)
# Simulierter modprobe (falls sicherheitsseitig erlaubt)
sudo modprobe -v artifacts/mydriver.ko || true
sudo dmesg | tail -n 50 | egrep -i "module verification failed|Required key not available" && exit 1 || echo "Preflight OK"

Stratégie de repli (Break-Glass) — par étapes

Si un déploiement provoque des incidents :

• Identifiez via la console les erreurs dmesg et modprobe.
• Démarrez, si possible, sur un noyau antérieur via le menu de démarrage.
• Si l’enrôlement est défaillant : effectuez manuellement le MOK-Enrollment via la console (en cas d’accès physique) ou utilisez des procédures de console distante planifiées.
• En dernier recours et uniquement temporairement : désactiver Secure Boot (firmware) pour sauver les systèmes critiques — puis analyser de manière forensique la cause.

Chaque cas Break-Glass doit être documenté, évalué et le processus modifié ensuite de façon à empêcher toute répétition.

Brève liste de contrôle opérationnelle avant un large déploiement

• Inventaire : hôtes avec Secure Boot, variantes de firmware et options de console.
• Modèle de signature : clé privée sécurisée, certificat public distribué.
• CI/CD : signature automatisée ; Preflight-Checks implémentés.
• DKMS : utiliser des hooks ou des images construites.
• Kubernetes : stratégie d’image pour les nœuds, Canary-Rollout, scripts de drain/uncordon.
• Monitoring : motifs dmesg, métriques de readiness des nœuds, alerting.
• Rollback : sauvegardes de démarrage/noyau, procédures de console, contacts administratifs.

Conclusion

Secure Boot protège la chaîne de démarrage et augmente la sécurité du centre de données, mais n’est opérationnellement pertinent que si les processus de signature, la gestion des clés et l’enrôlement sont correctement organisés. S’appuyant sur un modèle central de signature, une signature automatisée dans CI/DKMS-Hooks, une distribution packagée et des Canary-Rollouts soigneux, Secure Boot peut être exploité de manière fiable dans des environnements Linux hétérogènes et Kubernetes. Planifiez les voies d’enrôlement, testez les Preflight-Checks et définissez des procédures Break-Glass claires — ainsi Secure Boot reste actif et vos modules noyau propriétaires restent disponibles et maintenables au fil des mises à jour du noyau.

Secure Boot pour les modules noyau propriétaires : risques opérationnels et alternatives d’architecture

Outre la signature et le MOK-Enrollment, vous devez examiner l’architecture opérationnelle et les risques potentiels de point de défaillance unique. Trois domaines sont décisifs : la conservation des clés, le chemin de distribution et d’enrôlement ainsi que l’observabilité. Des modèles d’architecture éprouvés minimisent la surface d’attaque et le risque d’indisponibilité.

Modèle d’architecture recommandé :

• Service central de signature avec HSM ou Vault : la clé privée reste dans un service sécurisé, le CI/CD reçoit uniquement des tokens autorisés de courte durée. Cela évite la distribution de clés privées sur les hôtes cibles.
• Métadonnées de signature dans les paquets: complétez les DEB/RPM par des informations sur le signataire et la provenance des checksums, afin que les outils de déploiement puissent prendre des décisions de preflight.
• Stratégies d’enrôlement séparées par classes d’hôtes: Cloud‑VMs, bare‑metal et bare‑metal avec console restreinte requièrent des workflows d’enrôlement distincts (image avec MOK préalable, iKVM/serial pour les enrollements, modifications du firmware du fournisseur pour les hôtes critiques).

Mesures opérationnelles de précaution:

• Inventaire: implémentation du firmware, console disponible ?, capacités prises en charge (shim, mokutil).
• Pool canari avec télémétrie: validez les chargements de modules, la disponibilité des nœuds et les erreurs dmesg avant un déploiement à grande échelle.
• Monitoring: centralisez les motifs journald/dmesg pour « module verification failed » et mettez en place l’alerte avec des SLO.

Plan d’urgence: définissez des procédures break‑glass claires et testées (fallback‑kernel, plan de console distante, désactivation temporaire de Secure Boot uniquement en dernier recours) et documentez les responsabilités. Ainsi vous reliez les exigences de sécurité à un modèle d’exploitation robuste pour des environnements d’entreprise et de cluster sur mesure.

La signature des modules du noyau et le Machine Owner Key (Mok) sont également importants pour ce sujet. L’article replace ces aspects de façon compréhensible et montre ce qui compte au quotidien.