Les cartes bancaires menacées par une faille de sécurité

Moué va payer tes courses avec 3 pc, 1 transfo, une connexion web et une paire de tenaille sans oublié la CB volée, tu passeras inaperçue ...

moué, va payer tes courses à Auchan avec 3 pc, un transfo, une connexion web et une paire de tenaille sans oublié d'avoir volé juste avant une CB... Tu passeras inaperçue et tu payeras rien !!! Mouahahahah

Je vois pas pourquoi on pourrait pas payer sur Internet avec...
Tu n'as pas besoin d'entrer de code sur Internet, tu as besoin du numéro de carte bleue, de la date de validité et des 3 chiffres au dos.
Si le voleur a la carte, il a ces 3 informations...

jp971
@OmaR
justement sur une transaction internet les serveurs de la banque sont interrogés. Donc la manip ne marche pas

Rien n'est totalement sécurisé, et rien ne le sera jamais.

Je ne crois absolument pas à cette faille, et je m'explique.

Le code, c'est interne à la carte. L'OS reçoit une APDU du terminal contenant le code, le vérifie, et renvoie au terminal la validité ou non du code.
Je pense qu'il a créé une applet interface qui répond au terminal que le code a toujours été validé, quelque soit la valeur donnée. Du coup avec cette applet, il peut effectivement leurer un Status en faisant croire que le détenteur de la carte est bien son propriétaire. Il faut connaitre la programmation de carte à puce, et s'arrêter à ce niveau sans aller s'authentifier sur la banque (qui là ne peut pas être leurer de cette façon puisque des protections ont été prévus).

Par contre, la difficulté est d'installer une telle application dans la carte, car pour faire ça, il faut s'authentifier sur la carte avec une ou plusieurs clés. Le problème est bien d'avoir ces clés connues uniquement par la banque.
Il aurait pu trouver une faille particulière dans l'OS, mais dans ce cas, ça ne serait pas généralisé sur toutes les cartes.
Je pense qu'il a fait ces tests sur une carte n'appartenant à aucune banque, et ne contenant que des clés vides.

Les banques ont mis en place des sécurités supplémentaires maintenant, la société générale par exemple demande un code de validation qui est envoyé sur le n° de portable défini au départ par le propriétaire, donc avec seulement la carte, ce n'est pas si simple.

Tout se pirate en mettant les moyens mais la solution retenue n'est pas discrète ...

De toute façon, vérifiez votre contrat de CB : si le paiement est effectué sans saisie de votre code confidentiel, le paiement peut être considéré comme frauduleux : cas de tous les paiement sur le net !
Donc vous êtes couvert !
Avez vous enregistré le numéro d'opposition carte bleu dans votre téléphone pour appeler le centre d'opposition des que vous découvrez que votre CB a été volée ?
N'oubliez pas que même si vous avez perdu votre carte à 10h et que vous la déclarez volée à 12h, vous êtes remboursé/couvert que pour les transaction effectuées à partir de 12h !
Relisez vos contrats Vous savez, les petites lignes que personne ne lit jamais

@CRicky : Pas besoin de s'authentifier pour avoir les clef. Le chalenge obtenu avec le code seul le serveur de la banque peut vraiment le vérifier. Comme la connexion avec la banque c'est pas requise. Il est tout à fait possible de leurrer les terminal en filant une fausse réponse (Ce que vient de trouver ce chercheur). Les autres clef peuvent être fournis facilement en jouant le protocole EMV sans authentification.
Après faire une fausse carte bleu, c'est facile (carte programmable ca ce trouve).

Le problème, c'est que ça implique que pour la banque l'empreinte a été faite avec le code. Donc refuseront d'indemniser les victimes.

C'est pour ça que quand certains sites affirment demander en plus de ça à des fins de sécurité à qui appartient ladite carte c'est vraiment se foutre de la gu**** du monde, vu que cette info est elle aussi présente sur la carte !

@but2ene, déjà, un challenge n'est pas un cryptogramme, et pour une authentification avec la banque, il n'y a pas que le code pin (qui n'a que 9999 possibilités) pour s'authentifier (ça serait trop facile).

Bref, je ne parlais pas d'authentification auprès de la banque mais de l'authentification sur la carte pour y installer une applet. Ce n'est pas la même chose ! L'installation d'une applet dans la carte à puce est restreinte (ça serait trop facile). Et pour faire cette installation, les communications entre le lecteur (là on n'est plus sur un terminal évidemment) sont sécurisées grâce à une authentification utilisant des clés particulières que seule la banque connait. Donc, à moins que cracker l'algo ou trouver une faille OS, seule la banque peut modifier ses cartes.

