• Announcements

    • Thear

      Battle For Azeroth : Ouverture du royaume !   31/12/2014

      Le royaume Sethraliss ouvrira ses portes le samedi 16 mars 2019 à 14h00 CET. Prévenez vos amis et partez à l'aventure de cette nouvelle extension ! Pour toutes les infos, rendez-vous ici:  
    • Thear

      Battle For Azeroth - Guide de téléchargement   11/02/2015

      Voici le guide complet pour pouvoir rejoindre notre serveur Battle For Azeroth:  
    • Thear

      Recrutement Équipe Firestorm   23/05/2018

      Bonjour à tous et à toutes, l'équipe Firestorm est actuellement à la recherche de 3 nouveaux membres dans chacun de ses multiples pôles : Maîtres du Jeu, Modérateurs, Animateurs. 
      N'hésitez pas à vous rendre ici pour connaître les recrutements en cours : http://fr.forum.firestorm-servers.com/index.php?/forum/11-recrutements/

      Merci pour votre futur engagement au sein de l'équipe Firestorm.
    • Ouroboros

      Gamepoints.mx (Paypal)   09/07/2018

      Paypal est de retour sur Firestorm !  Pour plus d'informations : https://gamepoints.mx  
    • Skydosh

      Suggestions   23/07/2019

      La section suggestion a été remise à zéro, si vous aviez posé une proposition, nous vous invitons à la remettre.
Sign in to follow this  
Followers 0
Praetonus

Le protocole d'authentification de WoW (1/2)

10 posts in this topic

Bonjour.

Aujourd'hui, nous allons parler d'authentification. Plus précisément, nous allons parler du processus d'authentification de World of Warcraft, qui se déroule pendant le bref instant entre votre entrée de mot de passe et votre arrivée sur l'écran de sélection de royaume, et qui permet de s'assurer que seules les personnes connaissant votre mot de passe puissent accéder à vos personnages. En effet, derrière ce fameux « connexion » se cache un procédé complexe que nous allons explorer. Cette présentation est divisée en deux parties. La première, celle que vous êtes en train de lire, dresse un portrait théorique du protocole utilisé par World of Warcraft : Secure Remote Password. La seconde partie est dédiée aux spécificités du protocole pour World of Warcraft et à l'implémentation d'un serveur d'authentification minimal.

Il est recommandé de disposer d'une certaine affinité avec les mathématiques pour pouvoir suivre correctement le présent article. Dans la deuxième partie, nous utiliserons le langage de programmation Python, une connaissance basique de celui-ci est donc conseillée.

Quelques notions mathématiques et cryptographiques

Arithmétique modulaire

L'arithmétique modulaire est une branche de l'algèbre qui se repose sur la division euclidienne et où l'on travaille sur un « anneau » d'entiers. Autrement dit, on revient à 0 lorsque l'on atteint une certaine valeur. L'exemple le plus parlant est celui d'une horloge : si on part de 10 heures et qu'on avance de 5 heures, on termine à 3 heures au lieu de 15. On se trouve ici dans un système modulo 12. On associe à cela la notion de congruence. On dit que deux entiers sont congruents modulo n si ils ont le même reste dans la division euclidienne par n. On écrit a ≡b (mod n). Pour reprendre l'exemple de l'horloge, 3 ≡15 (mod 12).

Nous allons également parler des racines primitives modulo n. Derrière ce nom compliqué se cache un concept très simple. Si on prend un nombre entier n et l'ensemble des nombres premiers avec n (ensemble pris modulo n), un nombre g est une racine primitive modulo n si chaque élément de l'ensemble peut être exprimé sous la forme g^x. Par exemple, si on prend n = 10, les nombres premiers avec sont 1, 3, 7 et 9. On a alors 3^2 ≡9, 3^3 ≡7, 3^4 ≡1, 3^5 ≡3 (mod 10). 3 est donc une racine primitive modulo 10. Ce concept est encore plus intéressant si on prend n premier. En effet, les nombres premiers avec un nombre premier sont tous les nombres inférieurs à celui-ci. À partir de la racine primitive d'un nombre premier, on peut donc obtenir tous les nombres de l'anneau modulaire associé.

