Architecture de surveillance iranienne et crise de suivi Telegram : exposition de auth_key_id et guide de défense
Corriger mtproto ne fonctionne pas · Mauvaises orthographes mtrproto, mtporoto, мтпрото

En Iran, au moment où vous ouvrez une discussion Telegram, votre appareil a déjà remis sa carte d'identité au système de surveillance.

Ce n'est pas alarmiste – cela découle d'une caractéristique de conception du protocole de chiffrement MTProto de Telegram appelée "auth_key_id" (identifiant de clé d'autorisation). En mai 2026, un rapport d'évaluation technique publié par la société indépendante de cybersécurité Symbolic Software a confirmé que les clients Telegram transmettent les messages MTProto sur des connexions TCP non chiffrées, exposant ainsi auth_key_id en clair dans le trafic réseau. Toute entité ayant un accès passif au réseau peut facilement extraire cet identifiant. Si vous rencontrez mtproto ne fonctionne pas, cette exposition peut également être liée à l'empreinte DPI.

Cet article combine l'architecture de surveillance unique de l'Iran pour analyser les risques spécifiques de l'exposition de auth_key_id, évalue l'efficacité des différents VPN et proxys, et fournit enfin un plan de défense pratique pour les utilisateurs.

I. Architecture de surveillance systématique de l'Iran : de Shahkar à SIAM

L'avantage central du système de surveillance iranien réside dans son intégration entre la couche réseau, la couche réseau mobile et la couche d'authentification d'identité. Même si vous vous connectez avec succès à un serveur proxy, le système de surveillance peut toujours vous identifier, vous et votre appareil, par plusieurs moyens, et l'exposition de auth_key_id de Telegram fournit à ces systèmes un identifiant supplémentaire et précis.

1. Réseau d'information national et système d'interception légale (LIS)

L'Iran a construit le Réseau d'information national (NIN), qui sépare l'internet domestique de l'internet international. Les autorités sont passées d'un modèle de blocage par "liste noire" à un modèle de "liste blanche", utilisant les bases de données SHAHKAR et HAMTA pour suivre les pièces d'identité et les appareils des utilisateurs, coupant facilement l'accès du public à l'internet international tout en réservant un accès privilégié à certains groupes.

Sur cette architecture, l'Autorité de régulation des communications iranienne, en coopération avec le plus grand opérateur national, a établi le système d'interception légale (LIS), qui comprend principalement quatre sous-systèmes : Interception légale (LI), Contrôle des appareils illégaux (CID), système SHAHKAR et système SHAMSA. Parmi eux :

• Système SHAHKAR : Base de données d'authentification centrale stockant les informations de tous les utilisateurs mobiles. L'enregistrement de la carte SIM nécessite un enregistrement biométrique et la carte d'identité nationale. Le système vérifie si l'utilisateur utilisant une adresse IP ou un numéro de téléphone spécifique est une personne réelle.
• Système SIAM : Système informatique capable de manipuler à distance les connexions mobiles, fournissant aux opérateurs environ 40 fonctions pour modifier, perturber et surveiller l'utilisation du téléphone, y compris la rétrogradation forcée vers des réseaux 2G non sécurisés, la localisation, la collecte de métadonnées, etc.
• Inspection approfondie des paquets (DPI) : Le système de surveillance peut analyser le contenu des paquets et les caractéristiques du trafic, identifiant les signatures des protocoles VPN, les schémas de chiffrement anormaux, les ports non standard et les adresses IP pointant vers des centres de données.

2. Fonctionnement de la chaîne de surveillance

Une fois que votre appareil génère du trafic, le système de surveillance collecte des informations provenant de plusieurs couches : les dispositifs DPI analysent le trafic réseau en temps réel, identifient les protocoles et extraient les métadonnées ; le système SIAM peut obtenir les numéros de téléphone et l'IMSI depuis la couche réseau mobile ; la base de données SHAHKAR lie les cartes SIM aux identités réelles. Lorsque ces systèmes s'associent à auth_key_id, une chaîne d'ancrage d'identité complète est formée. La partie la plus effrayante du système iranien n'est pas ses capacités techniques individuelles, mais cette architecture intégrée cross-couches : Shahkar relie les SIM aux identifiants nationaux, SIAM peut manipuler les appareils, HAMTA enregistre les modèles d'appareils – combinés, auth_key_id devient la clé finale pour ouvrir cette porte.

II. Exposition de auth_key_id : la clé finale de la chaîne de surveillance

1. Qu'est-ce que auth_key_id ?

auth_key_id est un identifiant 64 bits du protocole MTProto. Lorsqu'un client Telegram se connecte pour la première fois à un appareil, il génère une clé d'autorisation de 2048 bits (auth_key) via l'échange de clés Diffie-Hellman, et auth_key_id est le hachage SHA-1 des 64 bits de poids faible de cette clé. Il se trouve tout au début de l'en-tête externe MTProto dans chaque transmission de message, indiquant au serveur "quelle clé utiliser pour déchiffrer le contenu suivant".

2. Gravité de l'exposition

L'évaluation technique de Symbolic Software confirme : auth_key_id reste inchangé d'une session à l'autre, après un changement d'IP, de réseau ou de zone géographique, ce qui en fait un outil puissant pour les observateurs réseau passifs afin de suivre un seul appareil à long terme. Tout intermédiaire réseau – FAI, administrateur réseau, système de surveillance gouvernemental – peut collecter les valeurs auth_key_id via une surveillance réseau passive, sans attaque de l'homme du milieu, ni cassage de certificat, ni manipulation de protocole. Une simple capture de paquets et désobfuscation suffit.

3. Voies d'abus dans le système de surveillance iranien

Face au système de surveillance multicouche iranien, auth_key_id est exposé à plusieurs risques. Que vous utilisiez une connexion directe ou un VPN, il peut fuir à plusieurs nœuds clés :

Couche de surveillance	Mécanisme technique	Risque d'exposition
Couche réseau (DPI)	Le FAI analyse les paquets via des dispositifs DPI	Même si le VPN chiffre le contenu, auth_key_id en tant qu'identifiant de couche application peut être extrait ; si Telegram utilise TCP non chiffré, il est complètement exposé. Cela cause souvent mtproto ne fonctionne pas lorsque le DPI perturbe les handshakes.
Couche réseau mobile (SIAM)	SIAM peut forcer la rétrogradation vers 2G non sécurisé, collecter des métadonnées	Enregistre auth_key_id et le lie à l'IMSI/numéro de téléphone, ancrant précisément l'identité à un appareil personnel.
Couche identité (Shahkar)	Carte SIM liée à l'identifiant national, peut cibler des numéros spécifiques	Si une connexion (ex. WiFi d'hôtel avec authentification) associe auth_key_id à votre identité réelle, le système de surveillance peut utiliser Shahkar pour retracer tous vos enregistrements de connexion auth_key_id passés.
Couche physique (capteur IMSI)	Déploie de fausses stations de base sur les lieux de manifestation	Capture l'IMSI du téléphone, le modèle d'appareil et auth_key_id simultanément, formant un profil d'identité complet de l'appareil.
Rétrospection passive	Les opérateurs conservent des journaux à long terme	Une fois qu'un ancrage identitaire lie auth_key_id, le système de surveillance peut rechercher dans les journaux historiques pour reconstruire les schémas de communication et les traces comportementales sur des mois ou des années.

