Le but du projet EnSkred est de concevoir et d'implémenter un protocole reposant sur TCP qui permet à un réseau d'applications de communiquer en échangeant des messages textuels de taille arbitraire. Chaque application est identifiée par une clé publique RSA 2048 bits. Le but du projet est de permettre la confidentialité des échanges :
Le but du protocole est que même si l'on observe le trafic TCP entre toutes les applications, on ne puisse pas savoir qui parle avec qui.
Chaque application rejoignant le réseau se connecte initialement à une application existante et, après un premier échange, tente de se connecter à une autre application choisie aléatoirement (les deux premières applications formant le point de départ du réseau). Ainsi, chaque nouvelle application initie deux connexions, bien qu'ultérieurement une application puisse recevoir davantage de connexions au fur et à mesure que d'autres applications se connectent à elle.
Une application est identifiée par une clé publique RSA 2048 bits. Au moment de sa connexion au réseau, elle doit prouver qu'elle possède bien la clé privée associée (sans la divulguer bien entendu).
L'exemple ci-dessus illustre qu'à l'initiation, une nouvelle application (F) établit deux connexions (ici, vers A et B), tout en laissant entendre qu'ultérieurement d'autres applications pourront se connecter aux applications existantes.
Le protocole que vous allez écrire doit permettre les fonctionnalités suivantes pour les applications.
Une application implémentant votre protocole doit pouvoir obtenir la liste des clés publiques RSA des applications connectées au réseau.
Une application doit pouvoir envoyer un message texte de taille arbitraire à une autre application identifiée par sa clé publique. Le message est transmis par un chemin le plus court pour atteindre l'application cible. Ici, la taille du chemin est le nombre d'applications intermédiaires qui vont relayer le message.
Dans le mode de messagerie sécurisée, le protocole doit garantir que, même en cas de compromission d'une application intermédiaire ou de surveillance de l'ensemble du trafic TCP, ni l'expéditeur, ni le destinataire, ni le contenu du message ne soient dévoilés.
Pour ce faire, le chiffrement asymétrique RSA est utilisé. Par exemple, si l'application A souhaite envoyer un message à l'application E via l'application C, A envoie à C un message chiffré avec la clé publique de C. Le message pour C contient le nom de E et un message destiné à E chiffré avec la clé publique de E. L'idée est que lorsque C va recevoir le message de A, il va décoder le message avec sa clé publique. Il trouvera les information sur E et un message pour E qu'il transmettra. A va changer en permanence de chemin pour parler à E, rendant l'identification de son destinataire réel complexe. Le protocole ne spécifie pas le chemin exact à utiliser pour la transmission d'un message sécurisé, laissant ainsi le choix de la mise en œuvre à l'application implémentant le protocole.
Votre protocole doit permettre un chemin de taille arbitraire. Votre protocole devra se baser sur cette idée générale et l'adapter aux différentes contraintes.
Une application doit pouvoir se déconnecter du réseau. Les autres applications doivent veiller à garantir si c'est possible qu'elles maintiennet au moins deux connexions. On ne vous demande pas de gérer les cas de défaillance de connexion.
La cryptographie asymétrique, également appelée cryptographie à clé publique, repose sur l'utilisation de deux clés distinctes : une clé publique, que l'on peut librement partager, et une clé privée, qui doit rester confidentielle. Les messages chiffrés à l'aide de la clé publique ne peuvent être déchiffrés qu'avec la clé privée correspondante, assurant ainsi la confidentialité des échanges.
La librairie UGEncrypt vous propose une implémentation en Java permettant de :
Elle vous est fournie pour que vous compreniez plus facilement les principes et limitations. La librairie UGEncrypt est disponible sur ici.
Attention, votre RFC ne doit faire référence qu'à d'autres RFC, mais jamais à du code.
Le travail est à réaliser en binôme (deux personnes : pas plus, pas moins, et du même groupe).
Les trois étapes du rendu seront évaluées à parts égales.
Attention : si rien n'est rendu pour la RFC, la note globale du projet sera 0 et il ne sera pas possible d'accéder aux étapes suivantes. Le projet est obligatoire et sa note n'est pas compensable même en session 2 conformément aux MCCs spécifiques de la formation.
Pour la partie code, chaque groupe doit créer un projet sur GitLab avec votre binôme et ajouter votre chargé de cours comme Maintainer du projet. Les deux membres du projet doivent faire toutes leurs contributions sur le git dans des commits réguliers. Le nom de votre projet sera EnSkred-NOM1-NOM2 avec NOM1 et NOM2 correspondant aux noms de famille du binôme dans l'ordre lexicographique.
À l'exception du code fourni par l'équipe enseignante, tout le code présent sur votre dépôt Git doit avoir été écrit par vous-même. La présence de code provenant d'une source extérieure rendra impossible l'évaluation de votre projet et sera transmise au comité de discipline de l'IGM.
Votre rapport doit contenir les informations suivantes: