Trusted Platform Module (TPM) : fonctionnement, IAM et sécurité

Le Trusted Platform Module (TPM) est un composant de sécurité normalisé qui génère, protège et utilise des clés cryptographiques sans jamais les exposer au système d'exploitation, tout en mesurant chaque étape du démarrage pour prouver qu'une machine n'a pas été altérée. En 2026, la fin du support de Windows 10, l'exigence du TPM 2.0 pour Windows 11 et la généralisation de l'authentification sans mot de passe en font une brique centrale de la gestion des identités : Windows Hello Entreprise, les jetons Microsoft Entra ID, les certificats machine et le chiffrement de disque s'appuient sur lui. Ce guide détaille son architecture, ses usages IAM, ses limites et les failles documentées, en complément de notre article pilier consacré aux attaques visant le couple TPM et BitLocker, dont le cold boot. L'objectif est concret : savoir ce que la puce garantit réellement, et ce qu'elle ne garantit pas.

Qu'est-ce que le Trusted Platform Module ?

Un TPM est un microcontrôleur ou un environnement d'exécution isolé dédié à la cryptographie. Microsoft le décrit comme un processeur de chiffrement sécurisé capable de créer des clés, de les chiffrer pour qu'elles ne soient déchiffrables que par lui, et de les utiliser sans que leur partie privée ne quitte la puce. Il dispose de son propre firmware et ne dépend donc pas du système d'exploitation pour traiter ses commandes. La documentation Microsoft en français le nomme « module de plateforme sécurisée ».

La norme est publiée par le Trusted Computing Group, consortium industriel qui maintient la spécification TPM 2.0 Library, dont la version 185 date de mars 2026. Cette « bibliothèque » décrit les commandes et structures communes ; des profils de plateforme précisent ensuite ce qu'un TPM de PC, de serveur, de mobile ou de véhicule doit implémenter au minimum.

La spécification a aussi été reprise par l'ISO et la CEI sous la forme de la norme ISO/IEC 11889-1:2015 et de ses trois parties complémentaires. L'ISO indique qu'une nouvelle édition est en cours d'élaboration. Pour un acheteur public ou un responsable conformité, cette double référence TCG et ISO permet d'exiger des composants conformes dans un cahier des charges.

Les trois racines de confiance

Le modèle du TCG distingue trois fonctions. La racine de confiance pour le stockage (RTS) protège les clés et les secrets. La racine de confiance pour le rapport (RTR) signe l'état mesuré de la machine. La racine de confiance pour la mesure (RTM) est le premier code exécuté qui calcule les empreintes du démarrage ; elle réside dans le firmware de la plateforme, pas dans la puce elle-même.

Un point souvent mal compris : le TPM est passif. Il reçoit des commandes et renvoie des réponses, mais n'interrompt jamais un démarrage et ne bloque aucun logiciel par lui-même. Ce sont le firmware UEFI, le chargeur d'amorçage et le système d'exploitation qui décident d'utiliser ses fonctions. Sa valeur dépend donc entièrement de la qualité de cette intégration.

Architecture interne : clés, hiérarchies et registres PCR

À l'intérieur d'un TPM 2.0, on trouve un moteur cryptographique (RSA, courbes elliptiques, SHA-256, HMAC, AES selon le profil), un générateur d'aléa, une petite mémoire non volatile, des registres de mesure et un mécanisme anti-martèlement. La liste exacte des algorithmes varie selon le fabricant et le profil : Microsoft rappelle que certains TPM ne prennent pas en charge tous les algorithmes du registre du TCG.

Hiérarchies et clés primaires

Le TPM 2.0 organise ses objets en quatre hiérarchies, chacune dérivée d'une graine secrète interne. Une même graine produit toujours la même clé primaire avec les mêmes paramètres, ce qui évite de stocker de nombreuses clés dans une mémoire limitée. Les hiérarchies séparent les responsabilités entre le constructeur, le propriétaire de la machine et les usages liés à la vie privée.