4. Nature du risque

Le risque de l'exposition de auth_key_id réside dans sa persistance et sa capacité de liaison. Ce n'est pas un marqueur temporaire de session, mais un identifiant fixe lié à la clé d'autorisation à long terme de l'appareil. Si une seule connexion (par exemple l'enregistrement sur le WiFi d'un hôtel) associe votre auth_key_id à votre identité réelle, le système de surveillance peut utiliser cet "ancrage" pour rechercher tous les journaux de trafic historiques – vos enregistrements de communication des derniers mois sur différents réseaux pourraient être retracés d'un coup, même si vous utilisiez un VPN ou changiez de réseau à ce moment-là.

III. Évaluation des VPN et proxys en Iran (y compris les correctifs pour mtproto ne fonctionne pas)

1. VPN traditionnels : systématiquement bloqués

• OpenVPN : Empreintes protocolaires pleinement reconnues par les systèmes DPI, bloqué en Iran depuis des années, taux de détection proche de 100%.
• WireGuard : Le processus d'handshake a une structure fixe, les systèmes DPI iraniens ont été entraînés à le reconnaître. Un nouveau serveur WireGuard est typiquement identifié et bloqué en quelques heures. L'ajout de couches d'obfuscation n'apporte qu'une amélioration de courte durée, car l'obfuscation elle-même forme progressivement une empreinte classifiable par le système.
• IPSec/L2TP : Pratiquement "morts" en Iran, également massivement bloqués en raison d'empreintes protocolaires évidentes.

Conclusion : Compter sur ces protocoles pour monter soi-même des serveurs VPN n'est plus une solution durable.

