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é
Idx Représentation binaire de l'identité
de l'entité X
nx Nombre aléatoire émis par
l'entité X
EK(m1, m2, . . . , mn)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, ... , mn) Résultat du hachage avec
la clé K de la chaîne binaire constituée par la
concaténation des messages m1, m2, . . . , mn
Kxy Clé secrète partagée par les
entités X et Y
Soit le protocole suivant :
1. A envoie à B : Ida et na ;
2. B envoie à A : Idb,nb, EKab(na,
Ida) ou hKab(na, Ida) ;
3. A atteste l'identité de B en comparant son calcul
de EKab(na, Ida) ou hKab(na, Ida) avec celui envoyé par B
à l'étape 2. Si B est bien celui qui prétend être A
envoie à B : EKab(na, nb, Idb) ou hKab(na, nb,
Idb) ;
4. B prouve l'authenticité de A en comparant son calcul
de EKab(na,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
ma 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 ma 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 : Ida,
mx
2. (session 1) B envoie à X : Idb , mb ,
EKab(mx, Ida) ou hKab(mx, Ida);
3. (session 2) X envoie à A : Idb,mb ;
4. (session 2) A envoie à X : Ida ,
ma , 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 ma dans le
calcul du résultat, la preuve est faite à l'étape 5.
|