@CRicky : Justement ce chercheur viens de montrer que le protocole est foireux. D'ailleurs la première partie n'est pas protégé contre le rejeu. Pourquoi voulez vous installer une applet dans une carte. Hors qu'il suffit d'en faire une fausse, en utilisant les clefs données par la version sans code de la carte.
Enfin bref la crypto n'est pas la seule faille. Le protocole aussi (cf needham schroeder).
Depuis 2005 une faille est connue, mais il fallait arracher la carte au bon moment et en mettre une autre. Les infos d'authenfications (pin) et les donnée était désolidarisé. Là ça en est une autre.
Mais comme en 1997, cette personne devra faire une yes card pour montrer les failles.(à l'époque c'était la crypto qui était vieille - j'espère qu'ils sont passé au SHA pour les signatures ...).

Je ne vois pas pourquoi vous me parler du cryptogramme. Le terminal ne connais pas tout (notamment la clef privée de visa mastercard.). On peu envoyer une message valide pour le terminal et pas pour la banque.

Parce qu'un challenge est juste une clé générée en vu de calculer un cryptogramme (qui authentifie la communication).

Sinon, tu penses vraiment que la communication entre le terminal et la carte se fait en clair après validation du PIN ?

Non pas en clair. Mais l'EMV se fait en plusieurs parties avec plusieurs niveau de sécurités. Entre ces différentes parties, il est possible de les combiner modifier certaines choses. Notamment il est jouable sans code et sans connexion à la banque...
Là le gars il arrive a faire jouer la chose en faisant croire à la carte qu'il est en mode sans code. et le plus fort c'est qu'il fait croire au terminal que la réponse est correcte. (Ressemble à une attaque Man in the middle - il est possible d'ajouter une puce sur le bus)

Le but dans ce protocoles n'est que l'authenticité et non le secret. Aucun intérêt de chiffrer tout les messages. Même le code, le terminal connaît le code vu que vous l'avez taper dessus et la carte aussi elle va le vérifier via un challenge. (un problème, j'ai entendu parlé d'une prochaine carte sans contacte ou on tapera le code dessus).

Mais la carte veux authentifier le terminal et l'utilisateur, et le terminal veut authentifier la carte.
A mon avis le leurre utilisé ne tiendra pas face à la banque (c'est probablement pour cela que ça ne marche qu'avec les commerçants probablement un re-jeux).

Je pense qu'il s'agit de cela mais ça date déjà.
http://www.lightbluetouchpaper.org [...] #more-1196

Tout n'est pas rose dans l'EMV ...

Pour ton lien, je n'ai pas suivi ce qui a été fait depuis, mais le problème des Yes card avait été corrigé, je me trompe ?
Pour le Man in the middle, on retombe sur le problème d'interfaçage (à moins qu'il ne simule de fausses transactions pour retrouver le PIN).
Pour le mode sans code, OK, mais là visiblement, c'est le mode avec code PIN (à moins qu'il ne force un changement dans la protocole pour passer dans un mode sans vérification de PIN).

Si dans la suite des échanges, il n'y a pas de MAC calculé à partir du code PIN (au lieu de clés bancaires), alors effectivement l'authentification par code PIN ne sert absolument à rien... mais je doute qu'une telle erreur ait été faite (même si plus rien ne m'étonne sur la sécurité ).

Dans tous les cas, il est clair que face à la banque, il faut retrouver les clés bancaires ou chercher une faille dans les algorithmes de chiffrement (ce qui est bien plus complexe).

Je crois que vous n'avez rien compris.
Ce lien est justement ce qui est dit dans l'article... Donc pas un article de première fraîcheur.

C'est justement cela.
Les deux éléments ne jouent pas pareil et pour le MAC seul la banque peut la vérifié. Donc en mode sans connexion ...

C'est pas une erreur c'est pour remplir le cahier des charges avec les différents protocoles. Notamment il n'y a qu'en France où le terminal des commerçants demande un code.

C'est le cas parce que le MAC est calculé à partir d'une clé bancaire, mais si au lieu de prendre la clé bancaire, le MAC avait été calculé à partir d'une clé dérivée du code PIN, le terminal pourrait vérifier un MAC, même si celui-ci est léger à cause des faibles combinaisons du PIN.


Bien sûr que si c'est une erreur !
L'erreur est de vouloir maintenir des protocoles qui ne tiennent pas debout. D'ailleurs, si on raisonne comme ça, même les terminaux connectées aux banques devraient avoir la compatibilité avec les protocoles de base. Du coup, ce changement de protocole serait également possible sur les terminaux connectés.
ça voudrait simplement dire que les banques veulent bien restreindre les possibilités pour se protéger, mais ne cherche pas à protéger les utilisateurs vis-à-vis des commerçants...

