publish: TPM 2.0 : pourquoi Windows l'impose, pourquoi Linux ne le fait pas, et ce que cela révèle vraiment de la sécurité des systèmes
This commit is contained in:
Cédrix
@@ -1,12 +0,0 @@
|
||||
{
|
||||
"title": "TPM 2.0 : pourquoi Windows l'impose, pourquoi Linux ne le fait pas, et ce que cela révèle vraiment de la sécurité des systèmes",
|
||||
"slug": "tpm2",
|
||||
"_updated_at": "2026-05-17 06:20:06",
|
||||
"published": true,
|
||||
"published_at": "2023-02-28 13:42",
|
||||
"category": "Informatique",
|
||||
"tags": [],
|
||||
"seo_title": "",
|
||||
"seo_description": "",
|
||||
"og_image": "https://www.abonnel.fr/file?uuid=575cb5b1-9a12-4915-8839-2d5f2e9c86b9&name=cover.svg"
|
||||
}
|
||||
@@ -1,234 +0,0 @@
|
||||
# TPM 2.0 : pourquoi Windows l'impose, pourquoi Linux ne le fait pas, et ce que cela révèle vraiment de la sécurité des systèmes
|
||||
|
||||
## Introduction
|
||||
|
||||
Depuis la sortie de Windows 11 en 2021, une petite puce soudée à la carte mère est passée du statut de composant obscur à celui de sujet de débat grand public : le **TPM 2.0** (*Trusted Platform Module*). Microsoft en a fait une condition d'installation officielle, excluant d'un trait des millions de PC parfaitement fonctionnels de la mise à niveau. Pendant ce temps, le monde Linux a continué sa route sans rien imposer du tout, tout en sachant parfaitement exploiter cette même puce quand elle est présente.
|
||||
|
||||
Ce contraste soulève une question légitime : si Microsoft considère le TPM comme indispensable, est-ce que son absence d'obligation côté Linux ne traduirait pas une faiblesse, un retard, ou un déni des bonnes pratiques modernes de sécurité ?
|
||||
|
||||
La réponse, développée dans cet article, est claire : **non**. Mais elle mérite d'être étayée, parce qu'elle touche à des philosophies de conception logicielle radicalement différentes, à l'histoire du secteur, et à la nature même de ce qu'on appelle "sécurité".
|
||||
|
||||
---
|
||||
|
||||
## 1. Comprendre ce qu'est réellement le TPM 2.0
|
||||
|
||||
### Un coprocesseur dédié à la confiance
|
||||
|
||||
Le TPM (*Trusted Platform Module*) est une puce de sécurité matérielle, soit soudée à la carte mère, soit intégrée directement au processeur principal sous forme de **fTPM** (firmware TPM) chez AMD ou de **PTT** (Platform Trust Technology) chez Intel. Sa version 2.0, standardisée par le *Trusted Computing Group*, est aujourd'hui la norme.
|
||||
|
||||
Son rôle n'est pas d'accélérer les calculs ou de remplacer un antivirus. C'est un **coffre-fort cryptographique** capable de :
|
||||
|
||||
- générer et stocker des clés de chiffrement de façon que même l'OS ne puisse pas les extraire ;
|
||||
- mesurer (au sens cryptographique : hacher) chaque étape du démarrage du système et conserver ces mesures dans des registres internes appelés **PCR** (*Platform Configuration Registers*) ;
|
||||
- attester à un service distant que le système a bien démarré dans un état connu et non altéré ;
|
||||
- fournir une source d'entropie matérielle pour la génération de nombres aléatoires ;
|
||||
- sceller des secrets à un état précis de la machine, qui ne pourront être déverrouillés que si cet état est rigoureusement reproduit.
|
||||
|
||||
### Ce que le TPM **n'est pas**
|
||||
|
||||
Il faut tordre le cou à plusieurs malentendus tenaces :
|
||||
|
||||
- Le TPM **n'est pas** un mouchard. Il ne communique avec personne de son propre chef.
|
||||
- Le TPM **n'empêche pas** un virus de tourner sur un système déjà démarré. Une fois le PC allumé et la session ouverte, le malware s'exécute exactement comme avant.
|
||||
- Le TPM **ne chiffre pas** automatiquement les données. Il fournit des briques cryptographiques que d'autres logiciels (BitLocker, LUKS, etc.) utilisent.
|
||||
- Le TPM **n'est pas infaillible**. Plusieurs failles notables l'ont touché ces dernières années : TPM-Fail (2019), la vulnérabilité ROCA d'Infineon (2017), des attaques par *bus sniffing* qui interceptent les communications entre le TPM discret et le CPU sur certaines cartes mères.
|
||||
|
||||
---
|
||||
|
||||
## 2. L'obligation Windows 11 : une décision technique ou commerciale ?
|
||||
|
||||
### La position officielle de Microsoft
|
||||
|
||||
Microsoft justifie l'exigence TPM 2.0 par la volonté de garantir un **socle de sécurité minimal homogène** sur tout l'écosystème Windows 11. La logique tient en quelques points :
|
||||
|
||||
- **BitLocker** (chiffrement de disque) devient activable par défaut sans saisir de mot de passe à chaque démarrage, car la clé est scellée dans le TPM.
|
||||
- **Windows Hello** (reconnaissance biométrique) stocke les empreintes biométriques de façon protégée.
|
||||
- **Credential Guard** isole les identifiants utilisateurs (hashs NTLM, tickets Kerberos) hors d'atteinte d'un malware qui aurait obtenu les droits administrateur.
|
||||
- **Secure Boot** combiné au TPM permet le *measured boot* : chaque étape du démarrage est mesurée, et toute altération devient détectable.
|
||||
- Les développeurs d'applications peuvent compter sur la présence universelle d'une racine de confiance matérielle.
|
||||
|
||||
Cette logique est cohérente. Elle s'adresse à un parc de plusieurs centaines de millions de machines administrées par des utilisateurs aux compétences hétérogènes, dont une partie ne configurera jamais consciemment la moindre option de sécurité.
|
||||
|
||||
### Ce qui se cache aussi derrière
|
||||
|
||||
Il serait naïf de ne voir là qu'une décision purement technique. L'obligation TPM s'inscrit dans une stratégie plus large :
|
||||
|
||||
- **Pousser au renouvellement matériel** : exclure les machines antérieures à ~2016-2018 a stimulé le marché des PC neufs, à un moment où le marché stagnait.
|
||||
- **Préparer l'attestation** : à terme, Microsoft envisage que certains services en ligne refusent d'interagir avec des PC ne pouvant pas prouver leur intégrité. Sans TPM généralisé, ce modèle est impossible.
|
||||
- **Lutter contre le piratage logiciel** : les licences peuvent être liées matériellement au TPM.
|
||||
- **Verrouiller l'écosystème** : harmoniser le matériel facilite le contrôle de la chaîne logicielle complète, au prix d'une perte d'autonomie pour l'utilisateur final.
|
||||
|
||||
### Une obligation contournable dans les faits
|
||||
|
||||
Détail souvent passé sous silence : malgré le discours officiel, l'obligation TPM est **techniquement contournable** sans bricolage extrême :
|
||||
|
||||
- modification de la clé de registre `LabConfig\BypassTPMCheck` pendant l'installation ;
|
||||
- création d'une clé USB d'installation avec Rufus, qui propose explicitement une option *"supprimer les exigences TPM 2.0 / Secure Boot / 8 Go de RAM"* ;
|
||||
- utilisation de scripts qui font passer l'installateur en mode "Windows Server", lequel ne vérifie pas le TPM.
|
||||
|
||||
Microsoft agite régulièrement la menace de couper les mises à jour pour les machines non conformes, sans jamais l'avoir réellement mise à exécution. Cela en dit long sur la nature de l'exigence : un standard imposé à grande échelle, pas une condition absolue de fonctionnement.
|
||||
|
||||
---
|
||||
|
||||
## 3. Pourquoi Linux ne l'impose pas
|
||||
|
||||
### Une philosophie différente : adapter le logiciel au matériel
|
||||
|
||||
Linux est un noyau qui tourne sur tout : de la montre connectée au superordinateur, du Raspberry Pi sans aucune sécurité matérielle au serveur d'entreprise avec HSM dédié, en passant par le téléphone Android, la box Internet, le système embarqué d'une voiture. Imposer un TPM 2.0 comme prérequis n'aurait aucun sens — cela exclurait la majorité du parc cible.
|
||||
|
||||
La philosophie est donc inversée : **le système s'adapte au matériel, pas l'inverse**.
|
||||
|
||||
### Pas d'éditeur unique pour décréter une exigence
|
||||
|
||||
Linux n'a pas de "Microsoft". Le noyau est développé par des milliers de contributeurs, encadré par la Linux Foundation. Les distributions (Debian, Ubuntu, Fedora, Arch, openSUSE, Red Hat...) prennent ensuite leurs propres décisions. Aucune autorité centrale ne peut imposer une exigence matérielle uniforme, et c'est par construction.
|
||||
|
||||
Cette absence de centralisation est parfois vue comme une faiblesse en termes de cohérence ; elle est en réalité une force en termes de résilience et de diversité d'usages.
|
||||
|
||||
### Modularité plutôt qu'obligation
|
||||
|
||||
Là où Windows mise sur un pilier unique (le TPM, censé porter une grande partie de l'architecture de sécurité), Linux dispose d'une **panoplie d'outils indépendants**, qui peuvent être combinés selon les besoins :
|
||||
|
||||
- chiffrement de disque avec LUKS/dm-crypt, utilisable avec ou sans TPM ;
|
||||
- contrôle d'accès obligatoire avec SELinux ou AppArmor ;
|
||||
- isolation des processus via namespaces, cgroups, seccomp ;
|
||||
- Secure Boot pris en charge nativement par la plupart des distributions majeures ;
|
||||
- vérification d'intégrité des fichiers avec IMA/EVM ;
|
||||
- pare-feu avec nftables ;
|
||||
- gestionnaire de paquets vérifiant cryptographiquement chaque binaire installé.
|
||||
|
||||
Aucun de ces outils ne **dépend** du TPM. Beaucoup peuvent en bénéficier s'il est présent.
|
||||
|
||||
---
|
||||
|
||||
## 4. Linux sait parfaitement utiliser le TPM
|
||||
|
||||
C'est le point crucial pour répondre à la question initiale. Linux ne rejette pas le TPM, il ne l'impose pas. Sur une machine moderne équipée d'un TPM 2.0, un utilisateur Linux peut :
|
||||
|
||||
### Déverrouiller automatiquement un disque LUKS
|
||||
|
||||
Avec `systemd-cryptenroll` ou le projet Clevis (couplé à Tang pour les configurations réseau), la clé maître LUKS peut être scellée dans le TPM. Le disque se déverrouille automatiquement au démarrage **si et seulement si** la chaîne de démarrage est intacte. C'est exactement le mécanisme décrit dans l'article *Fedora Magazine* — et c'est l'équivalent fonctionnel direct de BitLocker.
|
||||
|
||||
### Sceller des clés SSH ou GPG
|
||||
|
||||
Les outils `tpm2-tools`, `tpm2-pkcs11` ou `tpm2-tss-engine` permettent de générer des clés SSH ou GPG qui ne quittent jamais le TPM. Un attaquant qui copierait le contenu du disque dur ne pourrait pas les utiliser.
|
||||
|
||||
### Faire de l'attestation à distance
|
||||
|
||||
Les projets Keylime (CNCF) ou tpm2-totp permettent de prouver à un service distant que le système a bien démarré dans un état attendu — fonctionnalité utilisée notamment dans les déploiements cloud et conteneurs critiques.
|
||||
|
||||
### Disposer d'une source d'entropie matérielle
|
||||
|
||||
Le démon `rng-tools` peut alimenter le pool d'entropie du noyau avec les nombres aléatoires générés par le TPM, utile sur des serveurs très sollicités.
|
||||
|
||||
**En résumé** : un Linux installé sur une machine avec TPM 2.0 bénéficie exactement des mêmes garanties matérielles qu'un Windows 11. La différence est uniquement dans l'obligation, pas dans la capacité.
|
||||
|
||||
---
|
||||
|
||||
## 5. Les arguments empiriques en faveur de Linux
|
||||
|
||||
Si l'absence d'obligation TPM constituait réellement une faiblesse de sécurité, on s'attendrait à ce que les acteurs les plus exigeants en matière de sécurité abandonnent Linux. Or, c'est exactement l'inverse :
|
||||
|
||||
- **La quasi-totalité des serveurs Internet** mondiaux tourne sous Linux ou BSD.
|
||||
- **La NSA** a co-développé SELinux, qui équipe par défaut Red Hat, Fedora, et CentOS.
|
||||
- **Android**, déployé sur des milliards d'appareils dont beaucoup ne possèdent pas de TPM au sens PC du terme (ils ont d'autres mécanismes comme TrustZone), repose sur un noyau Linux.
|
||||
- **Les supercalculateurs** classés dans le TOP500 tournent à 100 % sous Linux.
|
||||
- **Les infrastructures critiques** (banques, télécoms, énergie) sont massivement sous Linux ou Unix propriétaires.
|
||||
- **Les distributions orientées sécurité** (Tails, Qubes OS, Whonix) sont des projets Linux, utilisés par des journalistes, dissidents et chercheurs en cybersécurité.
|
||||
|
||||
Ces acteurs n'ont rien à prouver : s'ils choisissent Linux, ce n'est pas par idéologie, c'est parce que l'arsenal de sécurité disponible est jugé adéquat — voire supérieur sur certains points spécifiques comme l'auditabilité du code source.
|
||||
|
||||
---
|
||||
|
||||
## 6. Là où Linux est même structurellement plus solide
|
||||
|
||||
Sans vouloir basculer dans le militantisme, plusieurs éléments donnent à Linux une avance objective sur des aspects de sécurité **indépendants** du TPM :
|
||||
|
||||
### Le modèle de permissions
|
||||
|
||||
Linux repose sur des décennies de tradition Unix où l'utilisateur courant n'est **pas** administrateur. Sous Windows, malgré les progrès du UAC, la culture de l'administrateur permanent reste très ancrée, et beaucoup d'applications le supposent encore.
|
||||
|
||||
### Le code source ouvert et auditable
|
||||
|
||||
Toute personne disposant des compétences peut inspecter le noyau Linux, ses outils de sécurité, ses bibliothèques cryptographiques. Les vulnérabilités sont trouvées plus tôt et corrigées publiquement. À l'inverse, le code de Windows reste largement fermé, et certaines failles n'apparaissent qu'à l'occasion de fuites ou d'attaques actives.
|
||||
|
||||
### Le gestionnaire de paquets
|
||||
|
||||
Installer un logiciel sous Linux passe presque toujours par un dépôt cryptographiquement signé, maintenu par la distribution. Sous Windows, l'utilisateur moyen télécharge des `.exe` sur des sites web — modèle structurellement plus risqué.
|
||||
|
||||
### La granularité du contrôle
|
||||
|
||||
SELinux, AppArmor, les capabilities, les namespaces : Linux offre une granularité de contrôle des permissions qu'aucune version grand public de Windows n'égale aujourd'hui.
|
||||
|
||||
### Une surface d'attaque souvent plus réduite
|
||||
|
||||
Une installation Linux serveur typique tourne avec une fraction des services activés sur un Windows 10/11 grand public. Moins de services exposés, moins de portes d'entrée potentielles.
|
||||
|
||||
---
|
||||
|
||||
## 7. Les limites réelles du TPM qu'on évoque rarement
|
||||
|
||||
Pour être complet, il faut aussi rappeler ce que le TPM **ne résout pas**, et ce qu'il peut introduire comme inconvénients :
|
||||
|
||||
- **Vulnérabilités passées** : TPM-Fail (CVE-2019-11090), ROCA (CVE-2017-15361 chez Infineon), attaques par *cold boot*, attaques par *bus sniffing* sur les TPM discrets non chiffrés.
|
||||
- **Dépendance au firmware** : le code interne du TPM est généralement propriétaire et fermé. Confier ses clés à une boîte noire est un acte de foi.
|
||||
- **Risque de perte de données** : en cas de panne de carte mère, les clés scellées dans le TPM sont irrécupérables. Sans sauvegarde de la clé de récupération, les données chiffrées sont perdues.
|
||||
- **Aucune protection contre les attaques post-démarrage** : une fois le système ouvert et l'utilisateur connecté, le TPM ne protège plus de grand-chose. Un ransomware ou un keylogger fonctionne comme avant.
|
||||
- **Aucune protection contre l'humain** : phishing, ingénierie sociale, mots de passe faibles — le TPM n'y peut rien.
|
||||
- **Risque de verrouillage écosystème** : à terme, l'attestation pourrait être utilisée pour refuser à un utilisateur d'exécuter des logiciels non approuvés par l'éditeur, glissant de la sécurité vers le contrôle.
|
||||
|
||||
---
|
||||
|
||||
## 8. La vraie hiérarchie de la sécurité
|
||||
|
||||
L'erreur classique est de croire que la sécurité est une **propriété du matériel**. Elle est en réalité d'abord une **propriété de la configuration et des usages**. Schématiquement, la hiérarchie de l'efficacité est à peu près celle-ci :
|
||||
|
||||
1. Comportement de l'utilisateur (mots de passe forts, vigilance face au phishing, mises à jour à jour, sauvegardes).
|
||||
2. Configuration de l'OS (utilisateur non administrateur, services inutiles désactivés, pare-feu, MAC).
|
||||
3. Chiffrement du disque, quelle que soit la technologie sous-jacente.
|
||||
4. Authentification forte (clés cryptographiques, 2FA).
|
||||
5. Présence d'une racine de confiance matérielle (TPM, Secure Enclave, etc.).
|
||||
|
||||
Le TPM est utile, mais il occupe la cinquième position, pas la première. Un Windows 11 avec TPM mais utilisateur administrateur, mot de passe `123456`, sans 2FA, qui clique sur tout, sera moins sûr qu'un Linux sans TPM correctement configuré.
|
||||
|
||||
Inversement, un Linux bien administré qui ajoute le TPM à sa configuration n'a rien à envier à un Windows 11 sur le même matériel. La sécurité est cumulative, pas exclusive.
|
||||
|
||||
---
|
||||
|
||||
## 9. Réponse directe à la question initiale
|
||||
|
||||
> *Si Linux n'impose pas le TPM, est-ce une faiblesse ?*
|
||||
|
||||
**Non, et voici pourquoi en synthèse :**
|
||||
|
||||
- Linux **peut utiliser** le TPM aussi bien que Windows, avec les mêmes garanties matérielles ;
|
||||
- Linux ne l'impose pas parce qu'il vise un éventail de matériels infiniment plus large que Windows, et parce qu'aucune entité centrale n'a intérêt ou autorité à l'imposer ;
|
||||
- Linux dispose d'une **multiplicité d'outils de sécurité** indépendants du TPM, dont plusieurs sont structurellement plus puissants que leurs équivalents Windows ;
|
||||
- Les acteurs les plus exigeants en matière de sécurité (États, militaires, banques, hébergeurs, dissidents) choisissent massivement Linux ;
|
||||
- L'obligation TPM de Windows est autant une décision **commerciale et stratégique** qu'une mesure de sécurité, comme le montre sa contournabilité largement documentée ;
|
||||
- Le TPM lui-même a des limites, des vulnérabilités, et ne protège pas des classes entières de menaces.
|
||||
|
||||
L'absence d'obligation est donc un **choix philosophique** (laisser le contrôle à l'utilisateur), pas une lacune technique. Et dans la pratique, un utilisateur Linux soucieux de sécurité activera très probablement le TPM s'il est disponible — sans y être contraint, ce qui est précisément la différence culturelle entre les deux écosystèmes.
|
||||
|
||||
---
|
||||
|
||||
## Conclusion
|
||||
|
||||
Le débat TPM 2.0 illustre parfaitement deux conceptions opposées de la sécurité informatique :
|
||||
|
||||
- **Le modèle Microsoft** : imposer un socle uniforme, quitte à exclure du matériel ancien, en partant du principe que l'utilisateur ne configurera rien lui-même.
|
||||
- **Le modèle Linux** : fournir un éventail d'outils puissants, laisser l'administrateur décider, et faire confiance à sa compétence (ou à celle de la distribution qui pré-configure pour lui).
|
||||
|
||||
Aucun des deux modèles n'est intrinsèquement supérieur — ils répondent à des publics, des usages et des philosophies différents. Mais affirmer que l'un est "non sécurisé" parce qu'il ne reproduit pas l'obligation matérielle de l'autre reviendrait à confondre **conformité à une norme commerciale** avec **niveau réel de sécurité**. Ce sont deux choses très distinctes.
|
||||
|
||||
Linux n'a rien à prouver sur ce terrain. Il sécurise depuis vingt-cinq ans la majorité de l'Internet mondial, sans avoir jamais eu besoin d'imposer la moindre puce à ses utilisateurs.
|
||||
|
||||
---
|
||||
|
||||
### Pour approfondir
|
||||
|
||||
- *Fedora Magazine* — [Automatically decrypt your disk using TPM2](https://fedoramagazine.org/automatically-decrypt-your-disk-using-tpm2/)
|
||||
- Documentation `systemd-cryptenroll`, `tpm2-tools`, projet Clevis
|
||||
- *Trusted Computing Group* — spécifications TPM 2.0
|
||||
- Articles de recherche sur TPM-Fail, ROCA, attaques par *bus sniffing*
|
||||
- Documentation officielle Microsoft sur les exigences Windows 11
|
||||
- *The Linux Documentation Project* — sections sur LUKS, SELinux, AppArmor
|
||||
@@ -7,7 +7,7 @@
|
||||
"featured": false,
|
||||
"published_at": "2023-02-28 13:42",
|
||||
"created_at": "2023-02-28 13:42:55",
|
||||
"updated_at": "2026-05-16 22:09:06",
|
||||
"updated_at": "2026-05-17 06:20:07",
|
||||
"revisions": [
|
||||
{
|
||||
"n": 1,
|
||||
@@ -21,7 +21,7 @@
|
||||
"external_links": [],
|
||||
"seo_title": "",
|
||||
"seo_description": "",
|
||||
"og_image": "",
|
||||
"og_image": "https://www.abonnel.fr/file?uuid=575cb5b1-9a12-4915-8839-2d5f2e9c86b9&name=cover.svg",
|
||||
"category": "Informatique",
|
||||
"tags": []
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user