Aujourd'hui, je voudrais parler des résultats de mes sept années de recherche dans le domaine de la transmission vocale via le réseau Tor. Il est généralement admis que la communication vocale via Tor est presque impossible:
- les protocoles de transport existants pour la téléphonie fonctionnent sur UDP, et Tor ne fournit que des connexions TCP;
- Tor achemine les paquets à travers plusieurs nœuds, chiffrant les données, ce qui provoque une latence importante et rend la téléphonie duplex impossible ou extrêmement inconfortable.
Mais est-ce vraiment le cas?
En 2012, j'ai d'abord pensé à la possibilité fondamentale de mettre en œuvre des communications téléphoniques anonymes en utilisant les anonymiseurs Tor et i2p. La réaction de la communauté a été clairement négative, y compris Phil Zimmermann lui-même, l'auteur du célèbre PGPFone, sur la base duquel a travaillé le premier Torfon. Mais j'étais têtu, j'ai testé de nouvelles idées, testé et amélioré des astuces trouvées, visant principalement à réduire la latence à un niveau acceptable. D'autres chercheurs ont également travaillé dans ce sens, et leurs publications m'ont donné de nouvelles idées et la base de futurs travaux. Les aspects positifs ont été l'accélération significative du réseau Internet mondial et du réseau Tor en particulier, ainsi que le sevrage progressif des utilisateurs du RTPC en faveur de la communication GSM avec sa latence significative inhérente. Enfin, un concept adapté a été développé et c'est au tour de mettre en œuvre le plan.
En 2013, Roger Dingledine dans sa correspondance personnelle a sévèrement critiqué le projet pour le manque de multiplateforme (à l'époque PGPFone était utilisé comme base sur une plate-forme Windows) et pour son architecture non modulaire. Dans le contexte de cette critique, les bases ont été jetées pour la mise en œuvre moderne de Torfon, en tenant compte de nombreux essais et erreurs, ainsi que des tendances modernes de la cryptographie.
Aujourd'hui, Torfon se compose de quatre modules logiciels qui interagissent les uns avec les autres à l'aide de paquets de 36 octets avec des champs strictement fixes. Il s'agit d'un module de transport qui fournit du travail avec des sockets, un module de cryptographie et de son, un module de stockage (effectue des opérations avec une clé privée et contient un carnet d'adresses crypté) et un module d'interface utilisateur. Ils peuvent être exécutés sur la même plate-forme matérielle (dans un ou dans des flux différents) ou sur plusieurs plates-formes isolées en utilisant un protocole série standard (matériel UART, USB CSD ou Bluetooth SPP) comme interface. Cette architecture permet au développeur de déterminer un compromis entre sécurité et facilité d'implémentation. Les options sont disponibles à partir d'une application Windows autonome jusqu'à l'implémentation matérielle sous la forme d'une carte unique avec Linux pour Tor et d'un module de transport en conjonction avec un microcontrôleur Cortex M4 isolé, qui crypte, traite et lit entièrement l'audio, stocke la clé privée et les contacts, et une interface utilisateur graphique est implémentée.
Le code source des modules est écrit en C et est entièrement multiplateforme, à l'exception du travail de bas niveau avec audio, réalisé dans des fichiers séparés spécifiques à Windows (Wave), Linux (Alsa), Android (OpenSL) et bare metal (ADC / DAC + DMA pour le microcontrôleur) )
Lors du choix d'un codec audio et d'une file d'attente, les caractéristiques du réseau Tor ont été prises en compte: des retards spontanés fréquents périodiques, une légère diminution de la latence pour les paquets dans une certaine plage de longueur, la possibilité de créer des chaînes en double avec différents chemins de routage pendant un appel, etc. Le projet intermédiaire OnionPhone comprenait 17 des codecs audio à faible débit binaire les plus courants. Après des tests minutieux, l'option la plus appropriée a été choisie: AMR avec un débit binaire minimum de 4750 bps et un VAD à haute vitesse. Ainsi, compte tenu des pauses naturelles entre les mots et de la nature duplex de la communication, le débit binaire moyen total dans chaque direction est d'environ 2000 à 3000 bps., Ce qui permet d'utiliser le GPRS même dans des conditions de faible couverture GSM et de perte massive de paquets GSM.
En tant que suppresseur de bruit, l'algorithme efficace NPP7 a été développé, qui a été développé pour lutter contre le bruit audio intense et fait partie du codec MELPe, la norme de communication militaire actuelle STANAG-4591. L'algorithme d'annulation d'écho a été sélectionné dans le projet WebRTC comme la solution ouverte la plus efficace disponible.
La fonctionnalité générale de Torfon a été développée en tenant compte des cas d'utilisation possibles et des modèles de menace existants qui étaient déjà utilisés contre les messageries instantanées populaires.
Modes de fonctionnement de base:
- Appels vocaux anonymes au service caché Tor (à l'adresse oignon). Ces appels sont protégés autant que possible, mais il y a un certain retard, ce qui peut gêner les utilisateurs non habitués.
- Passer à une connexion UDP directe (avec passe NAT) après avoir configuré une connexion Tor. Les clés de chiffrement de session négociées au sein de Tor offrent une forte confidentialité, mais l'anonymat est perdu (les utilisateurs se révèlent leur adresse IP).
- Appels directs vers l'adresse IP (ou le nom de domaine) et le numéro de port TCP spécifiés. Pour recevoir de tels appels, vous avez besoin d'une adresse IP «blanche» (routable) sur l'appareil (de nombreux opérateurs mobiles proposent cela en tant que service payant) ou d'une redirection du port TCP utilisé sur un routeur local (par exemple, dans un réseau WiFi domestique). Les appels directs peuvent être effectués dans un réseau local isolé (par exemple, un réseau Wi-Fi local créé à l'aide d'un puissant point d'accès installé au centre de la zone de service). Dans ce cas, Torfon ne nécessite pas d'interaction avec Internet: le projet n'a pas son propre serveur, ce qui est un point d'échec potentiel, d'attaque et de collecte de métadonnées. Ainsi, Torfon peut fonctionner avec succès même avec l'isolement complet du segment de réseau ou de l'ensemble du Runet au niveau de l'état.
Aujourd'hui, la question de la confiance en Tor se pose assez souvent à la fois en termes de maintien de l'anonymat et de confidentialité des données transmises. Le célèbre messager TorChat n'a pas utilisé son cryptage et son authentification, s'appuyant entièrement sur les services fournis par Tor. Personnellement, je fais confiance à Tor, au moins en termes de confidentialité et de parfait secret en arrière. Mais, malheureusement, cette position est éclipsée par la découverte de vulnérabilités mondiales SPECTRE / MELTDOWN, ainsi qu'une masse de vulnérabilités zero-day pour tous les systèmes d'exploitation connus qui sont pratiquement utilisés comme outils de travail dans l'arsenal de tout service spécial. Par conséquent, je n'ai pas pu suivre le chemin TorChat et j'ai ajouté ma propre couche de cryptage et d'authentification à Torfon, en utilisant les protocoles les plus modernes et les primitives cryptographiques les plus solides.
Le concept est basé sur la possibilité de passer des appels entre des abonnés non familiers, puis d'échanger automatiquement leurs clés publiques pour une authentification mutuelle lors des sessions de communication suivantes. Cette approche permet un certain déni en matière de présence d'une clé compromettante dans la liste de vos contacts: tout abonné, connaissant votre adresse oignon, peut passer un appel anonyme et vous transmettre immédiatement tout contact depuis son carnet d'adresses. Ce contact sera automatiquement ajouté à votre carnet d'adresses. Cependant, cette fonctionnalité peut être désactivée dans les paramètres, mais qui sait si vous l'aviez activée avant?
Une attention particulière est portée à la protection des identifiants des abonnés. Ainsi, l'appelant sait qui il appelle et doit lui indiquer son ID (clé). Mais seulement lui et personne d'autre! De plus, si la connexion est interceptée, y compris par un attaquant actif, et plus tard toutes les clés privées des participants sont divulguées, il n'y a aucun moyen d'établir (ou de sélectionner dans la liste des connus) les identifiants des participants dans chaque échantillon ou session interceptée dans le passé. En d'autres termes, la protection de l'ID des abonnés appelants et appelés avec une parfaite confidentialité inverse (PFS). Cela a été réalisé en modifiant le protocole Triple-DH (Diffie-Hellman triple, qui est également utilisé dans Signal) en ajoutant un protocole SPEKE parallèle, qui ne fournit aucune divulgation en ce qui concerne les authentificateurs explicites échangés entre les parties lors de l'échange de clés initial.
Le protocole utilisé dans Torfon a la propriété Denibility, lorsqu'après une session de communication terminée, la partie malveillante ne peut pas convaincre le juge que le contact a réellement eu lieu. Le déni à terme est également fourni lorsque la partie malveillante convient à l'avance avec le juge qu'il conduira la session et, une fois la session terminée, essaie de prouver qu'elle a eu lieu. Pleine déniabilité (Pleine déniabilité, lorsque la partie malveillante contacte le juge lors d'une session de communication), est en concurrence avec une propriété aussi importante que KCI - la stabilité (l'incapacité de se présenter à un autre abonné dont la clé privée est connue). Sur la base des réalités pratiques, la préférence était en faveur de la stabilité de KCI, en tant que propriété plus pratique, en particulier dans des conditions de relations non juridiques.
Parmi les capacités supplémentaires de s'authentifier mutuellement au premier contact (pour garantir l'authenticité de l'échange de clés), deux protocoles sont implémentés:
- Comparaison d'une courte empreinte digitale d'un secret partagé (SAS, similaire au protocole ZRTP). Pour bloquer l'attaque par empreinte digitale courte pendant le processus MitM, la validation dans la procédure Diffie-Hellman est utilisée. De plus, l'empreinte digitale du secret partagé est automatiquement incluse dans le nom du contact accepté dans cette session. Ainsi, lors de l'échange de contacts au cours d'une session, le début du nom du nouveau contact doit être le même pour les deux participants, ce qui peut être vérifié plus tard, par exemple, en personne. Et au fait, le contact reçu doit être renommé afin de permettre à Torfon de se représenter (sa carte d'identité) à ce contact.
- comparaison d'un secret préalablement convenu (mots, phrases). En OTR, le protocole Socialist-Millionaire remplit une fonction similaire. Peat utilise le même protocole SPEKE en termes de propriétés (sans aucune divulgation).
Dans le cas où les deux participants de la session ont des contacts (clés publiques) l'un de l'autre, si l'authentification est réussie et que Tor (appel à l'adresse oignon) est utilisé, alors la partie réceptrice fait un contre-appel en utilisant l'adresse oignon de la partie appelante à partir de son carnet d'adresses. Une fois la connexion établie, l'authentification mutuelle est effectuée sur le deuxième canal, confirmant l'adresse oignon de l'appelant. Une procédure similaire est utilisée par TorChat pour authentifier les chats, en utilisant l'adresse oignon du contact comme identifiant.
La connexion Tor parallèle se compose d'autres chaînes, qui sont avantageusement utilisées pour compenser les retards spontanés: les paquets vocaux sont envoyés aux deux canaux à la fois, le paquet reçu plus tôt est utilisé. De plus, des statistiques sur les retards dans les deux canaux sont conservées et si l'un des canaux est beaucoup plus lent, il est périodiquement reconnecté pendant une conversation. Cela réduit la latence globale de l'appel authentifié par rapport à un appel d'un abonné inconnu.
Comme le montre la triste pratique, il est aujourd'hui très important d'apprendre à l'application à se défendre contre d'éventuels verrous. Heureusement, Torfon n'a pas son propre serveur ou cloud, utilisant Tor à la place. Par conséquent, le blocage de Torfon n'est possible qu'en verrouillant Tor. Mais aujourd'hui, c'est aussi une réalité, et dans ce cas, il n'y aura que la possibilité de faire des appels directement à l'adresse IP et au port TCP. Dans le scénario le plus pessimiste, le grand frère tentera d'enseigner aux systèmes DPI (analyse approfondie des paquets) la détection du trafic entre deux Torfons dans un réseau p2p contrôlé. Par conséquent, des mesures supplémentaires ont été prises pour maximiser la dissimulation de ce trafic. Tout d'abord, le port d'écoute TCP peut être sélectionné manuellement et fait en fait partie de l'adresse de l'abonné. Deuxièmement, absolument tous les paquets (y compris les paquets sonores) au cours d'une session de communication (session TCP) n'ont pas de caractéristiques distinctives (champs constants ou incrémentiels, longueur, etc.) et ressemblent à des données aléatoires de longueur aléatoire pour un observateur externe . Troisièmement, pour mener un essai actif du protocole, une «preuve de travail» est requise comme protection contre une analyse massive des adresses et des ports pour la détection de la tourbe.
En fait, la connexion est établie par deux connexions TCP consécutives. Lors de la première connexion, les parties échangent des clés de session primaires sous forme de points sur la courbe elliptique X25519, exécutant le protocole Diffie-Hellman habituel. Étant donné que le format Montgomery de la représentation par points n'est pas un nombre aléatoire, la représentation Elligator2, complétée par des octets aléatoires, est utilisée. Après avoir supprimé le secret partagé, la première session est interrompue, et après une période de temps aléatoire (plusieurs secondes), la deuxième session est établie, toutes les données dans lesquelles est chiffrée avec une clé dérivée du secret partagé. De nouvelles clés de session sont générées et le protocole Diffie-Hellman est à nouveau exécuté, maintenant avec un commentaire. Les clés symétriques pour le chiffrement et le déchiffrement sont dérivées du secret obtenu. Le triple protocole Diffie-Hellman est ensuite exécuté en parallèle avec le protocole SPEKE pour protéger l'ID de l'appelant et l'authentification. En l'absence de clés dans le carnet d'adresses (contact inconnu) ou de toute divergence, tous les messages sont remplacés par des octets aléatoires., C'est-à-dire le protocole n'est pas interrompu pour empêcher la fuite des informations d'identité des participants.
Pour la mise en œuvre de ces protocoles, des codes source C soigneusement vérifiés de primitives cryptographiques sont utilisés, extraits de bibliothèques cryptographiques bien connues. Pour la vérification au stade du développement, des vecteurs de test bien connus ont été utilisés et après chaque lancement d'application, une vérification supplémentaire d'une implémentation spécifique du code exécutable (résultat de la compilation) est effectuée.
Pour la couche d'obscurcissement, l'algorithme symétrique Serpent-128 a été sélectionné, fonctionnant en mode de cryptage OCB authentifié. Pour la couche de base du chiffrement symétrique, la transformation Keccak-800 en tant que fonction Shake-128 et un compteur de paquets CTR unidirectionnel sont utilisés. La même primitive est utilisée comme Hash, MAC et PKDF. L'algorithme ChaCha20 est utilisé pour crypter le carnet d'adresses et le générateur de nombres pseudo aléatoires. Le générateur est résident au début de chaque session, pour l'accumulation d'entropie dans les systèmes d'exploitation multitâche, l'algorithme Havege est utilisé, et dans le microcontrôleur, le bit de poids faible du résultat ADC, qui mesure le bruit du diviseur résistif. L'entropie est accumulée à la quantité requise, estimée à l'aide du test de fréquence de groupe.
Les principales primitives cryptographiques (mathématiques élémentaires pour X25519, Keccak800, ChaCha20) utilisent des implémentations d'assembleurs optimisées pour le compilateur pour les plates-formes de microcontrôleurs (Cortex M1 et M4), soigneusement vérifiées pour un temps d'exécution constant et avec une fuite minimisée à travers les canaux latéraux d'EMR et des fluctuations de la consommation de courant. Je dois dire tout de suite que ces codes assembleurs ont été reçus de professionnels de renommée mondiale, je les ai juste portés de GNU ASM vers l'environnement Keil, qui est plus familier pour la construction de projets embarqués.
Eh bien, qu'en fin de compte?
Si vous lisez cet endroit et n'êtes pas mort d'ennui, cela signifie que ce projet peut vraiment vous être utile. Si c'est le cas, alors, sur demande par courrier, je suis heureux de fournir des assemblages de test (fichiers exécutables liés statiquement, aucune installation requise), ainsi que le code source de l'interface graphique pour Windows, Linux et Android dans les environnements de développement respectifs. Le cœur du projet est basé sur la bibliothèque torfone multiplateforme, disponible sur la recherche github. Vous y trouverez également des liens directs vers la version alpha de l'application Android et un bref guide pour son installation et son utilisation, qui aidera tout le monde à évaluer la latence de la téléphonie dans le réseau Tor.
L'interface graphique est implémentée séparément pour chaque plate-forme et n'est pas une option (jusqu'à présent, il s'agit uniquement de tests alpha). L'application de test pour toutes les versions de Windows (à partir de l'ancien Windows 98) a été exécutée dans l'ancien mais puissant Borland C ++ Builder 6. Pour Linux, l'application GUI a été développée en utilisant séparément les graphiques Wide Studio for X11 pour les architectures i386 et ARM. Le premier devrait fonctionner sur les ordinateurs de bureau 32 bits et 64 bits, le second - sur les ordinateurs à carte unique peu coûteux: RPi, Orange, Nano, etc. Un fichier apk compilé dans Embarcadero RAD Studio 10.2 est disponible pour Android. C'est loin d'être la meilleure option et ne sait toujours pas comment créer un service Foreground, mais, néanmoins, cela fonctionne de manière stable en arrière-plan avec l'optimisation de l'utilisation de la batterie désactivée. De plus, l'environnement Android prend en charge la sauvegarde automatique des fichiers de configuration, des clés et du carnet d'adresses (sous forme cryptée) vers le stockage externe et la récupération lors de la réinstallation de Torfon ou du transfert vers un autre appareil. Au moment de la rédaction du présent document, des travaux sont en cours sur un projet dans l'environnement Keil uVision, qui comprend le transport, des modules de chiffrement, une interface audio et graphique basée sur Arduino - un écran TFT + Touch compatible 320 * 240. Le NanoPi Neo avec le serveur Debian installé et la carte Nucleo STM32F446RE connectée via un UART physique sera utilisé comme plate-forme matérielle ouverte.
Dans les plans à long terme - le portage sur iOS, bien que je comprenne à peine comment cela peut être combiné avec des garanties de sécurité de base.Et en conclusion.On me pose souvent les mêmes questions: comment gérer des utilisateurs sans serveur central? Comment lancer des mises à jour, des publicités? Et, plus important encore, pourquoi ai-je besoin de tout cela s'il n'y a aucune valeur commerciale?En fait, le monde n'est pas si gris et ruiné. Et il existe de nombreuses valeurs qui ne peuvent pas être mesurées avec de l'argent. Mais la réponse aux deux premières questions - pas question. Eh bien, vous ne pouvez pas arrêter Turfon. Vous ne pouvez pas obtenir de lui des «clés», vous ne pouvez pas fusionner les actions des utilisateurs, même ceux qui ont été remarqués dans le terrorisme ou la pédophilie, vous ne pouvez pas interdire les personnes indésirables. Vous ne pouvez pas forcer les mises à jour. Vous ne pouvez pas contrôler de l'extérieur. Il n'y a pas de fuites, composés latéraux à Torfon, sauf comme prévu par le protocole. Cela peut être facilement vérifié à la fois dans le code (presque chaque ligne est mise en commentaire et il n'y a pas tellement de fichiers dans le projet), ainsi que dans les analyseurs de réseau. Par conséquent, personne ne pourra gérer les utilisateurs de Torfon. Mais rappelez-vous: Torfon n'est qu'un outil, et toutes vos actions sont sur votre conscience, et vous en êtes responsable, pas l'auteur du projet.