Merci pour ta question, elle est légitime : avant de parler d’outils, il faut clarifier le threat model.
Dans mon cas, je ne cherche pas à me protéger d’un datacenter entièrement compromis façon “attaquant omnipotent”. Je pars du principe que :
L’infrastructure peut être honnête-mais-curieuse (accès physique limité mais possible, techniciens qui peuvent voir/booter la machine).
Je veux réduire les attaques opportunistes ou non ciblées, pas me défendre contre un adversaire disposant d’un budget NSA.
Le matériel est standard, donc pas de racine de confiance matérielle parfaite, mais je veux au moins détecter les modifications de firmware/boot.
Je sais bien qu’on ne peut pas atteindre la sécurité absolue sur du hardware que je ne maîtrise pas. En revanche, ce que permettent Heads, TrenchBoot et les mécanismes de mesure d’intégrité, c’est :
Augmenter le coût de l’attaque : un technicien ne pourra plus simplement booter une clé USB ou flasher un firmware sans que ce soit détecté.
Détecter l’altération de la chaîne de démarrage via des mesures dans le TPM — ce qui est déjà un gain considérable.
Valider l’intégrité du système avant de déployer des secrets (clé de déchiffrement, volumes, etc.).
Limiter l’impact d’un accès physique court (evil-maid, reflash simple, boot sur matériel modifié).
Et justement :
c’est parce que ces menaces existent mais ne relèvent pas d’un attaquant tout-puissant que de tels outils sont développés et utilisés — pour rendre l’attaque plus difficile, plus coûteuse et surtout détectable.
En résumé :
- Je ne cherche pas une sécurité absolue, mais un niveau de confiance raisonnable dans un environnement que je ne contrôle pas entièrement.
- Les outils du type Heads/TrenchBoot servent précisément à couvrir ce type de scénario.
Tu parles de la seed des Ledger, ou bien des passkeys utilisées avec cryptsetup ?
Parce que rien ne t’oblige à sortir ta seed du Ledger ou à la noter. :)
Si tu parle du passkey, cryptsetup ne reçoit JAMAIS la clé privée FIDO2
Avec FIDO2, le fonctionnement est inversé par rapport à un smartcard classique :
LUKS n’a jamais le secret.
Seule la clé USB FIDO2 possède la clé privée.
LUKS n’obtient qu’une signature.
Ce comportement est imposé par le protocole CTAP2 : aucune commande ne permet d’exporter la clé privée.
Pendant l’enrôlement (cryptenroll), cryptsetup enregistre uniquement un identifiant
Quand tu enroll un token FIDO2, cryptsetup :
envoie un challenge à la clé FIDO2 ;
la clé crée un credential interne : une paire de clés privée/publique ;
cryptsetup reçoit uniquement :
la clé publique,
un credential ID,
quelques métadonnées FIDO2.
Jamais la clé privée.
Elle reste dans le Secure Element de la clé USB.
LUKS stocke juste la clé publique dans l’en-tête du volume.
Pendant l’ouverture du disque, cryptsetup fait une vérification FIDO2
Quand tu tapes : cryptsetup open /dev/sdaX toto --token-id 1
voici ce qui se passe :
1) LUKS génère un challenge aléatoire
Ce challenge ne contient aucune clé sensible.
2) La clé FIDO2 signe ce challenge en interne
La signature est faite avec la clé privée interne, qui :
n’est pas exportable,
n’est jamais vue par le kernel,
n’est jamais stockée dans la RAM du PC.
3) Cryptsetup vérifie cette signature avec la clé publique stockée dans l’en-tête LUKS
Si la signature est valide :
cryptsetup débloque la clé LUKS (la vraie clé de chiffrement).
Cette clé LUKS est chiffrée dans un keyslot et n’est pas liée au FIDO2.
La clé FIDO2 ne dérive pas la clé LUKS et ne la voit jamais.
Elle sert uniquement à valider que l’utilisateur possède le bon token.
Résultat : cryptsetup n’a jamais accès à la clé FIDO2
La clé privée FIDO2 :
n’est jamais transmise,
n’entre jamais dans la RAM du PC,
n’est jamais écrite sur disque,
ne transite jamais sur USB sous forme brute.
Elle ne sert qu’à signer un challenge, à l’intérieur du token.
Donc :
✔ LUKS ne voit que des signatures
✔ La clé privée reste physiquement dans le hardware
✔ Même un rootkit ne peut pas l’extraire
✔ L’hôte ne peut rien faire d’autre que vérifier l’authenticité du token
Comme tu l’as dit, FIDO2 est une norme ouverte.
On peut donc utiliser des clés Yubikey, Nitrokey, ta Thetis PRO-A…
Mais on peut aussi utiliser des clés avec SEED, comme les clés Ledger.
Contrairement à une clé FIDO2 “classique”, qui génère un secret interne aléatoire et non récupérable, une clé avec SEED repose sur une phrase secrète standardisée (généralement 12, 18 ou 24 mots).
Cette phrase — la seed — sert de secret maître.
Grâce à cette seed :
l’appareil peut reproduire exactement les mêmes secrets internes, même après réinitialisation ;
si tu perds la clé, tu peux en racheter une autre, y restaurer la seed, et régénérer le même secret ;
tu peux même avoir une seconde clé configurée avec la même seed pour faire un backup fiable.
C’est pour ça que les clés Ledger ne servent pas uniquement à la crypto : elles peuvent aussi être utilisées dans des scénarios de chiffrement comme DM-Crypt/LUKS avec FIDO2, tout en permettant une restauration fiable du secret si le matériel est perdu ou détruit.
Si vous souhaitez utiliser une clé Ledger, il faut bien sûr adapter la commande cryptenroll en modifiant :
--fido2-with-client-pin=false
En effet, sur une clé Ledger, la validation du PIN se fait physiquement sur l’appareil.
Personnellement, pour le chiffrement de mon disque, je préfère ce type de clé : le PIN est saisi directement sur l’appareil, ce qui élimine tout risque de keylogger côté système.
Il existe aussi des solutions open source pour les clés FIDO2, comme SoloKey ou Nitrokey (qui s’appuie d’ailleurs sur SoloKey).
Malheureusement, je n’ai trouvé aucune clé open hardware offrant le même fonctionnement qu’une Ledger, qui reste un produit intéressant… et en plus provenant d’une société française. 🇫🇷
Effectivement, GrapheneOS a un Duress PIN. Et pour rappel, bien avant GrapheneOS il existait déjà des petites applications capables de wipe le téléphone si on le branchait à un port USB-C, si on entrait un mot de passe trop long, un PIN spécifique, si on activait le mode avion, etc.
Sauf que ces applications avaient un énorme défaut : il suffisait de booter le téléphone en Safe Mode, et hop, dans le cul Lulu, elles étaient désactivées :)
Donc la police scientifique ne s’y intéressait pas plus que ça.
Mais le chiffrement d’un Pixel sous Stock OS ou sous GrapheneOS, c’est le même. Le bootloader est verrouillé, et il faut évidemment que le suspect — qui n’a pas encore été condamné — coopère.
S’il ne coopère pas, on peut lui infliger une peine.
Là où ça coince, c’est que l’arsenal législatif n’a pas pris en compte les mécanismes d’autodestruction :)
Et c’est là que les criminels (les vrais) manquent d’imagination :
pourquoi détruire le téléphone avec un code Duress ? C’est idiot : ils risquent quand même une peine. Du genre « on n’a rien pu déchiffrer, mais on vous punit quand même parce qu’on n’a rien trouvé » :)
Je dis bien risquent, car un bon avocat pourrait défendre l’idée qu’il n’y a plus rien, donc qu’on ne cache aucun secret de chiffrement.
Alors comment faire pour respecter la loi tout en étant encore plus vertueux ?
Très simplement : avec GOS, pas besoin de Duress PIN.
Il y a une fonction d’auto-reboot, par défaut réglée à 18 h.
Tu configures ton profil owner avec tes applications “templates” vides.
Tu crées un user guest dans lequel tu installes tes applications, et tu actives l’option auto-delete pour le profil invité.
Tu ne travailles que dans le profil guest, évidemment avec une vraie phrase de passe.
Pour rappel, chaque profil a son propre chiffrement séparé.
Tu te fais arrêter dans une belle manifestation et on te demande ton mot de passe.
Tu attends les 18 h, le téléphone reboot.
Et automatiquement, la clé de chiffrement du profil guest est effacée du keystore.
Dans le cul Lulu, en même temps que le profil guest.
Tu peux alors donner très calmement ton téléphone au gentil officier.
Et maintenant, on a des applis de messagerie open source qui commencent à être vraiment bonnes.
Simplex Chat, par exemple :)
Un bon backup de la base exporté via Cryptomator, et tu récupères tes contacts. Pas de serveur central, pas de numéro de téléphone.
Vive la liberté, et vive le cul à Lulu.
PS : On peut, avec un Pixel sous Stock OS, avoir la même sécurité que sous GOS :
une application d’auto-reboot avec les droits admin Android + un profil guest.
Dans le cul Lulu.
PPS : Pas besoin de parler de Gaël Duval, de son passif avec Mandrake, et de la bouse que ça a été — pourtant tellement aimée par certains d’entre vous.
Longue vie à Debian, longue vie à OpenBSD.
Et de toute façon, les projets de Gaël finiront comme Mandrake/Mandriva : les mauvais produits finissent toujours à la benne.
OK, OK, j’arrête de troller → user@trollfr:~$ exit 🚪
Je pense justement que plus de personnes qui les contactent, plus ça les fera réfléchir.
Un envoi massif, avec des milliers de développeurs qui s’expriment, les pousserait peut-être à sortir de leurs réponses mollassonnes.
# stboot
Posté par gnuromain . En réponse au journal Sécuriser le boot dans un datacenter hostile : Heads, Trenchboot, ME… que choisir en 2025 ?. Évalué à 7 (+8/-1).
Chers moules,
En fait, j’ai besoin de ce projet open source qui fait exactement ce que je veux :
https://git.glasklar.is/system-transparency/core/stboot
https://www.system-transparency.org/
Il ne me reste plus qu’à trouver des serveurs compatibles coreboot :) Une idée de bons revendeurs ? Du bon matos de chez pépé ? :)
Je ne me suis encore jamais amusé avec coreboot, donc tout retour d’expérience ou conseil est le bienvenu.
[^] # Re: Threat model
Posté par gnuromain . En réponse au journal Sécuriser le boot dans un datacenter hostile : Heads, Trenchboot, ME… que choisir en 2025 ?. Évalué à 10 (+11/-1).
Merci pour ta question, elle est légitime : avant de parler d’outils, il faut clarifier le threat model.
Dans mon cas, je ne cherche pas à me protéger d’un datacenter entièrement compromis façon “attaquant omnipotent”. Je pars du principe que :
L’infrastructure peut être honnête-mais-curieuse (accès physique limité mais possible, techniciens qui peuvent voir/booter la machine).
Je veux réduire les attaques opportunistes ou non ciblées, pas me défendre contre un adversaire disposant d’un budget NSA.
Le matériel est standard, donc pas de racine de confiance matérielle parfaite, mais je veux au moins détecter les modifications de firmware/boot.
Je sais bien qu’on ne peut pas atteindre la sécurité absolue sur du hardware que je ne maîtrise pas. En revanche, ce que permettent Heads, TrenchBoot et les mécanismes de mesure d’intégrité, c’est :
Augmenter le coût de l’attaque : un technicien ne pourra plus simplement booter une clé USB ou flasher un firmware sans que ce soit détecté.
Détecter l’altération de la chaîne de démarrage via des mesures dans le TPM — ce qui est déjà un gain considérable.
Valider l’intégrité du système avant de déployer des secrets (clé de déchiffrement, volumes, etc.).
Limiter l’impact d’un accès physique court (evil-maid, reflash simple, boot sur matériel modifié).
Et justement :
c’est parce que ces menaces existent mais ne relèvent pas d’un attaquant tout-puissant que de tels outils sont développés et utilisés — pour rendre l’attaque plus difficile, plus coûteuse et surtout détectable.
En résumé :
- Je ne cherche pas une sécurité absolue, mais un niveau de confiance raisonnable dans un environnement que je ne contrôle pas entièrement.
- Les outils du type Heads/TrenchBoot servent précisément à couvrir ce type de scénario.
[^] # Re: DM-CRYPT et FIDO2
Posté par gnuromain . En réponse au journal Les bases de l'authentification, clé de sécurité FIDO2 sous Linux et Windows. Évalué à 2 (+2/-0).
Tu parles de la seed des Ledger, ou bien des passkeys utilisées avec cryptsetup ?
Parce que rien ne t’oblige à sortir ta seed du Ledger ou à la noter. :)
Si tu parle du passkey, cryptsetup ne reçoit JAMAIS la clé privée FIDO2
Avec FIDO2, le fonctionnement est inversé par rapport à un smartcard classique :
LUKS n’a jamais le secret.
Seule la clé USB FIDO2 possède la clé privée.
LUKS n’obtient qu’une signature.
Ce comportement est imposé par le protocole CTAP2 : aucune commande ne permet d’exporter la clé privée.
Pendant l’enrôlement (cryptenroll), cryptsetup enregistre uniquement un identifiant
Quand tu enroll un token FIDO2, cryptsetup :
envoie un challenge à la clé FIDO2 ;
la clé crée un credential interne : une paire de clés privée/publique ;
cryptsetup reçoit uniquement :
la clé publique,
un credential ID,
quelques métadonnées FIDO2.
Jamais la clé privée.
Elle reste dans le Secure Element de la clé USB.
LUKS stocke juste la clé publique dans l’en-tête du volume.
Pendant l’ouverture du disque, cryptsetup fait une vérification FIDO2
Quand tu tapes : cryptsetup open /dev/sdaX toto --token-id 1
voici ce qui se passe :
1) LUKS génère un challenge aléatoire
Ce challenge ne contient aucune clé sensible.
2) La clé FIDO2 signe ce challenge en interne
La signature est faite avec la clé privée interne, qui :
n’est pas exportable,
n’est jamais vue par le kernel,
n’est jamais stockée dans la RAM du PC.
3) Cryptsetup vérifie cette signature avec la clé publique stockée dans l’en-tête LUKS
Si la signature est valide :
cryptsetup débloque la clé LUKS (la vraie clé de chiffrement).
Cette clé LUKS est chiffrée dans un keyslot et n’est pas liée au FIDO2.
La clé FIDO2 ne dérive pas la clé LUKS et ne la voit jamais.
Elle sert uniquement à valider que l’utilisateur possède le bon token.
Résultat : cryptsetup n’a jamais accès à la clé FIDO2
La clé privée FIDO2 :
n’est jamais transmise,
n’entre jamais dans la RAM du PC,
n’est jamais écrite sur disque,
ne transite jamais sur USB sous forme brute.
Elle ne sert qu’à signer un challenge, à l’intérieur du token.
Donc :
✔ LUKS ne voit que des signatures
✔ La clé privée reste physiquement dans le hardware
✔ Même un rootkit ne peut pas l’extraire
✔ L’hôte ne peut rien faire d’autre que vérifier l’authenticité du token
# DM-CRYPT et FIDO2
Posté par gnuromain . En réponse au journal Les bases de l'authentification, clé de sécurité FIDO2 sous Linux et Windows. Évalué à 6 (+6/-0).
Il n’y a pas que l’authentification : on peut aussi utiliser FIDO2 pour protéger des secrets et chiffrer son système.
Voici un petit script qui fonctionne parfaitement sous Debian 12/13 :
https://github.com/bertogg/fido2luks
Comme tu l’as dit, FIDO2 est une norme ouverte.
On peut donc utiliser des clés Yubikey, Nitrokey, ta Thetis PRO-A…
Mais on peut aussi utiliser des clés avec SEED, comme les clés Ledger.
Contrairement à une clé FIDO2 “classique”, qui génère un secret interne aléatoire et non récupérable, une clé avec SEED repose sur une phrase secrète standardisée (généralement 12, 18 ou 24 mots).
Cette phrase — la seed — sert de secret maître.
Grâce à cette seed :
l’appareil peut reproduire exactement les mêmes secrets internes, même après réinitialisation ;
si tu perds la clé, tu peux en racheter une autre, y restaurer la seed, et régénérer le même secret ;
tu peux même avoir une seconde clé configurée avec la même seed pour faire un backup fiable.
C’est pour ça que les clés Ledger ne servent pas uniquement à la crypto : elles peuvent aussi être utilisées dans des scénarios de chiffrement comme DM-Crypt/LUKS avec FIDO2, tout en permettant une restauration fiable du secret si le matériel est perdu ou détruit.
Si vous souhaitez utiliser une clé Ledger, il faut bien sûr adapter la commande cryptenroll en modifiant :
--fido2-with-client-pin=false
En effet, sur une clé Ledger, la validation du PIN se fait physiquement sur l’appareil.
Personnellement, pour le chiffrement de mon disque, je préfère ce type de clé : le PIN est saisi directement sur l’appareil, ce qui élimine tout risque de keylogger côté système.
Il existe aussi des solutions open source pour les clés FIDO2, comme SoloKey ou Nitrokey (qui s’appuie d’ailleurs sur SoloKey).
Malheureusement, je n’ai trouvé aucune clé open hardware offrant le même fonctionnement qu’une Ledger, qui reste un produit intéressant… et en plus provenant d’une société française. 🇫🇷
# Les trafiquants n'ont vraiment pas assez d'imagination :)
Posté par gnuromain . En réponse au journal Le Parisien qualifie GrapheneOS de "botte secrète des narcotrafiquants", les devs n'apprécient pas. Évalué à -3 (+4/-7).
Effectivement, GrapheneOS a un Duress PIN. Et pour rappel, bien avant GrapheneOS il existait déjà des petites applications capables de wipe le téléphone si on le branchait à un port USB-C, si on entrait un mot de passe trop long, un PIN spécifique, si on activait le mode avion, etc.
Sauf que ces applications avaient un énorme défaut : il suffisait de booter le téléphone en Safe Mode, et hop, dans le cul Lulu, elles étaient désactivées :)
Donc la police scientifique ne s’y intéressait pas plus que ça.
Mais le chiffrement d’un Pixel sous Stock OS ou sous GrapheneOS, c’est le même. Le bootloader est verrouillé, et il faut évidemment que le suspect — qui n’a pas encore été condamné — coopère.
S’il ne coopère pas, on peut lui infliger une peine.
Là où ça coince, c’est que l’arsenal législatif n’a pas pris en compte les mécanismes d’autodestruction :)
Et c’est là que les criminels (les vrais) manquent d’imagination :
pourquoi détruire le téléphone avec un code Duress ? C’est idiot : ils risquent quand même une peine. Du genre « on n’a rien pu déchiffrer, mais on vous punit quand même parce qu’on n’a rien trouvé » :)
Je dis bien risquent, car un bon avocat pourrait défendre l’idée qu’il n’y a plus rien, donc qu’on ne cache aucun secret de chiffrement.
Alors comment faire pour respecter la loi tout en étant encore plus vertueux ?
Très simplement : avec GOS, pas besoin de Duress PIN.
Il y a une fonction d’auto-reboot, par défaut réglée à 18 h.
Tu configures ton profil owner avec tes applications “templates” vides.
Tu crées un user guest dans lequel tu installes tes applications, et tu actives l’option auto-delete pour le profil invité.
Tu ne travailles que dans le profil guest, évidemment avec une vraie phrase de passe.
Pour rappel, chaque profil a son propre chiffrement séparé.
Tu te fais arrêter dans une belle manifestation et on te demande ton mot de passe.
Tu attends les 18 h, le téléphone reboot.
Et automatiquement, la clé de chiffrement du profil guest est effacée du keystore.
Dans le cul Lulu, en même temps que le profil guest.
Tu peux alors donner très calmement ton téléphone au gentil officier.
Et maintenant, on a des applis de messagerie open source qui commencent à être vraiment bonnes.
Simplex Chat, par exemple :)
Un bon backup de la base exporté via Cryptomator, et tu récupères tes contacts. Pas de serveur central, pas de numéro de téléphone.
Vive la liberté, et vive le cul à Lulu.
PS : On peut, avec un Pixel sous Stock OS, avoir la même sécurité que sous GOS :
une application d’auto-reboot avec les droits admin Android + un profil guest.
Dans le cul Lulu.
PPS : Pas besoin de parler de Gaël Duval, de son passif avec Mandrake, et de la bouse que ça a été — pourtant tellement aimée par certains d’entre vous.
Longue vie à Debian, longue vie à OpenBSD.
Et de toute façon, les projets de Gaël finiront comme Mandrake/Mandriva : les mauvais produits finissent toujours à la benne.
OK, OK, j’arrête de troller → user@trollfr:~$ exit 🚪
[^] # Re: Meme réponse molle
Posté par gnuromain . En réponse au journal Contribution à la consultation sur la première révision du Digital Markets Act. Évalué à 2.
Très bonne idée, fais-leur un mail :)
Il faut les réveiller un peu :)
[^] # Re: Meme réponse molle
Posté par gnuromain . En réponse au journal Contribution à la consultation sur la première révision du Digital Markets Act. Évalué à 2.
Je pense justement que plus de personnes qui les contactent, plus ça les fera réfléchir.
Un envoi massif, avec des milliers de développeurs qui s’expriment, les pousserait peut-être à sortir de leurs réponses mollassonnes.