Chiffrement des disques (LUKS)

Un hôte chiffré (volume LUKS2 déclaré dans sa configuration disko) protège ses données en cas de vol ou de mise au rebut, mais réclame une passphrase à chaque démarrage. DNF industrialise ce point de friction avec deux garanties :

• plusieurs moyens de déverrouillage coexistent en permanence, la perte d’un moyen (passphrase oubliée, YubiKey égarée) n’enferme jamais dehors ;
• le prompt du boot se répond à distance, depuis le poste d’administration, sans écran ni clavier branchés sur l’hôte, et cela dès le tout premier démarrage qui suit l’installation.

Les moyens de déverrouillage

Chaque moyen occupe son propre keyslot dans l’en-tête LUKS2. Tous sont valables en même temps, sur chaque volume chiffré de l’hôte.

Moyen	Où il vit	Rôle
Passphrase partagée	sops → luks-passphrase	Une seule pour tout le parc, autorise la gestion des keyslots. C’est aussi elle qui formate le disque
Passphrase par hôte	sops → luks/<hôte>/passphrase	À confier à l’utilisateur de la machine sans exposer le parc
YubiKeys FIDO2	Dérivé de la clé physique	Toucher la clé au boot, rien à taper

Pourquoi deux passphrases et pas une

Elles ne s’adressent pas aux mêmes personnes : la partagée est la clé de l’administrateur du parc, celle par hôte se confie à l’utilisateur d’une seule machine. Et parce qu’elles sont deux, la rotation de l’une reste autorisée par l’autre : le service de synchronisation ne se retrouve jamais sans moyen d’agir sur les keyslots, il ajoute le nouveau slot avant de tuer l’ancien.

Il n’y a plus de passphrase d’installation

just install formate le volume avec la passphrase partagée (nixos-anywhere --disk-encryption-keys) : le keyslot de formatage est le keyslot partagé. Rien à retenir de l’installation, rien à retaper ensuite. Le premier poste, installé par darkone new, est formaté avec la passphrase tapée dans l’assistant : elle devient la passphrase partagée du parc. Un hôte installé avant cette bascule est détecté par just luks <hôte>, qui demande alors sa passphrase d’installation une dernière fois pour amorcer le slot partagé.

Rien à déclarer dans la configuration Nix

Le module darkone.system.luks est actif par défaut mais totalement inerte tant que l’hôte n’apparaît pas dans le manifeste usr/secrets/luks.json et ne déclare pas de volume LUKS dans son disko. Les hôtes chiffrés existants ne bougent pas tant que just luks <hôte> n’a pas été lancé.

Provisionner un hôte

just luks <hôte>            # provisionne (ou converge) le chiffrement
just luks <hôte> pre        # moitié hors ligne, sans toucher à la machine
just luks <hôte> passwd     # fait tourner la passphrase par hôte
just luks <hôte> show       # audit : table des keyslots + conformité
just luks <hôte> '' <ip>    # cible une IP explicite (hôte pas encore résolu)

La recette est idempotente : chaque exécution converge et ne demande que ce qui manque. Elle est appelée automatiquement à deux moments, et il est rare d’avoir à la lancer soi-même :

Appelée par	Action	Ce qu’elle fait
just install <hôte>	pre	Avant le build, donc avant l’installation
just install-here <hôte>	pre, sans compte nix (bootstrap-keys)	Premier poste, depuis l’ISO
just configure <hôte>	(défaut)	Après le premier démarrage

Sans volume LUKS dans le disko, c’est un no-op journalisé.

La phase pre ne touche jamais la machine. Elle prépare ce qui doit exister avant que le système ne soit construit :

1. la passphrase partagée dans sops si absente (demandée une seule fois pour tout le parc) ;
2. la passphrase par hôte dans sops si absente, générée au hasard et sans rien demander (voir l’encadré ci-dessous) ;
3. la clé d’hôte SSH de l’initrd, générée localement et rangée dans sops (luks/<hôte>/initrd-key, encodée en base64) ;
4. l’inscription de l’hôte dans le manifeste public usr/secrets/luks.json (versionné en clair, il ne contient aucun secret) : c’est cette entrée qui active le module.

