Attestation distante TPM et démarrage mesuré

Le Secure Boot décide si un composant signé peut démarrer. Le démarrage mesuré enregistre ce qui a effectivement démarré, puis l’attestation à distance permet de présenter cette trace à un vérificateur. La différence est décisive : autoriser n’est pas prouver, et un écran vert dans la console d’administration ne constitue pas une preuve cryptographique.

→ Lire l’explication complète de la marmotte

TPM, PCR et chaîne de mesures

Le TPM (Trusted Platform Module) est un composant matériel qui conserve des secrets et réalise des opérations cryptographiques sans exposer directement ses clés privées au système d’exploitation. Son rôle ici est de rendre une mesure difficile à falsifier après coup. Il ne rend pas le serveur vertueux par magie. Les slides de vendeurs aiment beaucoup cette partie, les attaquants aussi.

Le démarrage mesuré commence dans le micrologiciel UEFI (Unified Extensible Firmware Interface). Chaque composant chargé calcule ou reçoit une empreinte cryptographique du composant suivant, puis étend cette valeur dans un PCR (Platform Configuration Register), registre de configuration de plateforme. L’opération n’écrase pas le registre :

PCR_nouveau = SHA-256(PCR_actuel || mesure)

L’ordre compte. Une même liste de composants chargés dans un ordre différent produit un résultat différent. Un PCR ne contient donc pas une liste lisible, mais l’empreinte cumulative d’une séquence. Le journal d’événements de démarrage fournit la liste détaillée permettant de recalculer cette valeur.

Les PCR 0 à 7 couvrent généralement le micrologiciel, sa configuration, les composants de démarrage et les politiques Secure Boot. Les conventions varient selon le matériel et les implémentations UEFI : considérer le numéro d’un PCR comme une preuve universelle est une erreur de conception. La politique d’attestation doit décrire les événements attendus, pas réciter des numéros comme une incantation.

Le compromis central est net : l’attestation apporte une décision d’accès fondée sur l’état mesuré, mais elle impose une gestion rigoureuse des références autorisées. Chaque mise à jour de micrologiciel, de chargeur ou de noyau peut modifier les mesures. Pour une flotte hétérogène, comparer un unique condensat attendu est une stratégie qui fonctionne admirablement jusqu’à la première mise à jour de sécurité.

La recommandation est de valider le journal d’événements et sa cohérence avec les PCR, puis d’évaluer des règles versionnées. Une règle peut accepter plusieurs versions explicitement approuvées d’un chargeur, refuser une configuration Secure Boot désactivée et exiger un noyau donné. Le condensat brut sert de preuve d’intégrité, pas de format de politique exploitable.

Attestation distante, nonce et identité matérielle

L’attestation distante répond à une question précise : « cette machine, dans l’état annoncé maintenant, possède-t-elle une racine matérielle attendue ? » Elle ne répond pas à « ce système est-il exempt de vulnérabilités ? ». Confondre les deux transforme une preuve limitée en talisman, avec les résultats habituels des talismans en production.

Le vérificateur envoie un nonce, valeur aléatoire à usage unique. La machine demande alors au TPM de produire une quote, déclaration signée qui lie ce nonce aux valeurs sélectionnées des PCR. Le nonce interdit la réutilisation d’une ancienne attestation valide. Sans nonce généré côté vérificateur et conservé jusqu’à validation, une capture réseau devient une autorisation rejouable. C’est rarement le moment le plus glorieux d’une architecture zero trust.

La signature est produite par une AK (Attestation Key), clé d’attestation créée dans le TPM. Une EK (Endorsement Key), clé d’endossement provisionnée par le fabricant, et son certificat permettent d’établir que l’AK est liée à un TPM matériel authentique. Cette chaîne doit être validée contre les autorités de certification des fabricants, avec contrôle des usages de certificat et des listes de révocation quand elles existent.

Une EK ne doit pas devenir un identifiant applicatif réutilisé. Elle favorise le pistage inter-services et lie inutilement l’identité de la plateforme à tous les vérificateurs. Créer une AK distincte par domaine de confiance, ou utiliser une autorité d’attestation intermédiaire, limite cette corrélation. La confidentialité n’est pas un supplément décoratif ajouté après la fuite.

Le vérificateur doit contrôler quatre éléments avant toute décision :

le nonce reçu correspond exactement au défi émis ;
la signature de la quote est valide avec la clé publique de l’AK ;
l’AK est rattachée à un TPM autorisé par une chaîne d’identité contrôlée ;
les PCR et le journal d’événements satisfont la politique de démarrage attendue.

