Quelle est la différence entre un TPM 1.2 et un TPM 2.0 ?

Le TPM 1.2, publie en 2005 et standardise comme ISO/IEC 11889 première édition, fige les algorithmes (RSA-2048, SHA-1, hiérarchie de clés fixe) et expose un jeu de commandes ferme. Le TPM 2.0, dont la Library Specification atteint la version 1.62 en 2020, devient algorithm-agile : SHA-256 et plus fort en base, ECC avec NIST P-256 et BN-256 supportes, plusieurs hiérarchies (platform, storage, endorsement, null) coexistent et l'autorisation se generalise via des policies. Le hardware n'est pas compatible entre les deux : une carte mère TPM 1.2 ne se flashe pas en TPM 2.0, le silicium differe. Les nouveaux designs visent TPM 2.0 ; le TPM 1.2 est en fin de vie et plus accepte par Windows 11 ni par la plupart des services d'attestation actuels.

A quoi servent les Platform Configuration Registers (PCR) ?

Les PCR sont des registres extend-only, au nombre de 24 dans le profil standard (PCR 0 a 23), utilises pour enregistrer une chaine de hash immuable des mesures de boot et d'exécution. Chaque mesure applique la regle PCR[n] = SHA-256(PCR[n] concatene avec mesure). Le firmware de boot étend PCR 0 a 7 avec ses propres mesures (UEFI, option ROM, boot loader, secure boot state) ; l'OS étend PCR 8 et au-dela. Deux usages principaux suivent : le scellement, qui lie une donnée a un état de PCR choisi et refuse de la descelle si l'état differe, et le quoting, qui signe le contenu des PCR sous une cle d'attestation pour l'attestation distante. Le layout des PCR differe entre Windows et Linux : une donnée scellée sur l'un ne se descelle quasi jamais sur l'autre.

TPM discret, TPM firmware ou TPM virtuel, lequel choisir ?

Un TPM discret (Infineon SLB 9670, ST33, Nuvoton NPCT) est une puce dédiée sur SPI, I2C ou LPC. Il offre l'isolation physique, une évaluation Common Criteria forte et constitue la reference pour l'attestation matérielle. Un TPM firmware (Intel PTT dans le Management Engine, AMD fTPM dans le Platform Security Processor) tourne dans un Trusted Execution Environment du SoC principal : nomenclature réduite, mais surface d'attaque partagée avec le firmware plate-forme. Un TPM virtuel (vTPM, swtpm) cible les machines virtuelles et le développement ; le point d'ancrage de confiance remonte a l'hyperviseur ou, pour software TPM, est simule. Choix typiques : dTPM pour PC, serveur, défense, paiement, automobile ; fTPM pour portables grand public ; vTPM pour workloads cloud ; swtpm pour pipelines CI.

Que certifie l'Endorsement Key (EK) ?

L'EK est une paire de clés asymétriques (RSA-2048 ou ECC NIST P-256) injectée a la fabrication du silicium par le constructeur du TPM, partie privée non extractible. Le certificat EK associe est signe par une autorité de certification intermédiaire opérée par le constructeur (Infineon, ST, Nuvoton, AMD, Intel), elle-même rattachée a une autorité racine publique listée par le TCG. L'EK prouve que le TPM est un vrai TPM certifie d'un constructeur connu, sans révéler l'identité plate-forme. Il sert de point d'ancrage de confiance pour émettre des Attestation Identity Keys (AIK) et pour les services de provisioning comme Microsoft Azure Device Provisioning Service, qui valident la chaine de l'EK avant d'autoriser le device.

Quelles évaluations Common Criteria couvrent les puces TPM 2.0 ?

Les puces TPM 2.0 discrètes d'Infineon, ST et Nuvoton sont évaluées Common Criteria contre le profil de protection BSI-CC-PP-0030 Trusted Platform Module Library Family 2.0, publie par le BSI allemand et reconnu internationalement via CCRA et SOG-IS. Niveau d'assurance typique : EAL 4 augmente avec AVA_VAN.4 ou AVA_VAN.5 (analyse de vulnérabilités Moderee ou Haute), ALC_DVS.2 et ALC_FLR.1. L'évaluation couvre le matériel, le firmware embarque et la bibliothèque cryptographique. Les évaluations de TPM firmware existent mais sont plus rares ; AMD fTPM et Intel PTT n'ont historiquement pas poursuivi un certificat Common Criteria équivalent a une puce dédiée, ce qui pese dans l'analyse de confiance pour les secteurs régulés.

Qu'était la vulnérabilité ROCA et reste-t-elle d'actualité ?

ROCA (Return Of Coppersmith Attack), publiée en 2017 sous CVE-2017-15361, a touche la génération de clés RSA dans la bibliothèque cryptographique Infineon RSALib utilisée dans plusieurs puces TPM 1.2 et TPM 2.0. Le biais dans la génération des nombres premiers rendait les clés RSA 2048 bits factorisables en quelques jours-CPU. Infineon a diffuse des mises a jour firmware et Microsoft, Lenovo, HP et d'autres ont regenere les clés affectées. En 2026, les devices encore en service avec une version de firmware TPM vulnérable restent non conformes FIPS 140-3 et a la plupart des baselines de sécurité actuelles ; vérifier la version firmware du TPM (tpm2_getcap properties-fixed sous Linux, Get-Tpm sous Windows) contre le bulletin de sécurité constructeur reste une étape d'audit essentielle.