Pourquoi la passphrase par hôte n’est jamais demandée à l’installation

Elle sert à confier le déverrouillage d’une station à son utilisateur sans lui donner la clé de tout le parc. Mais au moment du formatage on ignore encore qui utilisera la machine : la réponse était toujours « vide ». Et une question interactive au milieu d’une installation est exactement ce qui casse une installation à distance.

Elle est donc tirée au hasard et gardée dans sops seule. Le slot garde son utilité — c’est un second moyen d’ouvrir le volume, et le repli de just unlock. Le jour où quelqu’un doit vraiment taper une passphrase sur cette machine, just luks <hôte> passwd lui en donne une choisie, et luks-passphrase-sync échange le slot au prochain apply.

La phase par défaut ajoute ce qui demande la machine :

5. repose la clé d’initrd depuis sops si elle manque sur la cible (elle n’en régénère jamais une nouvelle, cela invaliderait celle qu’a posée l’installation) ;
6. sur une passerelle, relève l’IP WAN courante dans le manifeste (repli de just unlock, voir plus bas), à relancer si le fournisseur d’accès renumérote ;
7. si aucune passphrase gérée ne déverrouille le volume (hôte installé avant la bascule vers le formatage partagé), demande sa passphrase d’installation une dernière fois et enrôle la partagée avec.

Puis committer et déployer :

git add usr/secrets/luks.json
just commit "system(luks): <hôte>"
just apply <hôte>

Au déploiement, deux services idempotents convergent l’en-tête LUKS à chaque apply : luks-passphrase-sync (passphrases partagée et par hôte) et yubikey-luks-enroll (une entrée FIDO2 par YubiKey enrôlée sur le parc, voir Authentification forte).

La clé d’initrd doit précéder le chargeur d’amorçage

Les secrets d’initrd sont embarqués à l’installation du chargeur d’amorçage : une clé créée après coup n’est tout simplement pas dans l’initrd qui démarre. Une installation neuve est couverte, just install dépose la clé sous /mnt avant nixos-install. Sur une machine déjà en service, c’est just luks <hôte> qui la pose par SSH : ne jamais ajouter un hôte à luks.json à la main, et ne jamais déployer avant que la clé ne soit sur la cible. En cas de doute, just luks <hôte> show le vérifie.

Rotation des passphrases

• Par hôte : just luks <hôte> passwd, puis commit et apply. L’ancien keyslot est supprimé et remplacé au déploiement suivant.
• Partagée : modifier luks-passphrase via just sops, puis apply sur tout le parc — chaque hôte chiffré fait tourner son keyslot au passage.

Le service de synchronisation détecte les changements grâce à un registre local (/var/lib/luks-passphrase/ledger) : une valeur sops modifiée enrôle la nouvelle passphrase puis tue l’ancien slot. Les slots absents du registre (FIDO2, enrôlements manuels) ne sont jamais touchés.

Déverrouiller au démarrage

Tout hôte chiffré suit la même séquence, sans rien à régler :

1. YubiKey — une clé enrôlée et branchée fait clignoter sa diode : la toucher ouvre le volume, rien à taper. Aucune clé branchée, l’étape dure ~6 s ; une clé que personne ne touche, ~30 s (limite du firmware).
2. Passphrase — une invite est ensuite posée, sans limite de temps. Elle accepte la passphrase par hôte, la partagée ou celle d’installation.

L’invite de l’étape 2 est une seule et même demande, servie en parallèle sur la console physique (/dev/tty1) et par ssh sur le port 2222. Rien à choisir, aucune fenêtre à rater : le premier qui répond ouvre le volume.

Comment la clé est essayée

fido2-device= n’est pas écrit dans l’entrée crypttab mais dans une unité initrd séparée, yubikey-luks-unlock-<volume>, ordonnée avant systemd-cryptsetup@<volume> et seulement reliée à elle par un Wants= : elle a le droit d’échouer, et son échec ne change rien au démarrage.

Cette séparation évite deux défauts qui se contredisent :