Le journal doit être recalculé à partir de son état initial, puis comparé aux PCR signés. Accepter le journal sans vérifier cette correspondance permet à un système compromis de fournir un récit séduisant. Accepter les PCR sans journal empêche de comprendre pourquoi l’état diffère. Les deux ensemble constituent la preuve exploitable.

Exemple de quote TPM reproductible

L’exemple suivant utilise tpm2-tools sur Linux avec un TPM 2.0 accessible via /dev/tpmrm0. Il crée une clé d’attestation RSA, génère un défi imprévisible et produit une quote sur les PCR de démarrage usuels. L’enrôlement de la clé publique et la validation de la chaîne EK restent du ressort du vérificateur.

# Vérifier que le gestionnaire de ressources TPM est présent.
test -c /dev/tpmrm0

# Créer une clé d'endossement RSA persistante si aucune n'est déjà provisionnée.
# L'index persistant doit être réservé par la politique de plateforme.
tpm2_createek -c 0x81010001 -G rsa

# Créer une clé d'attestation, puis exporter sa partie publique.
tpm2_createak -C 0x81010001 -c ak.ctx -G rsa -g sha256 -s rsassa \
  -u ak.pub -n ak.name

# Produire un défi de 32 octets qui sera conservé côté vérificateur.
openssl rand 32 > nonce.bin

# Signer les PCR 0, 2, 4 et 7 avec ce défi.
tpm2_quote -c ak.ctx -l sha256:0,2,4,7 -q nonce.bin \
  -m quote.msg -s quote.sig -o pcr.bin -g sha256

# Exporter le journal UEFI afin que le vérificateur recalcule les PCR.
cat /sys/kernel/security/tpm0/binary_bios_measurements > eventlog.bin

Ne pas transmettre ak.ctx comme s’il s’agissait d’une clé sauvegardable. Ce contexte dépend du TPM local. La clé privée d’attestation doit rester non exportable. En cas de remplacement matériel, l’AK change et un nouvel enrôlement est nécessaire. Une sauvegarde de fichier ne ressuscite pas une identité matérielle détruite, ce qui est précisément le but.

Les PCR sélectionnés doivent correspondre à la politique, pas à un copier-coller. Ajouter le PCR 10 permet souvent d’inclure IMA (Integrity Measurement Architecture), mécanisme Linux de mesure des fichiers chargés à l’exécution. Cela donne une visibilité supplémentaire sur le noyau et certains exécutables, mais augmente fortement le volume de règles à maintenir. Mesurer chaque bibliothèque d’un environnement mutable pour autoriser un accès réseau critique revient à construire un détecteur de mise à jour, très performant, très indisponible.

Surface d’attaque et limites de confiance

Une quote valide prouve que le TPM a signé des mesures. Elle ne prouve pas que le service demandé est exécuté sur la machine qui a répondu. L’attaque dite cuckoo consiste à relayer les requêtes d’attestation vers un TPM sain, tandis que le service réel tourne ailleurs. Lier l’attestation au canal applicatif est donc obligatoire : certificat de service délivré après attestation, clé de session scellée à des PCR, ou jeton à durée très courte lié à l’identité réseau et à une preuve de possession de clé.

Le scellement consiste à chiffrer ou autoriser un secret uniquement si des PCR ont des valeurs données. Une clé de disque peut ainsi être libérée seulement après un démarrage conforme. Cette protection bloque le vol hors ligne et certaines modifications du démarrage. Elle ne protège pas les données une fois le disque déverrouillé par un noyau compromis qui respecte encore les mesures attendues.

Le Secure Boot bloque normalement les composants non autorisés, mais il peut accepter un ancien composant signé et vulnérable. Une politique d’attestation doit donc refuser les versions révoquées, même correctement signées. La signature établit l’origine et l’autorisation cryptographique, pas l’absence de défaut. Cette distinction rejoint les limites détaillées dans lire une garantie cryptographique sans la surinterpréter.

Une compromission avant ou pendant la mesure est critique. Un micrologiciel altéré peut mentir sur les événements si la racine matérielle ne vérifie pas sa chaîne. Une faille de TPM, une configuration de débogage ouverte ou une attaque physique peuvent également invalider le modèle. Le verrouillage des interfaces de débogage, les mises à jour de micrologiciel validées et l’inventaire matériel sont des prérequis, pas des options de confort.

Les machines virtuelles exigent encore plus de prudence. Un vTPM (virtual Trusted Platform Module) dépend de l’hyperviseur qui l’émule ou le protège. Attester un invité sans attester l’hôte prouve surtout que l’invité a reçu un récit cohérent de son environnement. Pour des secrets à haute valeur, attester l’hôte, la chaîne de virtualisation et le mécanisme d’isolation avant de faire confiance au vTPM.

Exploitation, rotation et décisions d’accès