Comment TPM 2.0 s'inscrit-il dans le Cyber Resilience Act ?

Le Cyber Resilience Act (CRA), publie en novembre 2024 et applicable en décembre 2027, exige pour les produits avec éléments numériques un boot securise, la confidentialité et l'intégrité des données, la limitation de la surface d'attaque et un processus de gestion des vulnérabilités. Le TPM 2.0, ou un secure élément aux propriétés équivalentes, constitue une des voies pratiques pour ces exigences : measured boot ancre dans les PCR, scellement des secrets a l'état plate-forme, gestion des vulnérabilités via mise a jour firmware signée et vérifiée par le TPM, attestation de l'état du device. Le CRA ne nomme pas TPM explicitement mais, pour les produits des classes importantes et critiques (annexes III et IV), la conception sans ancrage matériel securise devient difficile a défendre en évaluation de conformité.

Quels sont les pieges les plus fréquents a l'intégration d'un TPM discret ?

Premier piege : placement BGA et protection ESD ; les TPM discrets sont sensibles aux défauts de soudure, le dry pack doit être respecte et la protection ESD dimensionnée pour l'interface choisie (SPI plus tolérant que LPC). Deuxième : la vitesse du bus ; un TPM LPC utilise pour le Static Root of Trust for Measurement allonge le boot de plusieurs centaines de millisecondes, le SPI a 30 MHz est préférable sur plate-forme moderne. Troisième : la chaine de certificats EK ; oublier de charger le certificat intermédiaire constructeur bloque le provisioning Azure DPS. Quatrième : le TPM firmware est souvent desactive par défaut au BIOS (fTPM Disabled), ce qui casse silencieusement le scellement BitLocker ou LUKS au premier déploiement. Cinquième : réutiliser une donnée scellée sous layout PCR Windows sur un système Linux est impossible, la chaine de boot mesure des objets différents dans un ordre different.

TCG TPM 2.0 Library Specification : guide de conformité

Auteur Hugues Orgitello Mis à jour le 12 juillet 2026 ~16 min de lecture

Guide, TPM 2.0 et TCG

TPM 2.0 est défini par la TCG Library Specification, publiée en 2014, en version 1.62 depuis 2020, et standardisée comme ISO/IEC 11889-1 à -4 en 2015. Un TPM conforme TCG passe la suite de tests TCG Compliance ; l'assurance sécurité vient séparément, de l'évaluation Common Criteria contre BSI-CC-PP-0030 et de la validation FIPS 140-3. Le Trusted Platform Module est le point d'ancrage de sécurité matérielle standardise par le Trusted Computing Group (TCG), consortium industriel fonde en 2003 qui réunit Intel, AMD, Microsoft, IBM, HP et la plupart des fondeurs et fabricants de plates-formes ; TPM 2.0 remplace TPM 1.2 (2005), désormais considéré comme legacy. Cette page présente l'écosystème TCG et les normes, l'architecture TPM 2.0 et ses fonctions concrètes (Endorsement Key, PCR, scellement, attestation), les form factors (discret, firmware, virtuel), les certifications (TCG Compliance, Common Criteria contre BSI-CC-PP-0030, FIPS 140-3), l'intégration aux systèmes d'exploitation (BitLocker, LUKS, IMA), l'usage en produit connecte et IoT, les compromis connus (ROCA, TPM-Fail, Sandman) et les pieges observes a l'intégration de TPM discrets (Infineon SLB 9670, ST33, Nuvoton NPCT) ou firmware (AMD fTPM, Intel PTT) dans des produits PC, serveur, IoT et embarque.

En résumé :

TCG Compliance atteste la conformité à la Library Specification, pas la sécurité ; Common Criteria (EAL 4 augmenté, contre BSI-CC-PP-0030) est la référence sécurité.
TPM 2.0 est algorithm-agile (SHA-256 en base, ECC NIST P-256) ; TPM 1.2 est en fin de vie et rejeté par Windows 11.
24 PCR extend-only enregistrent la chaîne de boot ; une donnée scellée sous layout PCR Windows ne se descelle quasi jamais sous Linux.
Choix typiques : TPM discret pour les secteurs régulés, fTPM pour les portables grand public, vTPM pour le cloud, swtpm pour la CI.

Trusted Computing Group, le cadre institutionnel

Le Trusted Computing Group est l'organisme de normalisation qui maintient la spécification TPM et une famille plus large de standards de trusted computing. Comprendre son périmètre conditionne les choix techniques et contractuels.

