Résumé technique : OmniSphinx : Réseaux de mélange actifs
Problématique
Les réseaux de mélange (mix networks) sont un outil critique pour la communication anonyme, protégeant à la fois le contenu des messages et les métadonnées (par exemple, les relations émetteur-récepteur). Cependant, les réseaux de mélange existants souffrent de rigidité : ils reposent sur des formats de paquets spécifiques et fixes (par exemple, Sphinx, PolySphinx, EROR). Ces formats sont mutuellement incompatibles, nécessitant des déploiements de logiciels et d'infrastructures distincts. Cette fragmentation force les opérateurs à choisir un format unique, ce qui limite les fonctionnalités des utilisateurs (par exemple, le trafic multicast) et empêche le réseau de s'adapter aux futurs formats sans mises à jour coordonnées de l'infrastructure.
Bien que les concepts de « réseau actif » (active networking) — où les nœuds exécutent du code intégré dans les paquets — aient été proposés pour ajouter de la flexibilité, ils ont historiquement été rejetés en raison des pénalités de performance et d'un manque d'études de cas convaincantes. Les auteurs postulent que les réseaux de mélange, qui subissent déjà une latence significative due au chiffrement et au brassage (shuffling), représentent un cas d'utilisation viable où la surcharge du traitement actif pourrait être acceptable en échange de la capacité d'émuler divers formats au sein d'un même déploiement.
Méthodologie
Les auteurs proposent OmniSphinx, un nouveau format de mélange actif qui intègre les idées du réseau actif dans le protocole Sphinx établi.
Conception de base
OmniSphinx structure les paquets en un en-tête et une charge utile (payload). Contrairement aux formats traditionnels où la logique de traitement des paquets est codée en dur dans le protocole, OmniSphinx intègre un programme de mélange (mix program) pour chaque nœud du chemin directement dans l'en-tête du paquet.
- Jeu d'instructions : Le système utilise un jeu d'instructions personnalisé, basé sur des registres, adapté aux opérations requises par les formats de mélange existants (par exemple, dérivation de clés, chiffrement/déchiffrement, vérification de MAC, padding et transfert). Ce jeu équilibre la flexibilité et la surcharge, évitant l'inefficacité du code machine de bas niveau tout en restant plus adaptable que les abstractions de haut niveau.
- Traitement des paquets : Lors de la réception d'un paquet, un nœud de mélange effectue trois étapes :
- Prétraitement : Dérive le secret partagé via Diffie-Hellman et déballe le chiffrement de l'oignon pour révéler le programme de mélange pour le saut (hop) actuel.
- Exécution du programme : Le nœud exécute les instructions intégrées. Le programme a accès à l'en-tête, à la charge utile et au secret partagé. Une instruction dédiée
Forward met en file d'attente le paquet résultant.
- Post-traitement : Le nœud s'assure que le paquet sortant respecte les exigences de taille via un padding déterministe.
Analyse de la sécurité et de la confidentialité
Les auteurs abordent trois défis principaux : la flexibilité, la confidentialité et la performance.
- Garanties de confidentialité : L'article soutient que pour des programmes de mélange arbitraires, les preuves de confidentialité standards (Unlinkabilité de couche et Indistinguabilité de queue) ne tiennent pas automatiquement car le comportement des nœuds n'est plus fixe. Pour y remédier, les auteurs :
- Prouvent qu'OmniSphinx satisfait des versions adaptées de l'Unlinkabilité de couche d'instruction (ILU) et de l'Indistinguabilité de queue d'instruction (ITI) en utilisant une instruction
Forward simple, en s'appuyant sur l'hypothèse Gap Diffie-Hellman (GDH).
- Introduisent l'Analyse de flux d'information dans le contexte de la communication anonyme. Cette méthode classifie les données comme « bénignes » ou « malignes » et suit les dépendances à travers le graphe d'instructions. Un programme de mélange est jugé sûr si aucune information maligne (par exemple, le secret partagé ou les données de paquets précédentes) ne coule vers l'instruction
Forward.
- Sécurité des nœuds : Le jeu d'instructions est restreint pour empêcher les utilisateurs malveillants d'exfiltrer des secrets, de contrôler le nœud (par exemple, participation à un botnet) ou de causer des dénis de service. Le temps d'exécution et la mémoire sont limités, et l'ensemble ne possède pas d'accès réseau arbitraire.
Contributions clés
- Protocole OmniSphinx : Un nouveau format de mélange qui permet aux émetteurs d'intégrer une logique de traitement personnalisée, permettant à une seule instance de réseau d'émuler plusieurs formats existants et futurs.
- Architecture de jeu d'instructions : Un ensemble d'instructions défini capable d'émuler les formats de mélange pertinents (spécifiquement démontré pour Sphinx et PolySphinx) tout en maintenant l'efficacité.
- Analyse de flux d'information : L'application de l'analyse de flux d'information pour vérifier la confidentialité des programmes de mélange arbitraires, garantissant que le traitement dynamique ne fuit pas de métadonnées.
- Évaluation empirique : Un benchmark complet de la surcharge de bande passante et de calcul par rapport aux formats natifs.
Résultats
Les auteurs ont implémenté OmniSphiment en Java et ont évalué ses performances par rapport à Sphinx natif, AE-Sphinx, EROR, MultiSphix et PolySphinx.
- Surcharge de bande passante :
- L'émulation de Sphinx (le format le plus compact) augmente la taille de l'en-tête de 33 % (de 205 B à 273 B).
- L'émulation d'autres formats entraîne des surcharges relatives plus élevées (par exemple, +127 % pour AE-Sphinx, +139 % pour MultiSphinx) principalement parce qu'OmniSphinx doit inclure le programme de mélange et un MAC supplémentaire dans l'en-tête, alors que les formats natifs réutilisent souvent les MAC pour l'intégrité de la charge utile.
- Dans un scénario pessimiste, émulant tous les formats avec une charge utile de 2 KiB, la taille du paquet augmente d'environ 61 %.
- Surcharge de calcul :
- Création de paquet : Les performances sont identiques à celles de Sphinx natif (~1,12 ms), car cela est géré par des implémentations Java natives pour les deux.
- Traitement de paquet : Le traitement d'OmniSphinx est plus lent d'environ 90 µs par rapport à Sphinx natif (283 µs contre 198 µs pour les nœuds intermédiaires).
- Coûts d'instruction : Les instructions simples de mouvement d'octets prennent
1,5 µs. Les opérations cryptographiques (MAC, Hash, Encrypt/Decrypt) sont 2 à 3 fois plus longues, tandis que les opérations à clé publique (Exponent) sont les plus lentes (153 µs).
- Capacité d'émulation : Les auteurs ont démontré avec succès qu'OmniSphinx peut émuler la pleine fonctionnalité de Sphinx et PolySphinx (incluant la réplication et la communication de groupe) en utilisant le jeu d'instructions défini.
Signification et affirmations
L'article affirme qu'OmniSphinx démontre la viabilité du réseau actif dans les contraintes spécifiques des réseaux de mélange. Bien que l'émulation introduise une surcharge mesurable tant en bande passante qu'en calcul, les auteurs soutiennent que ces coûts sont raisonnables pour des cas d'utilisation typiques comme la communication par courrier électronique, où la latence réseau et les coûts cryptographiques existants dominent déjà.
La principale signification réside dans le passage de déploiements rigides à format unique vers une infrastructure flexible et unifiée. Cela permet :
- Une meilleure utilisation des ressources : Une seule instance de réseau de mélange peut servir des clients ayant des besoins divers (par exemple, unicast standard vs multicast) sans nécessiter de réseaux séparés.
- Des ensembles d'anonymat accrus : Les utilisateurs peuvent choisir parmi un ensemble plus large et plus diversifié de nœuds et d'opérateurs supportant leurs besoins de format spécifiques.
- Une pérennité (Future-Proofing) : De nouveaux formats de mélange peuvent être implémentés et déployés via des mises à jour logicielles du jeu d'instructions ou de la logique client, sans nécessiter de changements d'infrastructure coordonnés chez tous les opérateurs.
Les auteurs concluent que bien qu'OmniSphinx ne soit pas un remplacement direct (drop-in replacement) pour les formats natifs en raison de la surcharge, il offre un compromis convaincant pour les opérateurs et les utilisateurs recherchant flexibilité et extensibilité dans les systèmes de communication anonyme.