Un disque chiffré, une clé matérielle… et un démarrage qui échoue

Un ordinateur professionnel peut être perdu ou volé. Chiffrer son volume système permet de protéger les données au repos, mais laisse une question très concrète : comment autoriser leur accès au démarrage ? Une phrase secrète est une première réponse. Une carte à puce ou une YubiKey permet d’ajouter une méthode de déverrouillage fondée sur un matériel détenu par l’utilisateur.

C’est ce besoin qui m’a conduit, dans le cadre de travaux menés chez ADACIS, à examiner le déverrouillage d’un volume LUKS via PKCS#11. La configuration fonctionnait sous Fedora, mais le même usage rencontrait des difficultés sous Debian et Ubuntu avec dracut. Le point bloquant se trouvait dans l’environnement de démarrage, avant l’ouverture du volume racine.

Le 30 octobre 2025, j’ai ouvert le signalement dracut nº 1794. Un an après son traitement, ce retour complète l’article publié sur le blog ADACIS : comprendre la chaîne technique, regarder ce qui a réellement été corrigé et savoir quoi vérifier sur une machine actuelle.

Le résultat à valider n’est pas seulement « ma clé est reconnue ». C’est « ma clé permet de déverrouiller le bon volume, dans l’environnement réellement exécuté au démarrage ».

Le besoin de sécurité : protéger un poste perdu ou volé

Le repère principal est la mesure 31 du Guide d’hygiène informatique de l’ANSSI : « Chiffrer les données sensibles, en particulier sur le matériel potentiellement perdable ». LUKS fournit le chiffrement ; la carte contrôle l’accès au secret d’ouverture. Mesure 31, p. 42.

Une carte avec PIN contribue aussi à la mesure 13, consacrée à l’authentification forte, sous réserve de valider les deux facteurs et les accès alternatifs. Mesure 13, p. 19.

Ce que fait LUKS, et ce que fait la YubiKey

Il faut d’abord séparer le chiffrement des données de la méthode utilisée pour accéder aux clés. LUKS organise notamment les métadonnées et les emplacements de clés, ou keyslots, du volume. Le chiffrement et le déchiffrement des blocs sont réalisés sur l’ordinateur, par la pile de stockage Linux et dm-crypt. La clé USB ne traite donc pas chaque lecture et chaque écriture du disque. Documentation du noyau : dm-crypt.

Dans le parcours étudié ici, la YubiKey fournit une fonction de carte à puce accessible via PKCS#11, une interface standard pour utiliser des objets et opérations cryptographiques. Une paire de clés RSA ou EC doit déjà être disponible dans le jeton, avec les objets nécessaires à sa découverte. systemd-cryptenroll permet de l’associer à un volume LUKS2.

Dans le cas RSA, le jeton réalise l’opération privée permettant de retrouver le secret utilisé pour le déverrouillage. La clé privée matérielle n’a pas à être exportée. Le secret obtenu est toutefois utilisé par le système : cela ne signifie pas que tous les secrets restent en permanence dans le périphérique. Enrôlement PKCS#11 dans systemd.

Le mot YubiKey ne suffit pas à décrire cette architecture : une même clé peut offrir plusieurs applications. Le mode PIV/PKCS#11 présenté ici et le mode FIDO2 sont deux parcours distincts. Le bug de 73pcsc ne doit pas être généralisé au déverrouillage FIDO2.

Une prise en charge native, au-delà de la YubiKey

Le parcours présenté s’appuie sur des fonctions intégrées à la pile Linux : dm-crypt/LUKS pour le disque, systemd-cryptenroll pour l’enrôlement et systemd-cryptsetup pour l’ouverture. La prise en charge PKCS#11 de systemd-cryptenroll existe depuis systemd 248. « Natif » signifie ici que ces composants prennent en charge le mécanisme ; les paquets, la configuration et l’image de démarrage doivent encore être préparés pour la distribution utilisée. Manuel de systemd-cryptenroll.