• Hiérarchie plateforme : contrôlée par le firmware de la machine, elle sert au constructeur.
• Hiérarchie de stockage : celle du propriétaire ; elle porte la clé racine de stockage (SRK) qui enveloppe les clés applicatives.
• Hiérarchie d'approbation : elle porte la clé d'approbation (EK), identité unique du TPM, souvent accompagnée d'un certificat du fabricant.
• Hiérarchie null : éphémère, sa graine change à chaque redémarrage ; elle sert aux opérations temporaires.

Pour prouver son état sans exposer directement son EK, le TPM utilise une clé d'attestation (AK, anciennement AIK), certifiée comme résidant dans le même TPM. Selon Microsoft, la partie privée de l'EK ou de la SRK n'est jamais exposée à un autre composant, logiciel ou utilisateur. Les clés applicatives peuvent, elles, être déclarées migrables ou non migrables à leur création.

Registres PCR, scellement et anti-martèlement du TPM

Trois mécanismes du TPM 2.0 conditionnent presque tous ses usages : les registres de mesure, le scellement des secrets et la protection contre les essais répétés. Les comprendre permet de choisir des politiques de chiffrement robustes et d'expliquer aux équipes support pourquoi une mise à jour de firmware peut déclencher une demande de clé de récupération.

Les registres PCR et l'opération d'extension

Les registres de configuration de plateforme (PCR) accumulent des empreintes. On ne peut pas leur affecter une valeur : on peut seulement les « étendre », c'est-à-dire remplacer leur contenu par le hachage de l'ancienne valeur concaténée à la nouvelle mesure. Un PCR résume ainsi toute une séquence d'événements, et seul un redémarrage le remet à zéro. Le profil PC en définit vingt-quatre, numérotés de 0 à 23.

Chaque registre a une vocation. Le PCR 0 reflète le code du firmware, le PCR 4 le chargeur d'amorçage, le PCR 7 l'état et les certificats de Secure Boot. Sous Linux, systemd mesure en PCR 11 l'image noyau unifiée et les phases du démarrage. Choisir les bons registres est décisif : un registre trop volatil casse le déverrouillage à chaque mise à jour, un registre trop large laisse passer des modifications.

Scellement et protection contre le martèlement

Le scellement chiffre un secret de telle sorte que le TPM ne le libère que si certains PCR présentent les valeurs attendues. C'est le mécanisme qu'utilisent BitLocker et LUKS pour libérer la clé du disque uniquement sur une chaîne de démarrage inchangée. Une politique peut en outre exiger une valeur d'autorisation, par exemple un PIN, avant tout usage de la clé.

Pour éviter qu'un attaquant ne devine ce PIN par essais successifs, le TPM applique un verrouillage global après un nombre limité d'échecs. Microsoft souligne qu'un succès d'authentification ne remet pas ce compteur à zéro, afin d'empêcher un attaquant de créer sa propre clé au mot de passe connu pour réinitialiser la protection. Le compteur décroît uniquement avec le temps, ou d'un coup par une commande de réinitialisation autorisée par le propriétaire du TPM.

TPM 1.2 et TPM 2.0 : pourquoi la version compte

Le TPM 1.2 n'autorise que RSA et l'algorithme de hachage SHA-1, aujourd'hui déprécié. Le TPM 2.0 introduit l'agilité cryptographique, des hiérarchies multiples, des politiques d'autorisation combinables et un comportement anti-martèlement normalisé, là où chaque fabricant de TPM 1.2 implémentait sa propre logique de verrouillage. Microsoft recommande le TPM 2.0 pour toutes les fonctions qui le prennent en charge.

Côté matériel, Microsoft impose depuis le 28 juillet 2016 que tout nouveau modèle d'appareil Windows implémente et active par défaut un TPM 2.0. Windows 11 en a fait un prérequis d'installation. Le TPM 2.0 exige également un firmware UEFI en mode natif : les modes hérités et le module de compatibilité CSM doivent être désactivés, faute de quoi la puce n'est pas exploitable.

La version a aussi des conséquences directes en IAM. Selon la documentation Microsoft Entra sur le Primary Refresh Token, Entra ID n'utilise plus le TPM 1.2 pour les clés d'appareil depuis Windows 10 version 1903, pour des raisons de fiabilité. Sur un poste équipé d'un TPM 1.2, ces clés d'identité ne bénéficient donc plus de l'ancrage matériel attendu.

L'effet de la fin de Windows 10

