yescard

ludovic3187@my-deja.com <ludovic3187@my-deja.com>
Friday, 10 March, 2000 15:56
fr.misc.cryptologie
Précision sur l'exposant publique des CB

Juste une petite précision concernant l'exposant publique des CB.

Mail à "démontré" que se peut être 3 et non pas que ce soit 3, les
calculs effectués permettent simplement de vérifier que 3 est une
valeur possible, comme tous les nombres premiers autre que p et q.

De plus les papiers référencés disent simplement que 3 est une valeur
possible et non pas que 3 soit la valeur retenue pour les CB. De plus
étant donné que la clef publique de la carte ne l'était pas vraiment
(publique), il n'y a pas de raison pour que l'exposant retenu le soit
(publique). Donc le fait de le trouver dans un brevet ou une
proposition de spécification ou autre ne veut rien dire !

Il reste donc beaucoup de travail pour ceux qui désirent découvrir le
mystère dans son entier.

Voici les mêmes calculs que mail avec e = 5 et e = 11 :

On remarquera que cette fois ci, le calcul de l'exposant privé est fait
dans les règles du schéma RSA. En effet on trouve l'exposant privé par
le calcul de (exposant publique)^-1 mod phi(n),
où phi(n) = (p-1)*(q-1).

>pub:=2^320+convert
(`90b8aaa8de358e7782e81c7723653be644f7dcc6f816daf46e532b91e84f`,decimal,
hex);
pub :=
21359870359209100823950227049996287970510953418264174064425\
       24165008583957746445088405009430865999


> facteur1:=convert(`c31f7084b75c502caa4d19eb137482aa4cd57aab`,
decimal, hex);

    facteur1 := 1113954325148827987925490175477024844070922844843


> facteur2:=convert(`14fdeda70ce801d9a43289fb8b2e3b447fa4e08ed`,
decimal, hex);

    facteur2 := 1917481702524504439375786268230862180696934189293


>  produit:=facteur1*facteur2;

produit := 2135987035920910082395022704999628797051095341826417406\
    442524165008583957746445088405009430865999


EXEMPLE AVEC UN EXPOSANT PUBLIQUE = 5

> exposant_public:=5;

                         exposant_public := 5


> modulo_div_eucl:=(facteur1-1)*(facteur2-1);

modulo_div_eucl := 21359870359209100823950227049996287970510953418\
    23385970414850832581282681302737201380241573831864


> exposant_prive:=expand(1/exposant_public mod modulo_div_eucl);

exposant_prive := 427197407184182016479004540999925759410219068364\
    677194082970166516256536260547440276048314766373


> testnb:=12345678;

                          testnb := 12345678


> testsignnb:= testnb &^ exposant_prive mod produit;

testsignnb := 3225932080532329235534788835504083607171046974137697\
    4242251357960987750028428284852894162142916


> testverifsignnb := testsignnb &^ exposant_public mod produit;

                     testverifsignnb := 12345678


EXEMPLE AVEC UN EXPOSANT PUBLIQUE = 11

> exposant_public:=11;

                        exposant_public := 11


> modulo_div_eucl:=(facteur1-1)*(facteur2-1);

modulo_div_eucl := 21359870359209100823950227049996287970510953418\
    23385970414850832581282681302737201380241573831864


> exposant_prive:=expand(1/exposant_public mod modulo_div_eucl);

exposant_prive := 970903198145868219270464865908922180477770609919\
    720895643114014809673946046698727900109806287211


> testnb:=12345678;

                          testnb := 12345678


> testsignnb:= testnb &^ exposant_prive mod produit;

testsignnb := 1808495522964509506256256343739329345620926604821326\
    628640526923534741517255914237158541959332428


> testverifsignnb := testsignnb &^ exposant_public mod produit;

                     testverifsignnb := 12345678

   Voila,
   J'espère que la démonstration est convaincante.


Sent via Deja.com http://www.deja.com/
Before you buy.


Petite feuille Maple
 
>
pub:=2^320+convert(`90b8aaa8de358e7782e81c7723653be644f7dcc6f816daf46e532b91 e84f`,decimal,hex);
 
pub := 21359870359209100823950227049996287970510953418264174064425\     24165008583957746445088405009430865999
 
> facteur1:=convert(`c31f7084b75c502caa4d19eb137482aa4cd57aab`, decimal,
hex);
 
    facteur1 := 1113954325148827987925490175477024844070922844843
 
> facteur2:=convert(`14fdeda70ce801d9a43289fb8b2e3b447fa4e08ed`, decimal,
hex);
 
    facteur2 := 1917481702524504439375786268230862180696934189293
 
> produit:=facteur1*facteur2;
 
produit := 2135987035920910082395022704999628797051095341826417406\     442524165008583957746445088405009430865999
 
> exposant_public:=3;
 
                        exposant_public := 3
 
> modulo_div_eucl:=(facteur1-1)*(facteur2-1);
 