On s’éloigne ainsi des montages plus délicats qui ajoutaient des scripts au démarrage pour transformer une réponse du jeton en secret LUKS. Le projet historique yubikey-luks, par exemple, utilise un keyscript et le mode challenge-response de la YubiKey. Ce mécanisme appartient à son application OTP ; il ne faut pas le confondre avec U2F. Aujourd’hui, FIDO2 dispose lui aussi d’une intégration native dans systemd, avec un jeton compatible hmac-secret. L’intérêt du parcours PKCS#11 étudié ici est notamment de réutiliser une infrastructure de cartes à puce et de certificats. Projet yubikey-luks et modes pris en charge par systemd.

La YubiKey est donc un exemple de matériel, pas une dépendance exclusive. D’autres cartes à puce et jetons à certificats peuvent remplir ce rôle, si leur module PKCS#11 permet de retrouver le certificat ou la clé publique et d’effectuer les opérations de déverrouillage avec la clé privée conservée dans le périphérique. OpenSC contient notamment un pilote pour plusieurs modèles Gemalto/Thales IDPrime. Cela ouvre la voie à la réutilisation de cartes d’entreprise existantes. Pilote IDPrime d’OpenSC.

La présence d’un certificat ne suffit cependant pas à promettre une compatibilité universelle. Il faut valider le modèle de carte, le lecteur, le middleware, les algorithmes et les usages autorisés de la clé privée : une carte réservée à la signature peut ne pas permettre l’opération attendue. Ces éléments doivent aussi fonctionner dans l’initramfs. C’est précisément cette dernière condition qui explique le bug rencontré entre distributions.

Avant le système complet, il y a l’initramfs

Pour ouvrir la racine chiffrée, Linux doit disposer d’un premier environnement qui ne dépend pas encore de cette racine. C’est le rôle de l’initramfs : une image contenant les outils, bibliothèques, pilotes et configurations utiles à cette phase du démarrage. dracut construit cette image à partir de modules et de la configuration de la machine.

Installer OpenSC dans le système principal ne garantit donc pas sa présence dans cette image. Le matériel peut fonctionner une fois la session ouverte, alors que la pile nécessaire pour l’utiliser au pré-boot reste incomplète. Documentation dracut.

Du démarrage au volume ouvert
  1. Charger l’environnement initialLe noyau lance l’initramfs, avant de pouvoir accéder à la racine chiffrée.noyau → initramfs
  2. Rendre la carte utilisableLa pile PKCS#11 et ses dépendances doivent être présentes dans cette image.p11-kit · OpenSC · pcscd
  3. Autoriser l’opération privéeLa YubiKey effectue l’opération ; le PIN est requis selon sa politique.PKCS#11 ↔ YubiKey
  4. Ouvrir le volume LUKS2Le système obtient l’accès au volume et poursuit le démarrage sur la racine.systemd-cryptsetup → dm-crypt

Schéma de principe : la clé matérielle participe au déverrouillage ; le chiffrement des blocs reste effectué sur l’ordinateur.

Dans cet environnement, systemd-cryptsetup prend en charge l’ouverture du volume. Pour le parcours carte à puce, il doit pouvoir accéder au jeton par une pile logicielle cohérente : p11-kit pour la découverte des modules, OpenSC pour l’interface PKCS#11 et pcscd, avec les pilotes nécessaires, pour l’accès à la carte. OpenSC documente précisément ce rôle d’intermédiaire avec les cartes cryptographiques. Présentation d’OpenSC et service systemd-cryptsetup.

Le bug : trois différences entre distributions

Le signalement initial concernait dracut 108, avec un cas fonctionnel sous Fedora 42 et un échec rapporté sous Ubuntu 25.10, ainsi que les problèmes de portabilité Debian/Ubuntu détaillés dans l’issue. Ce sont les références du diagnostic de 2025, pas une affirmation sur toutes les installations actuelles.

Trois écarts ressortaient de l’analyse du module 73pcsc :

ÉlémentHypothèse ou omission dans le module concernéBesoin identifié côté Debian/Ubuntu
Déclaration p11-kitRecherche de opensc.modulePrendre aussi en compte opensc-pkcs11.module
Bibliothèques OpenSCInclusion incomplète dans le cas étudiéAjouter la famille libeac.so*
Configuration localeChemin /etc/opensc.confConsidérer aussi /etc/opensc/opensc.conf