Organisme	Perimetre	Type de livrable
TCG (Trusted Computing Group)	TPM, attestation, measured boot, sécurité stockage, sécurité réseau	Library Specifications, Platform TPM Profiles, programmes de certification
ISO/IEC JTC 1/SC 27	Adoption de TPM 2.0 comme ISO/IEC 11889	Norme internationale, citable librement
BSI (Allemagne)	Profil de protection Common Criteria du TPM 2.0	BSI-CC-PP-0030, Protection Profile reference
NIST (USA)	Validation FIPS 140-3 du module, guidance cryptographique	Certificats Cryptographic Module Validation Program (CMVP)
Constructeurs de TPM	Silicium et firmware (Infineon, ST, Nuvoton, AMD, Intel, Microsoft)	Produits TPM 2.0 conformes, certificats EK, bulletins de sécurité

Le TCG opere via des groupes de travail : TPM Work Group pour la bibliothèque coeur, PC Client pour les profils ordinateur personnel et serveur, Mobile pour le monde mobile, Embedded Systems pour l'IoT industriel, Storage pour les disques auto-chiffres, Network Equipment Building System (NEBS) et DICE (Device Identifier Composition Engine) pour les devices ultra-contraints. Les livrables sont publics, téléchargeables depuis le site du TCG. La certification de conformité (TCG Compliance Programme) est un service payant, avec publication sur une liste publique.

TPM 1.2 a TPM 2.0, la bascule algorithm-agile

Le TPM 1.2 (2005) était lie a un profil algorithmique fixe : RSA-2048 pour l'asymétrique, SHA-1 pour le hashage, pas de support ECC natif, jeu de commandes ancre sur la structure de ces algorithmes. Les collisions SHA-1 (Stevens et al., 2017, puis SHAttered) et l'obsolescence progressive de RSA-2048 a l'horizon 2030 ont rendu cette architecture intenable.

Le TPM 2.0, redige a partir de 2011 et publie comme Library Specification 1.07 en 2014, puis standardise ISO/IEC 11889 en 2015, atteignant la version 1.62 en 2020 avec errata ultérieurs, devient algorithm-agile. La spécification separe le profil algorithmique de l'architecture : un TPM 2.0 supporte un sous-ensemble choisi par le constructeur (SHA-256 obligatoire, SHA-384 optionnel, RSA-2048 en base, ECC NIST P-256 largement répandu, ECC BN-256 pour Direct Anonymous Attestation). Les hiérarchies sont réorganisées (platform, storage, endorsement, null) et l'autorisation est généralisée via des policies (TPM2_PolicyOR, TPM2_PolicyPCR, TPM2_PolicySigned et autres).

Le matériel n'est pas compatible entre les deux : une carte mère TPM 1.2 ne se flashe pas en TPM 2.0. Les nouveaux designs visent TPM 2.0 ; le TPM 1.2 est en fin de vie et rejeté par Windows 11, les baselines BitLocker récentes et la plupart des services d'attestation actuels.

Architecture TPM 2.0

Un TPM 2.0 expose un petit ensemble d'objets structurants.

Endorsement Key (EK)

L'EK est une paire de clés asymétriques (RSA-2048 ou ECC NIST P-256) injectée a la fabrication du silicium par le constructeur, partie privée non extractible. Le certificat EK associe est signe par une autorité de certification intermédiaire constructeur (Infineon, ST, Nuvoton, AMD, Intel), elle-même rattachée a une racine publique listée par le TCG. L'EK prouve que le TPM est un vrai TPM certifie d'un constructeur connu, sans révéler l'identité plate-forme. C'est le point d'ancrage de confiance pour toute l'attestation aval.

Storage Root Key (SRK)

La SRK est créée lorsque le propriétaire de plate-forme prend le controle du TPM (TPM2_CreatePrimary dans la hiérarchie storage). C'est la racine de la hiérarchie de clés applicative : les clés générées et scellées par la plate-forme en descendent. La SRK ne sort jamais du TPM et disparaît quand la propriété est reinitialisee.

Attestation Identity Key (AIK)

L'AIK, parfois appelée Attestation Key (AK), est une cle de signature générée par le TPM, dérivée de l'EK mais pseudonyme : elle ne revele pas directement l'identité EK. Elle est certifiée soit par une Privacy CA (service externe qui valide la chaine EK et émet un certificat AIK), soit par Direct Anonymous Attestation (DAA), protocole zero-knowledge qui prouve que l'AIK provient d'un vrai TPM sans identifier le TPM. L'AIK signe les quotes de PCR lors de l'attestation distante.

Platform Configuration Registers (PCR)

Les PCR sont des registres extend-only, au nombre de 24 dans le profil standard PC Client (PCR 0 a 23). Chaque mesure obéit a la regle PCR[n] = SHA-256(PCR[n] concatene avec mesure). L'architecture interdit d'écraser un PCR : seule l'extension est permise. Le firmware de boot étend PCR 0 a 7 avec ses mesures (UEFI, option ROM, boot loader, secure boot state, boot policy) ; l'OS étend PCR 8 et au-dela.

