Déverrouillage disque / Authentification matérielle

FIDO2 + LUKS

Clés FIDO2 opérationnelles pour LUKS, SDDM, Hyprlock et des comptes sensibles, avec voies de secours conservées.

LUKS2 FIDO2 TPM2 Plymouth UKI

Chaîne FIDO2, TPM et LUKS anonymisée — Vue publique: plusieurs voies de déverrouillage, cmdline UKI cohérente, token FIDO2 et voie de secours LUKS.

Enrôler

Maintenir plusieurs voies de déverrouillage indépendantes.

Embarquer

Vérifier que l'UKI contient les options nécessaires pour tenter FIDO2 au boot.

Démarrer

Distinguer visuellement le flux FIDO2 du flux TPM2 + PIN.

Diagnostiquer

Interpréter les erreurs token sans conclure trop vite à une corruption disque.

Contexte

Le problème réel.

Ajouter FIDO2 au déverrouillage disque ne suffit pas: la clé peut exister dans LUKS sans être tentée au boot si l'UKI n'embarque pas les bonnes options.

Objectifs

Ce que la solution devait garantir.

Conserver phrase de passe, clé de récupération, TPM2 + PIN et FIDO2 comme voies indépendantes.
Éviter qu'un slot FIDO2 dormant donne une fausse impression de protection.
Rendre l'invite de boot compréhensible pour l'utilisateur.
Documenter les points de blocage sans publier de slots réels ni identifiants matériel.

Architecture publique

Structure documentée, détails exploitables retirés.

LUKS2. Le volume chiffré conserve plusieurs méthodes d'ouverture.
UKI. La cmdline embarquée doit demander explicitement FIDO2 et TPM2 selon la cible.
Token. La clé matérielle demande PIN puis présence utilisateur quand ce chemin est utilisé.
Voies de secours. Le système garde des voies de secours en cas d'incident firmware ou token.

Exemples anonymisés

Ce qui peut être montré sans exposer le système réel.

Matrice d'ouverture

La matrice garde les rôles, mais retire numéros de slots, UUID et identifiants des clés.

méthode            rôle
phrase de passe    voie manuelle universelle
clé récupération   chemin d'urgence hors ligne
TPM2 + PIN         chemin quotidien lié au matériel
FIDO2 principale   chemin de déverrouillage par clé matérielle
FIDO2 secours      chemin de déverrouillage par clé de secours

Cmdline UKI attendue

La condition importante est publiée avec des placeholders documentaires : FIDO2 et TPM2 doivent être dans les options LUKS embarquées.

rd.luks.options=<encrypted-root>=fido2-device=auto,tpm2-device=auto,token-timeout=<short-timeout>,discard

Interprétation token

Les erreurs connues sont reformulées sans traces de boot réelles.

invite PIN affichée         le chemin FIDO2 est bien tenté
demande de contact affichée attendre la requête de présence avant de toucher la clé
PIN_AUTH_BLOCKED            vérifier le PIN et l'état du token hors boot
invite TPM affichée d'abord inspecter la cmdline UKI courante
slot présent mais inutilisé option fido2-device absente dans l'artefact de boot

Runbook public

Commandes et états attendus issus de la documentation privée.

Les commandes ci-dessous sont volontairement anonymisées: chemins, noms de machines, interfaces, dépôts, périphériques et actions destructrices sont remplacés par des placeholders.

Documentation privée: fido2-luks

Vérification des voies LUKS

Commandes anonymisées

systemd-cryptenroll <encrypted-root-device>
ukify inspect <signed-uki>
ykman fido info
ykman otp info

État attendu

LUKS2 contient les types de token fido2 et tpm2
la cmdline UKI inclut fido2-device=auto et tpm2-device=auto
le token FIDO est lisible hors boot
les slots OTP sont vides ou désactivés
le chemin du périphérique et les numéros de slots restent privés

Documentation privée: fido2-luks

Test FIDO2 contrôlé

Commandes anonymisées

systemd-cryptsetup attach <test-mapper-name> <encrypted-root-device> none fido2-device=auto
systemd-cryptsetup detach <test-mapper-name>
journalctl -b -0 --no-pager | rg -n 'fido2|tpm2|cryptsetup|luks'

État attendu

le test utilise un nom de mapper jetable
le PIN est demandé avant la présence utilisateur
l'échec d'authentification du token est diagnostiqué avant tout changement d'état LUKS
les logs sont lus par catégories, pas publiés bruts

Documentation privée: fido2-luks + Plymouth FIDO

Expérience de boot attendue

Commandes anonymisées

démarrer sur l'entrée UKI attendue
observer l'invite d'authentification
toucher la clé seulement après la demande de présence
revenir vers TPM2 + PIN ou une voie manuelle si FIDO2 échoue

État attendu

Plymouth affiche une invite FIDO2 explicite
la présence de la clé est visuellement distincte
l'état d'authentification acceptée est visible
la voie TPM2 ne demande pas de toucher la clé
les voies de secours restent disponibles et documentées

Travail réalisé

Décisions techniques publiables.

Matrice d'accès

La documentation distingue phrase de passe, clé de récupération, TPM2 + PIN, FIDO2 principal et FIDO2 secours.

Plymouth

Le thème rend l'étape FIDO2 lisible: attente de présence, validation et état final.

Authentification locale

Les clés sont également utilisées pour SDDM et Hyprlock, avec des voies de secours conservées.

OTP désactivé

Les clés sont exploitées sans OTP actif pour éviter les injections clavier parasites pendant le prompt.

Validation

Preuves et contrôles retenus.