Leur conséquence est plus importante que la taille des changements : un fichier oublié à la génération de l’image manque aussi au moment où le système essaie d’utiliser la carte. Description et échanges du signalement nº 1794.

Même matériel, deux environnements différents
Après le démarrage

Système principal

  • Paquets et dépendances installés
  • Configuration OpenSC accessible
  • Jeton utilisable dans la session

Fonctionne dans ce contexte

Avant l’ouverture de la racine

Initramfs incomplet

  • Déclaration p11-kit absente ou inadaptée
  • Bibliothèque omise dans l’image
  • Chemin de configuration non pris en compte

Parcours PKCS#11 en échec

Illustration du diagnostic historique, pas une capture ni un constat sur toutes les versions actuelles.

Ce diagnostic évite une fausse piste : reconnaître le périphérique USB ne prouve pas que l’application peut l’utiliser. Entre le périphérique et le déverrouillage LUKS, une bibliothèque ou une configuration manquante suffit à interrompre le parcours.

Du signalement au correctif intégré

La contribution a suivi le fonctionnement habituel d’un projet open source : un cas reproduit, des échanges avec les mainteneurs, puis un changement intégré. La PR nº 1804, proposée par jozzsi, a conduit à l’intégration du commit 1575aea44209d56ca0e80ca287b8f00f739e332d, le 31 octobre 2025. Le signalement a été fermé comme résolu le même jour. PR nº 1804 et commit intégré.

Voici trois extraits du changement retenu dans modules.d/73pcsc/module-setup.sh. Ils expliquent le correctif ; ils ne constituent pas un patch à appliquer aveuglément à une version récente.

1. Déclarer les deux noms de module p11-kit

     inst_multiple -o \
         pcscd \
-        /usr/share/p11-kit/modules/opensc.module
+        /usr/share/p11-kit/modules/opensc.module \
+        /usr/share/p11-kit/modules/opensc-pkcs11.module

Le nom historique reste accepté, et le nom utilisé côté Debian/Ubuntu est ajouté. L’option -o rend cette installation de fichiers optionnelle : un chemin absent sur une distribution n’empêche pas, à lui seul, la génération.

2. Inclure la bibliothèque manquante

+        {"tls/$_arch/",tls/,"$_arch/",}"libeac.so*" \
         {"tls/$_arch/",tls/,"$_arch/",}"libpcsclite.so.*" \

Cette expression Bash couvre plusieurs variantes de chemins de bibliothèques. Son rôle est de faire entrer la dépendance dans l’initramfs. Ajouter son paquet sur le système principal sans reconstruire l’image ne corrigerait pas une image déjà générée.

3. Prévoir le second chemin de configuration

     if [[ $hostonly ]]; then
         inst_multiple -H -o \
             /etc/opensc.conf \
+            /etc/opensc/opensc.conf \
             "/etc/reader.conf.d/*"

L’ajout concerne ici le bloc host-only, qui reprend la configuration locale dans l’image adaptée à la machine. Cette condition fait partie du correctif : il serait inexact de présenter la copie comme inconditionnelle.

Extraits du commit cité, fichier du projet dracut sous licence GPL-2.0-or-later. Les chemins et la variable $_arch correspondent à cette révision historique.

Le correctif final ne reprend donc pas exactement toutes les pistes évoquées au départ : il conserve deux déclarations explicites plutôt qu’un joker sur leur nom, et l’ajout de bibliothèque porte sur libeac.so*. Cette distinction est utile pour comprendre ce qui a effectivement été accepté en amont.

Vérifier une installation actuelle, dans le bon ordre

Un correctif intégré au dépôt amont ne prouve pas qu’un paquet installé le contient. Les distributions livrent leurs versions et peuvent appliquer des rétroportages. La bonne démarche consiste à identifier le paquet, lire son historique et examiner l’image de démarrage réellement utilisée.

Identifier le volume et la pile installée

Les commandes suivantes servent au diagnostic ; elles ne chiffrent ni ne modifient un volume :

lsblk -o NAME,TYPE,FSTYPE,UUID,MOUNTPOINTS
systemd --version
dracut --version