Fonctions de hachage

Une fonction de hachage permet, à partir d'une donnée source, de calculer une empreinte associée à cette donnée. En cryptographie, les fonctions de hachage utilisées sont :

  • À sens unique : il est très difficile de retrouver la source à partir de l'empreinte ;
  • Chaotiques : pour une faible variation de la source, l'empreinte varie grandement ;
  • Résistantes aux collisions : la probabilité que deux données différentes aient la même empreinte est très faible.

Les fonctions de hachage les plus connues sont SHA-1 et les familles SHA-2 et SHA-3 (cette dernière étant un sous-ensemble de la famille Keccak).

Exemple :

SHA-1("Portez ce vieux whisky au juge blond qui fume") -> 6919a3247b50ab45fd704d03053cd8c0235af66f
SHA-1("Portez ce vieux whisky au juge brun qui fume")  -> 1de8cab778e678e1ef5db69ab3afc755d668c401

Les sels

En cryptographie, un sel est une donnée générée aléatoirement pour chaque utilisateur, qui sera associée aux données de celui-ci. L'utilisation d'un sel permet d'obtenir, avec la même fonction de transformation et les mêmes données utilisateur, une sortie différente. Par exemple, dans le cas d'une fonction de hachage et d'un mot de passe, disposer d'un sel différent provoque la génération d'une empreinte distincte entre deux utilisateurs ayant le même mot de passe.

Le protocole SRP

Maintenant que nous avons introduit les concepts dont nous allons avoir besoin, nous pouvons aborder le cœur du sujet, le protocole Secure Remote Password (SRP). Ce protocole permet à un client et à un serveur de se prouver mutuellement qu'ils possèdent le même mot de passe, et ce sans transmettre ledit mot de passe ou une information directement dérivée de celui-ci, ce qui présente des avantages évidents de sécurité. On parle de preuve à divulgation nulle de connaissance. Pour les connaisseurs, SRP est à la base de l'authentification dans le protocole SSL/TLS (qui est lui même à la base du protocole HTTPS).

SRP a évolué au fil des vulnérabilités découvertes dans les premières versions du protocole. Il existe en tout 5 versions, les deux dernières étant quasiment identiques. Nous allons parler de chaque version et des vulnérabilités associées.

SRP-1

Les données de SRP-1 sont les suivantes :

N : Un grand nombre premier sûr (N = 2q + 1 avec q premier (ce qui fait de q un nombre premier de Sophie-Germain))
g : Une racine primitive modulo N
s : Un sel
I : L'identifiant de l'utilisateur
P : Le mot de passe de l'utilisateur
H() : Une fonction de hachage
^ : L'exponentiation modulo N
a, b : Valeurs privées
A, B : Valeurs publiques
x : Clé privée
v : Vérifieur du mot de passe

Lors de l'inscription de l'utilisateur, les données suivantes sont calculées :

x = s * H(P)   (s est choisi aléatoirement)
v = g^x        (calcul du vérifieur)

Le serveur stocke I, s et v. Lors d'une connexion, le protocole se déroule de la façon suivante :

Client -> Serveur : I, A ; A = g^a      (le client envoie son identité. a est choisi aléatoirement)
          Serveur : B = g^b             (b est choisi aléatoirement)