Microsoft a cessé le support gratuit de Windows 10 le 14 octobre 2025. Les machines incompatibles avec Windows 11, souvent faute de TPM 2.0 activé ou présent, basculent soit vers le programme de mises à jour étendues, soit vers le renouvellement. Pour une équipe sécurité, c'est l'occasion de mesurer le taux de postes disposant d'un TPM 2.0 fonctionnel et d'en faire un critère d'accès.

Puce discrète, firmware, intégrée ou virtuelle : les formes du TPM

Le terme TPM recouvre plusieurs implémentations aux propriétés de sécurité différentes. Microsoft distingue la puce discrète dans son propre boîtier, la solution intégrée qui partage un boîtier avec d'autres composants tout en restant logiquement séparée, et le TPM firmware exécuté dans un mode d'exécution de confiance du processeur. Il faut y ajouter les TPM virtuels des hyperviseurs et le processeur Pluton.

Pour Windows, ces implémentations sont équivalentes : le système utilise tout TPM conforme de la même manière. Pour l'analyse de risque, elles ne le sont pas. Une puce discrète résiste mieux aux attaques logicielles sur le processeur, mais son bus peut être écouté. Un fTPM supprime ce bus, mais partage le silicium et le firmware du processeur, ce qui ouvre d'autres vecteurs étudiés par la recherche.

Le cas des TPM virtuels et du cloud

Les principaux fournisseurs cloud proposent des instances avec vTPM, Secure Boot et démarrage mesuré, comme les Shielded VM décrites dans notre audit de sécurité Google Cloud Platform. Vérifier que ces options sont activées sur toutes les instances sensibles relève de la gestion de posture ; une plateforme CNAPP de protection des applications cloud natives peut automatiser ce contrôle à l'échelle de plusieurs comptes.

Démarrage mesuré, Secure Boot et attestation à distance

Secure Boot et démarrage mesuré sont complémentaires, mais distincts : Secure Boot bloque, le démarrage mesuré enregistre. Le premier vérifie la signature de chaque composant et refuse ceux qui ne sont pas autorisés. Le second calcule l'empreinte de chaque composant, l'étend dans un PCR et l'inscrit dans un journal d'événements, sans rien interdire. C'est ce journal, combiné aux PCR, qui permet ensuite de prouver l'état de la machine.

Comment fonctionne une attestation

Lors d'une attestation à distance, un vérificateur envoie un nombre aléatoire au poste. Le TPM renvoie une « quote », c'est-à-dire la valeur des PCR demandés et ce nombre aléatoire, signés par la clé d'attestation. Le vérificateur rejoue le journal d'événements, contrôle qu'il aboutit bien aux PCR signés, puis compare le résultat à une politique de référence. Le nombre aléatoire empêche de rejouer une ancienne preuve.

Microsoft indique que le journal du démarrage mesuré peut être transmis à un serveur distant qui déclenche, si besoin, des actions de remédiation. C'est le principe de l'attestation d'intégrité des appareils : un serveur de gestion interroge un service d'attestation, qui confirme par exemple que BitLocker, Secure Boot et la prévention d'exécution des données sont actifs, puis autorise ou refuse l'accès.

De l'attestation à l'accès conditionnel

Dans un environnement Microsoft, l'attestation alimente la conformité Intune, qui alimente à son tour l'accès conditionnel d'Entra ID. Un poste dont le démarrage a été altéré ou dont le chiffrement est désactivé perd son statut conforme et l'accès aux applications sensibles. La mise en œuvre détaillée est décrite dans notre guide Intune et BitLocker 2026 pour la gestion des endpoints.

Sur Windows, Microsoft mentionne aussi System Guard, qui s'appuie sur un démarrage à racine de mesure dynamique (DRTM) et nécessite un TPM 2.0 associé à un firmware UEFI. Le principe est de relancer la mesure à partir d'un point de confiance après l'exécution du firmware, afin de réduire la dépendance à l'intégrité de tout le code exécuté avant le système d'exploitation.

Le TPM au service de l'IAM : des identités liées au matériel