2. Shadowsocks : légèrement meilleur que les VPN traditionnels, mais pas à long terme

Shadowsocks a été créé par des développeurs chinois pour contourner le "Grand Pare-feu", en utilisant des méthodes d'obfuscation non standard. Les systèmes DPI ne peuvent pas clairement classer son trafic comme proxy/VPN, ce qui lui confère un avantage relatif dans l'environnement de censure iranien. Mais Shadowsocks n'est pas une panacée. Il ne simule pas de fonctionnalités avancées comme les handshakes TLS, et après une utilisation prolongée, ses schémas de trafic peuvent être classés et reconnus par des systèmes d'apprentissage automatique.

3. VLESS + Reality : la technologie anti-censure actuellement la plus robuste

Le protocole VLESS est conçu spécifiquement pour échapper à la détection DPI, en encapsulant les informations de routage dans du TLS standard, rendant le trafic généré au niveau des paquets indiscernable des connexions HTTPS ordinaires. Avec la technologie de transport REALITY, il peut emprunter les certificats TLS de sites web légitimes pour masquer la vraie cible. Les systèmes de sondage actif iraniens, lorsqu'ils sondent un serveur VLESS+Reality, reçoivent la même réponse qu'un site web authentique, et le serveur ne révèle pas sa fonction proxy. Les opérateurs qui configurent correctement des serveurs VLESS à l'intérieur de l'Iran rapportent des taux de détection inférieurs à 5%. Un serveur qui serait bloqué en quelques jours sous WireGuard peut fonctionner pendant des mois avec une configuration VLESS+Reality correcte.

4. Proxy MTProto : conçu spécifiquement pour Telegram (et mtproto ne fonctionne pas)

Le proxy MTProto est conçu spécifiquement pour Telegram et ne fonctionne que pour Telegram ; il ne peut pas proxifier le trafic du navigateur ou d'autres applications. Dans l'environnement de censure de 2026, seuls les proxys MTProto de troisième génération commençant par "ee" (activant Fake TLS) restent efficaces. Si vous rencontrez mtproto ne fonctionne pas, passer à MTG 2.2.8 ou utiliser un proxy dédié comme celui de TGV résout souvent le problème.

Cependant, même les proxys MTProto Fake TLS ne peuvent pas cacher auth_key_id. Les clients Telegram utilisent du TCP non chiffré au niveau transport, et l'exposition de auth_key_id est un problème fondamental de conception du protocole – peu importe à quel point le proxy obfusque, auth_key_id est exposé aux nœuds intermédiaires du réseau avant d'atteindre le serveur proxy. Le 1er avril 2026, plusieurs FAI russes ont commencé à identifier sélectivement les handshakes Telegram MTProto/FakeTLS via l'analyse d'empreintes TLS, provoquant des échecs généralisés de mtproto ne fonctionne pas, tandis que les services VLESS Reality sur les mêmes serveurs continuaient à fonctionner normalement.

IV. Solutions réalisables : stratégie de défense multicouche

Face à la surveillance globale de l'Iran, aucun outil unique ne suffit à garantir une sécurité absolue. Vous avez besoin d'une stratégie de défense à plusieurs niveaux.

Couche	Stratégie	Points de mise en œuvre
Couche 1 : Proxy anti-censure	Utiliser le protocole VLESS + Reality	Déployer avec Xray-core ou Sing-box, choisir un domaine de masquage approprié (ex. api.github.com, update.microsoft.com), activer REALITY, de préférence avec routage décentralisé P2P.
Couche 2 : Canal dédié à Telegram	Proxy MTProto 3e génération (Fake TLS)	Utiliser secret préfixé ee, port 443, avec un domaine de masquage réputé ; comme canal d'entrée Telegram. Remarque : le proxy MTProto ne fonctionne que pour Telegram et ne résout pas l'exposition de auth_key_id.
Couche 3 : Réinitialisation périodique de auth_key_id	Réinitialiser régulièrement la clé d'autorisation, stopper le suivi à long terme (obligatoire et central)	Plus complet : Aller dans Paramètres Telegram → Appareils, terminer toutes les sessions suspectes ; utiliser la déconnexion puis reconnexion officielle pour générer un tout nouveau auth_key_id. L'utilisation de PFS ne peut pas empêcher l'exposition de l'identifiant mais peut limiter la période de traçabilité. Effectuer une réinitialisation tous les 1-3 mois réduit considérablement le risque de suivi à long terme.
Couche 4 : Isolement d'identité	Séparer strictement l'identité réelle des communications sensibles	Ne pas utiliser le même compte Telegram pour des activités sensibles sur des réseaux authentifiés (WiFi d'hôtel, réseau d'entreprise). Pour les communications sensibles, utiliser Tor ou un tunnel VPS de confiance à l'étranger. Éviter d'enregistrer des comptes sensibles avec des numéros de téléphone liés à la SIM.
Couche 5 : Chaîne VPN/Proxy multi-niveaux	Combiner les protocoles anti-censure	Faire passer le trafic Telegram d'abord par un proxy MTProto (ee Fake TLS) puis l'envelopper dans un tunnel VLESS, de sorte que auth_key_id soit protégé par plusieurs couches de chiffrement pendant toute la transmission.
Couche 6 : Réseau P2P décentralisé	Éviter la dépendance à un point unique	Utiliser un réseau P2P décentralisé empêche une interruption complète du service si une seule IP est bloquée.

