RSA : Lutter contre les attaques de l'homme du milieu (MITM)
Bonjour,
je souhaite crypter les échanges entre un client java et un serveur apache/PHP.
Dans un premier temps, je compte utiliser l'algorithme de cryptage asymétrique RSA me permettant d'échanger une clef secrète puis ensuite utiliser cette dernière pour communiquer via un algorithme de cryptage symétrique (exemple : 3DES).
Pour le moment, voici le détail de ma réflexion sur le sujet :
--------------------------------------------------------------
1) le client demande au serveur de générer une paire de clefs RSA,
2) le serveur garde en session la clef privée et retourne au client l'identifiant de la session PHP + la clef publique générée,
3) le client génère une clef secrète et la crypte via la clef publique qu'il vient de recevoir et renvoit l'id de session + la clef secrète cryptée au serveur,
4) le serveur décrypte la clef secrète cryptée via sa clef privée qu'il a gardée en session,
5) le client et le serveur peuvent communiquer en utilisant la clef secrète...
Cependant, ce système ne résisterait pas à l'attaque de l'homme du milieu.
Si une personne mal intentionnée écoute la conversation, il peut générer une paire de clefs RSA et se faire passer pour le serveur pour récupérer la clef secrète puis dans un second temps pour récupérer le hash du mot de passe.
J'ai bien pensé utilisé la notion de signature.
Le client et le serveur connaîtraient la signature du serveur.
Par exemple, "coucou" qui hasché devient "fdjfhjfqh....".
Le serveur enverrait au client la clef publique + la signature hasché et cryptée via la clef privée.
Le client décrypterait la signature via la clef publique et s'assurerait que le résultat produit serait bien égal à "fdjfhjfqh....".
Cependant, cela ne me satisfait pas car un attaquant pourrait facilement connaître la signature du message via la signature cryptée + clef publique en clair.
Et lors de la prochaine connexion de l'utilisateur, l'attaquant pourrait générer une paire de clefs RSA, signer "fdjfhjfqh...." avec sa clef privée et se faire
passer pour le serveur.
Je ne vois pas bien de solution à ce problème.
J'entends partout sur internet parler de notion de certificat et de tiers de confiance mais je ne vois pas bien en quoi cela peut éviter l'attaque de l'homme du milieu (MITM).
Dans tous les cas, il faut bien envoyer au client java la clef publique générée et je ne vois pas comment ce dernier peut s'assurer que la clef publique est bien celle du serveur et non pas d'un attaquant ?
Même en utilisant la notion de certificat de type X.509 comme signature, un attaquant pourrait toujours récupérer la signature puisqu'on doit envoyer la signature cryptée + la clef publique...
J'ai l'impression de tourner en rond...
N'hésitez pas à éclairer ma lanterne....
Merci pour votre aide,
F.
Répondre avec citation
: 
Partager