PCR	Contenu typique (profil TCG PC Client)
PCR 0	Mesure firmware UEFI (BIOS), S-CRTM
PCR 1	Configuration plate-forme (options BIOS, oprom config)
PCR 2, 3	Option ROM, drivers
PCR 4	Boot loader (MBR ou loader UEFI)
PCR 5	Table de partitions GPT
PCR 7	Etat Secure Boot et clés de signature
PCR 8 a 15	Mesures système d'exploitation et applications
PCR 17 a 22	Dynamic Root of Trust (DRTM, Intel TXT, AMD SKINIT)
PCR 23	Usage applicatif, réinitialisé régulièrement par l'OS

Le layout PCR differe entre Windows et Linux : une donnée scellée sur un OS ne se descelle quasi jamais sur l'autre.

Scellement et quoting

Le scellement lie une donnée a un état de PCR choisi. Le TPM ne descelle que si les PCR correspondent a la valeur attendue. Le quoting produit un rapport signe des valeurs de PCR sous une cle d'attestation, utilise en attestation distante. Ces deux mécanismes forment le coeur du measured boot et du trusted boot.

Form factors, discret, firmware, virtuel

Form factor	Exemples	Avantages	Limites
TPM discret (dTPM)	Infineon SLB 9670, ST33TPHF20, Nuvoton NPCT75x	Isolation physique, évaluation Common Criteria forte (EAL 4+), surface d'attaque indépendante	Nomenclature, surface PCB, interfaçage SPI/I2C/LPC
TPM firmware (fTPM)	Intel PTT dans le Management Engine, AMD fTPM dans le Platform Security Processor	Aucune puce supplémentaire, pas de coût nomenclature	Surface d'attaque partagée avec le firmware plate-forme, évaluation Common Criteria plus limitée
TPM virtuel (vTPM)	QEMU/KVM avec swtpm, VMware vTPM, Hyper-V vTPM	Adapte aux machines virtuelles, isolation logicielle par VM	Ancrage de confiance remonte a l'hyperviseur
TPM logiciel (swtpm)	swtpm, simulateur de reference IBM TPM 2.0	Developpement, pipelines CI, tests d'intégration	Aucune sécurité réelle, usage développement uniquement

Choix typique : dTPM pour PC, serveur, défense, paiement, industriel et automobile ; fTPM pour portables grand public ; vTPM pour workloads cloud ; swtpm pour pipelines CI.

Interfaces et pile logicielle

Un TPM discret expose l'une de plusieurs interfaces physiques.

Interface	Vitesse typique	Usage
LPC (Low Pin Count)	33 MHz, legacy	PC plus anciens, de moins en moins utilise pour cause de latence bus
SPI	jusqu'a 33 MHz typiquement	Interface moderne de reference, PC, serveur, embarque
I2C	400 kHz a 1 MHz	Systemes embarques, IoT, interactions plus lentes
FIFO (memory-mapped)	dépend de la plate-forme	Variante sur certaines plates-formes

Sous Linux, le noyau expose deux périphériques caractère : /dev/tpm0 pour l'accès brut (utilise par le sous-système integrity) et /dev/tpmrm0 avec le resource manager cote noyau (utilise par les applications espace utilisateur). La pile de reference est tpm2-tss (Trusted Software Stack, couches ESAPI, SAPI, TCTI) plus tpm2-tools (ligne de commande). La bibliothèque tpm2-pkcs11 expose le TPM comme un token PKCS#11 pour OpenSSL ou l'intégration navigateur.

Sous Windows, l'accès passe par l'API TPM Base Services (TBS), encapsulée par Windows Cryptography API: Next Generation (CNG) et exposée aux applications via des providers specifiques. BitLocker, Windows Hello et Credential Guard utilisent le TPM directement via ces API.

Qu'est-ce qui rend un TPM 2.0 conforme TCG ?

Un produit TPM 2.0 fait l'objet de plusieurs certifications : TCG Compliance, Common Criteria et FIPS 140-3.

TCG Compliance Programme

Le TCG opere un programme de conformité base sur le TPM 2.0 Test Suite. Le constructeur soumet son produit, execute la suite de tests (couverture fonctionnelle de la bibliothèque TPM), et reçoit une déclaration TCG Certified TPM listée sur la liste publique du TCG. Cette certification est une conformité (le TPM fait ce que dit la spécification), pas une sécurité en tant que telle.

Common Criteria et BSI-CC-PP-0030

La reference sécurité est l'évaluation Common Criteria contre le profil de protection BSI-CC-PP-0030 Trusted Platform Module Library Family 2.0, publie par le BSI allemand. Ce profil de protection définit les exigences fonctionnelles de sécurité (SFR) attendues d'un TPM 2.0 et les exigences d'assurance. Niveau d'assurance typique : EAL 4 augmente avec AVA_VAN.4 ou AVA_VAN.5 (analyse de vulnérabilités Moderee ou Haute), ALC_DVS.2 et ALC_FLR.1.

