Carte jettable ou calculette, c'est pareil, tout ca c'est de l'OTP. mot de passe qui change avec le temps et/ou un compteur d'evenements et/ou un challenge.
Qu'ils soient generes a la volee ou de facon statique puis envoyer par la poste, fax ou a dos de corbeau, ca revient au meme, conceptuellement.
C'est effectivement tres costaud a casser (chiffrement 3des ou asymetrique en fonction des prestataires).
L'idee est toute simple: chiffrer avec un algo fort la date et/ou un compteur d'evenement et/ou le challenge cote client et l'envoyer au serveur.
Le serveur a lui la connaissance de la cle du client (certificat publique si asymetrique, prive si symetrique) et genere des mots de passes dans une certaine fenetre (temps/evenements + eventuel challenge) jusqu'a tomber sur le meme.
S'il trouve pas, va te faire voire.
Dans ma boite on faisait du symetrique (la gestion des certifs, c'ets un gros boulot, plus simple de gerer un cle symetrique), je me dit que dans le cas de l'asymetrique il doivent se contenter de dechiffrer l'otp et de verifier si les donnees envoyees sont bien celles attendues (temps+challenge+evenement).
Le tout est base sur des algos publiques costauds, auquels on ajoute un sel d'obscurite parce qu'on va pas leur faciliter la tache quand meme (pis surtout, techniquement ca peut aider aussi).
Par contre, ca ne protege pas du tout du man in the middle. Enfin pas en soi. Vu que l'homme du milieu connait le challenge, il peut aisement se faire passer pour le client.
Ya diverses pistes pour contrer ca, par exemple passer par une solution soft et de faire intervenir le certificat SSL du serveur.
On avait fait ca via une applet:
L'applet, une fois chargee, va recuperer le certif du serveur a qui elle parle (MITM donc), introduire la cle publique dans la generation de l'OTP et envoyer tout ca au serveur MITM.
Le MITM s'empresse de faire suivre a la banque, qui n'a pas la meme cle publique (ou alors ya un serieux probleme de secu que tous les OTP du monde ne peuvent resoudre).
La banque va essayer de regenerer le mot de passe de son cote et ne va pas y arriver car meme si temps+evenement+challenge correspondent, la cle publique n'est pas la meme.
Et paf l'homme du milieu.
Evidemment, si l'homme du milieu decompile/modifie l'applet, t'es baise.
Mais l'applet est of course signee par la banque.
Donc si le certif n'est pas le bon, la faute incombe (et surtout, decombe) au client, et c'est tout ce que veut la banque: proteger ses petits sous a elle, pas ceux du client.
[^] # Re: 3D Secure
Posté par thedude . En réponse au journal "MasterCard Secure Code" ou "Verified by Visa" ou comment ne plus assumer. Évalué à 1.
Qu'ils soient generes a la volee ou de facon statique puis envoyer par la poste, fax ou a dos de corbeau, ca revient au meme, conceptuellement.
C'est effectivement tres costaud a casser (chiffrement 3des ou asymetrique en fonction des prestataires).
L'idee est toute simple: chiffrer avec un algo fort la date et/ou un compteur d'evenement et/ou le challenge cote client et l'envoyer au serveur.
Le serveur a lui la connaissance de la cle du client (certificat publique si asymetrique, prive si symetrique) et genere des mots de passes dans une certaine fenetre (temps/evenements + eventuel challenge) jusqu'a tomber sur le meme.
S'il trouve pas, va te faire voire.
Dans ma boite on faisait du symetrique (la gestion des certifs, c'ets un gros boulot, plus simple de gerer un cle symetrique), je me dit que dans le cas de l'asymetrique il doivent se contenter de dechiffrer l'otp et de verifier si les donnees envoyees sont bien celles attendues (temps+challenge+evenement).
Le tout est base sur des algos publiques costauds, auquels on ajoute un sel d'obscurite parce qu'on va pas leur faciliter la tache quand meme (pis surtout, techniquement ca peut aider aussi).
Par contre, ca ne protege pas du tout du man in the middle. Enfin pas en soi. Vu que l'homme du milieu connait le challenge, il peut aisement se faire passer pour le client.
Ya diverses pistes pour contrer ca, par exemple passer par une solution soft et de faire intervenir le certificat SSL du serveur.
On avait fait ca via une applet:
L'applet, une fois chargee, va recuperer le certif du serveur a qui elle parle (MITM donc), introduire la cle publique dans la generation de l'OTP et envoyer tout ca au serveur MITM.
Le MITM s'empresse de faire suivre a la banque, qui n'a pas la meme cle publique (ou alors ya un serieux probleme de secu que tous les OTP du monde ne peuvent resoudre).
La banque va essayer de regenerer le mot de passe de son cote et ne va pas y arriver car meme si temps+evenement+challenge correspondent, la cle publique n'est pas la meme.
Et paf l'homme du milieu.
Evidemment, si l'homme du milieu decompile/modifie l'applet, t'es baise.
Mais l'applet est of course signee par la banque.
Donc si le certif n'est pas le bon, la faute incombe (et surtout, decombe) au client, et c'est tout ce que veut la banque: proteger ses petits sous a elle, pas ceux du client.