• l’option dans le crypttab tue le démarrage quand une clé est branchée sans que personne la touche : systemd-cryptsetup sort en erreur au lieu de proposer la passphrase, aucun prompt n’est posé — ni console, ni port 2222 — et l’initrd bascule en emergency. Une coupure de courant sur un hôte sans personne devant suffisait à l’immobiliser ;
• sans l’option, le token n’est essayé que s’il est déjà énuméré. Or hidraw0 apparaît environ une seconde après le lancement de systemd-cryptsetup : jamais à temps. La clé cesse alors de déverrouiller quoi que ce soit, en silence, et sans rien dans le journal.

Ce que l’option apporte réellement, c’est l’attente du périphérique (token-timeout=, réglé à 5 s).

À distance, l’initrd démarre un sshd dédié sur le port 2222, avec sa propre clé d’hôte persistante, accessible uniquement avec la clé de déploiement nix. just unlock y répond :

just unlock <hôte>     # passphrase lue dans sops, sinon demandée au terminal

just unlock attend que le port 2222 apparaisse (un point par tentative), lit la passphrase partagée dans sops et la pousse dans l’initrd, puis vérifie que la machine a bien quitté son initrd avant d’annoncer un succès. Si elle est refusée, il réessaie avec la passphrase par hôte. C’est ce que just full-install appelle tout seul après le premier redémarrage. Sur un hôte non chiffré, c’est un no-op journalisé.

Pourquoi la partagée d’abord

Au tout premier démarrage, le slot par hôte n’existe pas encore : disko formate avec la passphrase partagée, et luks-passphrase-sync n’ajoute le slot par hôte que depuis le système démarré, donc après le déverrouillage. La partagée est le seul moyen d’entrer à ce moment-là.

Par ailleurs dnf-unlock sait seulement qu’il a répondu à la demande, jamais si la passphrase a été acceptée : systemd se contente de redemander. Le seul témoin fiable est donc la machine qui quitte son initrd et répond sur le port 22, et c’est ce que just unlock observe depuis le poste d’administration.

Aucune passphrase stockée acceptée, ou pas de clé d’infrastructure sur le poste : depuis un terminal, just unlock présente le prompt LUKS via systemd-tty-ask-password-agent. Il sonde le 2222 sur l’IP explicite (si fournie), le nom d’hôte, puis l’IP WAN enregistrée dans le manifeste. Dans les deux cas, la passphrase acceptée, le démarrage continue et le port 22 revient.

Pourquoi deux chemins

systemd-tty-ask-password-agent ne parle qu’à un terminal : aucun script ne peut le piloter. L’initrd embarque donc un petit utilitaire dnf-unlock qui prend la passphrase sur un tube et répond à toutes les demandes en attente. C’est lui que just unlock appelle.

Pourquoi l’IP WAN ?

Le VPN d’une zone meurt avec sa passerelle : quand celle-ci attend sa passphrase, seule sa patte WAN est joignable. Son initrd réplique d’ailleurs l’adressage de production (IP statique sur le pont lan0, DHCP côté WAN), puisqu’elle est elle-même le serveur DHCP que son initrd attendrait sinon. Les autres hôtes font un simple DHCP sur leurs interfaces filaires.

Portables en Wi-Fi

Pas de réseau en initrd sans câble : un portable chiffré se déverrouille à la console (passphrase ou YubiKey), le déverrouillage à distance ne s’applique pas.

Un pilote de NIC ne suffit pas toujours

Une carte virtio ne se branche pas sur son emplacement PCI mais sur le périphérique virtio0 que crée son transport (virtio_pci, virtio_mmio). Sans ce module dans l’initrd, virtio_net n’est jamais chargé : aucun lien, aucune IP, et le sshd du port 2222 écoute dans le vide — l’hôte attend indéfiniment sa passphrase, sans rien dans le journal pour le dire.

Les deux transports sont désormais embarqués d’office, et just luks <hôte> show compare les pilotes réellement utilisés par les cartes filaires de la machine avec ceux que porte l’initrd construit.

Pilotes réseau détectés à l’installation

nixos-generate-config ne met jamais de pilote réseau dans l’initrd. Une carte hors de la liste embarquée d’office (Broadcom tg3 par exemple) laisse donc l’hôte injoignable en initrd.

