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
|