L’attestation doit produire une décision exploitable : refuser, restreindre, mettre en quarantaine ou autoriser temporairement. Un échec ne doit pas déclencher une collecte de journaux sans fin pendant que l’accès reste ouvert. Pour les services sensibles, la règle est de refuser par défaut. Pour les plateformes où la disponibilité prime, limiter l’accès à un réseau de remédiation et journaliser la dérogation avec une durée d’expiration.

Les références de mesures doivent être versionnées, signées et associées à un cycle de changement. Une mise à jour de noyau sans nouvelle référence approuvée provoque un refus prévisible. Un changement de référence sans approbation forte crée une porte dérobée de gouvernance. Les deux incidents se ressemblent à trois heures du matin, mais un seul est un échec de sécurité.

Superviser au minimum les échecs de validation de signature, les nonces expirés ou réutilisés, les divergences entre journal et PCR, les certificats EK expirés ou révoqués, et les plateformes qui sortent soudainement de leur profil attendu. Conserver les quotes, journaux et décisions associées permet d’enquêter sans conserver indéfiniment des identifiants matériels bruts.

La rotation porte sur les AK, les certificats d’autorité, les règles de référence et les secrets scellés. Elle ne porte pas sur la clé privée EK, généralement non exportable et liée au matériel. Prévoir un processus de remplacement de carte mère ou de TPM avant la panne : désenrôlement, révocation de l’AK, émission d’une nouvelle identité et récupération contrôlée des secrets. Les mécanismes de récupération doivent être séparés des clés scellées, idéalement protégés par un module cryptographique matériel et PKCS#11.

L’attestation n’est pas un système de détection d’intrusion, ne remplace pas la gestion des correctifs, ne prouve pas l’identité humaine devant un clavier et ne sécurise pas un réseau plat. Elle fournit un signal de posture pour alimenter l’IAM (Identity and Access Management), la délivrance de certificats ou l’accès à un bastion. Le reste relève d’une architecture cohérente, notamment des fondations de sécurité et de la segmentation réseau.

🐝 Ce qui arrive si on s’en passe

Sans démarrage mesuré ni attestation, la posture d’une machine n’est connue que par ce que son propre système d’exploitation déclare : un agent de conformité exécuté au-dessus d’un chargeur ou d’un noyau altéré rapporte l’état que ce code choisit de montrer. La désactivation de Secure Boot dans la configuration du micrologiciel, ou le retour à un chargeur signé mais révoqué, reste invisible depuis le réseau. L’identité de la machine se réduit alors à des secrets stockés sur disque : une image copiée démarre sur un autre matériel et obtient les mêmes certificats et les mêmes accès, sans lien vérifiable avec un TPM enrôlé. Après un incident, aucune mesure signée et datée ne permet de situer le moment où la chaîne de démarrage a divergé, ni de délimiter les machines concernées.

🦫 Explication de la marmotte 🍫

Au démarrage, l’ordinateur lance d’abord un programme intégré à la machine, puis un programme de démarrage, puis le système d’exploitation. À chaque étape, une empreinte numérique est calculée sur ce qui va être lancé. Cette empreinte est ajoutée à un registre protégé par une puce de sécurité. Ajouter une nouvelle valeur change le résultat final, et il devient impossible de retirer discrètement une étape déjà enregistrée.

Un serveur de contrôle peut demander une preuve récente. Il envoie alors une valeur aléatoire, différente à chaque demande. La puce de sécurité signe cette valeur avec les registres de démarrage. Le serveur vérifie la signature, vérifie que la valeur aléatoire est bien celle qu’il a envoyée, puis compare les registres et la liste détaillée des programmes chargés avec une politique autorisée.

Si la valeur aléatoire ne correspond pas, la preuve peut être ancienne ou rejouée. Si la liste détaillée ne produit pas les mêmes registres, elle a été modifiée ou ment. Si les programmes chargés ne correspondent pas à une version autorisée, l’accès est refusé ou limité.

Cette vérification montre l’état du démarrage au moment de la demande. Elle ne garantit pas qu’aucun pirate n’agit ensuite, qu’aucune faille n’existe dans un programme autorisé, ni que la personne utilisant la machine est légitime. Il faut donc compléter cette preuve par des mises à jour, des contrôles d’accès, une surveillance et des règles réseau.

Pages voisines

La citent

Attestation distante TPM et démarrage mesuré

Elle cite

Attestation distante TPM et démarrage mesuré

Attestation distante TPM et démarrage mesuré

TPM, PCR et chaîne de mesures

Attestation distante, nonce et identité matérielle

Exemple de quote TPM reproductible

Surface d’attaque et limites de confiance

Exploitation, rotation et décisions d’accès

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines