Ma banque m'envoie une nouvelle carte à puce, et le code secret est inchangé.
Cela signifie que la PassPhrase (code secret) n'est pas limité spatialement à la carte le temps de débloquer la clé secrète, mais qu'il est stocké ailleurs.
Je pensais que la sécurité physique du système postulait:
-jamais de backup d'une clé secrète, ni logiciel ni matériel.
-jamais de backup de la passphrase.
N'est-ce pas une porte ouverte à des attaques?
--
Laurent Jumet - Point de Chat, Liège, BELGIUM
KeyID: 0xCFAF704C
[Restore address to laurent.jumet for e-mail reply.]
Ce n'est pas si simple. Pour des raisons de compatibilité avec d'autres systèmes, notamment de retrait de liquide dans les automates étrangers, qui n'utilisent la puce que minoritairement dans le monde, le code PIN doit pouvoir être validé par un serveur centralisé.
J'avais crus comprendre que c'était encore le cas en France, que c'était la bande magnétique qui était utilisé.
On Sat, 7 Apr 2007 16:08:25 +0200, "JL" <JL@jlamy.com> wrote:
Ce n'est pas si simple. Pour des raisons de compatibilité avec d'autres
systèmes, notamment de retrait de liquide dans les automates étrangers, qui
n'utilisent la puce que minoritairement dans le monde, le code PIN doit
pouvoir être validé par un serveur centralisé.
J'avais crus comprendre que c'était encore le cas en France, que
c'était la bande magnétique qui était utilisé.
Ce n'est pas si simple. Pour des raisons de compatibilité avec d'autres systèmes, notamment de retrait de liquide dans les automates étrangers, qui n'utilisent la puce que minoritairement dans le monde, le code PIN doit pouvoir être validé par un serveur centralisé.
J'avais crus comprendre que c'était encore le cas en France, que c'était la bande magnétique qui était utilisé.
Sylvain
Xavier Roche wrote on 07/04/2007 10:23:
Ma banque m'envoie une nouvelle carte à puce, et le code secret est inchangé.
Le code est choisi par la banque, ou peut être choisi par le client. Vous pouvez même changer vous même votre code secret si cela vous chante à l'aide de n'importe quel lecteur de carte (c'est une commande carte documentée ; ISO 7816-4)
ah bon ?! une appli EMV serait strict ISO compliant ? je pensais que le PIN ne pouvait être débloqué, optionnellement (selon mask) updaté, qu'en script processing, ie après un 2nd Generate AC valide.
Sylvain.
Xavier Roche wrote on 07/04/2007 10:23:
Ma banque m'envoie une nouvelle carte à puce, et le code secret
est inchangé.
Le code est choisi par la banque, ou peut être choisi par le client.
Vous pouvez même changer vous même votre code secret si cela vous chante
à l'aide de n'importe quel lecteur de carte (c'est une commande carte
documentée ; ISO 7816-4)
ah bon ?! une appli EMV serait strict ISO compliant ?
je pensais que le PIN ne pouvait être débloqué, optionnellement (selon
mask) updaté, qu'en script processing, ie après un 2nd Generate AC valide.
Ma banque m'envoie une nouvelle carte à puce, et le code secret est inchangé.
Le code est choisi par la banque, ou peut être choisi par le client. Vous pouvez même changer vous même votre code secret si cela vous chante à l'aide de n'importe quel lecteur de carte (c'est une commande carte documentée ; ISO 7816-4)
ah bon ?! une appli EMV serait strict ISO compliant ? je pensais que le PIN ne pouvait être débloqué, optionnellement (selon mask) updaté, qu'en script processing, ie après un 2nd Generate AC valide.
Sylvain.
Sylvain
Patrick Coilland wrote on 07/04/2007 12:12:
Je crois que ce qui choque Laurent est simplement que le PIN de
livraison est mémorisé par le SI de l'émetteur de la carte afin de pouvoir émettre la carte de remplacement avec le *même* PIN.
je fais la même lecture.
C'est l'existence de cette mémorisation qu'il pointe - à juste titre, je pense - comme une faiblesse potentielle.
mais ce n'est imho en aucun cas une faiblesse, ou à tout le moins le porteur est encore plus faible et serait le premier à raler si on lui changeait son PIN à chaque renouvellement de carte.
bien sur que le SI de la banque mémorise le PIN attribué à la carte d'un compte, vous avez peur que quelqu'un le vole ?? ce même SI stocke évidemment également le numéro complet de la carte, son CVV, votre pédigré, etc; si ce SI était pénétré les codes PIN récupérés seraient de faible valeur par rapport aux autres informations directement utilisables (un PIN sans la carte ne sert pas à grand chose).
Sylvain.
Patrick Coilland wrote on 07/04/2007 12:12:
Je crois que ce qui choque Laurent est simplement que le PIN de
livraison est mémorisé par le SI de l'émetteur de la carte afin de
pouvoir émettre la carte de remplacement avec le *même* PIN.
je fais la même lecture.
C'est l'existence de cette mémorisation qu'il pointe - à juste titre, je
pense - comme une faiblesse potentielle.
mais ce n'est imho en aucun cas une faiblesse, ou à tout le moins le
porteur est encore plus faible et serait le premier à raler si on lui
changeait son PIN à chaque renouvellement de carte.
bien sur que le SI de la banque mémorise le PIN attribué à la carte d'un
compte, vous avez peur que quelqu'un le vole ?? ce même SI stocke
évidemment également le numéro complet de la carte, son CVV, votre
pédigré, etc; si ce SI était pénétré les codes PIN récupérés seraient de
faible valeur par rapport aux autres informations directement
utilisables (un PIN sans la carte ne sert pas à grand chose).
Je crois que ce qui choque Laurent est simplement que le PIN de
livraison est mémorisé par le SI de l'émetteur de la carte afin de pouvoir émettre la carte de remplacement avec le *même* PIN.
je fais la même lecture.
C'est l'existence de cette mémorisation qu'il pointe - à juste titre, je pense - comme une faiblesse potentielle.
mais ce n'est imho en aucun cas une faiblesse, ou à tout le moins le porteur est encore plus faible et serait le premier à raler si on lui changeait son PIN à chaque renouvellement de carte.
bien sur que le SI de la banque mémorise le PIN attribué à la carte d'un compte, vous avez peur que quelqu'un le vole ?? ce même SI stocke évidemment également le numéro complet de la carte, son CVV, votre pédigré, etc; si ce SI était pénétré les codes PIN récupérés seraient de faible valeur par rapport aux autres informations directement utilisables (un PIN sans la carte ne sert pas à grand chose).
Sylvain.
Sylvain
Xavier Roche wrote on 07/04/2007 14:58:
Le PIN doit bien à un moment ou a un autre entrer dans le terminal, qui envoi à la puce un challenge haché avec le code PIN.
c'est quelle appli ça ??? pour EMV, le PIN en envoyé en clair à la carte.
Quand au code, seul la banque le garde,
le garde oui, mais le personnalisateur le reçoit à chaque demande de renouvelement.
et à part une fraude de la part de la banque, je ne vois pas bien où se situe le problème (autant garder la clé privée, dans ce cas)
?!? le PIN ne protège pas /une/ clé unique propre au porteur, à la carte, /les/ clés de la banque sont évidemment garder par la banque et implémentés dans les systèmes de persos (HSM) des personalisateurs.
Xavier Roche wrote on 07/04/2007 14:58:
Le PIN doit bien à un moment ou a un autre entrer dans le terminal, qui
envoi à la puce un challenge haché avec le code PIN.
c'est quelle appli ça ???
pour EMV, le PIN en envoyé en clair à la carte.
Quand au code, seul la banque le garde,
le garde oui, mais le personnalisateur le reçoit à chaque demande de
renouvelement.
et à part une fraude de la part de la banque,
je ne vois pas bien où se situe le problème (autant garder
la clé privée, dans ce cas)
?!? le PIN ne protège pas /une/ clé unique propre au porteur, à la
carte, /les/ clés de la banque sont évidemment garder par la banque et
implémentés dans les systèmes de persos (HSM) des personalisateurs.
Le PIN doit bien à un moment ou a un autre entrer dans le terminal, qui envoi à la puce un challenge haché avec le code PIN.
c'est quelle appli ça ??? pour EMV, le PIN en envoyé en clair à la carte.
Quand au code, seul la banque le garde,
le garde oui, mais le personnalisateur le reçoit à chaque demande de renouvelement.
et à part une fraude de la part de la banque, je ne vois pas bien où se situe le problème (autant garder la clé privée, dans ce cas)
?!? le PIN ne protège pas /une/ clé unique propre au porteur, à la carte, /les/ clés de la banque sont évidemment garder par la banque et implémentés dans les systèmes de persos (HSM) des personalisateurs.
Sylvain
Laurent Jumet wrote on 07/04/2007 18:16:
C'est l'existence de cette mémorisation qu'il pointe - à juste titre, je pense - comme une faiblesse potentielle.
C'est nécessaire ne serais-ce que pour pouvoir renvoyer le code de leur carte aux distraits...
C'est comme si ton meilleur ami gardait copie de la clé de la ceinture de chasteté de ta femme, au cas où tu serais distrait... :-)
Aucune copie ne doit exister. Perte de carte = Oubli de code = Remplacement du tout.
tu oublies juste qu'un carte de paiement ne t'appartient pas ! elle appartient à la banque qui l'émets et cette banque veut que tu utilises ta carte, le plus souvent possible, le plus simplement possible.
à moins de défendre l'industrie du silicium, il n'y a aucune raison de remplacer une carte prématurément; le GIE-CB impose déjà une cadence élevée (tous les 2 ans) alors que d'autres pays utilisent un rythme de 3 ou 4 ans.
Sylvain.
Laurent Jumet wrote on 07/04/2007 18:16:
C'est l'existence de cette mémorisation qu'il pointe - à juste titre, je
pense - comme une faiblesse potentielle.
C'est nécessaire ne serais-ce que pour pouvoir renvoyer le code de leur
carte aux distraits...
C'est comme si ton meilleur ami gardait copie de la clé de la ceinture de chasteté de ta femme, au cas où tu serais distrait... :-)
Aucune copie ne doit exister.
Perte de carte = Oubli de code = Remplacement du tout.
tu oublies juste qu'un carte de paiement ne t'appartient pas ! elle
appartient à la banque qui l'émets et cette banque veut que tu utilises
ta carte, le plus souvent possible, le plus simplement possible.
à moins de défendre l'industrie du silicium, il n'y a aucune raison de
remplacer une carte prématurément; le GIE-CB impose déjà une cadence
élevée (tous les 2 ans) alors que d'autres pays utilisent un rythme de 3
ou 4 ans.
C'est l'existence de cette mémorisation qu'il pointe - à juste titre, je pense - comme une faiblesse potentielle.
C'est nécessaire ne serais-ce que pour pouvoir renvoyer le code de leur carte aux distraits...
C'est comme si ton meilleur ami gardait copie de la clé de la ceinture de chasteté de ta femme, au cas où tu serais distrait... :-)
Aucune copie ne doit exister. Perte de carte = Oubli de code = Remplacement du tout.
tu oublies juste qu'un carte de paiement ne t'appartient pas ! elle appartient à la banque qui l'émets et cette banque veut que tu utilises ta carte, le plus souvent possible, le plus simplement possible.
à moins de défendre l'industrie du silicium, il n'y a aucune raison de remplacer une carte prématurément; le GIE-CB impose déjà une cadence élevée (tous les 2 ans) alors que d'autres pays utilisent un rythme de 3 ou 4 ans.
Sylvain.
Xavier Roche
ah bon ?! une appli EMV serait strict ISO compliant ?
Mes cours de carte sont un peu éloignés pour répondre à la question, mais de mémoire un gros morceau de la 7816-4 est appliquable, avec pas mal de morceaux dans EMV
je pensais que le PIN ne pouvait être débloqué, optionnellement (selon mask) updaté, qu'en script processing, ie après un 2nd Generate AC valide.
Je confirme que le PIN peut être modifié sur une CB standard (en tout cas pour la puce), même si j'ai largement oublié les détails passionnants (qui m'ont été pourtant expliqué à l'époque)
ah bon ?! une appli EMV serait strict ISO compliant ?
Mes cours de carte sont un peu éloignés pour répondre à la question,
mais de mémoire un gros morceau de la 7816-4 est appliquable, avec pas
mal de morceaux dans EMV
je pensais que le PIN ne pouvait être débloqué, optionnellement (selon
mask) updaté, qu'en script processing, ie après un 2nd Generate AC valide.
Je confirme que le PIN peut être modifié sur une CB standard (en tout
cas pour la puce), même si j'ai largement oublié les détails
passionnants (qui m'ont été pourtant expliqué à l'époque)
ah bon ?! une appli EMV serait strict ISO compliant ?
Mes cours de carte sont un peu éloignés pour répondre à la question, mais de mémoire un gros morceau de la 7816-4 est appliquable, avec pas mal de morceaux dans EMV
je pensais que le PIN ne pouvait être débloqué, optionnellement (selon mask) updaté, qu'en script processing, ie après un 2nd Generate AC valide.
Je confirme que le PIN peut être modifié sur une CB standard (en tout cas pour la puce), même si j'ai largement oublié les détails passionnants (qui m'ont été pourtant expliqué à l'époque)
Xavier Roche
pour EMV, le PIN en envoyé en clair à la carte.
Hein ? Il me semble pourtant que si le PIN est envoyé "en clair" depuis le clavier vers le terminal, le terminal n'envoi pas ce dernier tel quel, mais utilise un système de challenge/response. C'est pas B0' qui posait problème ?
pour EMV, le PIN en envoyé en clair à la carte.
Hein ? Il me semble pourtant que si le PIN est envoyé "en clair" depuis
le clavier vers le terminal, le terminal n'envoi pas ce dernier tel
quel, mais utilise un système de challenge/response. C'est pas B0' qui
posait problème ?
Hein ? Il me semble pourtant que si le PIN est envoyé "en clair" depuis le clavier vers le terminal, le terminal n'envoi pas ce dernier tel quel, mais utilise un système de challenge/response. C'est pas B0' qui posait problème ?
Francois Grieu
Dans l'article , Erwan David a écrit:
Une vérification de signature RSA avec une clef 1024 bits c'est très long sur une carte. Ou alors la carte coute très cher.
Non, pour ce qui concerne la VERIFICATION de signature RSA; en réalité l'ordre de grandeur est 1 seconde pour e=3, 1024 bits, sur un processeur 8 bits exécutant moins de 2 million d'instructions par seconde, avec à peine 400 octets de RAM, 1ko de code (assembleur et pas facile il est vrai) sans aucun compromis sur le format des clés ni la sécurité contre les attaques DPA etc. Si on est pressé, on peut utiliser Rabin-Williams, encore plus rapide, et dont la sécurité est démontrablement celle de la factorisation. Bref la vérification d'une signature, y compris dans un système avec hierarchie de certificats, est parfaitement faisable dans une carte à puce bas de gamme sans cryptoprocesseur. Ce qui n'est pas raisonable sans cryptoprocesseur, c'est la génération de signature RSA, et le déchiffrement RSA.
Il est vrai que c'est peu employé dans les cartes à puce, et que la librairie que je vends à cet effet, pour plusieurs CPUs, trouve surtout des applications de type PIN Pad, et n'est pas gratuite.
François Grieu
Dans l'article <m2y7l3qnue.fsf@rail.eu.org>,
Erwan David <erwan@rail.eu.org> a écrit:
Une vérification de signature RSA avec une clef 1024 bits c'est
très long sur une carte. Ou alors la carte coute très cher.
Non, pour ce qui concerne la VERIFICATION de signature RSA;
en réalité l'ordre de grandeur est 1 seconde pour e=3, 1024 bits,
sur un processeur 8 bits exécutant moins de 2 million d'instructions
par seconde, avec à peine 400 octets de RAM, 1ko de code (assembleur
et pas facile il est vrai) sans aucun compromis sur le format des clés
ni la sécurité contre les attaques DPA etc.
Si on est pressé, on peut utiliser Rabin-Williams, encore plus rapide,
et dont la sécurité est démontrablement celle de la factorisation.
Bref la vérification d'une signature, y compris dans un système
avec hierarchie de certificats, est parfaitement faisable dans une
carte à puce bas de gamme sans cryptoprocesseur. Ce qui n'est pas
raisonable sans cryptoprocesseur, c'est la génération de signature
RSA, et le déchiffrement RSA.
Il est vrai que c'est peu employé dans les cartes à puce, et que
la librairie que je vends à cet effet, pour plusieurs CPUs, trouve
surtout des applications de type PIN Pad, et n'est pas gratuite.
Une vérification de signature RSA avec une clef 1024 bits c'est très long sur une carte. Ou alors la carte coute très cher.
Non, pour ce qui concerne la VERIFICATION de signature RSA; en réalité l'ordre de grandeur est 1 seconde pour e=3, 1024 bits, sur un processeur 8 bits exécutant moins de 2 million d'instructions par seconde, avec à peine 400 octets de RAM, 1ko de code (assembleur et pas facile il est vrai) sans aucun compromis sur le format des clés ni la sécurité contre les attaques DPA etc. Si on est pressé, on peut utiliser Rabin-Williams, encore plus rapide, et dont la sécurité est démontrablement celle de la factorisation. Bref la vérification d'une signature, y compris dans un système avec hierarchie de certificats, est parfaitement faisable dans une carte à puce bas de gamme sans cryptoprocesseur. Ce qui n'est pas raisonable sans cryptoprocesseur, c'est la génération de signature RSA, et le déchiffrement RSA.
Il est vrai que c'est peu employé dans les cartes à puce, et que la librairie que je vends à cet effet, pour plusieurs CPUs, trouve surtout des applications de type PIN Pad, et n'est pas gratuite.
François Grieu
Sylvain
Francois Grieu wrote on 08/04/2007 21:20:
Une vérification de signature RSA avec une clef 1024 bits c'est très long sur une carte. Ou alors la carte coute très cher.
Non, pour ce qui concerne la VERIFICATION de signature RSA; en réalité l'ordre de grandeur est 1 seconde pour e=3, 1024 bits,
je dirais plutôt 200ms pour ces paramètres (pas un ordre de grandeur mais presque) - mais peut être 1s. est le temps pour un chip sans proc. crypto.
sur un processeur 8 bits exécutant moins de 2 million d'instructions par seconde, avec à peine 400 octets de RAM, 1ko de code (assembleur et pas facile il est vrai) sans aucun compromis sur le format des clés ni la sécurité contre les attaques DPA etc.
euh une attaque DPA sur un exposant public ??...
Si on est pressé, on peut utiliser Rabin-Williams, encore plus rapide, et dont la sécurité est démontrablement celle de la factorisation. Bref la vérification d'une signature, y compris dans un système avec hierarchie de certificats, est parfaitement faisable dans une carte à puce bas de gamme sans cryptoprocesseur. Ce qui n'est pas raisonable sans cryptoprocesseur, c'est la génération de signature RSA, et le déchiffrement RSA.
assurément, et même équipé il est assez rare de vérifier des hiérarchies de signatures / cert. par la carte: là où le besoin est devenu indispensable, des "card verifiable certificats" ont été inventés.
Il est vrai que c'est peu employé dans les cartes à puce, et que la librairie que je vends à cet effet, pour plusieurs CPUs, trouve surtout des applications de type PIN Pad, et n'est pas gratuite.
plus cher qu'une puce avec cryptoproc ? (dont le prix fondeur, pas public, n'est nullement un obstacle).
Sylvain.
Francois Grieu wrote on 08/04/2007 21:20:
Une vérification de signature RSA avec une clef 1024 bits c'est
très long sur une carte. Ou alors la carte coute très cher.
Non, pour ce qui concerne la VERIFICATION de signature RSA;
en réalité l'ordre de grandeur est 1 seconde pour e=3, 1024 bits,
je dirais plutôt 200ms pour ces paramètres (pas un ordre de grandeur
mais presque) - mais peut être 1s. est le temps pour un chip sans proc.
crypto.
sur un processeur 8 bits exécutant moins de 2 million d'instructions
par seconde, avec à peine 400 octets de RAM, 1ko de code (assembleur
et pas facile il est vrai) sans aucun compromis sur le format des clés
ni la sécurité contre les attaques DPA etc.
euh une attaque DPA sur un exposant public ??...
Si on est pressé, on peut utiliser Rabin-Williams, encore plus rapide,
et dont la sécurité est démontrablement celle de la factorisation.
Bref la vérification d'une signature, y compris dans un système
avec hierarchie de certificats, est parfaitement faisable dans une
carte à puce bas de gamme sans cryptoprocesseur. Ce qui n'est pas
raisonable sans cryptoprocesseur, c'est la génération de signature
RSA, et le déchiffrement RSA.
assurément, et même équipé il est assez rare de vérifier des hiérarchies
de signatures / cert. par la carte: là où le besoin est devenu
indispensable, des "card verifiable certificats" ont été inventés.
Il est vrai que c'est peu employé dans les cartes à puce, et que
la librairie que je vends à cet effet, pour plusieurs CPUs, trouve
surtout des applications de type PIN Pad, et n'est pas gratuite.
plus cher qu'une puce avec cryptoproc ? (dont le prix fondeur, pas
public, n'est nullement un obstacle).
Une vérification de signature RSA avec une clef 1024 bits c'est très long sur une carte. Ou alors la carte coute très cher.
Non, pour ce qui concerne la VERIFICATION de signature RSA; en réalité l'ordre de grandeur est 1 seconde pour e=3, 1024 bits,
je dirais plutôt 200ms pour ces paramètres (pas un ordre de grandeur mais presque) - mais peut être 1s. est le temps pour un chip sans proc. crypto.
sur un processeur 8 bits exécutant moins de 2 million d'instructions par seconde, avec à peine 400 octets de RAM, 1ko de code (assembleur et pas facile il est vrai) sans aucun compromis sur le format des clés ni la sécurité contre les attaques DPA etc.
euh une attaque DPA sur un exposant public ??...
Si on est pressé, on peut utiliser Rabin-Williams, encore plus rapide, et dont la sécurité est démontrablement celle de la factorisation. Bref la vérification d'une signature, y compris dans un système avec hierarchie de certificats, est parfaitement faisable dans une carte à puce bas de gamme sans cryptoprocesseur. Ce qui n'est pas raisonable sans cryptoprocesseur, c'est la génération de signature RSA, et le déchiffrement RSA.
assurément, et même équipé il est assez rare de vérifier des hiérarchies de signatures / cert. par la carte: là où le besoin est devenu indispensable, des "card verifiable certificats" ont été inventés.
Il est vrai que c'est peu employé dans les cartes à puce, et que la librairie que je vends à cet effet, pour plusieurs CPUs, trouve surtout des applications de type PIN Pad, et n'est pas gratuite.
plus cher qu'une puce avec cryptoproc ? (dont le prix fondeur, pas public, n'est nullement un obstacle).
Sylvain.
Francois Grieu
Dans l'article <461a11e6$0$27407$, Sylvain a écrit:
Francois Grieu wrote on 08/04/2007 21:20:
Erwan David a écrit:
Une vérification de signature RSA avec une clef 1024 bits c'est très long sur une carte. Ou alors la carte coute très cher.
Non, pour ce qui concerne la VERIFICATION de signature RSA; en réalité l'ordre de grandeur est 1 seconde pour e=3, 1024 bits,
je dirais plutôt 200ms pour ces paramètres (pas un ordre de grandeur mais presque) - mais peut être 1s. est le temps pour un chip sans proc. crypto.
Oui, c'est le contexte que je considère.
sur un processeur 8 bits exécutant moins de 2 million d'instructions par seconde, avec à peine 400 octets de RAM, 1ko de code (assembleur et pas facile il est vrai) sans aucun compromis sur le format des clés ni la sécurité contre les attaques DPA etc.
euh une attaque DPA sur un exposant public ??...
On est tout à fait d'accord que dans une application vérification de signature, rien n'est secret, donc rien à récupérer par DPA. Par contre pour du chiffrement, ce que l'on chiffre avec l'exposant public est par définition secret (puisque l'on prends la peine de le chiffrer), et il faut prendre un minimum de précautions. Mon "DPA etc" visait aussi les attaques par injection de fautes, qui sont à craindre, un peu dans la vérification de signature (mais pas tellement pendant l'exponentiation); et davantage pendant le chiffrement.
Si on est pressé, on peut utiliser Rabin-Williams, encore plus rapide, et dont la sécurité est démontrablement celle de la factorisation. Bref la vérification d'une signature, y compris dans un système avec hierarchie de certificats, est parfaitement faisable dans une carte à puce bas de gamme sans cryptoprocesseur. Ce qui n'est pas raisonable sans cryptoprocesseur, c'est la génération de signature RSA, et le déchiffrement RSA.
assurément, et même équipé il est assez rare de vérifier des hiérarchies de signatures / cert. par la carte: là où le besoin est devenu indispensable, des "card verifiable certificats" ont été inventés.
Il y a un exemple relativement simple dans l'application cartes de tachygraphes, page 263 à 267 de http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CONSLEG:1985R3821:20060501:EN:PDF mais la carte a aussi besoin d'une clé secrète, donc il faut un vrai cryptoprocesseur.
Il est vrai que c'est peu employé dans les cartes à puce, et que la librairie que je vends à cet effet, pour plusieurs CPUs, trouve surtout des applications de type PIN Pad, et n'est pas gratuite.
plus cher qu'une puce avec cryptoproc ? (dont le prix fondeur, pas public, n'est nullement un obstacle).
Mon modèle de license est un "one-time-fee". A partir d'une quantité genre 100k, c'est nettement moins cher que le surcout d'un cryptoprocesseur et des options éventuellement inutiles qui viennent avec (pléthore relative de RAM et EEPROM); hélas, malgré cela, je ne vends pas ma librairie tous les jours (euphémisme) pour mettre dans une carte à puce.
François Grieu
Dans l'article <461a11e6$0$27407$ba4acef3@news.orange.fr>, Sylvain a écrit:
Francois Grieu wrote on 08/04/2007 21:20:
Erwan David <erwan@rail.eu.org> a écrit:
Une vérification de signature RSA avec une clef 1024 bits c'est
très long sur une carte. Ou alors la carte coute très cher.
Non, pour ce qui concerne la VERIFICATION de signature RSA;
en réalité l'ordre de grandeur est 1 seconde pour e=3, 1024 bits,
je dirais plutôt 200ms pour ces paramètres (pas un ordre de grandeur
mais presque) - mais peut être 1s. est le temps pour un chip sans proc.
crypto.
Oui, c'est le contexte que je considère.
sur un processeur 8 bits exécutant moins de 2 million d'instructions
par seconde, avec à peine 400 octets de RAM, 1ko de code (assembleur
et pas facile il est vrai) sans aucun compromis sur le format des clés
ni la sécurité contre les attaques DPA etc.
euh une attaque DPA sur un exposant public ??...
On est tout à fait d'accord que dans une application vérification de
signature, rien n'est secret, donc rien à récupérer par DPA. Par contre
pour du chiffrement, ce que l'on chiffre avec l'exposant public est
par définition secret (puisque l'on prends la peine de le chiffrer),
et il faut prendre un minimum de précautions.
Mon "DPA etc" visait aussi les attaques par injection de fautes,
qui sont à craindre, un peu dans la vérification de signature (mais
pas tellement pendant l'exponentiation); et davantage pendant le
chiffrement.
Si on est pressé, on peut utiliser Rabin-Williams, encore plus rapide,
et dont la sécurité est démontrablement celle de la factorisation.
Bref la vérification d'une signature, y compris dans un système
avec hierarchie de certificats, est parfaitement faisable dans une
carte à puce bas de gamme sans cryptoprocesseur. Ce qui n'est pas
raisonable sans cryptoprocesseur, c'est la génération de signature
RSA, et le déchiffrement RSA.
assurément, et même équipé il est assez rare de vérifier des hiérarchies
de signatures / cert. par la carte: là où le besoin est devenu
indispensable, des "card verifiable certificats" ont été inventés.
Il y a un exemple relativement simple dans l'application cartes de
tachygraphes, page 263 à 267 de
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CONSLEG:1985R3821:20060501:EN:PDF
mais la carte a aussi besoin d'une clé secrète, donc il faut un
vrai cryptoprocesseur.
Il est vrai que c'est peu employé dans les cartes à puce, et que
la librairie que je vends à cet effet, pour plusieurs CPUs, trouve
surtout des applications de type PIN Pad, et n'est pas gratuite.
plus cher qu'une puce avec cryptoproc ? (dont le prix fondeur, pas
public, n'est nullement un obstacle).
Mon modèle de license est un "one-time-fee". A partir d'une quantité
genre 100k, c'est nettement moins cher que le surcout d'un
cryptoprocesseur et des options éventuellement inutiles qui
viennent avec (pléthore relative de RAM et EEPROM); hélas, malgré
cela, je ne vends pas ma librairie tous les jours (euphémisme) pour
mettre dans une carte à puce.
Dans l'article <461a11e6$0$27407$, Sylvain a écrit:
Francois Grieu wrote on 08/04/2007 21:20:
Erwan David a écrit:
Une vérification de signature RSA avec une clef 1024 bits c'est très long sur une carte. Ou alors la carte coute très cher.
Non, pour ce qui concerne la VERIFICATION de signature RSA; en réalité l'ordre de grandeur est 1 seconde pour e=3, 1024 bits,
je dirais plutôt 200ms pour ces paramètres (pas un ordre de grandeur mais presque) - mais peut être 1s. est le temps pour un chip sans proc. crypto.
Oui, c'est le contexte que je considère.
sur un processeur 8 bits exécutant moins de 2 million d'instructions par seconde, avec à peine 400 octets de RAM, 1ko de code (assembleur et pas facile il est vrai) sans aucun compromis sur le format des clés ni la sécurité contre les attaques DPA etc.
euh une attaque DPA sur un exposant public ??...
On est tout à fait d'accord que dans une application vérification de signature, rien n'est secret, donc rien à récupérer par DPA. Par contre pour du chiffrement, ce que l'on chiffre avec l'exposant public est par définition secret (puisque l'on prends la peine de le chiffrer), et il faut prendre un minimum de précautions. Mon "DPA etc" visait aussi les attaques par injection de fautes, qui sont à craindre, un peu dans la vérification de signature (mais pas tellement pendant l'exponentiation); et davantage pendant le chiffrement.
Si on est pressé, on peut utiliser Rabin-Williams, encore plus rapide, et dont la sécurité est démontrablement celle de la factorisation. Bref la vérification d'une signature, y compris dans un système avec hierarchie de certificats, est parfaitement faisable dans une carte à puce bas de gamme sans cryptoprocesseur. Ce qui n'est pas raisonable sans cryptoprocesseur, c'est la génération de signature RSA, et le déchiffrement RSA.
assurément, et même équipé il est assez rare de vérifier des hiérarchies de signatures / cert. par la carte: là où le besoin est devenu indispensable, des "card verifiable certificats" ont été inventés.
Il y a un exemple relativement simple dans l'application cartes de tachygraphes, page 263 à 267 de http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CONSLEG:1985R3821:20060501:EN:PDF mais la carte a aussi besoin d'une clé secrète, donc il faut un vrai cryptoprocesseur.
Il est vrai que c'est peu employé dans les cartes à puce, et que la librairie que je vends à cet effet, pour plusieurs CPUs, trouve surtout des applications de type PIN Pad, et n'est pas gratuite.
plus cher qu'une puce avec cryptoproc ? (dont le prix fondeur, pas public, n'est nullement un obstacle).
Mon modèle de license est un "one-time-fee". A partir d'une quantité genre 100k, c'est nettement moins cher que le surcout d'un cryptoprocesseur et des options éventuellement inutiles qui viennent avec (pléthore relative de RAM et EEPROM); hélas, malgré cela, je ne vends pas ma librairie tous les jours (euphémisme) pour mettre dans une carte à puce.