modulo_div_eucl := 21359870359209100823950227049996287970510953418\     23385970414850832581282681302737201380241573831864
 
> essai_rate_exposant_prive:=expand((1+modulo_div_eucl)/3);
 
essai_rate_exposant_prive := 2135987035920910082395022704999628797\
 
    051095341823385970414850832581282681302737201380241573831865/3
 
> exposant_prive:=expand((1+2*modulo_div_eucl)/3);
 
exposant_prive := 142399135728060672159668180333308586470073022788\     2257313609900555054188454201824800920161049221243
 
> testnb:=1234;
 
                            testnb := 1234
 
> testsignnb:=testnb &^ exposant_prive mod produit;
 
testsignnb := 2235938147775183775641042325450404557899532144626481\     7152366942909748069192341215834242192574336
 
> testverifsignnb:=testsignnb &^exposant_public mod produit;
 
                      testverifsignnb := 1234
 
 
ou trouver  prog carte puce satellite ?


mail écrit :
>
> Petite feuille Maple
>
> >
> pub:=2^320+convert(`90b8aaa8de358e7782e81c7723653be644f7dcc6f816daf46e532b91
> e84f`,decimal,hex);
 
[..]
 
> > exposant_public:=3;
 
[...]
 
> exposant_prive := 142399135728060672159668180333308586470073022788\
>    2257313609900555054188454201824800920161049221243
 
Les calculs sont exacts : le nombre ci-dessus est bel et bien l'exposant privé d'une clé publique RSA dont l'exposant public est 3 et le module 2^320 + 0x90b8aaa8de358e7782e81c7723653be644f7dcc6f816daf46e532b91e84f. J'ai vérifié avec un autre logiciel (bc, détails à la demande.)
 
Cette clé ne peut manifestement plus assurer aucun service
d'authenticité ou de confidentialité. Sa clé secréte a été publiée sur un forum public Usenet ; dire que sa sécurité est compromise serait une litote.
 
Si elle est ou a été utilisée aux fins d'assurer l'authenticité ou la confidentialité de messages ou de transactions, la personne ou
l'organisme qui fournit ou qui fournissait de telles prestations cryptologiques doit à l'évidence la révoquer publiquement sans délai.
 
--
Johannes Baagoe


J'écrivais :
 
> > exposant_prive := 142399135728060672159668180333308586470073022788\
> >    2257313609900555054188454201824800920161049221243
>
> Les calculs sont exacts : le nombre ci-dessus est bel et bien l'exposant
> privé d'une clé publique RSA dont l'exposant public est 3 et le module
> 2^320 + 0x90b8aaa8de358e7782e81c7723653be644f7dcc6f816daf46e532b91e84f.
 
[ etc ]
 
D'autres intervenants du groupe voudront-ils bien vérifier à leur tour, et donner leur avis sur les conclusions que j'en tire ?
 
Merci d'avance.
 
--
Johannes


Erwann ABALEA écrit :
 
> C'est valable uniquement si tu as TOUS les éléments de la clé
> publique...
 
"mail" fournit également l'exposant public, à savoir 3. J'ai vérifié que si on prend un nombre au hasard, et qu'on l'élève à la puissance de la clé privée annoncée, puis au cube, le tout modulo le module public, on retrouve bien le nombre de départ.
 
> Si ce sur quoi tu travailles c'est la clé privée bancaire, alors il
> te manque l'exposant public...
 
JE NE SAIS PAS si la clé publique décrite par "mail" est celle (ou une de celles) des cartes bancaires.
 
J'ai une idée assez sûre de l'exposant public de ces dernières : http://www.deja.com/[ST_artlink=parodie.com,ST_rn=if]/jump/http://parodie.com/humpich/LCguillou_AnnTelecom_No43_1988.jpg, qui
semble une référence indiscutable, parle d'élever au cube.
 
Concernant le module, c'est moins clair.
 
