La sécurité moderne repose sur un paradoxe rarement formulé explicitement : chaque couche de protection que vous ajoutez déplace la confiance vers un acteur que vous ne contrôlez pas, sans l'éliminer. Comprendre ce déplacement est une condition préalable à tout raisonnement honnête sur la confidentialité.
Le mythe de la chaîne sans maillon faible
Un ingénieur qui conçoit un système sécurisé pense naturellement en couches : chiffrement de bout en bout, authentification forte, stockage sécurisé des clés, intégrité du boot. Chaque couche est auditée, documentée, justifiée. Le résultat final donne une impression de forteresse. C'est précisément cette impression qui est dangereuse.
La confidentialité absolue exigerait une propriété que l'informatique n'a jamais atteinte : être maître de l'intégralité de la chaîne de traitement, du silicium jusqu'à l'application. En pratique, cette chaîne comporte au minimum un processeur dont vous ne contrôlez pas le microcode, un compilateur dont vous ne pouvez pas vérifier l'intégrité à chaque build, et un ou plusieurs composants matériels dont le firmware est propriétaire. La sécurité réelle n'est pas l'absence de tiers de confiance ; c'est un choix raisonné sur la nature et la position de ces tiers dans votre modèle de menace.
Trois points illustrent ce déplacement de façon concrète et vérifiable.
Le TPM scelle vos secrets dans une boîte noire que vous ne pouvez pas ouvrir
Le Trusted Platform Module est devenu la pierre angulaire du stockage sécurisé de clés sur les architectures modernes. Son principe est solide : une puce dédiée, isolée du processeur principal, capable de générer des clés non extractibles et de conditionner leur usage à l'état mesuré du système via les PCR (Platform Configuration Registers). Ubuntu Core l'utilise explicitement pour sceller les clés LUKS2 directement au boot dans le TPM, si les empreintes du firmware, du bootloader et du noyau correspondent à l'état enregistré, la clé est restituée automatiquement. Sinon, le disque reste chiffré sans recours.
C'est élégant. C'est aussi une délégation totale de confiance au fabricant de la puce.
En 2017, une vulnérabilité critique baptisée ROCA (Return of Coppersmith's Attack, CVE-2017-15361) a été découverte dans les TPM Infineon. La bibliothèque de génération de clés RSA embarquée dans le firmware produisait des clés dont les facteurs premiers suivaient un pattern réductible, ramenant la complexité de factorisation de RSA-2048 à un niveau pratiquement attaquable. Des millions de puces déployées sur des laptops, des cartes à puce et des tokens d'authentification étaient concernées. La faille résidait dans du code fermé, non auditable, sur une puce certifiée Common Criteria EAL4+. La certification n'avait pas détecté le problème.
La correction a nécessité une mise à jour firmware, distribuée par les fabricants de laptops, pas directement par Infineon, avec des délais variables selon les constructeurs. Pendant cette fenêtre, tout système reposant sur la non-extractibilité des clés RSA générées par ces TPM avait une garantie de sécurité qui ne valait rien.
Ce n'est pas un argument contre le TPM. C'est un argument contre l'illusion que le TPM élimine la dépendance à un tiers. Il la concentre. Vous avez remplacé la faiblesse diffuse d'un mot de passe humain par une dépendance précise à Infineon, STMicroelectronics, Nuvoton, ou AMD selon votre matériel, sont des entreprises soumises à des juridictions, des contraintes légales, et des impératifs commerciaux que vous ne maîtrisez pas. AMD fTPM et Intel PTT sont des implémentations firmware intégrées directement dans le processeur principal : la frontière entre "puce dédiée isolée" et "code tournant sur le CPU principal" devient floue.
Le projet OpenTitan de Google est la réponse structurellement cohérente à ce problème : un root-of-trust dont la conception matérielle et le firmware sont publics et auditables. Il est disponible sur certains Chromebooks récents. Pour le reste du marché, la situation n'a pas fondamentalement changé.
Le chiffrement de bout en bout ne chiffre que ce que l'application veut bien ne pas voir
Signal est l'implémentation de référence du chiffrement de bout en bout pour la messagerie. Le protocole Signal (Double Ratchet + X3DH) est public, audité, formellement vérifié par des cryptographes indépendants. Les propriétés cryptographiques sont réelles : confidentialité persistante, authentification, protection contre la compromission de clés à long terme.
La confusion fréquente est de confondre les propriétés du protocole avec les propriétés de l'application.
Le chiffrement de bout en bout protège le contenu des messages en transit entre deux clients. Il ne dit rien sur ce que le client fait du contenu une fois déchiffré. Sur Android, l'application Signal tourne dans un processus qui peut être soumis à une extraction mémoire par le système d'exploitation si celui-ci est compromis. Les sauvegardes chiffrées de Signal sur Google Drive utilisent une clé dérivée du PIN utilisateur, stockée dans un HSM géré par Signal — vous faites confiance à Signal pour ne pas avoir accès à ce HSM de façon exploitable. Les métadonnées (qui contacte qui, à quelle fréquence) ne sont pas chiffrées de la même façon que le contenu, et Signal en collecte un minimum mais en collecte tout de même.
Un exemple plus direct : WhatsApp implémente le protocole Signal pour le chiffrement des messages. Les métadonnées de contact et de fréquence d'usage remontent à Meta. Le chiffrement est réel. La confidentialité vis-à-vis de Meta ne l'est pas. Ce n'est pas une faille technique — c'est un choix de conception délibéré, mais il illustre précisément le point : le protocole cryptographique et l'application sont deux objets distincts, avec des modèles de confiance distincts.
TerminalPhone, le projet Bash de communication chiffrée sur Tor que nous évoquions en introduction, pousse ce raisonnement à son terme logique : pas de serveur tiers, pas de compte, pas de métadonnées centralisées, adresse .onion comme seule identité. Le modèle de confiance est réduit au minimum — Tor Project, OpenSSL, et l'OS sous-jacent. C'est cohérent. C'est aussi le signe que réduire la surface de confiance exige des compromis d'ergonomie que peu d'utilisateurs sont prêts à accepter.
Le compilateur que vous n'avez pas audité compile le code que vous avez audité
En 1984, Ken Thompson publie "Reflections on Trusting Trust", un texte qui reste l'une des contributions les plus dérangeantes de l'histoire de l'informatique. La démonstration : il est possible d'injecter un cheval de Troie dans un compilateur de façon à ce que le binaire produit soit compromis, même si le code source est parfaitement propre. Le compilateur modifié se réinjecte lui-même lors de sa propre recompilation. La lecture du code source ne révèle rien. Seule l'analyse du binaire produit permet de détecter l'anomalie.
Ce n'est pas un exercice académique daté. La chaîne de compilation d'un système moderne implique : un compilateur (GCC, Clang/LLVM) dont vous n'avez pas compilé vous-même chaque version depuis les sources originales, des bibliothèques système (glibc, OpenSSL) dont les binaires de distribution sont produits par des tiers, un noyau dont le processus de build est maîtrisé par les équipes de la distribution, et un firmware UEFI dont le code source n'est que partiellement disponible (EDK2 est open source, les blobs des fabricants ne le sont pas).
L'attaque SolarWinds de 2020 a matérialisé exactement cette menace à grande échelle : la chaîne de build de SolarWinds Orion a été compromise, produisant des binaires signés avec le certificat légitime de l'entreprise mais contenant une backdoor. Des milliers d'organisations ont installé ce logiciel après avoir vérifié la signature — correcte. L'audit du code source n'aurait rien révélé, puisque la modification avait lieu lors du build.
La réponse technique à ce problème s'appelle le build reproductible (reproducible builds) : un processus de compilation déterministe tel que, à partir des mêmes sources et du même environnement, n'importe qui obtient bit-pour-bit le même binaire. Debian mène ce projet depuis 2013. Bitcoin Core l'a adopté. La couverture reste partielle sur l'ensemble de l'écosystème. Et même avec des builds reproductibles, la confiance dans le compilateur de bootstrap reste nécessaire — Thompson's Trusting Trust ne disparaît pas, il est repoussé d'un niveau.
Ce que cette analyse implique pour la conception
La confidentialité n'est pas une propriété binaire. C'est une fonction de votre modèle de menace, de la position de vos tiers de confiance dans la chaîne, et de la probabilité que ces tiers soient compromis ou contraints dans votre contexte opérationnel.
Un ingénieur qui conçoit un système réellement sensible doit cartographier explicitement ses tiers de confiance : fabricant du TPM, autorité de certification, compilateur de bootstrap, fournisseur de distribution, prestataire cloud si applicable. Pour chaque tiers, la question n'est pas "est-il de confiance ?" mais "quel est le coût d'une compromission de ce tiers, et est-ce que mon modèle de menace inclut un adversaire capable de le compromettre ou de le contraindre ?".
Pour un modèle de menace standard (protection contre un attaquant opportuniste, conformité réglementaire, protection des données utilisateurs), TPM + LUKS2 + protocole audité est un choix raisonnable et défendable. Pour un modèle de menace étatique ou haute valeur, chaque tiers de la liste précédente est un vecteur potentiel, et les réponses appropriées (OpenTitan, reproducible builds, air gap, passphrase manuelle en lieu et place du scellement TPM) représentent des contraintes opérationnelles significatives que peu de systèmes assument pleinement.
La confidentialité absolue n'existe pas en dehors d'un système dont vous maîtrisez l'intégralité de la chaîne, du silicium à l'application. Cette maîtrise est un horizon, pas un état atteignable dans des conditions de production réelles. La rigueur consiste à savoir précisément où vous avez placé vos tiers de confiance, pourquoi, et ce que vous perdez si l'un d'eux est compromis.
Références techniques : CVE-2017-15361 (ROCA, Infineon TPM) — K. Thompson, "Reflections on Trusting Trust", CACM 1984 — Reproducible Builds project, reproducible-builds.org — Google OpenTitan, opentitan.org — NIST SP 800-155 (BIOS integrity measurement) — SolarWinds supply chain attack, CISA Advisory AA20-352A.
