Interview avec Simone Basso (NEXA): Sur le compromis entre décentralisation et contrôle

Interview avec Simone Basso (NEXA):
Sur le compromis entre décentralisation et contrôle

 

Pensez-vous qu’il existe un compromis entre (1) le degré de décentralisation d’une architecture et (2) le degré de contrôle qui peut être exercé sur cette architecture – notamment dû au fait que de nombreuses architectures décentralisées ont été expressément conçues pour échapper au contrôle (Freenet, Tor, etc) ?

Plus grand est le degré de décentralisation d’une architecture, plus il sera difficile de la contrôler. Alors que toute architecture centralisée (e.g. cloud computing) est facilement contrôlée, toute architecture décentralisée (tels que la plupart des réseaux pair-à-pair) ne se pose pas facilement au contrôle. Cela dépend notamment du nombre d’acteurs concernés et de leur fonctions réciproques : alors que dans le premier cas, il est possible d’identifier un acteur qui est responsable et qui gouverne les activités de tous les autres, dans le second cas, il existe un très grand nombre d’acteurs qui interagissent et coopèrent de façon symétrique, sans qu’aucun d’eux ne puisse contrôler ce que font les autres.

Cette relation entre décentralisation et contrôle peut être illustrée sur un axe cartésien qui représente le degré de décentralisation sur l’axe des ordonnées et le degré de contrôle sur l’axe des absisses.


Il est cependant important de noter que ce compromis – entre décentralisation et contrôle – peut entraîner un cercle vicieux : plus une architecture est décentralisée, plus il est difficile de la contrôler ; de nouvelles méthodes sont ainsi développées afin d’assurer le contrôle de ces architectures par les autorités, ce qui poussent les communautés numériques qui ont un intérêt à échapper à ce contrôle à développer de nouveaux dispositifs encore plus décentralisés et difficiles à contrôler.

Un exemple peut illustrer ce problème : à l’origine, chaque application utilisait une porte spécifique (e.g. porte 80 pour le web, porte 20/21 pour le ftp, etc) ; il était donc possible pour les fournisseurs d’accès Internet (FAI) d’identifier  le « type » de trafic passant par leurs réseaux en analysant simplement la porte à laquelle les paquets étaient adressés. Cela rendait possible, par exemple, de bloquer tout le trafic à provenance ou à destination de certains réseaux pair-à-pair pour le partage de fichiers. Aujourd’hui, la plupart des dispositifs pair-à-pair utilisent des portes aléatoires afin de ne pas permettre aux FAI d’identifier (et de censurer) leur trafic. Les FAIs ont donc commencé à analyser le contenu des paquets avec les technologies de Deep Packet Inspection, ce qui a mené un nombre croissant d’utilisateurs à chiffrer leurs paquets pour échapper à ce contrôle. Aujourd’hui, de nouvelles techniques sont en train d’être étudiées afin d’identifier la nature du trafic en dépit du fait que les paquets soient chiffrés : l’analyse statistique des paquets sur certains protocoles a permis le développement de nouvelles techniques de data mining qui se basent sur les caractéristiques des paquets analysés (e.g. leur fréquence ou leur taille) pour en déterminer la nature. Par exemple, en analysant la proportion entre les paquets en entrée et les paquets en sortie, il est possible d’identifier s’il s’agit d’un client (lorsque le nombre de paquets en entrée est supérieur au nombre de paquets en sortie), d’un serveur (lorsque le nombre de paquets en sortie est supérieur au nombre de paquets en entrée), ou d’un dispositif pair-à-pair (lorsqu’il y a une sorte d’équilibre entre le nombre de paquets en entrée et le nombre de paquets en sortie).

*** 

Est-il possible de contrôler les opérations de ces architectures sans en modifier la structure, i.e. sans détruire une technologie qui présentent plusieurs avantages, notamment en termes de liberté d’expression et tutelle de la vie privée ?

Bien que les architectures décentralisées permettent d’échapper au « contrôle à  grande échelle » en éliminant la possibilité d’accéder à une structure centrale (ou « nœud central » qui gouverne le réseau), il est néanmoins possible de contrôler les opérations de ces architectures et les communications entre pairs à différents niveaux.

Tout d’abord, bien qu’une architecture soit décentralisée, il y a toujours un point de départ – que ce soit le « tracker » ou le « bootstrap node » – qui permet aux nouveaux utilisateurs de découvrir leurs pairs. En observant le trafic en provenance ou à destination de ces nœuds, il est possible d’identifier les pairs auxquels ils sont connectés. Bien qu’il ne soit (théoriquement) pas possible de monitorer les communications entre pairs, il est parfois possible d’intercepter ces communications par le biais d’un déguisement (i.e. en s’appropriant temporairement l’adresse IP de l’un des pairs qui prennent part à la communication).