Infineon (SLB 9670, SLB 9672), ST (ST33TPHF20, ST33KTPM2X) et Nuvoton (NPCT75x) détiennent tous des certificats Common Criteria courants contre ce profil, listes sur le portail BSI et sur le portail international Common Criteria. Les évaluations de TPM firmware existent mais sont plus rares : AMD fTPM et Intel PTT n'ont historiquement pas poursuivi un certificat Common Criteria équivalent a une puce dédiée. Pour le cadre plus large, voir Common Criteria, ISO/IEC 15408.

FIPS 140-3 (USA)

Pour le marche fédéral américain, le module cryptographique embarque dans le TPM est souvent valide sous FIPS 140-3 (ou son prédécesseur FIPS 140-2, en sunset depuis septembre 2026). La validation est conduite sous le programme NIST Cryptographic Module Validation Program (CMVP), au niveau 1 ou 2 typiquement pour un TPM. Le résultat est un certificat de validation publie sur la liste CMVP. Pour le cadre complet, voir FIPS 140-3.

Integration aux systèmes d'exploitation

Windows BitLocker

BitLocker utilise le TPM pour sceller la Volume Master Key (VMK) sur PCR 0, 2, 4, 7 et 11 (profil par défaut), ce qui couple le déchiffrement disque a l'état secure boot. Un changement de BIOS, de clés secure boot, de boot loader rompt le scellement et declenche la récupération BitLocker (prompt de cle de récupération). Sous Windows 11, TPM 2.0 est obligatoire, ce qui a fait de l'activation du fTPM un point critique sur les cartes mères livrées avec fTPM desactive par défaut.

Linux dm-crypt et LUKS

La pile de reference utilise dm-crypt pour le chiffrement disque complet, LUKS2 pour l'enveloppe de cle, et le mécanisme de descellement couple au TPM via l'une de deux voies : clevis (framework pluggable supportant TPM 2.0, Tang et Shamir secret sharing) ou systemd-cryptenroll (natif, depuis systemd 248). Dans les deux cas, la passphrase LUKS est scellée contre un profil PCR choisi a l'enrôlement (couramment PCR 7 pour l'état secure boot, PCR 0 pour le firmware UEFI, PCR 1 pour la configuration plate-forme). Le descellement au boot est silencieux si les PCR correspondent, retombe sur saisie de passphrase sinon.

Integrity Measurement Architecture (IMA)

Le noyau Linux implemente IMA (Integrity Measurement Architecture) pour mesurer les exécutables, fichiers de configuration et objets choisis a l'exécution. IMA étend un PCR dedie (PCR 10 par convention) et produit un journal de mesures lisible dans /sys/kernel/security/ima/ascii_runtime_measurements. Coupler IMA au TPM permet l'attestation distante de l'état d'exécution, au-dela du boot initial.

OpenSSL et tpm2-pkcs11

La bibliothèque tpm2-pkcs11 expose le TPM comme un token PKCS#11 a OpenSSL ou toute application compatible PKCS#11. Cela permet des opérations de signature et de déchiffrement de type HSM avec le TPM agissant comme magasin cryptographique a faible coût, adapte a l'authentification par certificat client X.509, au code signing sur environnements de build embarques ou au scellement de clés privées d'AC.

Produits connectes et IoT

Microsoft Azure Device Provisioning Service (DPS)

Azure DPS supporte l'attestation par TPM. Le device declare son endorsement key public (EKpub) a DPS ; DPS valide que l'EKpub est signe par une autorité intermédiaire connue d'un constructeur de TPM, puis émet un challenge d'attestation que le TPM signe sous une cle d'attestation dérivée. En succès, DPS provisionne le device vers son IoT Hub. La chaine de provisioning tombe si le certificat intermédiaire constructeur manque du dossier cote device : erreur frequente en premier déploiement.

AWS IoT et X.509 dans le TPM

AWS IoT ne supporte pas nativement l'attestation EK TPM ; l'intégration passe par un certificat client X.509 long-terme, dont la cle privée est générée et stockée dans le TPM. L'authentification mutual TLS au broker AWS utilise ensuite le TPM comme magasin de cle privée, sans extraction de la cle.

Matter (CSA) et le Device Attestation Certificate

Le standard Matter de la Connectivity Standards Alliance impose un Device Attestation Certificate (DAC) ancre dans un élément de stockage securise matériel, souvent un secure élément plutôt qu'un TPM discret (le TPM est rare dans les devices Matter grand public a cause de la nomenclature). La logique de chaine de confiance reste la même : certificat intermédiaire vendor, certificat racine constructeur, attestation lors du commissioning fabric. Pour le détail, voir certification Matter.

TPM, secure élément et HSM, ce qui differe

Aspect	TPM 2.0	Secure Element (SE)	HSM
Form factor	Puce discrète ou firmware, intégrée a une plate-forme	Puce discrète, plus petite, offload crypto générique	Appliance réseau ou carte PCI, datacenter
Usage typique	Confiance de boot, scellement, attestation, cle scellée a l'état plate-forme	Offload crypto générique, identité IoT, paiement, tickets transport	Operations crypto haut débit (TLS, code signing, PKI)
Standardisation	TCG, ISO/IEC 11889	GlobalPlatform, JavaCard, EMVCo pour le paiement	FIPS 140-3, Common Criteria pour les plus gros
Exemples typiques	Infineon SLB 9670, ST33, Nuvoton NPCT, fTPM	NXP A71CH, SE050, Microchip ATECC608B, Infineon OPTIGA Trust	Thales Luna, Utimaco, AWS CloudHSM
Ordre nomenclature	Faible pour fTPM, modere pour dTPM	Faible	Eleve