En gestion des identités, l'apport du TPM tient en une idée : lier un secret d'authentification à un appareil précis, sans possibilité de l'exporter. Un mot de passe peut être hameçonné, un jeton copié depuis un disque ; une clé non migrable générée dans un TPM ne peut pas être recopiée sur une autre machine. Cette propriété transforme le poste de travail en facteur de possession vérifiable.

Windows Hello Entreprise et authentification FIDO

Windows Hello Entreprise remplace le mot de passe par une paire de clés propre à l'utilisateur et à l'appareil, protégée par le TPM et déverrouillée par un geste local, PIN ou biométrie. Microsoft précise que Windows Hello, utilisé comme authentificateur de plateforme FIDO, stocke ses clés dans le TPM 2.0. Le PIN ne transite jamais sur le réseau : il autorise seulement l'usage local de la clé.

Les cartes à puce virtuelles, qui émulaient une carte dans le TPM, sont désormais déconseillées. Microsoft encourage leurs utilisateurs à migrer vers Windows Hello Entreprise ou vers des clés de sécurité FIDO2. Pour un projet IAM en 2026, cette trajectoire simplifie l'architecture : un seul mécanisme de clé liée au matériel, compatible avec les standards d'authentification sans mot de passe.

Jetons Entra ID, certificats et attestation de clé TPM

Au-delà de l'ouverture de session, le TPM (Trusted Platform Module) protège les artefacts qui prolongent l'authentification : jetons d'authentification unique, certificats machine et preuves d'origine des clés. Ce sont souvent eux que visent les attaquants après une compromission, car un jeton volé permet de contourner l'authentification multifacteur sans connaître le mot de passe.

Le Primary Refresh Token de Microsoft Entra ID

Lors de l'enregistrement d'un appareil, Windows génère une clé d'appareil et une clé de transport protégées par le TPM. Le Primary Refresh Token (PRT), qui porte l'authentification unique vers les applications cloud, est accompagné d'une clé de session déchiffrable uniquement par la clé de transport du TPM. Chaque requête est signée par cette clé de session, qui sert de preuve de possession.

Microsoft indique qu'un PRT est valable 90 jours et renouvelé en continu tant que l'appareil est utilisé. Sans TPM fonctionnel, ces clés perdent leur ancrage matériel, alors que Microsoft souligne que le TPM renforce nettement la résistance au vol d'identifiants. À l'inverse, si le TPM tombe en panne, les clés deviennent inaccessibles, le PRT est invalidé et Windows déclenche un parcours de réenregistrement de l'appareil.

Certificats machine et attestation de clé

Le fournisseur de stockage de clés Microsoft Platform Crypto Provider génère les clés privées des certificats dans le TPM, ce qui les rend non exportables. Utilisés pour le 802.1X, le VPN ou le TLS mutuel, ces certificats prouvent que la connexion provient bien d'un poste de l'entreprise. L'attestation de clé va plus loin : elle permet à une autorité de certification de vérifier que la clé a bien été créée dans un TPM de confiance, grâce à l'EK.

1. Authentification sans mot de passe des utilisateurs avec Windows Hello Entreprise ou une passkey de plateforme.
2. Identité d'appareil Entra ID et protection du PRT contre le rejeu.
3. Certificats machine non exportables pour le Wi-Fi, le VPN et les flux de serveur à serveur.
4. Clés SSH ou PKCS#11 sous Linux, via la pile tpm2-tss et le module tpm2-pkcs11.
5. Preuve d'intégrité du poste intégrée aux décisions d'accès conditionnel.

Chiffrement de disque : BitLocker et LUKS adossés au TPM

Avec BitLocker, la clé maîtresse du volume est scellée dans le TPM. Sur un poste UEFI avec Secure Boot, Windows lie par défaut ce scellement aux PCR 7 et 11. Si la chaîne de démarrage n'a pas changé, le TPM libère la clé et Windows démarre sans intervention. Si un composant mesuré a été modifié, la clé reste scellée et la clé de récupération devient nécessaire.

Ce confort a un prix : le mode TPM seul ne demande aucune preuve à l'utilisateur avant le démarrage. La clé est libérée à quiconque allume la machine intacte, ce qui expose le secret aux attaques physiques détaillées dans notre article pilier sur TPM, BitLocker et attaques cold boot. L'ajout d'un PIN de pré-démarrage transforme le TPM en second facteur et ferme une grande partie de ces scénarios.