# Détecter les jetons PKCS#11 utilisables, sans enrôlement.
systemd-cryptenroll --pkcs11-token-uri=list

La dernière commande examine les jetons depuis le système en cours d’exécution. Un résultat positif confirme cette partie du parcours, pas le bon fonctionnement de l’initramfs. L’absence de dracut ou d’une commande attendue est également une information : il faut d’abord établir quel générateur d’image utilise réellement la machine.

Inspecter l’image qui sera démarrée

Avec lsinitrd, fourni par dracut, on peut distinguer les modules inclus et les fichiers embarqués. Remplacer le chemin ci-dessous par l’image correspondant au noyau à tester :

INITRAMFS="/chemin/vers/image-initramfs"

sudo lsinitrd -m "$INITRAMFS"
sudo lsinitrd "$INITRAMFS" |
  grep -E 'pcscd|opensc.*\.module|opensc-pkcs11\.so|libeac\.so|opensc\.conf'

Sur Fedora, un chemin courant est /boot/initramfs-<version-noyau>.img. Sur Debian/Ubuntu, on rencontre notamment /boot/initrd.img-<version-noyau>. Le nom du fichier ne suffit pas à identifier son générateur. Manuel de lsinitrd.

Ce filtre donne des indices, pas une preuve complète : il faut contrôler les bons chemins, les dépendances de la version installée et le chargement effectif de la pile. De même, dracut --list-modules liste les modules disponibles, alors que lsinitrd -m examine ceux de l’image choisie.

Distinguer l’enrôlement de la configuration de démarrage

Sur un volume déjà en LUKS2, avec une carte correctement provisionnée et un moyen de récupération vérifié, l’enrôlement peut prendre cette forme :

# Exemple à adapter au conteneur LUKS identifié, en environnement de test.
sudo systemd-cryptenroll \
  --pkcs11-token-uri=auto \
  /dev/disk/by-uuid/UUID_DU_CONTENEUR_LUKS

Cette commande ajoute une méthode d’accès ; elle ne crée pas la paire de clés dans la carte et ne transforme pas un disque non chiffré en volume LUKS2. Le mode auto suppose qu’un unique jeton adapté puisse être sélectionné ; sinon, on utilise une URI PKCS#11 explicite. Documentation de systemd-cryptenroll.

La configuration de démarrage doit ensuite demander ce mode d’ouverture. Exemple schématique dans /etc/crypttab :

cryptroot UUID=UUID_DU_CONTENEUR_LUKS none luks,pkcs11-uri=auto

cryptroot est ici un nom d’exemple. Il faut préserver le nom de mapping et les options nécessaires à l’installation existante, puis régénérer l’image avec l’outil et la procédure de la distribution. Une ligne crypttab correcte dans le système principal ne garantit pas que l’image déjà présente dans /boot a été mise à jour. Format et options de crypttab.

Une clé matérielle suffit-elle à parler de MFA ?

Le matériel apporte un facteur de possession. Un PIN exigé par la carte peut ajouter un facteur de connaissance. La politique réellement appliquée doit toutefois être vérifiée : les règles de PIN et de présence tactile varient selon la clé, son application et sa configuration. Toucher une clé confirme une présence physique ; ce geste n’est pas, à lui seul, un secret supplémentaire. Politiques PIN et touch documentées par Yubico.

Il faut aussi examiner les autres méthodes d’ouverture. Une phrase secrète conservée dans un autre keyslot reste un accès alternatif : l’ajout du jeton ne rend pas automatiquement obligatoire l’association « carte + PIN » pour tous les accès. Cette voie de récupération a une utilité opérationnelle, mais elle fait partie du modèle de sécurité.

Enfin, le chiffrement au repos ne garantit pas l’intégrité de la chaîne d’amorçage. La confiance dans le firmware, le chargeur, le noyau et l’initramfs doit être traitée séparément, notamment avec une architecture Secure Boot adaptée. Après ouverture du volume, retirer la YubiKey ne le referme pas automatiquement et ne protège pas d’un système déjà compromis.

Ce que je validerais avant un déploiement