La plus sécurisé est la visa electron. Réponse de la banque est requise.
Tout le monde dit que c'est de la merde et qu'elle ne marche jamais ...
On est obliger de limiter la sécurité pour éviter que cela devienne inutilisable.

Si on veut qu'on puisse l'utiliser par exemple au péage. Il faut plusieurs niveau de sécurités c'est comme ça.

Le système de certificats actuel est plus sûr qu'une clef sur 4 chiffres...
La carte serait beaucoup plus facilement clonable. Seule la carte et vous connaissez le vrai code. Le terminal l'ignore, une fausse carte un faux code le terminal n'y verra que du feux. Votre solution ne fonctionne pas.
C'est grâce à l'utilisation de clef RSA bancaire qu'on ne peut pas copier la carte à puce, qu'on peut certifier que la transaction est authentique. Le terminal ne peut pas trop en savoir non plus.

La seule chose qui protège les utilisateur de carte bleue, c'est la loi.

Evidemment la sécurité est contraignante, c'est toujours le cas quelque soit le contexte, mais à vouloir rester compatible on garde les trous de sécurité (cf faille windows 7), mais je pense que même Microsoft va au final apporter une correction, sauf que pour eux, c'est clairement plus simple et moins cher à déployer.

ça, c'est une évidence, mais une clé de 4 chiffres est toujours plus sûr qu'aucune clé lorsqu'on est hors connexion.


Bien sûr que le problème serait qu'il faudrait changer tous les terminaux, mais ceux-ci pourraient évoluer petit à petit, pour ensuite enlever les compatibilités lorsque les cartes utilisant l'ancien système ne sont plus répandues.


Et on a accès à une telle fonctionnalité (hors protocole) après une simple authentification (suivant le protocole) ?


OK pour ça, mais en même temps il doit bien envoyer des APDU à un moment.


Oui, aucune sécurité numérique n'est sûre à 100%.

Pour microsoft le problème c'est qu'ils ont des trop fortes contraintes de temps.L'émulateur 16bit qui a été écrit en 1993. Je suis certain que personne ne l'a réécrit depuis. Mais cela cache une autre faille pourquoi un émulateur se lance avec les droits administrateur ? -_-"

Wine n'a jamais eu ce genre de problèmes. (Souvent réécrit).

Si les deux connaissent quelqu'un de confiance comme la banque Le certificat reste meilleurs .
En fait, les deux connaissent les clef publiques de chacun. Même en offline les deux peuvent savoir si il sont authaurisé. (pour le terminal il possède un certificat signé par la banque si je me souvient bien).

En fait je pense qu'ils n'ont pas testé grand choses. Comme les problème de représentation BCD en Allemagne (bug 2010). Comme leur doc est secrète... des hacker s'amusant dessus auront plus de chance de trouver des failles qu'un expert.

Le problèmes des protocoles cryptographique est un sujet de recherche encore actuellement. Ca a été montré indécidable.
Mais il y a des outils pour vérifier ce cas par exemple.

Je pense que contre cette attaque il aurait juste fallut signer avec la clef privé de la carte. le MAC avec l'once. Comme est proposé dans l'article d'ailleurs.

Il faut voir les américain avec leur nouveau passeport sans contact ^^ et sans sécurité.
La commission européenne y a ajouter un minimum de sécurité.

Je pense que les constructeurs devraient faire des cartes open-source, ça les pousserait à améliorer la sécurité.

Mon dieu, le mot interdit aaaaahhhh
C'est certain que ce serait mieux du moins tester le protocole par des expert reconnus ou même faire des challenge comme pour RSA.
Mais les banques qui ont la culture du secret je ne sais pas.

salut
en tout cas le code est facilement leurrable sur emv le plus dur c que les cartes on maintenant une authetification dynamique dite dda de 1024bit rsa donc elle son inclonable car la clée est differente a chaque transaction car elle est calculer a partir d'un nombre aleatoire en live envoyer par le tpe c'etait encore possible quand emv etait en mode sda ou les clée d'authentification etait statique mais la c mort et meme si le type a reussi a ecrire sur une carte officiel voler ou perdu il pourra juste faire quelque transaction offline de moin de 90 euro sur les tpe dont la blacklist n'as pas encore etait mise a jour autant vous dire que les banques en n'on rien a cirer
si il arrive a prendre 1000 euro avec sa carte c le bout du monde et encore certain tpe fon des apel systematique vers le centre et qui dit apel dit challenge et dit consultation de la blacklist donc c mort carte bloquer par le terminal et la c mort sauf si il as les clée de debloquage mais ceci m'etonnerait beaucoup dans tout les cas son hack n'est pas terrible par contre si il arrive a calculer les clée de 1024bit en live avec un simulateur a partir d'infos porteur bidon la sa devient dangereux
bon je vous laisse
ne comprendron que se qui doivent comprendre