Serveur -> Client : s, Z ; Z = v + B    (le serveur envoie le sel et sa valeur publique « masquée » par le vérifieur)

           Client : x = s * H(P)        (l'utilisateur entre son mot de passe)
           Client : v = g^x             (calcul du vérifieur)
           Client : B = Z - v           (récupération de B)
           Client : S = B^(a + x)       (calcul de la clé de session)
           Client : K = H(S)

          Serveur : S = (A * v)^b       (calcul de la clé de session)
          Serveur : K = H(S)

Les deux parties ont calculé une clé de session partagée. Vous avez surement remarqué que la formule n'est pas la même chez le client et chez le serveur. La démonstration de l'équivalence est laissée en exercice au lecteur. Le client et le serveur doivent à présent se prouver mutuellement la correspondance de leur clé :

Client -> Serveur : H(Z, K)    (« , » désigne la concaténation (K accolé à Z))
Serveur -> Client : H(A, K)

Après cela, l'authentification est complète.

Afin d'assurer la robustesse des valeurs générées, les précautions suivantes sont employées :

  • Le client stoppe l'opération si Z ≡0 (mod N) ;
  • Le serveur stoppe l'opération si A * v appartient à {-g, -1, 0, 1, g} (mod N) ;
  • Le client présente sa preuve de K en premier. Si le serveur constate que la preuve du client est fausse, il stoppe l'opération sans présenter sa propre preuve.

Vulnérabilité de SRP-1

SRP-1 possède une faille qu'un attaquant peut exploiter après avoir compromis le serveur et obtenu un vérifieur v :

Attaquant : T = v^(-1)
Attaquant : q : nombre aléatoire tel que 1 < q < N - 1

Attaquant -> Serveur : u, A ; A = g^q * T (au lieu de A = g^a)
Serveur -> Attaquant : s, Z ; Z = v + B

Serveur : S = (A * v)^b
Serveur : K = H(S)

Par substitution :

S = (g^q * T * v)^b
  = (g^q)^b
  = g^(q * b)

Attaquant : B = Z - v (on peut calculer B car on connait v)
Attaquant : S = B^q
Attaquant : K = H(S)

Par substitution :

B^q = (g^b)^q
    = g^(q * b)

L'attaquant a bien calculé la même clé que le serveur et peut donc s'authentifier.

SRP-2

SRP-2 apporte quelques modifications à la version 1 afin de corriger la vulnérabilité de celle-ci.

Les données sont :

N : Le produit de deux nombres premiers surs p et q (p = 2j + 1, q = 2k + 1 avec j, k, p, q premiers)
g : Une racine primitive modulo N
s : Un sel
I : L'identifiant de l'utilisateur
P : Le mot de passe de l'utilisateur
H() : Une fonction de hachage
^ : L'exponentiation modulo N
a, b : Valeurs privées
A, B : Valeurs publiques
x : Clé privée
v : Vérifieur du mot de passe

Lors de l'inscription de l'utilisateur, les données suivantes sont calculées :

x = s * H(P)    (s est choisi aléatoirement)
v = g^x         (calcul du vérifieur)

Le serveur stocke I, s et v. Lors d'une connexion, le protocole se déroule de la façon suivante :

Client -> Serveur : I, A ; A = g^a       (le client envoie son identité. a est choisi aléatoirement)
          Serveur : B = g^b              (b est choisi aléatoirement)
Serveur -> Client : s, Z ; Z = v + B     (le serveur envoie le sel et sa valeur publique « masquée » par le vérifieur)

           Client : x = s * H(P)         (l'utilisateur entre son mot de passe)
           Client : v = g^x              (calcul du vérifieur)
           Client : B = Z - v            (récupération de B)
           Client : S = B^(2 * a + x)    (calcul de la clé de session)
           Client : K = H(S)

          Serveur : S = (A^2 * v)^b      (calcul de la clé de session)
          Serveur : K = H(S)

Les deux parties ont calculé une clé de session partagée. De même, la démonstration de l'équivalence est laissée en exercice au lecteur. La preuve se déroule de la même manière que précédemment :

Client -> Serveur : H(Z, K)
Serveur -> Client : H(A, K)

Après cela, l'authentification est complète.

Afin d'assurer la robustesse des valeurs générées, les précautions suivantes sont employées :

  • Le client stoppe l'opération si Z ≡0 (mod N) ;
  • Le serveur stoppe l'opération si A ≡0 (mod N) ;
  • Le client présente sa preuve de K en premier. Si le serveur constate que la preuve du client est fausse, il stoppe l'opération sans présenter sa propre preuve.

Vulnérabilité de SRP-2

SRP-2 ne présente pas de faille connue. Néanmoins, aucune garantie n'est faite sur les possibilités de factorisation du module N, ce qui peut faciliter l'attaque par cryptanalyse.

SRP-3

SRP-3 comporte de larges modifications par rapport aux versions 1 et 2.

Les données sont :

N : Un grand nombre premier sûr (N = 2q + 1 avec q premier)
g : Une racine primitive modulo N
s : Un sel
I : L'identifiant de l'utilisateur
P : Le mot de passe de l'utilisateur
H() : Une fonction de hachage
^ : L'exponentiation modulo N
u : Le « paramètre de brouillage aléatoire »
a, b : Valeurs privées
A, B : Valeurs publiques
x : Clé privée
v : Vérifieur du mot de passe

Lors de l'inscription de l'utilisateur, les données suivantes sont calculées :

x = H(s, P)    (s est choisi aléatoirement)
v = g^x        (calcul du vérifieur)

Le serveur stocke I, s et v. Lors d'une connexion, le protocole se déroule de la façon suivante :

Client -> Serveur : I, A ; A = g^a             (le client envoie son identité. a est choisi aléatoirement)
Serveur -> Client : s, B, u ; B = v + g^b      (b et u sont choisis aléatoirement)

           Client : x = H(s, P)                (l'utilisateur entre son mot de passe)
           Client : v = g^x                    (calcul du vérifieur)
           Client : S = (B - v)^(a + u * x)    (calcul de la clé de session)
           Client : K = H(S)

           Serveur : S = (A * v^u)^b           (calcul de la clé de session)
           Serveur : K = H(S)

Les deux parties ont calculé une clé de session partagée. De même, la démonstration de l'équivalence est laissée en exercice au lecteur. Le client et le serveur doivent à présent se prouver mutuellement la correspondance de leur clé :

Client -> Serveur : M = H(H(N) xor H(g), H(I), s, A, B, K)     (xor correspond au OU exclusif)
Serveur -> Client : H(A, M, K)

Après cela, l'authentification est complète.

Afin d'assurer la robustesse des valeurs générées, les précautions suivantes sont employées :

  • Le client stoppe l'opération si B ≡0 ou u ≡0 (mod N) ;
  • Le serveur stoppe l'opération si A ≡0 (mod N) ;
  • Le client présente sa preuve de K en premier. Si le serveur constate que la preuve du client est fausse, il stoppe l'opération sans présenter sa propre preuve.

Vulnérabilité de SRP-3

Cette version du protocole présente une faiblesse assez subtile. Si un attaquant se fait passer pour un serveur légitime, il peut tenter de casser le mot de passe du client deux fois par tentative de connexion au lieu d'une :

  • L'attaquant calcule B = g^i + g^j (au lieu de B = g^x + g^b avec b aléatoire) ;
  • Le client calcule B - g^x. Si x = i, cette valeur vaut g^j et si x = j, elle vaut g^i ;
  • L'attaquant calcule deux clés de session avec x = i, b = j et x = j, b = i. Si l'une des deux valeurs correspond à la preuve M du client, le mot de passe a été trouvé.

SRP-6 et SRP-6a

Version actuelle du protocole, SRP-6 corrige la vulnérabilité de SRP-3.Les données sont :

N : Un grand nombre premier sûr (N = 2q + 1 avec q premier)
g : Une racine primitive modulo N
k : Paramètre multiplicatif (k = H(N, g) pour SRP-6a, k = 3 pour SRP-6)
s : Un sel
I : L'identifiant de l'utilisateur
P : Le mot de passe de l'utilisateur
H() : Une fonction de hachage
^ : L'exponentiation modulo N
u : Le « paramètre de brouillage aléatoire »
a, b : Valeurs privées
A, B : Valeurs publiques
x : Clé privée
v : Vérifieur du mot de passe

Lors de l'inscription de l'utilisateur, les données suivantes sont calculées :

x = H(s, P)    (s est choisi aléatoirement)
v = g^x        (calcul du vérifieur)

Le serveur stocke I, s et v. Lors d'une connexion, le protocole se déroule de la façon suivante :

Client -> Serveur : I, A ; A = g^a                 (le client envoie son identité. a est choisi aléatoirement)
Serveur -> Client : s, B, u ; B = k * v + g^b      (b et u sont choisis aléatoirement)

Client et Serveur : u = H(A, B)

           Client : x = H(s, P)                    (l'utilisateur entre son mot de passe)
           Client : v = g^x                        (calcul du vérifieur)
           Client : S = (B - k * v)^(a + u * x)    (calcul de la clé de session)
           Client : K = H(S)

          Serveur : S = (A * v^u)^b                (calcul de la clé de session)
          Serveur : K = H(S)

Les deux parties ont calculé une clé de session partagée. De même, la démonstration de l'équivalence est laissée en exercice au lecteur. Le client et le serveur doivent à présent se prouver mutuellement la correspondance de leur clé :

Client -> Serveur : M = H(H(N) xor H(g), H(I), s, A, B, K)    (xor correspond au OU exclusif)
Serveur -> Client : H(A, M, K)

Après cela, l'authentification est complète.

Afin d'assurer la robustesse des valeurs générées, les précautions suivantes sont employées :

  • Le client stoppe l'opération si B ≡0 ou u ≡0 (mod N) ;
  • Le serveur stoppe l'opération si A ≡0 (mod N) ;
  • Le client présente sa preuve de K en premier. Si le serveur constate que la preuve du client est fausse, il stoppe l'opération sans présenter sa propre preuve.

Utilité de k

Le paramètre k corrige la vulnérabilité de SRP-3. En effet, si l'attaquant ne connait pas le logarithme discret de k en base g (le nombre l tel que g^l ≡k (mod N)), il ne peut pas faire deux tentatives en une. Le papier de présentation de SRP-6 explique pourquoi le nombre 3 est sûr dans le cas général. Néanmoins, un k constant présente également une faiblesse : un attaquant peut choisir N et g tels que le logarithme discret de k soit calculable. La valeur de k dans la version 6a corrige ce problème en rendant le calcul du logarithme très difficile.

 

Vous êtes arrivé au terme de cette première partie, n'hésitez pas à poser des questions, demander des précisions et relever les possibles coquilles. La partie deux sera disponible très prochainement.

Edited by Praetonus
4 people like this

Share this post


Link to post
Share on other sites

Merci de m'avoir donné mal à la tête de si bon matin Prae.

Share this post


Link to post
Share on other sites

Pas de quoi, je suis là pour ça.

Share this post


Link to post
Share on other sites

Tu sais que c'est plus compréhensible comme ça que sur mes cours ?

Share this post


Link to post
Share on other sites

Super intéressant mais bien compliqué quand même  *va chercher une aspirine* ><

Share this post


Link to post
Share on other sites

Copier /Coller le cours se trouve sur wiki lol .

Share this post


Link to post
Share on other sites
Il y a 2 heures, Fury a dit :

Copier /Coller le cours se trouve sur wiki lol .

Lien ?

Share this post


Link to post
Share on other sites

Je veux la suite ! :3

Share this post


Link to post
Share on other sites

Excellente explication, je penserais à changer mes vieux protocol d'authentification par une auth de ce genre dans mes prochaine jeux ;)

Share this post


Link to post
Share on other sites

Super intéressant. ça fait plaisir de voir des posts comme cela.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0