La gestion des clés de récupération est l'autre moitié du sujet. Une clé non séquestrée transforme une simple mise à jour de firmware en perte de données. Notre guide Microsoft Intune : activer BitLocker et gérer les clés de récupération détaille le séquestre dans Entra ID, la rotation après usage et le contrôle des accès à ces clés, qui sont elles-mêmes des secrets à haut privilège.

Chiffrement LUKS2 et TPM 2.0 sous Linux

Les distributions Linux récentes savent, elles aussi, déverrouiller un disque chiffré grâce au TPM 2.0. Le format LUKS2 stocke des métadonnées de jeton qui décrivent comment obtenir la clé du volume, et systemd fournit les outils pour inscrire la puce, choisir les registres PCR (registres de configuration de plateforme) et ajouter un PIN.

LUKS2 et systemd-cryptenroll

Sous Linux, l'outil systemd-cryptenroll inscrit un TPM 2.0 comme moyen de déverrouillage d'un volume LUKS2. La documentation recommande de lier le volume à une combinaison des PCR 7, 11 et 14, et d'éviter les PCR 0 et 2, trop sensibles aux mises à jour de firmware. Les politiques signées permettent de mettre à jour le noyau sans réinscrire la clé.

Le chiffrement de disque adossé au TPM protège les données au repos sur l'appareil, pas les fichiers qui en sortent. Dès qu'un document est copié sur un partage, un support amovible ou envoyé par messagerie, il n'est plus couvert. Pour ces usages, un chiffrement par conteneur comme celui décrit dans notre article sur ZED de PrimX et les conteneurs chiffrés prend le relais.

Menaces et vulnérabilités connues du Trusted Platform Module

Le TPM réduit fortement la surface d'attaque, mais il n'est pas invulnérable. Les failles publiées depuis 2017 se répartissent en cinq familles : défauts de génération de clés, canaux auxiliaires temporels, écoute du bus des puces discrètes, injection de fautes sur les environnements de confiance des fTPM, et erreurs de programmation dans le code de référence. Chacune appelle une réponse défensive différente.

Génération de clés et canaux auxiliaires

En 2017, la vulnérabilité ROCA (CVE-2017-15361) a révélé que la bibliothèque RSA de certains firmwares TPM Infineon générait des clés affaiblies ; BitLocker avec TPM 1.2 figurait parmi les technologies touchées. En 2019, les travaux TPM-Fail (CVE-2019-11090 et CVE-2019-16863) ont montré des fuites temporelles lors de signatures sur courbes elliptiques dans le fTPM d'Intel et une puce STMicroelectronics, corrigées par mise à jour de firmware.

Attaques physiques sur le bus et injection de fautes

Une puce discrète communique avec le processeur par un bus externe. Lorsque BitLocker ou LUKS fonctionnent en mode TPM seul, la clé du volume circule en clair sur ce bus au démarrage et peut être interceptée par un attaquant disposant d'un accès physique. Le noyau Linux 6.10 a introduit des sessions chiffrées et authentifiées sur ce bus (option CONFIG_TCG_TPM2_HMAC), désactivées par défaut depuis fin 2025 pour des raisons de performance.

Les fTPM échappent à l'écoute du bus, mais pas à toutes les attaques physiques. En 2023, des chercheurs de l'université technique de Berlin ont publié faulTPM, une attaque par injection de fautes de tension sur le processeur de sécurité d'AMD permettant d'extraire l'état interne du fTPM, et donc ses secrets scellés. AMD l'a référencée sous CVE-2023-20589. Elle exige un accès physique prolongé et du matériel spécialisé.

Failles logicielles du TPM et limites de protection

Toutes les menaces ne nécessitent pas un accès physique. Le firmware d'un TPM est un logiciel, avec ses défauts de programmation, et la puce n'agit que sur ordre du système d'exploitation. Deux questions en découlent pour les équipes de sécurité : comment corriger un TPM vulnérable, et que se passe-t-il lorsque le poste lui-même est compromis ?

Failles dans le code de référence

