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: 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.
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.