En effet, il est important de rappeler qu’il est impossible de communiquer sur le réseau sans prendre le risque que cette communication soit interceptée. Par exemple, de nombreux réseaux pair-à-pair sont infiltrés par des « espions » qui ont pour objet d’espionner les activités de leurs pairs. Ce problème est amplifié par les externalités du réseau : plus un nœud est « connecté » (i.e. plus grand est son « swarm »), plus grands seront les risques que ce nœud soit effectivement contrôlé.

Enfin, de nombreuses autres techniques peuvent être employées pour intercepter les communications des internautes, quel que soit le type d’architecture sur lequel ils communiquent : e.g. par l’intermédiaire de virus ou de spyware installés directement sur leurs ordinateurs.

Par conséquent, un très grand nombre de variables doivent être considérées pour échapper au contrôle des autorités. La décentralisation d’une architecture est seulement un des moyens disponibles aux internautes pour rendre leur identification plus difficile – que ce soit dans le but de commettre des actes illicites ou dans le but de préserver leur vie privée et leur liberté d’expression. D’autres mécanismes fondés sur des protocoles de communication extrêmement complexes, des technologies de chiffrages et des mécanismes d’authentification extrêmement sophistiqués peuvent être utilisés, en complément ou en supplément aux architectures décentralisées.

Il s’agit, en définitive, d’établir une balance entre « paranoïa » et « efficience ». La plupart des réseaux pair-à-pair privilégient l’efficience : ils ont un intérêt à faciliter la recherche de pairs pour permettre aux utilisateurs de communiquer ou de transférer des fichiers le plus rapidement possible. D’autres réseaux utilisés pour l’échange de secrets militaires ou de documents pédophiles adopteront, eux, une architecture des plus décentralisée en combinaison avec un protocole des plus complexes – leur objectif n’étant pas le transfert efficace de fichiers mais la difficulté de se faire identifier.

***

Est-il possible d’identifier une solution qui permettrait d’échapper à cette dichotomie, afin de bénéficier des avantages fournis par les architectures décentralisées, tout en assurant un certain degré de contrôle sur leurs opérations ?

Il y a trois possibilités différentes qui permettent de contrôler une architecture décentralisée:

(1) Censure des architectures décentralisées, en interdisant le protocole ou en le modifiant afin d’assurer le contrôle de la part des autorités. Cela a cependant l’inconvénient de pousser les communautés numériques à développer des mécanismes toujours plus compliqués pour échapper au contrôle.

(2) Introduction d’une police informatique qui a pour but de superviser les opérations d’un réseau et, le cas écheant, de s’infiltrer dans le réseau afin de le démanteler.

(3) Collaboration avec les internautes qui ont un intérêt à faire appliquer les règles au sein du réseau. Par exemple, de nombreux réseaux pair-à-pair pour le partage de fichiers ont adopté des règles qui encouragent les utilisateurs à partager leur fichiers, avec des mécanismes fondés sur un équilibre entre le nombre de fichiers partagés et le nombre de fichiers téléchargés (c.f. BitTorent “tit-for-tat” fondé sur le volume d’échange). De tels mécanismes peuvent être implémentés, par analogie, à d’autres réseaux pair-à-pair dont le but n’est pas le partage de fichiers, mais la communication en ligne. Au lieu de se fonder sur le volume d’échange, ces mécanismes peuvent, par exemple, se fonder sur un système de réputation – où les utilisateurs qui proposent des contenus offensifs (e.g. pornographiques ou illicites) auront une mauvaise réputation et seront donc pénalisés. L’idée est d’incorporer la réputation des utilisateurs avec leur possibilité d’intéragir avec les pairs et de bénéficier des fonctionalités du réseau. Cela demande cependant la collaboration des autres utilisateurs du réseau (ou d’une force de police spécifique) qui auront la responsabilité de “signaler” (to flag) les utilisateurs malveillants. Ces derniers maintiennent toutefois un certain pouvoir dans la mesure où ils ont la possibilité de “tricher” (e.g. en créeant des nouvelles identités) ou tout simplement de se déplacer sur un autre réseau. L’objectif n’est pas pas celui de rendre le contrôle absolu (car ce n’est pas possible), mais tout simplement de décourager les utilisateurs à se comporter de façon non légittime (i.e. de désobéir aux règles du réseau) en pénalisant ce type de comportements.


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.