Il figure dans le désormais célèbre message signé "Anie Nomat" (http://www.deja.com/[ST_artlink=www.deja.com,ST_rn=if]/jump/http://www.deja.com/getdoc.xp?AN=583760249) du 9 février qui évoquait
les "spécifications du GIE CB (maintenant Groupement CB) dans l'édition de 1991". Mais je ne sais pas où trouver ces spécifications, bien qu'elles ne doivent pas être à proprement parler confidentielles.
 
Le message en question affirmait aussi que la clé décrite dans ces spécifications figurait bien sur la carte bancaire de l'auteur émise en 1999. Je suis encore moins en mesure de le vérifier : non seulement ça me semble d'une légalité problématique (une puce est-elle un
"système de traitement automatisé des données" au sens de la loi ?), mais en plus, je suis nul en électronique.
 
Enfin, le message d'"Anie Nomat" proposait une factorisation, celle-là même qui a été utilisée par "mail".
 
Beaucoup l'auront sans doute remarqué dès ce moment : elle
correspondait, non comme annoncé à la clé no 3 ("en principe non utilisable pour de "vraies" transactions"), mais bien à la clé no 1 présentée - à tort ou à raison - comme celle qui sert effectivement aux transactions. Apparemment, ceux qui s'en sont rendus compte sont restés discrets, même s'il était prévisible que quelqu'un finirait par calculer la clé privée et la publier.
 
C'est désormais chose faite avec le message de "mail". Pour le meilleur ou pour le pire, la boîte de Pandore est ouverte.
 
Que ce soit bien clair : je ne suis ni "mail", ni "Cyber Cube" alias "Anie Nomat". Je ne sais rien de ces personnes, si ce n'est ce qu'elles ont écrit, et que chacun a pu lire dans ce forum.
 
J'ose toujours croire que la clé publique dont nous parlons *n'est pas* la véritable clé d'authentification des cartes bancaires.
 
Il y a d'autres explications possibles, sinon plausibles :
 
- Le canular : une clé fantaisiste élaborée par "Anie Nomat" à partir de facteurs premiers calculés au préalable et exhibés ensuite comme "factorisation",
 
- L'erreur *en sens inverse* d'"Anie Nomat" : la clé factorisée est bien une clé des cartes bancaires, mais réservée aux test ; c'est la numérotation des clés qui était erronée dans son message,
 
- L'erreur ou le mensonge sur l'usage de la clé : il s'agit bien d'une clé RSA en service, mais dans un tout autre domaine, les cartes
bancaires étant loin d'être les seules applications concevables de RSA même 320 bits, que ce soit au moyen de cartes à puce ou non.
 
QUOI QU'IL EN SOIT, la clé décrite est compromise. A vrai dire, je ne vois pas comment elle pourrait être plus compromise que ça, sauf à devenir un classique des cours de crypto et de sécurité, ou encore à être abondamment commentée par l'ensemble de la presse, journal de 20 heures compris. L'un et l'autre risquent d'ailleurs de se produire.
 
SI la clé en question sert à quoi que ce soit d'important (je ne sais pas si c'est le cas, je dis "si" !), son propriétaire ou son gestionnaire doit IMMEDIATEMENT la révoquer, en avertir SANS TARDER l'ensemble de ses clients et partenaires, et prendre toutes les
mesures contractuelles ou techniques qui s'imposent du fait qu'un service garanti n'est plus assuré.
 
Il aurait déjà dû le faire dans les quelques jours suivant le 9
février : j'ose espérer qu'il suit fr.misc.cryptologie (sinon, son service de veille laisse franchement à désirer), et qu'il est capable de comprendre les conséquences d'une factorisation d'un module RSA.
 
Mais admettons qu'il vaut mieux tard que jamais. C'est MAINTENANT, ou alors, il perd toute crédibilité comme fournisseur fiable de solutions d'authentification, sans parler des conséquences juridiques possibles du fait de continuer à fournir un produit en sachant qu'il n'assure plus le service pour lequel les clients paient.
 
--
Johannes Baagoe


>Robert Harley wrote:
 
 
>> Il reste à savoir, comme vous l'avez remarqué, si les nombres composés
>> donnés par Anie Nomat sont vraiment utilisés ou si c'est un canular.
>> Si c'est un canular, il est drôlement bien réalisé.  Si c'en est pas,
>> c'est le GIE CB qui nous en fait un depuis des années.
 
 
Réponse du GIE ce matin dans le figaro : ce sont les bonnes clés


ZipZap écrit :
 
> >Robert Harley wrote:
>
> >> Il reste à savoir, comme vous l'avez remarqué, si les nombres composés
> >> donnés par Anie Nomat sont vraiment utilisés ou si c'est un canular.
> >> Si c'est un canular, il est drôlement bien réalisé.  Si c'en est pas,
> >> c'est le GIE CB qui nous en fait un depuis des années.
>
> Réponse du GIE ce matin dans le figaro : ce sont les bonnes clés
 
Est-ce que c'est officiel ?
 
Je n'ai rien trouvé sur le site http://www.deja.com/[ST_artlink=www.gie-cartebleue.fr,ST_rn=if]/jump/http://www.gie-cartebleue.fr/, si ce
n'est une amusante alerte javascript (de 1790 pixels de large sur mon ordinateur !) nous informant que le service de messagerie est fortement perturbé, et qu'il faut reposer sa question après le 1 mars.
 
Rien non plus sur http://www.deja.com/[ST_artlink=www.gie-cartes-bancaires.fr,ST_rn=if]/jump/http://www.gie-cartes-bancaires.fr/.
 
