Architecture: Serveur Central

Au coeur de ce système réside un serveur central qui implémente les fonctionnalités du réseau social. Ce serveur implémenterait un réseau social générique via des services web qui pourraient être utilisés pour créer des réseaux sociaux ouverts comme Friendster, ou des applications de Darknets comme l'échange de recettes de tartes aux pommes underground. Ce serveur central serait utilisé pour l'identification, l'authentification, la disponibilité et les relations en réseau des utilisateurs. Le serveur ne devrait pas savoir ce pour quoi le réseau social est utilisé -- vu de l'exterieur une application légitime devrait avoir exactement la même apparence qu'une application illégale.

Les avocats du P2P seront rapides à objecter qu'un serveur central est un talon d'Achille dans le système -- à la fois d'un point de vue technique et sous l'angle d'attaquants extérieurs. Objection accordée, le serveur est un point d'échec central , mais jusqu'à présent, des algoritmes qui implémentent une toile de confiance distribuée ne sont pas venus au monde. D'aussi loin que je puisse voir, il n'y a pas de solution solide pour implémenter un réseau social distribué qui est résistant aux attaquants exterieurs -- pas encore.

Du point de vue d'attaquants juridiques, le serveur central ne présente pas d'informations utiles. Si un serveur était compromis, l'attaquant juridique ne trouverait aucune preuve que des activités illégales se passaient. En fait, le serveur central ne devrait contenir aucune information incriminante ou autres informations utiles à propos du réseau social. La chose la plus utile glanée sur le serveur central serait les adresses IP des autres membres du réseau -- c'est tout.

Cette approche a deux autres avantages : les attaquants juridiques ne peuvent pas utiliser d'attaques de violations directes ou indirectes (du droit d'auteur, ndlt) sur le serveur, puisque le serveur ne peut pas savoir si les réseaux sont utilisés pour des utilisations illégales. De même, le serveur central résoud le problème embêtant du bootstrapping pour trouver le réseau P2P à rejoindre. Ici le serveur central sera capable de donner aux clients les adresses IP des autres membres qui sont actuellement en ligne.

Architecture: P2P Client

Pour construire un client P2P pour ce réseau, un client existant pourrait être employé ou un nouveau pourrait être développé. Toutes les connaissances des recherches sur le P2P menées depuis quelques années pourraient être appliquées pour créer un client high-tech qui utilise des logiciels haut de gamme comme BitTorrent ou Kademlia. Etant donné le nombre de bons systèmes P2P qui flottent autour du monde aujourd'hui, il est clair que ça n'est pas un problème difficile.

Le client P2P pourrait employer un protocole de routage des requêtes façon Gnutella ou utiliser des identificateurs externes comme les Bitprints de Bitzi, les identificateurs de MusicBrainz, ou les identificateurs IMDB, couplé avec une table de hash distribuée comme Kademlia.

Le système devrait sans aucun doute utiliser un système qui crée automatiquement des trackers BitTorrent pour maximiser l'utilisation de la bande passante des clients de partage de fichiers.

Pas d'invention de la poudre ici, avançons.

Inviter et Eviter les Détections

Pour rejoindre un réseau social de partage de fichiers, vous aurez besoin d'une invitation d'un membre existant. Les invitations sont simplement de petits fichiers XML qui contiennent les bonnes clés pour rejoindre le réseau. Les invitations peuvent aussi spécifier les bons paramètres pour trouver le réseau, puisque les Darknets font de leur mieux pour ne pas opérer au grand jour.

Premièrement, tout le traffic qui circule à travers le réseau social, y compris les transferts de fichiers, devraient être tunnelés via SSH, de façon à ce que quelqu'un qui sniff votre connexion réseau ne puisse pas dire la différence entre une connexion VPN légitime et un partage illégal de la meilleure recette de tarte aux pommes.

Deuxièmement, les applications qui forment le réseau social devraient essayer de se fondre dans le paysage et être soit invisibles soit impossibles à distinguer d'une infrastructure réseau normale, telle qu'un serveur SSH. La forme la plus simple pour ceci est d'opérer sur le même port que le serveur SSH lui-même. Une approche plus compliquée de Port Knocking a été récemment proposée sur Slashdot -- elle demande une série d'échecs de tentatives de connexion au serveur prédeterminés avant que le serveur n'ouvre le vrai port pour le client.

Une autre approche est le changement de port, où le serveur et le client changent fréquemment de ports sur lequel ils écoutent les connexions. L'invitation pourrait inclure le paramètre nécessaire pour calculer quel port un serveur serait entrain d'écouter à une heure donnée.

Quelle que soit la technique employée, le but est le même : les attaquants extérieurs ne voient rien si ce n'est des connexions SSH.

Sécurité

Les applications qui bâtissent le réseau social devraient employer des outils standards déjà disponibles comme SSH, PGP et BitTorrent. Après tout, ces outils se spécialisent dans leur domaine respectif, et il n'est pas sage de réinventer la roue -- tout spécialement quand on parle de sécurité. Toute connexion réseau réalisée par le logiciel de partage de fichiers devrait être tunellée par une connexion SSH.