V. Guide pratique d'utilisation

1. Réinitialiser activement auth_key_id (étape centrale)

Comme la persistance de auth_key_id est le plus grand risque, sa réinitialisation périodique est le moyen le plus efficace de briser le suivi à long terme.

• Se déconnecter puis se reconnecter dans l'application : Paramètres → Modifier le profil (iOS) ou toucher l'avatar du compte (Android), choisir "Se déconnecter". C'est le moyen le plus direct de déclencher la réinitialisation de auth_key.
• Déconnecter à distance les appareils suspects : Sur un appareil de confiance, aller dans Paramètres → Appareils, sélectionner et terminer les sessions qui ne sont pas sous votre contrôle, invalidant immédiatement auth_key sur ces appareils.

2. Déployer un proxy anti-censure

Il est recommandé de déployer le protocole VLESS + Reality sur un VPS. En utilisant Xray comme exemple, étapes succinctes :

• Installer Xray-core : bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install
• Générer la paire de clés Reality : xray x25519
• Configurer config.json, choisir un domaine de masquage de confiance (recommandé domaines Microsoft ou GitHub), éviter les domaines de masquage courants déjà signalés par les systèmes de surveillance.
• Importer la configuration sur le client (v2rayNG, Nekoray, etc.) et utiliser les options d'empreinte chrome ou safari.

3. Construire un canal dédié à Telegram

• Obtenir des nœuds proxy MTProto de troisième génération utilisables (format tg://proxy?secret=ee...). TGV les fournit à ses utilisateurs payants.
• Ouvrir Paramètres Telegram → Données et stockage → Paramètres proxy → Ajouter un proxy, sélectionner le type MTProto, remplir les détails du proxy.
• Rappel important : Le proxy MTProto est uniquement pour "l'accessibilité de connexion" de Telegram ; il ne résout pas l'exposition de auth_key_id. Vous devez toujours réinitialiser périodiquement auth_key_id.

VI. Résumé et recommandations

Sous l'architecture de surveillance actuelle de l'Iran, l'exposition de auth_key_id constitue un risque de confidentialité important et persistant. Conclusions clés :

• La menace de surveillance est globale. Les systèmes DPI, SIAM et Shahkar coopèrent, et l'exposition de auth_keyId superposée crée une capacité de suivi à long terme des appareils de haute précision.
• Les VPN traditionnels échouent. En 2026, OpenVPN et WireGuard ne peuvent plus fonctionner de manière stable à long terme en Iran ; le système de censure se modernise globalement.
• Les technologies actuellement efficaces sont VLESS+Reality et les proxys MTProto de troisième génération. Mais les proxys MTProto ne peuvent pas résoudre le problème fondamental de l'exposition de auth_key_id. Si vous voyez mtproto ne fonctionne pas, envisagez de passer à VLESS+Reality ou de mettre à niveau votre proxy MTProto vers MTG 2.2.8.
• La réinitialisation active et périodique de auth_key_id est obligatoire. Les utilisateurs devraient prendre l'habitude de "se déconnecter → se reconnecter" tous les 1 à 3 mois pour briser la chaîne de suivi à long terme.
• Une stratégie de défense multicouche est essentielle. En Iran, vous ne pouvez pas compter sur un seul outil ; vous devez utiliser globalement des proxys anti-censure, des réinitialisations périodiques de clés et un isolement d'identité pour construire une protection à plusieurs niveaux.
• Le jeu du chat et de la souris continue. Restez vigilant et maintenez vos méthodes de défense à jour – c'est la meilleure façon de protéger votre sécurité et votre vie privée.