Report for faculty (french)

Secure Talk

STRASSER Michel, DIALLO Amadou 2

Avant-propos

Les sources du programme, les sources de ce document ainsi que les différents diagrammes sont disponibles sur le CDROM joint au dossier.

Intérêts - Objectifs

La norme internet IPV4^1.1 n'assure pas de cryptage. Le service de cryptage n'est pas non plus assuré par TCP. Les données transitées sur internet sont susceptibles d'être "sniffées".

Attaque de type scan de port et sniffage

Un scan de port ^1.2 est l'action d'essayer de se connecter incrémentalement sur tous les ports d'une machine pour voir ceux qui sont utilisés. Les numéros de port sont en générale associés de façon statique à un certain type de serveur ^1.3 ce qui permet de faire des hypothèses sur les services proposés par le serveur situé en amont et susceptible d'offrir des brêches de sécurité.

Sur les réseaux ethernet, l'utilisation habituelle des cartes réseaux est de ne prendre en compte que les messages qui leur sont destinés. Pourtant il est possible de les positionner de tel sorte qu'ils écoutent tous les messages. Comme les paquets IPV4 ne sont pas cryptés, un tiers peut, si l'on ne dispose pas de mécanisme particulier, écouter des conversations une fois qu'il aura détecté la présence d'un serveur talk grâce à un scan de port précédemment effectué.

Les problèmes de sécurités prennent une grande échelle lorsque le réseau ne connait plus de contraintes physiques comme c'est le cas des réseaux sans fils^1.4.

Cryptage asymétrique, - symétrique

Les cryptages ne sont pas basés simplement sur la connaissance d'un algorithme mais sont généralement paramétrables grâce à une clé.

On appelle cryptage symétrique, les cryptages pour lesquelles la clé utilisée pour crypter est la même que pour décrypter. Exemple de tel cryptage XOR (le ou exclusif)^1.5.

Ce type de cryptage pose le problème de comment communiquer la clé unique. C'est un problème du type oeuf et la poule. En fait pour assurer le cryptage on aurait besoin d'un canal crypté pour communiquer la clé.

Le cryptage asymétrique se distingue par le fait que la clé utilisée pour crypter est différente de la clé utilisée pour décrypter. La clé de cryptage est publique, tout le monde à le droit de crypter, et il n'est pas considérer comme une faille de sécurité qu'un acteur non désiré s'empare de la clé publique, celle-ci ne sert qu'à crypter tout comme un téléviseur ne sert qu'à recevoir des émissions télévisées et non pas à en diffuser. La clé privée, pour le décryptage, doit rester secrète.

Les cryptages asymétriques sont en règle général plus lent et demandent des clés plus longues que leurs cousins symétriques. C'est pourquoi un bon compromis est de prendre un cryptage asymétrique simplement pour communiquer une clé de cryptage symétrique et crypter symétriquement par la suite.

Objectif du projet de téléinformatique

Il est demandé d'implémenter un talk sécurisé grâce au cryptage asymétrique RSA.

RSA

^2.1

Découpage logique

Le fonctionnement de la partie RSA a été découpé en deux couches :

une couche haute chargée de s'interfacer avec le serveur et le client, de proposer des objets clés, paire de clés, etc... de haut niveau, de découper les messages entiers en petits morceaux de 14 caractères qu'elle passera à la couche basse, et au retour, au décryptage, d'accumuler les blocs décryptés et de ne retourner que des messages entiers ou rien du tout;
une couche basse chargée de réaliser le travail de bas niveau:
- génération des nombres premiers et entre $2^{60}$ et $2^{64}$
- calcul de , et qui correspondent aux clées;
- la transformation d'une chaîne de caractères en un grand nombre et la transformation reciproque;
- le cryptage et le decryptage d'un message;

La couche haute

Le découpage pour le cryptage est assez facile. Par contre pour le décryptage, il fallait encore décomposer en deux couches. En effet, on obtient un flux qui peut ne pas être complet ni au niveau de mots de 16 caractères, ni au niveau de message. Ceci provient du fait que TCP bufferise^2.2. Il faut donc mettre en place un mécanisme compliqué de découpage et de bufferisation.

Pour le découpage en message, on a posé la convention que les messages étaient séparés par un saut à la ligne. On a, pour éviter tout risque que la fin d'un message se retrouve dans le même mot de 16 caractères d'un début d'un nouveau message, bourré les fins de messages avec le souligné '_'.

La première couche s'occupe du découpage en mot de 16 caractères, la deuxième du découpage en message. Le couplage des deux couches fournit un service de haut niveau puisque la méthode decrypt de l'objet de classe RsaDecrypter ne renvoie une chaîne décrypté que lorsqu'un message entier a pu être lu^2.3.

La couche basse

Comme le veut l'algorithme RSA qui est un algorithme de cryptage à clés publique et privée, on doit trouver une manière de générer des clées. Vue la difficulté de factoriser les grand nombres, on cherche deux entiers