Beaucoup de TPM, matériels comme virtuels, réutilisent le code de référence publié par le TCG. En février 2023, le TCG a publié un avis sur deux défauts de gestion mémoire découverts par Quarkslab (CVE-2023-1017 et CVE-2023-1018), déclenchables depuis une application en mode utilisateur, y compris dans des TPM virtuels d'hyperviseurs. En juin 2025, la fiche NVD de la CVE-2025-2884 a documenté une lecture hors limites dans la fonction CryptHmacSign, notée 6,6 par CISA.

Ces failles ont une conséquence opérationnelle majeure : la correction passe par le firmware du TPM ou de la plateforme, distribué par chaque constructeur à son rythme. Un correctif Windows ou un noyau Linux à jour ne suffit pas. L'inventaire précis des fabricants et des versions de firmware devient donc un prérequis de la gestion des vulnérabilités.

Ce que le TPM ne protège pas

Le TPM empêche l'extraction d'une clé, pas son utilisation. Une fois la session ouverte, une clé non exportable reste utilisable par un code malveillant qui contrôle la session : il peut demander au TPM de signer une requête ou de déchiffrer un jeton sans jamais voir la clé. La défense doit donc combiner le TPM avec la détection sur les postes, la protection des jetons et des durées de session maîtrisées.

Durcir un parc équipé de TPM : bonnes pratiques

Un TPM présent n'est pas un TPM exploité. Dans de nombreux parcs, la puce est active, mais les politiques qui en tirent parti sont incomplètes : Windows Hello en mode préféré, BitLocker en TPM seul sur des portables nomades, attestation non intégrée à la conformité. Les mesures suivantes forment un socle progressif, applicable par lots, du plus simple au plus structurant.

1. Inventorier la présence, la version, le fabricant et la version de firmware de chaque TPM, y compris sur les VM.
2. Configurer le firmware en mode UEFI natif, désactiver le CSM et activer Secure Boot.
3. Appliquer les mises à jour de firmware TPM et UEFI publiées par les constructeurs après chaque bulletin du TCG.
4. Exiger le TPM pour Windows Hello Entreprise et pour l'enregistrement des appareils dans Entra ID.
5. Activer un PIN de pré-démarrage BitLocker ou LUKS sur les postes exposés au vol ou aux déplacements.
6. Séquestrer les clés de récupération et restreindre leur consultation à un groupe audité.
7. Intégrer l'attestation d'intégrité aux règles de conformité et à l'accès conditionnel.
8. Activer vTPM, Secure Boot et démarrage mesuré sur les machines virtuelles sensibles.

La supervision complète ce socle. Les verrouillages anti-martèlement répétés sur un même poste, les demandes de clé de récupération inhabituelles ou la perte soudaine du statut conforme sont des signaux à corréler dans le SOC. Ils peuvent révéler une tentative d'accès physique, une modification de la chaîne de démarrage ou simplement une mise à jour de firmware mal préparée.

Retour terrain : Cas typique rencontré en mission — l'audit révèle des portables nomades chiffrés en TPM seul et des clés Windows Hello protégées par logiciel, inscrites avant que le TPM ne soit exigé. Durcir la stratégie ne corrige pas l'existant : il faut recréer les conteneurs Windows Hello concernés et faire définir un PIN de pré-démarrage par chaque utilisateur. Ce déploiement par lots, accompagné, se compte en semaines plutôt qu'en jours.

Vérifier et administrer le TPM sous Windows et Linux

Sous Windows 10 et 11, le système initialise et prend possession du TPM automatiquement. Microsoft déconseille donc de configurer la puce manuellement via la console tpm.msc, qui n'est plus activement développée depuis Windows 10 version 1809. L'administration courante passe par PowerShell, l'outil tpmtool et les stratégies de groupe ou Intune, ce qui facilite l'automatisation à l'échelle d'un parc.

Sous Linux, le noyau expose le TPM via /dev/tpm0 et, surtout, via /dev/tpmrm0, qui ajoute un gestionnaire de ressources partageant la puce entre plusieurs processus. La suite tpm2-tools permet de lire les capacités, les PCR et l'état du verrouillage. Les commandes ci-dessous sont des vérifications défensives en lecture, à l'exception de l'inscription LUKS qui modifie le volume.