Le communiqué de presse le plus récent à ce jour (daté du 25 février, http://www.deja.com/[ST_artlink=www.gie-cartes-bancaires.fr,ST_rn=if]/jump/http://www.gie-cartes-bancaires.fr/html/grpmnt/commun/Paris.htm)
commente la condamnation de Serge Humpich ("Un contrefacteur de cartes bancaires condamné à dix mois de prison avec sursis"), en précisant :
 
"Le Groupement des Cartes Bancaires "CB" rappelle qu'il ne s'agit pas d'une faille qui aurait été découverte dans le système "CB", mais du piratage d'un informaticien qui - au terme de cinq années de
recherches - a fabriqué une fausse carte capable de tromper un
automate distribuant des tickets de métro. Cette carte n'aurait jamais pu fonctionner sur les distributeurs de billets, ni être acceptée chez les commerçants."
 
Sans commentaires... pour le moment.
 
--
Johannes


Pierre Vandevenne <pierre@datarescue.com> a écrit dans le message :
8a401o$3g0_002@be.kpnqwest.net...
> In article <8a3bvq$svm$1@nnrp1.deja.com>, jluu@my-deja.com wrote:
>
> >Vous comprendrez que le fait de s'attaquer a cette clef est illicite.
> >Donc celui qui tape ces chiffres sur sa TI-92 risque la meme peine !
> >A moins qu'on ne risque quelque chose que si l'on regarde AUSSI le
>
> Tant qu'on y est, pourquoi ne pas interdire tout simplement la détention
de
> moyens de calcul ? En code barre sur un tee-shirt, c'est aussi illégal ?
 
Extrait du jugement :
"Attendu qu'il en est de même en ce qui concerne l'infraction de maintien frauduleux dans le système de traitement automatisé de données ; que cette infraction réside plus spécifiquement dans la recherche pour isoler et identifier l'algorithme de cryptage ; que le caractère frauduleux de ce maintien est sans conteste établi dès lors que Serge Humpich a consacré ses efforts à décrypter une donnée cryptée par le maître du système ;"
 
Il n'y a rien de "crypté" (ni de chiffré en bon français) dans les terminaux de paiements, il y a une clé publique. on passe à la clé privée en la décomposant en facteur premiers. Cela n'a rien à voir avec le décryptage de message.
Il n'y a même pas d'algorithme de cryptage, il n'y a qu'un protocole d'authentification.
 
Quant à considérer un terminal de paiement électronique lui même, non connecté au réseau comme un système automatisé de traitement. Les gens sont avertis : il ne faut pas démonter son four !
 
en outre, considérer qu'il y a infraction pour isoler et identifier l'algorithme de "cryptage" alors que cet algorithme figure dans des spécifications publiques (enfin semi-publiques)...
 
--
Laurent PELE 13 rue Lantiez 75017 PARIS
Tél/Fax +33 1 40 25 08 50 mob + 33 6 08 21 96 69
mailto:laurent@pele.org http://www.deja.com/[ST_artlink=www.pele.org,ST_rn=if]/jump/http://www.pele.org
Convertisseur euro et multi-devises sur http://www.deja.com/[ST_artlink=fxtop.com,ST_rn=if]/jump/http://fxtop.com/fr


In article <8a456q$2e22$1@news6.isdnet.net>, "Laurent PELE" <laurent@pele.org> wrote:
 
>"Attendu qu'il en est de même en ce qui concerne l'infraction de maintien
>frauduleux dans le système de traitement automatisé de données ; que cette
>infraction réside plus spécifiquement dans la recherche pour isoler et
>identifier l'algorithme de cryptage
 
Ouch :-)
 
>Il n'y a même pas d'algorithme de cryptage, il n'y a qu'un protocole
>d'authentification.
 
Certaines cartes, comme la Siemens 44C200, la Philips 83C852 ou encore la Thomson ST16CF54 supportent des algo symétriques, peut-être qu'ils ont confondu avec d'autres systèmes de payements ? :-)
 
Ce lien pourrait éventuellement être utile à la justice, si elle décidait à se documenter sur les smartcards :  www.maxking.com
 
Pierre
 
 
 
 
 
---
Pierre Vandevenne, MD
www.datarescue.com, home of the IDA Pro Disassembler
Version 4.02 available - Sparc and stuff
www.datarescue.com/idanew.htm


According to Johannes Baagoe  <baagoe@baagoe.com>:
> D'autres intervenants du groupe voudront-ils bien vérifier à leur tour,
> et donner leur avis sur les conclusions que j'en tire ?
 
Le calcul est correct : avec le module indiqué, et l'exposant public 3, l'exposant privé correspondant est bien celui que tu donnes.
 
Si un système utilise cette clé publique, avec cet exposant public, alors ce système est désormais compromis. Et, avec un autre exposant, pareil, parce qu'on peut dériver la factorisation du module de la connaissance de ces deux exposants.
 
Si c'est bien le module et l'exposant des cartes bleues, n'importe quel électronicien un peu doué peut refaire la même chose qu'Humpich (à savoir truander dans les restaurants et les distributeurs de tickets de métro).
 
--Thomas Pornin


