Authentification et protocole PPPOE: le cas de l'accessibilité à l'internet via "ringodialeré"

ANNEXE B

L'ORGANIGRAMME DE L'ENTREPRISE RINGO S.A.

La figure B.1 est une illustration de l'organigramme de l'entreprise Ringo S.A.

FIGURE B.1 Organigramme Ringo S.A.

Source: Entreprise Ringo S.A

ANNEXE C

LE PRINCIPE DES PROTOCOLES QUESTION/RÉPONSE

Un protocole question/réponse fonctionne d'après le principe illustré en la figure C.1 et selon le schéma suivant :

1. l'entité B qui joue le rôle de vérificateur choisit de manière aléatoire une donnée, appelée question, qui est envoyée à l'entité A qui doit prouver son identité;

2. l'entité A applique à son tour à la question une opération cryptographique basée sur un secret qu'elle détient;

3. le résultat de cette opération, appelé réponse, est renvoyé à B pour fournir la preuve de l'identité de A;

4. B atteste de l'identité de A, si sa réponse vérifie celle attendue par ce premier. FIGURE C.1 Principe général de fonctionnement d'un protocole question/réponse

ANNEXE D
L'EXEMPLE D'UN PROTOCOLE AVEC SECRET PARTAGÉ

Considérons les notations suivantes :

A Entité souhaitant se faire authentifié

B Entité jouant le rôle du vérificateur d'identité

Id_x Représentation binaire de l'identité de l'entité X

n_x Nombre aléatoire émis par l'entité X

EK(m1, _m2, . . . , m_n)Chiffrement obtenu par un algorithme symétrique basé sur la clé K et sur la chaîne binaire constituée par la concaténation des messages m1, _m2, . . . , mn

hK(m1, m2, ... , m_n) Résultat du hachage avec la clé K de la chaîne binaire constituée par la concaténation des messages m1, _m2, . . . , mn

K_xy Clé secrète partagée par les entités X et Y

Soit le protocole suivant :

1. A envoie à B : Id_a et n_a ;

2. B envoie à A : Idb,nb, EK_ab(n_a, Id_a) ou hK_ab(n_a, Id_a) ;

3. A atteste l'identité de B en comparant son calcul de EKab(na, Ida) ou hKab(na, Id_a) avec celui envoyé par B à l'étape 2. Si B est bien celui qui prétend être A envoie à B : EK_ab(n_a, nb, Idb) ou hKab(na, nb, Idb) ;

4. B prouve l'authenticité de A en comparant son calcul de EK_ab(n_a,nb, Idb) ou hKab(na, nb, Idb) avec celui que l'entité A lui a envoyé à l'étape 3.

Nota Benne

La présence des deux nombres aléatoires m_a et mb dans le troisième message de ce protocole est nécessaire pour éviter des attaques basées sur une session parallèle du même protocole. En effet, si le troisième message de ce protocole avait le même format que le second message, i.e. que m_a n'était pas pris en compte pour le calcul du résultat, l'attaquant X pourrait mettre en oeuvre le scénario suivant pour passer pour A auprès de B :

1. session 1 X envoie à B : Id_a, m_x

2. (session 1) B envoie à X : Idb , mb , EKab(mx, Id_a) ou hKab(mx, Id_a);

3. (session 2) X envoie à A : Idb,mb ;

4. (session 2) A envoie à X : Id_a , m_a , EKab(mb, Idb) ou hKab(mb, Idb);

5. (session 1) X envoie à B : EKab(mb, Idb) ou hKab(mb, Idb).

6. B authentifiera X comme étant A car la preuve de l'authenticité de l'identité se fera par la comparaison de EKab(mb, Idb) ou de hKab(mb, Idb) envoyé par X à l'étape 5 avec celui calculé par B.

Dans ce scénario, A comme B peuvent jouer aussi bien le rôle du demandeur que du vérificateur, ceci dépendant de celui ayant initié le processus d'authentification. Ainsi, la deuxième session permet elle à l'entité X d'utiliser l'entité A comme oracle pour prédire les réponses aux questions de l'entité B. Pour cela, X se fait passé pour le demandeur B auprès du vérificateur A.

Cette attaque réussit parce que le second message de la deuxième session peut parfaitement être utilisé en tant que troisième message de la première session. Autrement dit le vérificateur B accepte d'authentifier n'importe quel utilisateur, du moment que ce dernier peut prouver la connaissance d'un secret partagé entre le vérificateur B et un demandeur connu par ce dernier. Dans notre cas, à cause du manque de considération de m_a dans le calcul du résultat, la preuve est faite à l'étape 5.