Le test décisif reste un redémarrage maîtrisé sur une machine de validation. Je retiendrais au minimum ces scénarios :

  • Clé présente et PIN correct : le bon volume s’ouvre et le système poursuit son démarrage.
  • Clé absente ou PIN incorrect : le comportement correspond à la politique prévue, sans multiplier les essais au risque de bloquer la carte.
  • Clé perdue ou hors service : la procédure de récupération permet un redémarrage, avec un accès aux secrets de secours encadré.
  • Mise à jour du noyau ou des paquets : la nouvelle image contient toujours les composants nécessaires et le parcours est retesté.

Conserver un moyen de récupération éprouvé et une sauvegarde protégée de l’en-tête LUKS évite de dépendre d’un seul objet ou d’une seule image. Cette sauvegarde conserve des éléments d’accès aux données et doit être traitée comme sensible. Manuel de la sauvegarde d’en-tête. Les traces d’incident, quant à elles, doivent permettre de distinguer l’USB, PC/SC, PKCS#11 et l’ouverture du volume : « ça ne démarre pas » est un symptôme, pas encore un diagnostic.

Les commandes présentées ici ont été vérifiées dans les documentations citées. Cet article n’est pas le compte rendu d’un nouveau test de démarrage réalisé sur toutes les versions actuelles de Fedora, Debian et Ubuntu.

Du chiffrement à la conformité : ce que l’on peut justifier

Les recommandations de l’ANSSI permettent de traduire le besoin de protection en critères vérifiables. Deux textes complètent utilement le Guide d’hygiène :

  • Les Recommandations relatives à l’authentification multifacteur et aux mots de passe (2021), notamment R1 sur le multifacteur et R3 sur l’analyse de risque, aident à définir la politique « carte + PIN », l’attribution du matériel et le traitement des accès de secours. Guide ANSSI.
  • Les Recommandations sur le nomadisme numérique, version 2.0 (2023), vont plus loin : R9 prévoit chiffrement, TPM et contrôle de l’amorçage ; R9+ y associe carte à puce et PIN. Le parcours PKCS#11 présenté ici ne démontre pas cette combinaison. Deux enrôlements indépendants, TPM et carte, restent des accès alternatifs ; ils n’imposent pas leur usage conjoint. Guide ANSSI, § 3.3.4.

Sur le plan réglementaire, l’article 32, paragraphe 1, point a), du RGPD cite le chiffrement parmi les mesures de sécurité adaptées au risque pour les données personnelles. Un poste professionnel chiffré, avec un accès matériel maîtrisé, peut donc apporter une réponse concrète à cette obligation de sécurité. L’analyse de risque, la configuration retenue et les résultats des tests doivent permettre d’expliquer pourquoi cette protection est adaptée au traitement concerné. Texte de l’article 32 publié par la CNIL.

La conformité se construit avec les mesures techniques et leur exploitation : gestion des habilitations, secours, sauvegardes et contrôles réguliers. Le Guide d’hygiène est une recommandation ; le RGPD est un texte contraignant dans son champ d’application. Enfin, cette association de logiciels et de matériel ne lui confère pas automatiquement une qualification ou un agrément ANSSI : si le contexte l’exige, il faut sélectionner un produit disposant du statut requis et respecter son périmètre d’emploi.

Une alternative aux offres payantes sous Windows

Cette intégration change aussi la comparaison économique. Linux dispose d’une chaîne de chiffrement et de déverrouillage par carte à puce fondée sur des composants libres, sans licence de chiffrement supplémentaire par poste. À mes yeux, elle entre directement en concurrence avec les solutions propriétaires payantes qui proposent une authentification au pré-boot sous Windows, sur ce besoin précis. Symantec Endpoint Encryption documente, par exemple, l’usage de cartes PIV et de lecteurs au démarrage. Documentation Broadcom.

La comparaison mérite d’être précise : Windows possède aussi une solution native, BitLocker, disponible selon l’édition et la licence. Microsoft indique toutefois que BitLocker ne prend pas en charge les cartes à puce pour l’authentification au pré-boot ; leur utilisation sur des volumes de données est un autre cas. C’est bien le parcours « volume système + carte à puce au démarrage » que l’on compare ici. FAQ BitLocker, authentification par carte à puce au pré-boot.