Les produits embarques choisissent souvent un SE plutôt qu'un TPM (nomenclature plus faible, interface plus simple), mais la montée en charge de Matter, de l'IoT industriel régulé et du Cyber Resilience Act pousse l'attestation vers des devices type TPM, avec puce évaluée Common Criteria.

Compromis connus et historique de sécurité

Annee	Compromis	Perimetre touche	Mitigation
2017	ROCA (CVE-2017-15361)	Bibliotheque Infineon RSALib, génération de clés RSA dans TPM 1.2 et 2.0	Mise a jour firmware, régénération des clés RSA affectées
2019	TPM-Fail (CVE-2019-11090, CVE-2019-16863)	Canal auxiliaire temporel sur ECDSA dans Intel fTPM et ST33TPHF20	Mise a jour firmware, mitigations dans la pile cryptographique
2024	Sandman	Variante cold boot sur dTPM expose sur bus SPI	Chiffrement de bus (TPM 2.0 supporte le chiffrement de session depuis spec 1.38), controle d'accès physique

La leçon opérationnelle générale est la même : tout TPM en service doit être inventorie avec sa version firmware, et la version firmware vérifiée contre les bulletins de sécurité publies. Le measured boot via PCR reste la mitigation visible cote utilisateur : un TPM compromis qui aurait produit une valeur scellée malicieuse se trahit par une attestation qui ne correspond plus a l'état de reference attendu.

TPM 2.0 et Cyber Resilience Act européen

Le Cyber Resilience Act, publie en novembre 2024 (Règlement (UE) 2024/2847) et applicable en décembre 2027, fixe les exigences essentielles de cybersécurité pour les produits avec éléments numériques. Le TPM n'est pas nomme explicitement mais plusieurs exigences CRA ont une lecture naturelle TPM : boot securise, intégrité et confidentialité des données, limitation de la surface d'attaque, processus de gestion des vulnérabilités, voie de mise a jour de sécurité.

Pour les produits classes importants (annexe III) ou critiques (annexe IV), ou l'évaluation de conformité est renforcée (tiers le cas échéant), concevoir sans ancrage matériel securise devient difficile a justifier. Le TPM 2.0, ou un secure élément aux propriétés équivalentes, est l'une des voies pratiques pour répondre a ces exigences. Pour le cadre large, voir Cyber Resilience Act.

Procedure pas a pas pour un produit embarque

La séquence typique pour une equipe d'ingénierie intégrant un TPM 2.0 dans un nouveau produit electronique.

Choisir le form factor (dTPM, fTPM, aucun plus SE) en mappant les contraintes de nomenclature, l'exigence de certification (Common Criteria pour les secteurs régulés), le modele d'attaque et les OS cibles.
Selectionner la puce (Infineon SLB 9672, ST33KTPM2X, Nuvoton NPCT75x pour dTPM ; support plate-forme AMD ou Intel pour fTPM), vérifier le certificat Common Criteria courant, la validation FIPS 140-3 si pertinent, et les bulletins de sécurité actifs.
Definir le bus (SPI 25 a 33 MHz recommande pour dTPM moderne, I2C pour embarque ultra-contraint, LPC uniquement en compatibilité legacy).
Router la PCB avec protection ESD appropriée, découplage d'alimentation, placement BGA dans le respect du dry pack, et plan de masse dedie a la puce.
Integrer la pile logicielle (tpm2-tss et tpm2-tools sous Linux, API TBS sous Windows, SDK vendor pour RTOS).
Provisionner la chaine de certificats EK, charger le certificat intermédiaire constructeur sur le device, valider la chaine au premier boot.
Definir le profil PCR pour le scellement (couramment PCR 0, 2, 4, 7 sous Windows ; PCR 7 plus optionnel sous Linux), tester le comportement de descellement sur scenarios de mise a jour firmware.
Mettre en oeuvre l'attestation vers le back-end (Azure DPS, AWS IoT via X.509, plate-forme IoT interne), avec validation de la chaine EK cote serveur.
Prevoir les mises a jour firmware du TPM (le constructeur fournit des bundles firmware), avec inventaire de versions et suivi des bulletins de sécurité.
Documenter la chaine de confiance dans le dossier de sécurité (AC racine, intermédiaire, EK, AIK, données scellées) pour l'évaluation CRA, Common Criteria ou sectorielle.

Pieges fréquents

