> > Ce que je veux en effet, c'est qu'entre A(Client) et B(Server), C ne puisse > pas comprendre ce que A envoie à B et ne puisse pas non plus, le renvoyer > (validité). > Pour ça j'imaginais que B envoie à A un token avec un délai d'expiration et > A doit bien entendu le renvoyer. Cependant, pendant ce laps de temps, C peut > très bien envoyé ce qu'il veut. > > Donc à ce moment là, je pensais tout simplement crypter les échanges de A à > B mais aussi de B à A. > Comme ça, si C arrive à intercepter le token, il sera crypté et donc ne > pourra pas rien en faire. En plus, une fois que A a renvoyé son score (par > exemple) avec le token, ce même token expire donc si C renvoie le même > message, ce dernier sera rejeté. > > Alors dites moi si j'ai faux pour le moment ? > > Par contre, concernant le cryptage c'est là que le bas blesse. Un SWF peut > facilement se décompiler et donc la clé publique sera visible. Je n'ai pas > envie d'obfusquer mon code, trop lourd à faire et j'ai eu de mauvaises > surprises (des erreurs au runtime). > > Donc voilà, je me demande qu'elles sont vos solutions pour ce type de > problème ? >
tu utilises SSL c'est chiant et payant a configurer coté serveur (sans compter le crossdomain) mais une fois que ton SWF est servi sous SSL tu as au moins une encryption de 128bit par defaut et pas besoin d'ajouter une encryption dans le swf ou coté serveur apres aussi on peut faire du PKI dans Flash et coté server sans SSL, car y a des gens qui pensent que c'est moins cher sans payer la taxe verisign, c'est possible sauf qu'il n y a pas une seule lib de crypto qui est vraiment potable coté flash donc beaucoup de code en perspective je le repette a nouveau, mais dans le cas de PKI tu n'en as rien a fouttre de protéger la clef publique voir http://en.wikipedia.org/wiki/Public_key_infrastructure ce que tu veux proteger c'est la clef privée coté serveur bah pas de soucis ca reste coté serveur le client flash recup la clef publique donc du serveur, et genere sa propre clef publique qu'il envoit donc au serveur oui, le flash contient aussi la clef privée, mais en soit ce n'est pas un probleme (vu que le client genere ses propres clefs, ces clefs ne sont valide que pendant la session client, un client tierce ne peut pas intercepter cela) pour implementer ca en AS3 je conseille de se baser sur ca http://www-cs-students.stanford.edu/~tjw/jsbn/ (passer par une classe BigInteger c'est LA bonne approche) pour la partie authentification tu peux t'inspirer de ce que fait kerberos http://en.wikipedia.org/wiki/Kerberos_(protocol) donc maintenant c'est comment tout ca se connecte 1 - si tu as un system de login/password sur ton site tu peux utiliser ca pour l'authentification de départ 2 - apres que le client soit loggué ou pas tu vas validé sa connection tu peux: associer le client a un session-id et/ou IP coté serveur idealement tu veux donner un token d'identification au client (si client loggué le serveur peut aussi associé le login a la session-id/IP) A(client) -- se connecte à --> B(serveur) B crée un token 0x1234 B crée une entrée "client" avec les infos - session-id = 01234ABCDEF - IP = 123.123.123.123 - token = 0x1234 (- login) [option] A recoit la clef publique de B A recoit le token cad que pour ton SWF tu as 2 flashvars key=80808080808080&token=1234 -> important: a chaque fois que le serveur sert un *.swf dans une page il faut qu'il genere un nouveau token -- echange de clef publiques (debut du handshake) A envoit sa clef publique a B B dans l'entrée "client" ajoute l'info - clef publique = key publique de A A envoit un message crypté a B contenant le token (crypté avec la clef publique de B) -> le token etant unique il ne peut y avoir qu'une seule connection client envoyant ce token si un autre client, ou autre connection envoit le meme token ca veut dire que qlqn essaye de dupliquer la session client B decrypte le message de A (avec la clef privée de B) B recupere le token dans le message decrypté B desactibe le token 0x1234 (comme ca personne d'autre ne peut l'utiliser) B crée une "clef partagée" unique pour ce client et ajoute l'info - clef partagée = XYZXYZXYZetc. B renvoit un message crypté a A contenant une "clef partagée" (crypté avec la clef publique de A) A decrypte le message de B (avec la clef privée de A) A obtient la "clef partagée" -- fin de l'echange sous PKI (la fin du handshake) on peut considéré le client authentifié: A et B peuvent s'échanger des données avec la "clef partagée" cad utiliser n'importe quelle encryption symetrique (par ex: TEA) le serveur pour chaque client a cette liste d'info - session-id = 01234ABCDEF - IP = 123.123.123.123 - token = 0x1234 (- login) [option] - clef publique = ... - clef partagée = ... coté serveur, on peut utiliser le session-id et l'IP pour accepter chaque requette client, mais sans pour autant considéré cela comme une validation -> si la session-id est differente, automatiquement rejecté -> si l'IP est différente, automatiquement rejecté (d'autres params peuvent etre utilisés comme le "login", le code pays, etc.) -> si la session-id ET l'IP sont correctes alors le serveur peut decrypter le message avec la "clef partagé" -> si la clef partagée n'est pas trouvée - il y a un probleme, on peut tout déconnecter etc. -> si la clef partagée est présent on decrypte le message avec - si le message renvoit du "garbage", on deconnecte tout, etc. - si le message est "compris" on continue l'echange des donnees, etc. ca, c'est un bon début pour commencer a avoir qlqch de secure ensuite on peut aller plus loin on peut s'inspirer de HMAC http://c2.com/cgi/wiki?HmacUserAuthentication http://en.wikipedia.org/wiki/HMAC cad que en plus du token, on peut garder un compte des echanges cad que tous messages entre A et B aura un "nombre" A sait qu'il envoit le message "1" a B B sait qu'il repond avec le message "2" a A etc. comme ca, si qlqn essaye de se mettre au milieu des echanges de messages et bah cela decalera le compte et le serveur ou client peut savoir donc qu'il y a un probleme idem avec le session-id, on peut avoir un timeout et donc forcer un client a refaire le handshake si il y a eut un temps d'attente considéré "trop long" entre 2 echanges -> on peut aussi ajouter un echange de message "idle" pour garder la session "active" et donc valide zwetan -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes FCNG. Pour envoyer un message à ce groupe, adressez un e-mail à [email protected]. Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse [email protected]. Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/fcng?hl=fr