Le coût d’une offre commerciale peut aussi couvrir une console d’administration, le déploiement, la récupération centralisée, le support et les preuves de conformité. LUKS et systemd fournissent le mécanisme technique ; ces services d’exploitation restent à organiser. L’économie de licence doit donc être rapprochée du coût complet de gestion du parc.

Pourquoi la YubiKey reste un choix économique crédible

Dans cette architecture ouverte, je considère une YubiKey disposant de PIV comme une alternative économique et fiable, sous réserve de la validation du modèle et du parcours de démarrage. Son format USB évite un lecteur de carte séparé, et sa prise en charge documentée permet de s’appuyer sur une pile maintenue. Il faut budgéter le provisionnement, un moyen de secours et le remplacement du matériel. La gamme YubiKey 5 offre PIV ; une clé limitée à FIDO/U2F ne convient pas à ce parcours PKCS#11. Documentation PIV de Yubico.

L’adoption de ces matériels dépasse le poste Linux. Le 30 avril 2026, OpenAI et Yubico ont annoncé un partenariat pour protéger les comptes ChatGPT avec des passkeys matérielles dans le programme Advanced Account Security. Il s’agit de l’usage FIDO/passkeys, distinct du déverrouillage LUKS par PIV. Annonce officielle de Yubico.

L’annonce a aussi été suivie d’un fort intérêt boursier : le 4 mai 2026, Omni Économie rapportait une hausse d’environ 15 % en séance du titre Yubico, dans un contexte associant ce partenariat et une analyse de SEB sur les besoins de sécurité face à l’IA. C’est un signal commercial ; la fiabilité du pré-boot s’évalue par les contrôles techniques décrits plus haut. Compte rendu du 4 mai.

Linux et souveraineté : un choix qui s’inscrit dans une stratégie nationale

Cette possibilité de conserver un déverrouillage matériel sur Linux rejoint un enjeu plus large : réduire les dépendances numériques de l’État. Le 8 avril 2026, la DINUM a annoncé sa propre sortie de Windows au profit de postes Linux, dans une démarche de souveraineté menée avec la DGE, l’ANSSI et la DAE. Chaque ministère doit aussi formaliser un plan de réduction des dépendances extra-européennes. L’annonce porte donc sur les postes de la DINUM et sur une planification interministérielle plus large. Communiqué officiel.

Dans ce contexte, fiabiliser LUKS, systemd et la pile carte à puce lève un obstacle concret à la migration : pouvoir changer de système d’exploitation en conservant un moyen matériel de contrôle d’accès. Les composants libres et les interfaces standardisées donnent davantage de latitude pour auditer, maintenir et remplacer les briques. La souveraineté dépend aussi des fournisseurs de matériel, du support et des compétences disponibles ; l’ouverture de l’architecture permet justement de travailler ces choix sans l’enfermer dans une seule marque de jeton.

Ma conclusion

Le point central de ce retour d’expérience est simple : un déverrouillage matériel fiable dépend de toute la chaîne de démarrage. Une carte compatible et un volume correctement enrôlé ne suffisent pas si l’environnement chargé avant la racine chiffrée ne contient pas les bons fichiers.

L’intérêt de la contribution à dracut est d’avoir corrigé cette intégration à sa source, plutôt que de laisser chaque installation maintenir ses propres copies de bibliothèques. C’est aussi ce qui rend le travail utile au-delà de la YubiKey utilisée dans le cas initial : il porte sur la prise en charge de la pile carte à puce, avec ses conditions de compatibilité.

Pour moi, la valeur du dispositif se mesure à trois résultats : le démarrage nominal fonctionne, l’échec est compréhensible et la récupération reste possible. Une fois ces conditions remplies, cette chaîne native et ouverte constitue une alternative concrète pour protéger un parc Linux, contribuer aux exigences de sécurité applicables et accompagner une démarche de souveraineté. C’est cet ensemble qui permet de passer d’une démonstration technique à une protection exploitable au quotidien.

Sources et repères

Article rédigé le 3 novembre 2026 à partir du signalement historique, du correctif intégré et des documentations consultées. Les commandes et chemins sont à adapter aux versions installées.