Piege	Consequence
TPM discret en BGA mal soude ou sous-protege ESD	TPM instable en champ, retours sporadiques difficiles a diagnostiquer
Bus LPC utilise pour SRTM sur plate-forme moderne	Boot allonge de plusieurs centaines de millisecondes, impact utilisateur perceptible
fTPM desactive par défaut au BIOS	Scellement BitLocker ou LUKS rompu silencieusement au premier déploiement
Chaine de certificats EK non chargée sur le device	Provisioning Azure DPS echoue, message Unauthorized EK
Reutilisation de données scellées sous Windows sur système Linux	Descellement echoue systématiquement, layout PCR differe
TPM avec version firmware vulnérable ROCA encore en service	Cles RSA factorisables, audit de sécurité non conforme
FIPS 140-2 declare au lieu de FIPS 140-3 apres septembre 2026	Validation expirée, marche fédéral bloque
Confusion entre TCG Compliance et Common Criteria	Croyance que la conformité couvre la sécurité, lacune dans le dossier de sécurité
Scellement sur PCR 0 avec mises a jour BIOS frequentes	Prompts de cle de récupération routiniers, charge de support
Pas d'inventaire des versions firmware sur la flotte	Impossible de réagir a un nouveau bulletin de sécurité dans un délai compatible CRA

Aller plus loin

Common Criteria, ISO/IEC 15408 : le cadre sous lequel les puces TPM 2.0 sont évaluées contre BSI-CC-PP-0030.
FIPS 140-3, modules cryptographiques : le cadre de validation américain du module cryptographique embarque dans le TPM.
Cyber Resilience Act : le règlement UE poussant boot securise et intégrité, ou le TPM 2.0 est une voie structurante.
Certification Matter : logique parallèle, avec un DAC ancre dans un secure élément au rôle proche d'un TPM.
Glossaire : définitions de TPM, TCG, PCR, EK, AIK, scellement, attestation, dTPM, fTPM, vTPM.

Voir aussi

Sources & références

TPM 2.0 Library Specification, version 1.62 (2020) , Trusted Computing Group trustedcomputinggroup.org/resource/tpm-library-specification/
ISO/IEC 11889-1 a -4:2015, Information technology, Trusted Platform Module Library , ISO/IEC www.iso.org/standard/66510.html
BSI-CC-PP-0030, Trusted Platform Module Library Family 2.0, Protection Profile , Bundesamt fuer Sicherheit in der Informationstechnik (BSI) www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Zertifizierung-und-Anerkennung/Zertifizierung-von-Produkten/Zertifizierung-nach-CC/Schutzprofile-Protection-Profiles/schutzprofile-protection-profiles_node.html
FIPS 140-3, Security Requirements for Cryptographic Modules (2019) , NIST csrc.nist.gov/publications/detail/fips/140/3/final
TCG PC Client Platform TPM Profile Specification , Trusted Computing Group trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/
Pile logicielle TPM 2.0 sous Linux (tpm2-tss, tpm2-tools) , communaute tpm2-software github.com/tpm2-software

Questions fréquentes