Vérification des slots LUKS par type, pas par numéro publié.
Inspection de l'UKI pour confirmer les options FIDO2 et TPM2.
Authentification FIDO2 validée pour le déverrouillage LUKS, l'ouverture de session SDDM et le déverrouillage Hyprlock.
Clés FIDO2 utilisées sur les comptes sensibles, sans publier les services ni les écrans d'authentification.

Preuves visuelles

Contrôles observables et portée de la preuve.

**Slots LUKS et enrôlement FIDO2.** La capture montre les slots password, recovery, fido2 et tpm2 sur le volume chiffré, avec les identifiants masqués.

**UKI avec FIDO2 et TPM2.** L'inspection de l'UKI confirme la cmdline hybride avec fido2-device=auto et tpm2-device=auto.

**Référence de secours TPM2.** Cette capture PRA reste utile comme voie de secours et point de comparaison, mais elle ne remplace pas l'enrôlement FIDO2 sur l'hôte.

Résultats publics

Ce que le chantier démontre.

Chaîne d'authentification matérielle opérationnelle du boot à la session locale.
Réduction des ambiguïtés entre TPM et FIDO2.
Deux clés distinctes permettent de conserver une voie principale et une voie de secours.
Les preuves LUKS et UKI publiées sont représentatives; chaque authentification n'est pas reproduite en capture.

Anonymisation

Ce qui reste privé.

Pas de UUID LUKS, numéros de slots réels ou identifiants de clés.
Pas de périphérique disque exact.
Pas de cmdline complète.
Pas de capture de SDDM, Hyprlock ou de comptes sensibles contenant des informations personnelles.
Les commandes utilisent des placeholders documentaires et des états attendus.

Sources privées

Documentation d'origine.

Documentation FIDO2 + LUKS.
Documentation Boot Trust.
Runbook UKI stale après update.
Journal Plymouth FIDO premium.

Supplément de documentation privée anonymisé

FIDO2 + LUKS Morpheus

Cette page documente l'usage réel des clés FIDO2 pour LUKS, l'authentification locale et des comptes sensibles. Les UUID, périphériques, slots, identifiants de clés et informations de compte sont remplacés par des marqueurs documentaires ou restent privés.

Objectif

La cible est une ouverture de volume résiliente avec plusieurs voies indépendantes:

phrase de passe LUKS;
clé de récupération hors ligne;
slot TPM2 + PIN;
clé FIDO2 principale;
clé FIDO2 de secours.

L'objectif n'est pas de forcer un ordre particulier entre TPM et FIDO2, mais de conserver plusieurs moyens valides si l'un devient indisponible.

État validé

LUKS2 contient des slots FIDO2 en plus du slot TPM2.
La cmdline UKI embarque fido2-device=auto et tpm2-device=auto.
Le déverrouillage LUKS par FIDO2 fonctionne de bout en bout, avec les voies de secours conservées.
SDDM et Hyprlock acceptent les clés FIDO2 dans le flux d'authentification local prévu.
Les clés protègent également des comptes sensibles, sans publication des services concernés.
Les clés FIDO2 sont exploitées sans slot OTP actif pour éviter les injections clavier pendant l'invite PIN.

Les captures publiques se concentrent sur l'enrôlement LUKS et la cohérence UKI. Elles constituent un échantillon représentatif : reproduire chaque déverrouillage ou connexion n'apporterait pas de preuve technique supplémentaire et exposerait inutilement le contexte d'authentification.

Flux validé au boot

Voie FIDO2

Plymouth affiche une invite FIDO2 explicite.
Le PIN FIDO2 est saisi.
La clé est touchée seulement quand la présence utilisateur est demandée.
Si FIDO2 échoue, le flux peut retomber sur TPM2 ou les voies de secours LUKS conservées.

Voie TPM2 + PIN

Plymouth affiche une invite TPM explicite.
Le PIN TPM est saisi.
Le thème passe à l'état de chargement après validation.
Aucun message de touche de clé n'est affiché sur ce chemin.

Le rendu Plymouth distingue visuellement attente FIDO2, présence utilisateur, validation et chemin TPM2.

Usages complémentaires

SDDM : ouverture de session locale avec la clé FIDO2.
Hyprlock : déverrouillage de la session avec la clé FIDO2.
Comptes sensibles : second facteur ou méthode de connexion matérielle selon le service.

Les écrans d'authentification, noms de comptes et services concernés ne sont pas publiés. Cette retenue protège les informations personnelles sans remettre en cause la validation fonctionnelle.

Cmdline UKI attendue

rd.luks.options=<LUKS_UUID>=fido2-device=auto,tpm2-device=auto,token-timeout=10s,discard

Option obligatoire

Sans fido2-device=auto, un slot FIDO2 présent dans LUKS peut rester inutilisé au démarrage.

Vérification locale

sudo systemd-cryptenroll <LUKS_DEVICE>
sudo ukify inspect <UKI_IMAGE>
sudo systemd-cryptsetup attach <TEST_MAPPING> <LUKS_DEVICE> none fido2-device=auto
ykman fido info
ykman otp info

Attendu:

systemd-cryptenroll affiche les slots FIDO2 et TPM2.
ukify inspect confirme la cmdline hybride.
ykman otp info confirme que les slots OTP ne sont pas actifs sur les clés concernées.

Point de vigilance

Si PIN of security token is blocked apparaît, retirer puis réinsérer la clé FIDO2.
Si PIN_AUTH_BLOCKED revient, vérifier le PIN et l'état du token hors boot.
Si le boot demande encore TPM avant FIDO2, vérifier que l'UKI courante est bien celle attendue.