Chiffrement externe et clés partagées — L'approche de souveraineté de l'utilisateurChiffrement externe et clés partagées — L'approche de souveraineté de l'utilisateur

Si la porte que t'offre la plateforme a une copie de la clé pour le gardien, construis ta propre porte. Mais souviens-toi : le gardien peut exiger qu'on abatte toutes les portes qu'il ne peut pas ouvrir.

---

Il y a une approche qui surgit fréquemment lorsqu'on discute de Chat Control avec des personnes techniquement informées : et si les utilisateurs chiffraient leurs messages avec des clés qu'ils gèrent eux-mêmes, en dehors du contrôle de la plateforme ?

L'idée est simple et puissante. Au lieu de faire confiance au chiffrement offert par la plateforme (que la loi pourrait obliger à affaiblir), les utilisateurs conviennent d'une clé par un canal externe et chiffrent le contenu avant que la plateforme n'y touche.

Le schéma

Canal externe :   A —————————[k_AB]——————————→ B
                  (accord de clé en face à face, Signal, courriel chiffré, papier)

                  A écrit M
                  A chiffre M avec k_AB → C = E_k_AB(M)
                  A envoie C via la plateforme
                  B reçoit C
                  B déchiffre C avec k_AB → M

                  La plateforme ne voit que C (données inintelligibles)

Dans ce schéma :

• La plateforme reçoit $C$, qui de son point de vue est du bruit indistinguable de données aléatoires
• La plateforme ne peut pas analyser le contenu car mathématiquement elle n'a pas accès à $k_{AB}$
• Le CSAR ne peut pas obliger la plateforme à déchiffrer ce qu'elle ne peut pas déchiffrer
• A et B gardent un contrôle total sur leur communication

Ce que cette approche résout

Ce qu'elle ne résout pas

1. Le problème de la détection par haute entropie

Un message chiffré avec un schéma robuste produit des données statistiquement indistinguables de bruit aléatoire. Une plateforme qui connaît le format attendu de ses messages (par exemple, JSON avec des champs structurés) peut facilement détecter qu'un message ne suit pas ce format :

Payload normal de WhatsApp :
    {"key": {"remoteJid":"...","fromMe":true},"message":{"conversation":"Bonjour"}}
    Entropie : ~4,2 bits/octet

Payload chiffré extérieurement :
    <7e9f2b8a1c4d...  (octets apparemment aléatoires)
    Entropie : ~7,9 bits/octet → détectable

Si la loi oblige la plateforme à bloquer les messages non analysables, ce simple détecteur d'entropie suffirait à identifier et bloquer ces messages.

2. Le problème du canal externe

Le maillon le plus faible du schéma est l'échange initial de clés :

Comment A et B conviennent-ils de k_AB sans utiliser la plateforme ?
    ├→ Face à face :        Sûr, mais ne passe pas à l'échelle
    ├→ Signal :             Sûr, mais nécessite que les deux utilisent Signal
    ├→ Courriel chiffré :   Faisable, mais inconfortable
    ├→ WhatsApp même :      La plateforme peut l'intercepter
    └→ Papier/Code QR :     Sûr, mais peu pratique pour des contacts fréquents

Pour que l'approche fonctionne avec des contacts non techniques, l'échange de clés devrait se faire via la plateforme elle-même, ce qui réintroduit le problème : si la plateforme peut voir la clé, le chiffrement externe est inutile.

3. Le problème de la loi qui ferme la faille

C'est le point critique que l'analyse technique pure tend à négliger. Une loi comme CSAR ne se limite pas à dire "les plateformes doivent analyser". Elle peut (et inclurait probablement) des dispositions comme :

Article X : Les fournisseurs devront s'assurer que tous les messages
transmis via leur infrastructure soient susceptibles de
détection conformément aux Articles Y-Z. La transmission de
contenu qui, par son format ou ses caractéristiques techniques,
empêche l'application des mesures de détection obligatoires est interdite.

Dans ce scénario, la plateforme serait obligée de :

1. Détecter les messages à entropie anormalement élevée
2. Bloquer leur transmission
3. Signaler l'utilisateur comme "suspect de contournement"

Comparaison avec d'autres approches

Le problème de la masse critique

Le chiffrement externe avec clés partagées fonctionne parfaitement comme mesure artisanale pour un utilisateur technique qui :

• Sait générer et gérer des clés
• A des contacts qui savent aussi le faire
• Accepte la friction du processus

Mais il ne fonctionne pas comme solution systémique pour 500 millions d'Européens. La raison n'est pas technique mais structurelle : une loi qui exige l'analyse sur la plateforme interdira ou bloquera tout simplement le trafic qui ne peut pas être analysé, et l'immense majorité des utilisateurs n'aura ni les connaissances ni la motivation pour adopter un système de chiffrement externe.

Pyramide des utilisateurs :
    ▲  ~0,1 %  Techniciens avancés (chiffrement externe possible)
    ├  ~1 %    Techniciens moyens (possible avec effort)
    ├  ~10 %   Utilisateurs avertis (pas viable sans outil)
    ▼  ~90 %   Utilisateurs grand public (utilise ce que l'app offre)

Si la loi bloque le chiffrement externe, ~99,9 % des utilisateurs
n'auront pas de protection. Et les 0,1 % seront détectables comme
"utilisateur qui se protège", exactement le même paradoxe qu'Obscura
documente dans le contexte du fingerprinting.

Parallèle avec le paradoxe de la protection

Cette approche souffre de la même asymétrie que la recherche d'Obscura documente pour l'anti-fingerprinting :

Le défenseur doit gagner à chaque fois. L'attaquant n'a besoin de gagner qu'une seule fois.

Dans le contexte de Chat Control :

• L'utilisateur doit protéger tous ses messages de façon indistinguable
• La plateforme doit détecter une seule anomalie (un message à haute entropie, un motif de communication inhabituel) pour identifier l'utilisateur comme "suspect de contournement"
• Une fois identifié, l'utilisateur peut faire l'objet de mesures supplémentaires (blocage, signalement aux autorités, enquête)

L'analogie avec le fingerprinting est presque parfaite. Dans Obscura, le proxy devait normaliser tous les signaux pour ne pas être détecté ; ici, l'utilisateur doit faire en sorte que tous ses messages ressemblent à des messages normaux de la plateforme, ce qui est incompatible avec leur chiffrement externe.

Conclusion

Le chiffrement externe avec clés partagées est techniquement solide comme mesure de vie privée individuelle. Si A et B conviennent d'une clé en dehors de la plateforme et chiffrent leurs messages, la plateforme ne peut pas les lire, les analyser ni les signaler. Point.

Mais comme solution politique et systémique face à une loi comme CSAR, il a trois problèmes insolubles :

1. La loi fermera la faille en interdisant ou bloquant les messages non analysables
2. L'échange de clés réintroduit le problème pour la majorité des utilisateurs
3. L'asymétrie défenseur-attaquant rend l'utilisateur détectable comme "contourneur" même si son contenu est sécurisé

Ce n'est pas une approche erronée. C'est une approche qui fonctionne pour qui peut l'implémenter, mais qui ne peut pas être généralisée comme alternative à l'analyse massive. C'est la différence entre construire un abri antinucléaire pour ta famille et prétendre que toute l'humanité vive dans des abris antinucléaires.

---

Documents connexes :

• Alternatives à l'analyse massive
• Chiffrement et surveillance — Pourquoi l'analyse massive brise le E2EE
• Chat Control — Définition et contexte