premiers entre eux. Dans notre cas ces deux entiers qui restent privés sont pris aléatoirement entre $2^{60}$ et $2^{64}$ et sont différents.

Ce qui permet de calculer les grand entiers :

composante fondamentale du cryptage et du decryptage;
qui est premier avec et permet de trouver la clée publique utile pour le cryptage;

Ayant calculer

on cherche:

un entier compris, en principe,entre et $2^{127}$ et premier avec .
un entier tel que $e*d \equiv 1 mod ((p-1)*(q-1))$ et pour cela on se sert du lemme de Bezout: "Etant donnés deux entiers et premiers entre eux, il exite deux entiers et ,uniques, tels que " qui est equivalent à $e*d \equiv 1 mod ((p-1)*(q-1))$ .

Les entiers

correspondent respectivememt aux clées publique et privée.

Les messages à envoyer étant sous forme de chaînes de caractères on définit deux fonctions rsa_str2gdnb() et rsa_gdnb2str() qui, respectivement, transforment une chaîne de caractères de taille donnée en un grand entier et réciproquement.

Ce qui permet de transformer une chaîne en un gdnb et de coder pour obtenir par la relation: où et correspondent à leurs équivalents précédemment calculés. De même pour décoder un code et obtenir un gdnb on définit une fonction qui effectue l'opération: avec et précédemment calculés.

Or puisqu'on ne manipule, dans la couche supérieure, que des chaînes de caractères et pas de gdnb, il a fallu définir des fonctions d'interface telle que cryptage et décryptage qui prennent en paramètres, chacune, trois chaînes de caractères et en retourne une correspondant respectivement à une chaîne cryptée et une chaîne decryptée.

Fonctions définies pour le cryptage et le décryptage des messages

Voici les différentes fonctions implantées pour le cryptage RSA et leurs rôles respectifs:

rsa_premier(int min,int max): génère aléatoirement un grand nombre premier compris entre et ;
rsa_cle() :génère une structure contenant la partie publique et privée des clées;
gen_cle() :retourne un tableau de trois chaînes de caractères correspondant respectivement à , et ;
rsa_codage() : prend trois grand nombres en paramètre et retourne un grand nombre ; ce qui correspond à l'opération arithmétique ;
rsa_decodage() : prend trois grand nombres en paramètres et retourne un grand nombre;équvalent à l'opération ;
rsa_str2gdnb() : en paramètre un grand nombre et un entier, en retour donne une chaîne de caractères dont la taille correspond à l'entier donné en paramètre;
rsa_gdnb2str(): l'inverse de rsa_str2gdnb ;
cryptage() : en paramètre trois chaînes de caractères à savoir , et le bloc de 14 caractères à crypter; en retour un bloc de 16 caractères cryptés ; utilise rsa_codage(), rsa_str2gdnb() et rsa_gdnb2str();
décryptage() : en paramètre trois chaînes de caractères à savoir , ,et le bloc de 16 caractères à décrypter; en retour un bloc de 14 caractères ; utilise rsa_decodage(), rsa_str2gdnb() et rsa_gdnb2str();

Structures de données utilisées

Hormis la structure gdnb définie dans gdnb.h, on utilise les structures suivantes :

 typedef struct{
 	gdnb modulo;
	gdnb codage;
	}clepub;

avec modulo correspondant à

et codage à

;

  typedef struct{
 	clepub cle_pub;
	gdnb cle_priv;
	}keys;

avec cle_pub correspondant à

, cle_priv correspondant à

;

```
char ** clees;
```
tableau de trois chaînes de caractères correspondant aux équivalents de , et ;

Résumé de l'algorithme RSA

étape 1: trouver deux entiers et compris entre $2^{60}$ et $2^{64}$ , différents premiers entre eux;
étape 2: calculer ;
étape 3: trouver un entier compris entre et $2^{128}$ et premier avec
étape 4: calculer tel que $e*d \equiv 1 mod ((p-1)*(q-1))$
étape 5: cryptage;pour un bloc de message , avec bloc crypté;
étape 6: décryptage: pour un bloc crypté , avec bloc decrypté;

Talk

Les grands axes

Deux canaux : commandes / données

Analogie avec FTP^3.1 dans lequel on utilise une prise^3.2 pour les commandes, et une autre pour les données.

Cette solution est intéressantes à plus d'un titre, d'un part, les commandes peuvent être dans un format très réduit, par exemple s^3.3 pour un message, q pour quitter.

Quand au canal des données, la question est-ce qu'il est crypté ou non, ne se pose pas : il est crypté.

Bref un canal crypté pour les données, un canal non crypté pour les commandes.

Solution retenue : états et reconnaissances de motifs

On conserve des états comme par exemple déconnecté, en attente de clef ou encore en discussion. Les caractères lus au clavier ou sur le réseau rentre dans un pipeline : nature du message, mise en forme des paramètres, appel de méthode, basculement d'état. Les annexes

décrivent le fonctionnement de l'étape nature du message.

Les états