Décidement je suis dur à la comprenotte : le couple de clé dans la carte, il est personnel ou il est le même dans toutes les cartes ? S'il est perso , Anie Noma nous a fourni le moyen de cloner sa carte, donc bof. D'autre part vous dites (et toi aussi Thomas) que la clé publique est compromise parce qu'elle est connue. Euh pour une clé publique c'est un peu le principe non ?
Dernière question : il semble donc que la carte contiennent des clés RSA de 320 bits. A l'heure actuelle, on sait "facilement" casser des clés de 512, pourquoi cette histoire de CB sort maintenant ?
 
Merci d'éclairer ma lanterne
 
FAbrice
 
Thomas Pornin a écrit :
>
> According to Johannes Baagoe  <baagoe@baagoe.com>:
> > D'autres intervenants du groupe voudront-ils bien vérifier à leur tour,
> > et donner leur avis sur les conclusions que j'en tire ?
>
> Le calcul est correct : avec le module indiqué, et l'exposant public 3,
> l'exposant privé correspondant est bien celui que tu donnes.
>
> Si un système utilise cette clé publique, avec cet exposant public,
> alors ce système est désormais compromis. Et, avec un autre exposant,
> pareil, parce qu'on peut dériver la factorisation du module de la
> connaissance de ces deux exposants.
>
> Si c'est bien le module et l'exposant des cartes bleues, n'importe quel
> électronicien un peu doué peut refaire la même chose qu'Humpich (à
> savoir truander dans les restaurants et les distributeurs de tickets de
> métro).
>
>        --Thomas Pornin


According to Fabrice  <f.bruel@wanadoo.fr>:
> Décidement je suis dur à la comprenotte : le couple de clé dans la
> carte, il est personnel ou il est le même dans toutes les cartes ?
 
Le même dans toutes les cartes.
 
> D'autre part vous dites (et toi aussi Thomas) que la clé publique est
> compromise parce qu'elle est connue. Euh pour une clé publique c'est
> un peu le principe non ?
 
Oui et non. Oui, la clé est censée être publique, et c'est l'exposant secret qui est la vraie clé secrète. Le problème étant que, de toutes façons, un nombre de 320 bits est facile à factoriser.
 
Si ça ne sort que maintenant : il peut y avoir plusieurs raisons. Il est connu depuis un certain temps, et même un temps certain, dans les milieux universitaires qui parlent de crypto, que la clé publique est de 320 bits et qu'elle peut s'obtenir sans trop de problème. Mais 320 bits, ce n'est pas un challenge. Donc aucun universitaire ne va faire la factorisation (sans compter que ça pourrait donner une image de marque un peu trouble au labo, donc le chef de labo est forcément contre).
 
De toutes façons, ce système ne peut mener à des gains illégaux
importants que si on parallélise le système : par exemple, en fabriquant de fausses cartes, et en les revendant à des fraudeurs qui veulent juste ne pas payer dans les restaurants. L'histoire est sortie parce qu'un quidam (Serge Humpich) a fabriqué une fausse carte et l'a dit au GIE (car, selon lui, sa découverte était une trouvaille originale, et il était le premier à s'en apercevoir -- on l'a assez dit, Humpich n'est pas un cryptographe, donc il n'est pas très au courant de ce qui se fait dans le milieu).
 
--Thomas Pornin


Thomas Pornin a écrit :
>
> According to Fabrice  <f.bruel@wanadoo.fr>:
> > Décidement je suis dur à la comprenotte : le couple de clé dans la
> > carte, il est personnel ou il est le même dans toutes les cartes ?
>
> Le même dans toutes les cartes.
 
Et il sert à quoi ? J'ai bien compris que c'est pas un certificat, donc il ne sert pas à authentifier l'utilisateur. Il sert donc "juste" à prouver que c'est une CB ?
 