Quelle est la différence entre un TPM 1.2 et un TPM 2.0 ?: Le TPM 1.2, publie en 2005 et standardise comme ISO/IEC 11889 première édition, fige les algorithmes (RSA-2048, SHA-1, hiérarchie de clés fixe) et expose un jeu de commandes ferme. Le TPM 2.0, dont la Library Specification atteint la version 1.62 en 2020, devient algorithm-agile : SHA-256 et plus fort en base, ECC avec NIST P-256 et BN-256 supportes, plusieurs hiérarchies (platform, storage, endorsement, null) coexistent et l'autorisation se generalise via des policies. Le hardware n'est pas compatible entre les deux : une carte mère TPM 1.2 ne se flashe pas en TPM 2.0, le silicium differe. Les nouveaux designs visent TPM 2.0 ; le TPM 1.2 est en fin de vie et plus accepte par Windows 11 ni par la plupart des services d'attestation actuels.
A quoi servent les Platform Configuration Registers (PCR) ?: Les PCR sont des registres extend-only, au nombre de 24 dans le profil standard (PCR 0 a 23), utilises pour enregistrer une chaine de hash immuable des mesures de boot et d'exécution. Chaque mesure applique la regle PCR[n] = SHA-256(PCR[n] concatene avec mesure). Le firmware de boot étend PCR 0 a 7 avec ses propres mesures (UEFI, option ROM, boot loader, secure boot state) ; l'OS étend PCR 8 et au-dela. Deux usages principaux suivent : le scellement, qui lie une donnée a un état de PCR choisi et refuse de la descelle si l'état differe, et le quoting, qui signe le contenu des PCR sous une cle d'attestation pour l'attestation distante. Le layout des PCR differe entre Windows et Linux : une donnée scellée sur l'un ne se descelle quasi jamais sur l'autre.
TPM discret, TPM firmware ou TPM virtuel, lequel choisir ?: Un TPM discret (Infineon SLB 9670, ST33, Nuvoton NPCT) est une puce dédiée sur SPI, I2C ou LPC. Il offre l'isolation physique, une évaluation Common Criteria forte et constitue la reference pour l'attestation matérielle. Un TPM firmware (Intel PTT dans le Management Engine, AMD fTPM dans le Platform Security Processor) tourne dans un Trusted Execution Environment du SoC principal : nomenclature réduite, mais surface d'attaque partagée avec le firmware plate-forme. Un TPM virtuel (vTPM, swtpm) cible les machines virtuelles et le développement ; le point d'ancrage de confiance remonte a l'hyperviseur ou, pour software TPM, est simule. Choix typiques : dTPM pour PC, serveur, défense, paiement, automobile ; fTPM pour portables grand public ; vTPM pour workloads cloud ; swtpm pour pipelines CI.
Que certifie l'Endorsement Key (EK) ?: L'EK est une paire de clés asymétriques (RSA-2048 ou ECC NIST P-256) injectée a la fabrication du silicium par le constructeur du TPM, partie privée non extractible. Le certificat EK associe est signe par une autorité de certification intermédiaire opérée par le constructeur (Infineon, ST, Nuvoton, AMD, Intel), elle-même rattachée a une autorité racine publique listée par le TCG. L'EK prouve que le TPM est un vrai TPM certifie d'un constructeur connu, sans révéler l'identité plate-forme. Il sert de point d'ancrage de confiance pour émettre des Attestation Identity Keys (AIK) et pour les services de provisioning comme Microsoft Azure Device Provisioning Service, qui valident la chaine de l'EK avant d'autoriser le device.
Quelles évaluations Common Criteria couvrent les puces TPM 2.0 ?: Les puces TPM 2.0 discrètes d'Infineon, ST et Nuvoton sont évaluées Common Criteria contre le profil de protection BSI-CC-PP-0030 Trusted Platform Module Library Family 2.0, publie par le BSI allemand et reconnu internationalement via CCRA et SOG-IS. Niveau d'assurance typique : EAL 4 augmente avec AVA_VAN.4 ou AVA_VAN.5 (analyse de vulnérabilités Moderee ou Haute), ALC_DVS.2 et ALC_FLR.1. L'évaluation couvre le matériel, le firmware embarque et la bibliothèque cryptographique. Les évaluations de TPM firmware existent mais sont plus rares ; AMD fTPM et Intel PTT n'ont historiquement pas poursuivi un certificat Common Criteria équivalent a une puce dédiée, ce qui pese dans l'analyse de confiance pour les secteurs régulés.
Qu'était la vulnérabilité ROCA et reste-t-elle d'actualité ?: ROCA (Return Of Coppersmith Attack), publiée en 2017 sous CVE-2017-15361, a touche la génération de clés RSA dans la bibliothèque cryptographique Infineon RSALib utilisée dans plusieurs puces TPM 1.2 et TPM 2.0. Le biais dans la génération des nombres premiers rendait les clés RSA 2048 bits factorisables en quelques jours-CPU. Infineon a diffuse des mises a jour firmware et Microsoft, Lenovo, HP et d'autres ont regenere les clés affectées. En 2026, les devices encore en service avec une version de firmware TPM vulnérable restent non conformes FIPS 140-3 et a la plupart des baselines de sécurité actuelles ; vérifier la version firmware du TPM (tpm2_getcap properties-fixed sous Linux, Get-Tpm sous Windows) contre le bulletin de sécurité constructeur reste une étape d'audit essentielle.
Comment TPM 2.0 s'inscrit-il dans le Cyber Resilience Act ?: Le Cyber Resilience Act (CRA), publie en novembre 2024 et applicable en décembre 2027, exige pour les produits avec éléments numériques un boot securise, la confidentialité et l'intégrité des données, la limitation de la surface d'attaque et un processus de gestion des vulnérabilités. Le TPM 2.0, ou un secure élément aux propriétés équivalentes, constitue une des voies pratiques pour ces exigences : measured boot ancre dans les PCR, scellement des secrets a l'état plate-forme, gestion des vulnérabilités via mise a jour firmware signée et vérifiée par le TPM, attestation de l'état du device. Le CRA ne nomme pas TPM explicitement mais, pour les produits des classes importantes et critiques (annexes III et IV), la conception sans ancrage matériel securise devient difficile a défendre en évaluation de conformité.
Quels sont les pieges les plus fréquents a l'intégration d'un TPM discret ?: Premier piege : placement BGA et protection ESD ; les TPM discrets sont sensibles aux défauts de soudure, le dry pack doit être respecte et la protection ESD dimensionnée pour l'interface choisie (SPI plus tolérant que LPC). Deuxième : la vitesse du bus ; un TPM LPC utilise pour le Static Root of Trust for Measurement allonge le boot de plusieurs centaines de millisecondes, le SPI a 30 MHz est préférable sur plate-forme moderne. Troisième : la chaine de certificats EK ; oublier de charger le certificat intermédiaire constructeur bloque le provisioning Azure DPS. Quatrième : le TPM firmware est souvent desactive par défaut au BIOS (fTPM Disabled), ce qui casse silencieusement le scellement BitLocker ou LUKS au premier déploiement. Cinquième : réutiliser une donnée scellée sous layout PCR Windows sur un système Linux est impossible, la chaine de boot mesure des objets différents dans un ordre different.