**Figure:** Cycle de vie de la structure client du serveur
$\includegraphics{ServerClientSpeakerLifeCycle.eps}$

Voir figure

**Figure:** Cycle de vie du client
$\includegraphics{ClientServerSpeakerLifeCycle.eps}$

et figure

Les problèmes liées à l'implémentation

Chaînage

Définition du problème

Si l'on considère le serveur comme une base de données, on peut énoncer le problème ainsi : il n'existe pas de clef primaire évidente.

En effet, lorsque surgit des évènements réseau sur le serveur, comme par exemple le client Binta qui diffuse un message. Dans ce cas le plus pratique serait d'accédé à la structure associée au client à l'aide d'une table de hash dont la clé serait l'identificateur de socket de Binta pour récupérer son surnom .

Ensuite il faut envoyer le message à tous les clients connectés. Le mieux serait d'avoir une liste.

Mais lorsque sur le serveur, l'évènement kill Binta surgit, on a besoin d'accéder à la structure de donnée associée à Binta à partir de son surnom : On a besoin d'une table de hash dont la clé est le surnom .

Résolution

La solution retenue est de les retenir toutes, i.e. on utilise toutes ces structures de données décrites plus haut. Les dangers d'incohérences dues à la duplication des données nous ont conduit à la plus grande vigilence et à l'établissement de spécifications très poussées ^3.4.

Conflit de surnoms

Définition du problème

Le surnom affecté à un client est en principe proposé par le client lui-même lorsque celui-ci fait un connect. Un problème se pose lorsqu'un client veut se connecter sous le pseudo Binta alors que ce pseudo est déjà utilisé par un autre client.

Résolution

Plusieurs solutions étaient envisageables:

On ne fait pas, on refuse le 2ème client.
On ne fait pas, mais avec service. On refuse le 2ème client, en lui expliquant la raison et un surnom qui pourrait marcher à l'instant T de l'essai.
On réaffecte un surnom calculé à partir de celui proposé. On n'informe pas le client. C'est cette solution qui a été choisi car elle n'engendre pas de message sur le réseau pour ce qui n'est qu'un cas d'exception.

Mort précoce

Définition du problème

Les structures de données sont cohérentes tant que tous les parties jouent le jeu. La mort précoce provoque des situations d'incohérence. En effet, lorsqu'un client est tué parce que l'utilisateur a appuyé sur la combinaison CONTROL+C, ou plus simplement une coupure d'alimentation sur le client font en sorte que le client meurt sans avoir envoyé de quit au serveur.

Si le serveur ne reçoit pas de quit, il continera à référencer le client éternellement, en particulier un who affichera la présence de ce client alors que celui-ci peut-être mort depuis une semaine.

Résolution

Plusieurs solutions étaient envisageables:

Battement de coeur, les parties envoient un message de service à leur dual tous les secondes.
Solution partielle : utilisation des signaux UNIX. La mise en place de handler gèrant les signaux SIGTERM, etc... permettent de quitter proprement le programme.
C'est cette solution qui a été implémentée.
Remarque : ceci ne résout pas le problème, tel que cela a été implémenté, de la coupure de courant sur un client.

À propos de ce document...

Secure Talk

This document was generated using the LaTeX2HTML translator Version 2002-2-1 (1.70)

The command line arguments were:
latex2htm -dir outHtml2/ -split 0 SecureTalkWeb.tex

The translation was initiated by mist on 2004-01-07

Notes

... IPV4 ^1.1: Au contraire d'IPV6, mais cette norme n'est pas encore la norme de travail
... port ^1.2: Voir man nmap et man tcpdump
... serveur ^1.3: Voir sous UNIX le fichier /etc/services
... fils ^1.4: en Ang. wireless
... exclusif)^1.5: Le XOR est à éviter car sujet au reverse-ingeniring
... ^2.1: du nom des trois auteurs Rivest, Shamir et Adleman
... bufferise ^2.2: la bufferisation est accentué par le fait que l'on utilise des messages très courts
... lu ^2.3: Elle renvoie NULL sinon
...FTP ^3.1: File Transfert Protocol
... prise ^3.2: socket
...s ^3.3: de l'anglais say
... poussées ^3.4: cf. annexes

Docs

Menu

Report for faculty (french)

Secure Talk

Table des matières

Introduction

Avant-propos

Intérêts - Objectifs

Attaque de type scan de port et sniffage

Cryptage asymétrique, - symétrique

Objectif du projet de téléinformatique

RSA

Découpage logique

La couche haute

La couche basse

Fonctions définies pour le cryptage et le décryptage des messages

Structures de données utilisées

Résumé de l'algorithme RSA

Talk

Les grands axes

Deux canaux : commandes / données

Solution retenue : états et reconnaissances de motifs

Les états

Les problèmes liées à l'implémentation

Chaînage

Définition du problème

Résolution

Conflit de surnoms

Définition du problème

Résolution

Mort précoce

Définition du problème

Résolution

À propos de ce document...

Notes