Sous Windows, quatre commandes PowerShell, lancées dans une session administrateur, suffisent à établir l'état du TPM, son identité et celle de Secure Boot. Elles ne modifient rien et peuvent être intégrées à un script d'inventaire exécuté par l'outil de gestion du parc.

Get-Tpm                        # présence, état, propriétaire et verrouillage
Get-TpmEndorsementKeyInfo      # clé d'approbation (EK) et certificats associés
tpmtool getdeviceinformation   # version de spécification, fabricant, firmware
Confirm-SecureBootUEFI         # renvoie True si Secure Boot est actif

Sous Linux, les trois premières commandes lisent la famille du TPM, son fabricant, le compteur de verrouillage et les PCR utiles au chiffrement. Les deux dernières lient un volume LUKS2 au PCR 7 avec un PIN, puis ajoutent une clé de récupération indépendante du TPM.

tpm2_getcap properties-fixed | grep -A2 -E "FAMILY_INDICATOR|MANUFACTURER"
tpm2_getcap properties-variable | grep -i lockout
tpm2_pcrread sha256:0,7,11     # PCR 0, 7 et 11 de la banque SHA-256
systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 --tpm2-with-pin=yes /dev/nvme0n1p3
systemd-cryptenroll --recovery-key /dev/nvme0n1p3

Avant toute inscription LUKS, vérifiez la version de systemd : la documentation précise que les options et le format d'inscription évoluent selon les versions, et qu'un volume inscrit avec une version récente peut ne pas se déverrouiller avec une version plus ancienne. Testez toujours le redémarrage avec la clé de récupération à portée de main.

Gouvernance et cycle de vie du TPM en entreprise

Le TPM est un composant matériel : sa gouvernance commence à l'achat. Microsoft rappelle que les clients publics et les secteurs réglementés peuvent exiger des composants TPM certifiés, et que les constructeurs doivent alors s'y conformer. En pratique, ces exigences visent des certifications Critères communs ou FIPS 140. Intégrez ces exigences dans les appels d'offres plutôt que de les découvrir lors d'un audit de conformité.

La fin de vie compte autant. Avant de réattribuer ou de céder un poste, l'effacement du TPM fait partie de la procédure, car effacer le TPM détruit définitivement les clés qu'il protège. Cette opération invalide les identifiants Windows Hello, les certificats non exportables et la protection BitLocker associée. Elle doit donc être planifiée, précédée d'une sauvegarde des clés de récupération et suivie d'un réenregistrement de l'appareil.

Côté gestion des vulnérabilités, ajoutez une ligne dédiée au firmware TPM dans votre veille. Les bulletins du TCG, des fabricants de puces et des constructeurs de PC arrivent séparément, et les correctifs suivent le cycle des mises à jour UEFI. Mesurez le délai entre la publication d'un avis et le déploiement effectif sur le parc, comme vous le faites déjà pour les correctifs du système d'exploitation.

Retour terrain : Cas typique rencontré en mission — un correctif de firmware TPM se décline en autant de paquets que de modèles de PC, publiés à des rythmes différents selon les constructeurs ; certains modèles anciens n'en reçoivent jamais. Sans suspension préalable de BitLocker, la mise à jour déclenche des demandes de clé de récupération en série. Indicateurs utiles : part du parc au firmware cible par modèle, demandes de récupération après chaque lot.

À lire aussi : l'autorité de certification et la PKI.

Questions fréquentes

Conclusion

Le Trusted Platform Module n'est plus une option réservée aux postes haut de gamme : c'est la racine de confiance sur laquelle reposent le chiffrement des disques, l'authentification sans mot de passe et l'identité des appareils. Bien exploité, il rend les secrets non exportables, prouve l'intégrité du démarrage et donne à l'accès conditionnel un signal matériel fiable. Mal intégré, il crée une confiance illusoire.

Les priorités pour 2026 sont claires : inventorier les TPM et leurs firmwares, exiger le TPM 2.0 pour les identités, ajouter un PIN là où le vol est plausible, intégrer l'attestation à la conformité et suivre les bulletins du TCG. Pour approfondir les scénarios d'attaque physique et leurs contre-mesures, poursuivez avec notre analyse des attaques sur TPM et BitLocker.