Discussion :

[DeusXL]

(J'espère que c'est la bonne section, je programme en .NET mais je pense que ça touche plus le développement réseau qu'autre chose)

Voilà je vous explique mon problème, pas bien compliqué :
J'ai un serveur de jeu auquel se connectent des clients identifiés. Inutile de dire que le client envoit parfois des données très confidentielles (du style mots de passes) et qu'il a donc fallu mettre au point un système pour crypter les données de la manière la plus efficace possible.
En me documentant un peu j'ai vu que ce qui était le plus simple était d'utiliser un algorithme symmétrique (type DES ou Rijndael) en envoyant les clefs de cryptage avec un algorithme asymétrique (type RSA).
Ainsi le schéma est :
Serveur -> Client : envoit de la clef publique RSA pour crypter.
Cilent -> Serveur : envoit de la clef de l'algo symétrique pour crypter (et décrypter côté client).
Serveur -> Client : envoit d'une autre clef d'algo symétrique pour crypter (et décrypter côté serveur).
Ainsi on a l'assurance que les clefs n'ont pas été décryptée pendant son envoit.

Jusqu'ici tout va bien mais se pose à moi deux problèmes :
Le premier est simple, si le client se connecte à un faux serveur relié au vrai serveur. Le schéma devient :
Serveur -> Faux serveur : envoit de la clef publique RSA pour crypter.
Faux serveur -> Client : envoit d'une fausse clef publique RSA.
Client -> Faux serveur : envoit d'une clef symétrique.
Faux serveur -> Serveur : envoit d'une fausse clef symétrique.
Serveur -> Faux serveur : envoit d'une autre clef symétrique.
Faux serveur -> Client : envoit d'une fausse clef symétrique.
Ainsi, le faux serveur peut parfaitement intercepter n'importe quoi et l'analyser, sans qu'on y voit rien.
Ceci ne devrait jamais arriver étant donné que pour que le client se connecte au faux serveur, il faudrait qu'il le veuille... Et si c'est le cas, le fait qu'il puisse décrypter son propre mot de passe n'est pas le plus grand problème auquel j'ai eu à faire face.

Mon second problème est beaucoup plus tordu... Est-il possible que quelqu'un arrive par exemple à installer un logiciel sur le PC client (ou ailleurs) qui intercepterait les packets et les modifierait ? Ainsi, ce logiciel agirait en quelques sorte comme le faux serveur vu précédemment et pourrait, à l'insu du client, décrypter tout ce qui s'y passe sans problème.
Ce genre de possibilité est-elle à envisager sérieusement ?
Y a-t-il une erreur dans l'architecture ? (je suis vraiment débutant dans le domaine de la sécurité)

[dockurt2k]

Bravo pour avoir repéré ce problème sans documentation extérieure.
Il est connu sous le nom de Man-In-The-Middle.

Je me suis heurté a ce problème récemment (dev d'un protocole de messagerie instantanée sans serveur et sécurisé). Il n y a malheureusement pas de solution magique. Tu n a guère le choix, il te faut distribuer les clefs publiques manière sécurisé, soit:

• en utilisant une infrastructure de distribution de cle publique sécurisé (http://en.wikipedia.org/wiki/Public_key_infrastructure). Exemple le plus celebre, les certificats et Certificate Authority
• En distribuant les clefs par un autre moyen de distribution sécurisé (emails encrypte, main a main, ...)

Dans ton cas cependant il y a peut être une solution viable, intégrer la clef publique du serveur directement dans les clients. Je pense que ca empêcherai les attaques MIM efficacement tant que tu garde le contrôle sur la distribution du client.

[DeusXL]

Dans ton cas cependant il y a peut être une solution viable, intégrer la clef publique du serveur directement dans les clients. Je pense que ca empêcherai les attaques MIM efficacement tant que tu garde le contrôle sur la distribution du client.

Le problème est que je n'ai pas le moindre contrôle sur la distribution du client, dans le cas d'un jeu sur internet, c'est un peu trop difficile.
Cependant, étant donné que j'utilise .NET, je pense que c'est la solution la plus viable en effet... Je pense qu'il existe des moyens de mettre une clef publique dans le client de manière protégée... (car le code .NET peut être désassemblé et vu... donc même mettre la clef dans une dll externe ne résoudrait pas vraiment le problème).

Je vais creuser ça et si ma solution ne touche pas trop .NET, je la posterai ici

Merci pour avoir confirmé mes impressions, je met un tag résolu et vous tiendrai au courant

[dockurt2k]

Quand je parlais de distribution contrôlé je voulais surtout dire qu'il faut que tout tes utilisateurs utilisent ton client dans une version non modifié. Des fois que quelqu'un s amuse a le recompiler en modifiant la clef et le serveur à atteindre puis en le publiant sur un autre site que le tient.

Il est vrai que si tu peut carrément cacher la clef ce sera mieux (dotfuscator un outil de MS est peut être utile ici). Enfin c'est une clef publique, sa distribution n est pas tres grave.

J oubliais, il te faudra aussi intégrer une deuxième clef publique qui servira au client à vérifier que ce qu il reçoit vient bien du serveur.Signature des messages . Tu pourrais utiliser le même set de clef mais c est déconseillé.

[dockurt2k]

Je viens d aller voir le site de ton profil.

Sacre travail que tu as realise sur Irrlicht, bravo. Je regarderais ca de plus prés ce soir. Je suppose que c est pour Irrlicht que tu as commencé ce thread ?

Bon courage

[DeusXL]

Bon alors je résume ce que j'ai compris jusque là :
Je met une clef publique dans le client dès la compilation, et la clef privée correspondant dans le serveur.
Le serveur n'est pas redistribué donc là pas de problème, la clef publique du client, elle, est visible par tout le monde.

Au moment de la connexion, le serveur signera les échanges critiques avec sa clef privée générée à la compilation, ainsi le client peut être sûr que ce message qu'il reçoit vient du bon serveur.
Donc notre hacker aussi saît juste là que le client parle au bon serveur, mais il ne peut pas communiquer en se faisant passer pour le serveur.

Le client, pour prouver son authenticité, n'a qu'une solution simple : son mot de passe.
Il envoit login + mot de passe + clef d'un algorithme symétrique au serveur, le tout encrypté avec la clef publique du serveur.

La communication reprend entre les deux, crypté par Rijndael par exemple au moyen de la clef générée par le client.

Voilà je crois que jusqu'ici tout va bien, on a assuré les deux parties qu'ils communiquaient bien ensemble.
Je me demande s'il existerait un moyen autre que le login pour assurer le serveur mais à partir du moment où le client est presque Open Source, je n'en vois aucun.

[EDIT au sujet de ta réponse]
Merci
En fait ce qui est dans ce thread est un peu hors de tout contexte... Je dois actuellement me pencher sur la sécurité des échanges dans mon jeu (fait avec Irrlicht, oui) et j'en profite pour bien me documenter sur tout ce qui se passe. Je pense que les solutions que je met en oeuvre sont exagérées pour le domaine, étant donné qu'à ma connaissance, la plupart des jeux réseau à identification sont très facilement analysables, étant non cryptés ou crypté d'une manière assez superficielle (principalement pour ne pas surcharger le serveur) mais j'en profite pour me documenter sur un des sujet que je maîtrise le moins, ça ne coûte rien

[dockurt2k]

Exactement la bonne procedure je pense.

Par contre dans la documentation que j'ai put consulter il est recommande d'utiliser un set cle publique/prive différente pour la signature et le cryptage (peut etre pour eviter que si un set est corrompue tout le systeme s'ecroule).

Enfin tu auras deja une trés bonne securite sans je pense.

bon courage