La ligne à suivre du modèle de sécurité pour ce logiciciel devrait être de revenir vers la même sécurité qu'un système ouvert au cas où le système est compromis. Si le système est rendu largement à découvert pour une raison ou pour une autre, seule les adresses IP des participants devraient être exposées. Dans le climat juridique actuel, n'avoir qu'une adresse IP force l'attaquant à déposer une plainte contre X (il s'agit ici d'une plainte contre John Doe, aux Etats-Unis et au Canada. En France, la collecte même de l'adresse IP pose problème, ndlt). Il s'agit exactement de la même procédure réservée aux gens qui utilisent des systèmes ouverts comme Kazaa.

Ce fait donne aux utilisateurs de logiciels de partage de fichiers sociaux un avantage sur les partageurs de fichiers qui utilisent Kazaa. Monter une attaque contre les utilisateurs de Kazaa demande des outils réseaux librement disponibles et faciles à utiliser. Monter une attaque sur un réseau fortifié avec SSH demande des outils complètement différents et une attaque en force brute est hors de question. Aussi, les attaquants sont plus enclins à poursuivre les utilisateurs d'applications de partage de fichiers ouvertes.

La partie la plus vulnérable d'un réseau social est les utilisateurs eux-même. Comme les experts en sécurité le disent depuis longtemps, les attaques qui ont le plus de succès ne sont pas des attaques techniques, mais des attaques qui exploitent les faiblesses des utilisateurs. Des mots de passe gribouillés placés à des endroits non sécurisés, ou des attaquants au beau-parler qui convainquent les utilisateurs de leur nature bénine, présentent des faiblesses bien plus grandes que le protocole SSH.

Finalement, la sécurité du réseau tient dans les mains des utilisateurs. C'est pourquoi les politiques sociales mises en place par le chef de la tribu sont si importantes -- les politiques affectent l'esprit de l'utilisateur, ce qui en retour affecte son comportement. Des politiques sociales qui permettent un comportement promiscueux peuvent conduire à des brèches de sécurité.

Modèle d'Attaque

Analyser les attaques possibles sur un réseau social de partage de fichiers nous donne trois attaques possibles :

1. Attaque sur le serveur : Le serveur central se fait hacker, envahir par des attaquants juridiques, ou compromettre autrement. Puisque le serveur opère aveuglement en fonction de ce que les utilisateurs font, le serveur ne contient aucune preuve incriminante. L'attaquant ne peut pas différencier un réseau de partage de recettes d'un réseau de partage de films. Au pire, les adresses IP des membres peuvent être exposées et celles-ci doivent être poursuivies dans une attaque contre X.
   
2. Attaque sur le Client : Un client se fait hacker, envahir par des attaquants juridiques, ou compromettre autrement. Le client compromis pourrait potentiellement continuer à opérer et collecter les adresses IP de tout le monde sur le réseau. Un comportement incriminant pourrait être observé.
   
3. Attaque sur un Client Social : Un attaquant se fait inviter sur le réseau et commence à participer au réseau. Au fil du temps, l'attaquant collecte toutes les adresses IP des membres et observe potentiellement des comportements incriminants.

Au pire, l'attaque sur le serveur fourni des adresses IP qui peuvent ne pas avoir commis d'infraction. Des attaques sur des clients pourraient exposer des adresses IP et éventuellement permettre à l'attaquant d'observer des activités illégales. Alors que ce modèle pourrait sembler catastrophique, il est meilleur que le système de P2P ouvert que Kazaa utilise. Etant donné que les attaquants ont plus de chances d'attaquer les cibles faciles d'abord, utiliser un réseau social pour partager des fichiers présente un niveau accru de sécurité -- pour l'instant.

Si vient un temps où tous les systèmes ouverts ont été éradiqués, ce système nécessitera des fortifications supplémentaires. A mesure que les très discutés algoritmes de toile de confiance et d'anonymisation verront le jour, ces algoritmes devraient être adaptés pour une utilisation pour le partage de fichiers social et continuer à améliorer la résistance aux attaques de ces réseaux.

Conclusion

Depuis ces dernières années, nous avons tiré un certain nombre de leçons juridiques et techniques qui nous permettent aujourd'hui de construire des systèmes de partage de fichiers plus sécurisés et efficaces. Utiliser des plans pour éviter les détections et des outils de sécurité communs comme SSH et PGP force les attaquants à emprunter une voie différente quand ils attaqueront les systèmes de partage de fichiers des prochaines générations. Les attaquants doivent employer des attaques sociales pour démonter un système de partage de fichiers, et les attaques sociales ne s'étendent pas aussi bien que les attaques en ligne qui peuvent être assistées par des outils informatiques.

Le modèle de sécurité présenté ici n'est suffisant que pour un temps limité -- avec le temps, des algoritmes de toile de confiance plus avancés devraient être utilisés pour atténuer davantage les dommages d'un réseau compromis.

Enfin, nous devrions insister encore une fois sur le fait que la sécurité du réseau social se développe au travers des politiques sociales mises en place pour le réseau. Les chefs tribaux et les membres du réseau doivent être continuellement vigilants à garder le réseau à l'abris d'attaquants extérieurs.