just install et just copy-hw lancent just detect-hw : il relève sur la machine les modules de ses cartes filaires et les écrit dans usr/machines/<hôte>/hardware/detected-hardware.nix, importé automatiquement. Ces modules ne sont ajoutés à l’initrd que s’il a du réseau (déverrouillage à distance).

Sur un hôte déjà installé, si just luks <hôte> show signale un pilote manquant : just detect-hw <hôte>, puis just apply <hôte>.

Vérifier un hôte

just luks <hôte> show n’écrit rien : il interroge la machine et rend compte. Il sort en erreur dès qu’un contrôle échoue, donc il s’utilise aussi dans un script.

just luks <hôte> show

Un premier bloc dresse la table des keyslots de chaque volume. Rien n’y est supposé : chaque passphrase gérée est réellement essayée contre l’en-tête, donc la colonne « Check » dit ce que le volume accepte aujourd’hui, pas ce qu’un registre a mémorisé.

/dev/disk/by-partlabel/disk-main-luks
  Slot  Content              Source                       Check
  ----  -------------------  ---------------------------  -----------------
  0     Shared passphrase    sops luks-passphrase         opens the volume
  1     Host passphrase      sops luks/poste/passphrase   opens the volume
  2     YubiKey alice/main   systemd-fido2 token          enrolled
  7     Unknown              -                            not managed by DNF
  Slots in use: 4/32

Un slot « Unknown »

Aucune passphrase gérée ne l’ouvre et aucun token FIDO2 ne le revendique. Le plus souvent c’est un enrôlement YubiKey interrompu entre la création du keyslot et l’écriture de son token — typiquement pendant une installation, où la convergence de la passphrase redémarre le service d’enrôlement. Le service répare désormais lui-même ce cas au just apply suivant : il adopte le keyslot s’il appartient à une clé déclarée, le supprime s’il fait doublon. Un slot qui persiste après un apply vient donc d’ailleurs : un systemd-cryptenroll manuel, par exemple — DNF n’y touche jamais, faute de pouvoir prouver à qui il appartient.

Un second bloc audite le déverrouillage distant, point par point :

Contrôle	Ce qu’il attrape
Hôte présent dans luks.json	Le module resterait inerte
Clé d’initrd sur la cible (+ empreinte)	Prochain apply sans déverrouillage distant
Sauvegarde sops de même empreinte	Une réinstallation perdrait l’accès distant
sshd d’initrd activé dans la configuration	nix.pub manquant, ou hôte hors manifeste
Chargeur d’amorçage postérieur à la clé	Le piège : clé absente de l’initrd qui démarre
Pilotes des cartes filaires présents dans l’initrd	Pas de réseau en stage 1 : rien ne répond sur 2222
Système démarré = configuration auditée	Un apply en attente rendrait l’audit trompeur
IP WAN relevée (passerelles)	Injoignable en initrd une fois le VPN tombé

Sous le capot

Emplacement	Contenu	Statut
usr/secrets/luks.json	Manifeste des hôtes provisionnés + IP WAN des passerelles	Public, versionné
secrets.yaml → luks-passphrase	Passphrase partagée du parc	Chiffré sops
secrets.yaml → luks/<hôte>/passphrase	Passphrase par hôte	Chiffré sops
secrets.yaml → luks/<hôte>/initrd-key	Clé d’hôte SSH de l’initrd (base64)	Chiffré sops
/var/lib/luks-initrd/ (cible)	Copie de travail de la clé d’initrd	Persistant, hors dépôt
/var/lib/luks-passphrase/ledger (cible)	Registre des keyslots gérés (détection des rotations)	Persistant, hors dépôt

Le module expose deux options : darkone.system.luks.enable (défaut true) et darkone.system.luks.sshPort (défaut 2222).

Budget de keyslots

Un en-tête LUKS2 contient au plus 32 keyslots. Chaque YubiKey enrôlée en consomme un sur chaque hôte chiffré (politique de parc), en plus des passphrases partagée et par hôte. Le module avertit quand le total projeté approche de la limite.

Voir aussi

• Authentification forte (YubiKey) : l’enrôlement des clés physiques, dont le volet LUKS FIDO2
• Gestion des secrets : sops, clés age et rotation
• Le Justfile : la référence des recettes luks, enter et configure