En tous cas merci de tes réponses, je pige mieux (excuses-moi mais j'aime bien comprendre) ...
 
FAbrice


According to Fabrice <f.bruel@wanadoo.fr>:
> Il sert donc "juste" à prouver que c'est une CB ?
 
Ben oui. La carte est "signée" par la banque. Quand je dis "la carte", c'est un identifiant de la carte qui contient entre autres son numéro, c'est-à-dire ce qui la relie à un banque et un compte sur cette banque.
 
Le terminal de paiement, voyant cette signature, a confiance : c'est une vraie carte, donc tout va bien.
 
Le code à 4 chiffres est envoyé à la carte elle-même, pour convaincre la carte qu'elle a bien son propriétaire humain légitime à l'autre bout du clavier.
 
La transaction elle-même est chiffrée en DES par une autre clé, connue uniquement de la carte et de la banque (le terminal ne la connaît pas).
 
 
Ceci n'est pas valable dans un distributeur de billets de banque, qui doit de toutes façons contacter la banque pour vérifier le plafond hebdomadaire. Si le numéro est pipoté, ça se voit, et fin de la
transaction. C'est pour cela que la méthode "Humpich" reste gagne-petit : on peut manger au restaurant sans payer (mais on ne peut pas retourner dans le même restaurant après), ou faire de menus achats dans les magasins (au-delà de 500 F, il y a normalement vérification obligatoire auprès de la banque que le compte est crédité).
 
 
> (excuse-moi mais j'aime bien comprendre)
 
C'est parfaitement honorable.
 
 
--Thomas Pornin


According to <phaenor@hotmail.com>:
> Même si le numéro donné est valide, la vérification on-line rejettera
> la transaction, à cause du fait qu'il y a aussi un chiffrage en plus
> de la clé de 320 bits.
 
Oui, c'est pour ça que la méthode Humpich ne peut même pas permettre de débiter un compte autre, même si on a eu en main la carte bleue de la victime. Ça ne blouze que les automates 'offline'.
 
 
> Dans ces deux-cas, on fait un gros pari que la vérification on-line
> ne se déclenchera pas, certains restau ne vérifie jamais, c'est
> vrai, mais ca peut changer et le magasin peut décider de le faire
> aléatoirement pour les faibles montants.
 
Pour le restaurant, si la serveuse part avec sa boîte et la carte bleue vers le fond de la pièce, c'est le moment de se carapater vite fait. Ce qui est de toutes façons toujours possible. La fausse carte bleue n'augmente pas vraiment les risques pour le restaurateur ; c'est juste que la fraude est moins visible immédiatement.
 
À la rigueur, c'est même mieux avec la méthode Humpich, ça évite un esclandre en salle, devant les autres clients.
 
 
--Thomas Pornin


In article <8a844b$1stp$1@nef.ens.fr>, pornin@bolet.ens.fr (Thomas Pornin) wrote:
 
>on peut manger au restaurant sans payer (mais on ne peut pas retourner
>dans le même restaurant après),
 
Oui, j'ai vu plusieurs spécialistes côté banque affirmer cela.
 
OK admettons que la carte soit "cassée" en soirée après qu'une transaction bidon ait eu lieu. Mais comment le terminal passif le saura-t-il ? Par définition il n'est pas on-line donc il n'est pas capable de consulter la base de données de mauvaises cartes. En outre, il ne dispose pas d'une capacité de stockage illimité - comment parviendrait-il éventuellement à stocker 100.000 numéro de cartes interdites ? J'admets bien volontiers que l'on pourrait légèrement optimiser le stockage des numéros de ces carte invalides, mais à un certain moment, on se heurte tout de même à une limite...
 
Ne nous trouvons nous pas devant une nouvelle imprécision technique, basée sur de bonnes intentions, celles de semer le doute dans l'esprit des éventuels utilisateurs de yescard ?
 
Il est évidemment possible que je n'aie rien compris - dans ce cas là je ne demande qu'à être éclairé.
 
 
-
 
 
[Upgrader la capacité de stockage de tous les lecteurs passifs ne couterait-il pas plus cher que de remplacer toutes les cartes utilisateur ?]
 
Remplacer toutes les cartes utilisateurs est ce aussi couteux qu'on le prétend ? Mes banques (belges) ont changé toutes mes cartes cette année.
 
Passer à 512 ou 1024 bits est-il totalement impossible ? Quand un arrive à un coût faramineux en raison du nombre de cartes, il faut quand même se rappeller que ces cartes correspondent à des comptes sur lequels il y a de l'argent et que le coût des cartes est négligeable comparé à ce que ces comptes rapportent.
 
De plus, en cas d'amélioration des cartes, est-il forcément obligatoire de changer tous les terminaux ? Je ne le pense pas, à moins qu'ils soient vraiment très mal conçus au niveau software.  Même PGP qui, selon vous est très mal programmé, arrive à maintenir une bonne compatibilité ascendante et à vérifier des signatures réalisées avec des clés de longueur et de type différents.
 
De toute façon, nous ne parlons pas ici de changer tout en bloc, simplement de l'élimination des cartes à 320 bits.
 
 
---
Pierre Vandevenne, MD
www.datarescue.com, home of the IDA Pro Disassembler
Version 4.02 available - Sparc and stuff
www.datarescue.com/idanew.htm


Thomas Pornin <pornin@bolet.ens.fr> a écrit dans le message :
8a844b$1stp$1@nef.ens.fr...
> Ceci n'est pas valable dans un distributeur de billets de banque, qui
> doit de toutes façons contacter la banque pour vérifier le plafond
> hebdomadaire. Si le numéro est pipoté, ça se voit, et fin de la
> transaction. C'est pour cela que la méthode "Humpich" reste gagne-petit :
> on peut manger au restaurant sans payer (mais on ne peut pas retourner
> dans le même restaurant après), ou faire de menus achats dans les
> magasins (au-delà de 500 F, il y a normalement vérification obligatoire
> auprès de la banque que le compte est crédité).
 
Je te rappelle qu'il y a des distributeurs de billets qui acceptent la carte à puce uniquement,
ce sont les petits distributeurs présents dans quelques hotels ou dans les foires.
 
C'est peut être comme cela qu'a procéder celui qui a écrit le message "MERCI HUMPICH" si ce n'est pas un canular. J'ai tendance à le prendre au sérieux car la velle, avant cette diffusion un journialiste m'a reporté 2 cas de vidage de distributeurs de billets à carte à puce. Mais on n'a pu recoupé cette rumeur.
 
En outre, d'après des documents de la Banque de France que j'ai reçu aujourd'hui, la taille de la clé a été allongée (de combien ?) pour les cartes émises à partir du 1er novembre 1999.
Ces documents (qui comportent de nombreuses informations, très très intéressantes) seront disponibles cette nuit sur le site
http://www.deja.com/[ST_artlink=parodie.com,ST_rn=if]/jump/http://parodie.com/humpich/home.htm
 
La presse devrait en faire largement l'écho demain.
 
Ce serait cool d'émettre des commentaires sur ces documents comportant une partie technique importante.
 
--
Laurent PELE 13 rue Lantiez 75017 PARIS
Tél/Fax +33 1 40 25 08 50 mob + 33 6 08 21 96 69
mailto:laurent@pele.org http://www.deja.com/[ST_artlink=www.pele.org,ST_rn=if]/jump/http://www.pele.org
Convertisseur euro et multi-devises sur http://www.deja.com/[ST_artlink=fxtop.com,ST_rn=if]/jump/http://fxtop.com/fr


Je relance une question qui a été l'objet de débats houleux:
 
  Quelle est la taille des nombres factorisés par Serge Humpich ?
 
Sur <http://www.deja.com/[ST_artlink=www.acbm.com]/jump/http://www.acbm.com/pirates/num_05/interview.html> Pirate Mag cite
Serge Humpich, à propos du système CB:
"(..le système CB..) utilise un algorithme assez solide à 96 chiffres"
 
et plus loin, sans qu'il soit explicite si Humpich parle du système précédent ou d'une démonstration distincte à des experts:
"SH: Quand j'ai fait ma démonstration, les spécialistes sont tombés des nues ! L'algorithme de cryptage utilisé est de niveau militaire: RSA, 640 bits. PM: Il vous faut combien de temps pour retrouver un couple de nombres ? SH: Cela dépend. Tout n'est pas automatique, je dois intervenir
'manuellement'. Il ne faut pas partir du raisonnement 'soit x tel nombre', il faut dire 'soit x un nombre particulier' et sortir toutes ses caractéristiques spécifiques. Le produit avait une forme particulière. Aussi, ils n'ont pas pris le premier nombre, pas le dernier, ni au milieu, pour gêner ceux qui font un crible en partant d'une telle position. J'ai fait plein de raisonnements de ce genre et prévu des probabilités. J'ai utilisé des méthodes récentes de factorisation de nombres premiers, que j'ai adaptées à mes nombres particuliers. On pouvait se douter que la solution était proche de la racine carrée...'
PM: (..) Vous nous parlez de code 640 bits maîtrisé depuis un an ? SH: Trouver des nombres premiers de plus en plus grands, ce n'est pas facile. Et, ici, les nombres demandent une particularité supplémentaire qui les rend encore plus difficiles à trouver. L'avenir de cette
implémentation-là est fragilisée par cette considération. Car il n'est pas sûr que trouver de telles clefs suffisamment grandes soit plus simple que de briser l'algorithme sur des clefs plus importantes. Ce qui continuera à se faire de manière conventionnelle. De plus, mes 640 bits correspondent à deux nombres de 320 bits. Peut-être que les chercheurs sont toujours plus forts que moi !"
 
Dans la première citation, 96 chiffres décimaux c'est 320 bits. Cette taille est cohérente avec les informations que donne
<http://www.deja.com/[ST_artlink=humpich.com]/jump/http://humpich.com/histoire.htm>:
"A l'aide d'un logiciel japonais utilisant (..une..) variante de l'algorithme (..MPQS..) pour factorisation des grands nombres en facteurs premiers (..Humpich..) parvient à factoriser (..) la clé publique de 321 bits en 2 facteurs premiers" ce qui est aussi tout à fait cohérent avec l'état de l'art de la factorisation: 320 bits avec un PC, 384 bits avec quelques PCs, 512 bits avec une armée de PC et un gros Cray. Et est aussi cohérent avec des publications scientifiques de Louis Guillou (co-auteur de l'algorithme GQ) mettant en garde, en 1988 et 1990, contre l'utilisation de clés de 320 bits dans l'application CB. Et le fait, vérifié par mes soins sur ma carte émise en 1999, qu'elle contient un certificat de 320 bits, avec la clé publique de 320 bits des spécifications du GIE CB (maintenant Groupement CB) dans l'édition de 1991.
 
Dans la seconde citation, il est clairement fait état de 640 bits. Ce chiffre peut sembler très élevé, mais est en fait crédible dans le cas particulier de clés RSA choisies avec des facteurs très proches, et attaquées au moyen d'algorithmes de factorisation spécialisés (en particulier Fermat et variantes), ce que semble revendiquer Humpich une fois interprétée la transcription de Pirate Mag. Et si le nombre factorisé a été choisi pour une épreuve, ou à fortiori pour un système réel, c'est soit une magnifique performance de la part de Humpich, soit une faille (volontaire ou pas) dans le système qui a choisi la clé, soit un hasard si hautement improbable que c'est une hypothèse presque exclue. Mais que je sache Humpich n'a pas renouvelé ce type de déclaration fracassante, et le site <http://www.deja.com/[ST_artlink=humpich.com]/jump/http://humpich.com> ne mentionne pas cet épisode 640 bits, pourtant très
glorieux, et sans lequel l'affaire Humpich ne serait que la tentative de répression par voix judiciaire d'une demande de fond anonyme pour commenter et taire une attaque en réalité bien connue, sous le doux nom de "YES card", par les experts techniques du Groupement CB.
 
Les trois clés publiques données dans les spécifications (non
confidentielles) du système CB sont:
1:2^320+0x90b8aaa8de358e7782e81c7723653be644f7dcc6f816daf46e532b91e84f 2:2^320+0xd3ab7e06bc577b64101f69b96078a83f6703f49456a1025f65e9000b791f 3:2^320+0xc18407505f55c246af7ab247cbe332f0efc2d1c9b2b6bfa697e4d5766891 La clé 1 est utilisée par les deux cartes que j'ai testé, la clé 2 est une clé de réserve. J'ai factorisé les clés 1 et 3 en quelques jours avec un programme MPQS (japonais aussi !). La clé 3, en principe non utilisable pour de "vraies" transactions, se décompose en
    0xc31f7084b75c502caa4d19eb137482aa4cd57aab
  *0x14fdeda70ce801d9a43289fb8b2e3b447fa4e08ed
Ni cette factorisation, ni celle de la clé 1 ne sont du type "près de la racine" indiqué par Serge Humpich, sans que l'on puisse en déduire quoi que ce soit de certain sur la réalité de l'épisode 640 bits.
 
Si quelqu'un
- a connaissance de CB en circulation utilisant un certificat plus grand que 320 bits, peut-être en complément du certificat actuel
- a eu des échos sur la prouesse supposée de la factorisation de clés de 640 bits par Serge Humpich,
il est prié de le dire sur ce forum, depuis un cybercafé, c'est plus sur.
 
Anie Nomat


 


page d'accueil

contact

 

menu precedent
street fighting
Est-ce ainsi que les hommes vivent ?
Baudelaire Les Fleurs du mal
rfc1869 SMTP Service Extensions
rfc1870 Extension for Message Size Declaration
rfc1939 Post Office Protocol
rfc1957 Observations on Implementations of POP3
rfc2034 Extension for Returning Enhanced Error Codes
rfc2195 IMAP/POP AUTHorize Extension
rfc2449 POP3 Extension Mechanism
rfc2487 Secure SMTP over TLS
rfc2554 Extension for Authentication
rfc822 ARPA Internet text messages
rfc0959 File Transfer Protocol (FTP)
rfc2428 FTP Extensions for IPv6 and NATs
le dernier jour d'un condamne
du cote de chez swann
le joueur
libretto 100
didgeridoo
php
Capability Maturity Model
vcd
histoire de francois m.
le grand secret de toto
sources
1-wire bus
rtos
µC scenix
matrice clavier triangulaire
cables-connecteurs informatiques
format des fichiers S motorola
java
spc statistical process control
codage video couleur
conversion d'unites de surface
conversion d'unites d'energie
conversion d'unites de longueur
conversion d'unites de masse
conversion d'unites de puissance
conversion d'unites de pression
conversion hexa-bin-oct-dec
conversion d'unites de temperature
conversion d'unites de vitesse
calculatrice javascript
cryptographie
yescard
knot tie
Kyusho Atemi-Waza Vital Point Striking Techniques
CRC
source UPS
tcpintro.txt
tcp_ip_tutorial.txt
AWG with current ratings
port parallele
training
le reseau sous DOS
video test
macrovision
Teach Yourself C++
Teach Yourself Java
Teach Yourself C
Java Guide
Applets
Beyond Logic
www.hwb.acc.umu.se
cd

 
moteur de recherche
chercher sur ce site
powered by FreeFind

 

contact

 

FREE, la liberté n'a pas de prix !

<-- precedent ] page d'accueil ] menu precedent ] suite --> ]

derniere mise a jour : dimanche janvier 26, 2003 21:38:01 +0100