Carte bancaire et authentification dynamique.

Arnold McDonald \(AMcD\)

20/01/2006 à 13:22

ast wrote:

La question que l'on peut légitimement se poser est de savoir
pourquoi cela n'est pas utilisé par TOUS les terminaux ?

Une idée, comme ça, parce que sans doute que les terminaux qui acceptent ça
doivent coûter plus cher...

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/

Patrick 'Zener' Brunet

20/01/2006 à 14:14

Bonjour.

Je réponds à ast

Bonjour,

J'ai toujours lu que l'authentification de la CB était statique,
c'est à dire
qu'elle se limite à la vérification par le terminal de paiement d'une
signature numérique. Cette authentification statique n'empèche pas la
réalisation de
clones.

Or je viens de trouver un article qui affirme qu'il y a bien une
authentification dynamique, mais que celle-ci n'est utilisée que
lorsque il y a un appel à un
centre de controle.

C'est là:

http://www.linternaute.com/science/technologie/dossiers/05/0512-codes-secret

s/12.shtml

Je cite:

"La carte possède une troisième sécurité : une clé secrète K. Le
terminal interroge un centre de contrôle à distance, qui envoie à la
carte une valeur aléatoire x (3).
La carte calcule alors, à l'aide de la fonction f de chiffrement du
DES (ou du triple DES depuis 1999), de x et de K, y=f(x,K). Cette
valeur y est retransmise au centre (4), qui lui-même calcule f(x,K).
Si le centre et le terminal arrivent au même résultat, l'autorisation
est donnée (5)."

La question que l'on peut légitimement se poser est de savoir
pourquoi cela n'est pas utilisé par TOUS les terminaux ?

Comme le dit AMcD, la technologie est sans doute plus chère, mais AMHA il y
a d'autres problèmes bien plus bloquants, relevant de politiques
commerciales:

- Aligner de nombreux organismes financiers sur un protocole unique,

- Monter tout le réseau autour du fameux centre d'authentification, qui
devra garantir la capacité de traitement et la confidentialité, et donc
refacturer ses services en conséquence (risque de tarifs de monopole ?
etc.),

- Faire la promotion commerciale commune d'un nouveau système bien complexe
pour le vulgus pecum, ce qui est bien plus coûteux que de faire la promotion
privée d'un système simple à comprendre et absolument fiable à la fois :-)

Est-ce que tout cela ne risque pas de coûter plus cher que d'indemniser
l'infime proportion de fraudes éventuellement constatées ?

Cordialement,

--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

Bonjour.

Je réponds à ast <ast@ast.com>

Bonjour,

J'ai toujours lu que l'authentification de la CB était statique,
c'est à dire
qu'elle se limite à la vérification par le terminal de paiement d'une
signature numérique. Cette authentification statique n'empèche pas la
réalisation de
clones.

Or je viens de trouver un article qui affirme qu'il y a bien une
authentification dynamique, mais que celle-ci n'est utilisée que
lorsque il y a un appel à un
centre de controle.

C'est là:

http://www.linternaute.com/science/technologie/dossiers/05/0512-codes-secret

s/12.shtml

Je cite:

"La carte possède une troisième sécurité : une clé secrète K. Le
terminal interroge un centre de contrôle à distance, qui envoie à la
carte une valeur aléatoire x (3).
La carte calcule alors, à l'aide de la fonction f de chiffrement du
DES (ou du triple DES depuis 1999), de x et de K, y=f(x,K). Cette
valeur y est retransmise au centre (4), qui lui-même calcule f(x,K).
Si le centre et le terminal arrivent au même résultat, l'autorisation
est donnée (5)."

La question que l'on peut légitimement se poser est de savoir
pourquoi cela n'est pas utilisé par TOUS les terminaux ?

Comme le dit AMcD, la technologie est sans doute plus chère, mais AMHA il y
a d'autres problèmes bien plus bloquants, relevant de politiques
commerciales:

- Aligner de nombreux organismes financiers sur un protocole unique,

- Monter tout le réseau autour du fameux centre d'authentification, qui
devra garantir la capacité de traitement et la confidentialité, et donc
refacturer ses services en conséquence (risque de tarifs de monopole ?
etc.),

- Faire la promotion commerciale commune d'un nouveau système bien complexe
pour le vulgus pecum, ce qui est bien plus coûteux que de faire la promotion
privée d'un système simple à comprendre et absolument fiable à la fois :-)

Est-ce que tout cela ne risque pas de coûter plus cher que d'indemniser
l'infime proportion de fraudes éventuellement constatées ?

Cordialement,

--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour.

Je réponds à ast

Bonjour,

J'ai toujours lu que l'authentification de la CB était statique,
c'est à dire
qu'elle se limite à la vérification par le terminal de paiement d'une
signature numérique. Cette authentification statique n'empèche pas la
réalisation de
clones.

Or je viens de trouver un article qui affirme qu'il y a bien une
authentification dynamique, mais que celle-ci n'est utilisée que
lorsque il y a un appel à un
centre de controle.

C'est là:

http://www.linternaute.com/science/technologie/dossiers/05/0512-codes-secret

s/12.shtml

Je cite:

"La carte possède une troisième sécurité : une clé secrète K. Le
terminal interroge un centre de contrôle à distance, qui envoie à la
carte une valeur aléatoire x (3).
La carte calcule alors, à l'aide de la fonction f de chiffrement du
DES (ou du triple DES depuis 1999), de x et de K, y=f(x,K). Cette
valeur y est retransmise au centre (4), qui lui-même calcule f(x,K).
Si le centre et le terminal arrivent au même résultat, l'autorisation
est donnée (5)."

La question que l'on peut légitimement se poser est de savoir
pourquoi cela n'est pas utilisé par TOUS les terminaux ?

Comme le dit AMcD, la technologie est sans doute plus chère, mais AMHA il y
a d'autres problèmes bien plus bloquants, relevant de politiques
commerciales:

- Aligner de nombreux organismes financiers sur un protocole unique,

- Monter tout le réseau autour du fameux centre d'authentification, qui
devra garantir la capacité de traitement et la confidentialité, et donc
refacturer ses services en conséquence (risque de tarifs de monopole ?
etc.),

- Faire la promotion commerciale commune d'un nouveau système bien complexe
pour le vulgus pecum, ce qui est bien plus coûteux que de faire la promotion
privée d'un système simple à comprendre et absolument fiable à la fois :-)

Est-ce que tout cela ne risque pas de coûter plus cher que d'indemniser
l'infime proportion de fraudes éventuellement constatées ?

Cordialement,

--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

Sylvain

20/01/2006 à 15:53

ast wrote on 20/01/2006 13:17:

Bonjour,

J'ai toujours lu que l'authentification de la CB était statique,
c'est à dire qu'elle se limite à la vérification par le terminal
de paiement d'une signature numérique.
Cette authentification statique n'empèche pas la réalisation de
clones.

la CB (telle que définie par le GIE CB) n'a jamais été que statique; sa
remplaçante aux normes EMV non plus.

l'utilisation d'une carte de crédit peut se faire selon 3 modes, et donc
on peut distinguer 3 attaques / 3 clones possibles.

- le niveau 0 est la simple utilisation du numéro de compte encodé dans
la piste magnétique (et/ou embossé sur le recto), ce fonctionnement est
celui de certains automates type péage ou paiement de parking où le
porteur ne saisit pas son code PIN. les clones se contente d'utiliser un
numéro de compte valide et les attaques sont identiques à celles faites
via internet par exemple.
(la petite histoire veut que suite à la présentation de la toute
première carte à puce, des opérations illégales ont été enregistrées sur
le compte de cette carte qui avait été exhibé et zoomé à souhait)

- le mode off-line est l'obtention par la carte d'une autorisation de
paiement, cette autorisation est calculé après vérification du code
porteur sur des éléments incluant date, montant, identifiant vendeur.
la carte applique alors *son* /card risk management/ pour déterminer si
elle autorise spontanément / directement la transaction ou non. pour
cela elle prends en compte différents paramètres dont le montant de la
transaction en cours, le nombre de transactions réalisées depuis la
dernière connexion à la banque, le montant cumulé de ces transactions
(les seuils de ces derniers paramètres étant fixés par la banque avant
la fabrication de la carte).
les attaques possibles dans ce mode sont nées de la publication de
certaines clés sur le net et de la lenteur du GIE à opter pour une
crypto digne (ne plus utiliser un cryptogramme simple DES).

il faut comprendre ici que la carte décide si elle vous fait crédit ou
non; elle n'a aucun moyen de connaitre la situation de votre compte,
peut être celui-ci vient d'être vidé ou même clos; cependant elle
utilisera souvent ce mode car c'est ainsi que vous -utilisateur- voulez
la voir fonctionner. (cf plus bas)

- le mode on-line résulte d'un refus par la carte d'autoriser la
transaction sur ses seuls informations ou d'une volonté du terminal
d'obtenir une vérifiation en-ligne (le terminal applique lui aussi un
risk management qui lui est propre, un commerçant peut par exemple
forcer la connexion pour toute opération dépassant un montant X).

la carte et le terminal conversent alors avec le réseau inter-bancaire
comme briévement décrit par le lien fourni.

La question que l'on peut légitimement se poser est de savoir
pourquoi cela n'est pas utilisé par TOUS les terminaux ?

commençons par noter que tous les terminaux désirant une vérification
en-ligne peuvent l'obtenir; les faiblesses observables ne résultentdonc
pas d'un système opaque géré par des méchants incapables mais seulement
de la responsabilité de chaque participant.

coté opérateur de terminaux, certains ne peuvent pas se permettre une
telle vérification - par exemple un péage auto-routier où la fluidité du
traffic prime sur le reste; d'autres choississent d'y renoncer car la
perte pour transactions invalides (fausses cartes, comptes bloqués, ...)
est inférieure au cout de terminaux en-ligne (c'est la cas d'automates
de paiement de parking percevant des sommes moyennes de 5 à 10 euros).

coté utilisteur, nous ne souhaitons pas non plus une vérification en
ligne systématique - même si certaines banques présentent cette option,
par tapage publicitaire, comme le génial moyen de "savoir où j'en suis
avec mon compte" - car l'opération est nécessairement plus lente qu'une
opération off-line.

ici l'historique joue certes un role (et je ne prétends pas qu'il faille
perdurer dans l'erreur si erreur grave il y avait), nous pouvons par
exemple comparer le système français (basé sur une carte à puce opérant
son propre risk management) et le système US entièrement en-ligne (car
basé sur des cartes à piste magnétiques); le système CB a permis le
déploiement assez rapide et homogène sur tout le territoire d'un système
inter-opérable pour toutes les banques avec un faible taux d'arnaque, la
contre-partie est que la plupart des clients des services bancaires (le
commerçant) est mal ou sous équipé en terminal efficace (les terminaux
UMTS de Ingénico doivent représenter qlq pour-cents de leurs ventes), la
plupart vous laissant planté suur place plusieurs minutes quand "le
boitier doit se connecter"; le système (les systèmes!!) US a vu de son
coté la multiplication des réseaux privés concurentiels (de Visa et
MasterCard mais aussi propre à une enseigne bancaire) pouvant imposer de
disposer de plusieurs comptes (car chacun de ces prestataires n'est pas
présent partout) ou générant des frais d'opérations non négligeables
lorsque qu'une opération est sous-traitée à un réseau concurrent.

pour revenir à votre question, en fait en tant qu'utilisateur de cartes
de crédit, nous souhaiterions qu'elle ne réalise que des opérations
hors-ligne lorsque nous l'utilisons mais qu'elle bascule en tout
en-ligne dès qu'elle est volée, sur ce point les technos seront toujours
criticables servant de bouc-émissaire à la responsabilité de l'utilisateur.

Sylvain.

ast wrote on 20/01/2006 13:17:

Bonjour,

J'ai toujours lu que l'authentification de la CB était statique,
c'est à dire qu'elle se limite à la vérification par le terminal
de paiement d'une signature numérique.
Cette authentification statique n'empèche pas la réalisation de
clones.

la CB (telle que définie par le GIE CB) n'a jamais été que statique; sa
remplaçante aux normes EMV non plus.

l'utilisation d'une carte de crédit peut se faire selon 3 modes, et donc
on peut distinguer 3 attaques / 3 clones possibles.

- le niveau 0 est la simple utilisation du numéro de compte encodé dans
la piste magnétique (et/ou embossé sur le recto), ce fonctionnement est
celui de certains automates type péage ou paiement de parking où le
porteur ne saisit pas son code PIN. les clones se contente d'utiliser un
numéro de compte valide et les attaques sont identiques à celles faites
via internet par exemple.
(la petite histoire veut que suite à la présentation de la toute
première carte à puce, des opérations illégales ont été enregistrées sur
le compte de cette carte qui avait été exhibé et zoomé à souhait)

- le mode off-line est l'obtention par la carte d'une autorisation de
paiement, cette autorisation est calculé après vérification du code
porteur sur des éléments incluant date, montant, identifiant vendeur.
la carte applique alors *son* /card risk management/ pour déterminer si
elle autorise spontanément / directement la transaction ou non. pour
cela elle prends en compte différents paramètres dont le montant de la
transaction en cours, le nombre de transactions réalisées depuis la
dernière connexion à la banque, le montant cumulé de ces transactions
(les seuils de ces derniers paramètres étant fixés par la banque avant
la fabrication de la carte).
les attaques possibles dans ce mode sont nées de la publication de
certaines clés sur le net et de la lenteur du GIE à opter pour une
crypto digne (ne plus utiliser un cryptogramme simple DES).

il faut comprendre ici que la carte décide si elle vous fait crédit ou
non; elle n'a aucun moyen de connaitre la situation de votre compte,
peut être celui-ci vient d'être vidé ou même clos; cependant elle
utilisera souvent ce mode car c'est ainsi que vous -utilisateur- voulez
la voir fonctionner. (cf plus bas)

- le mode on-line résulte d'un refus par la carte d'autoriser la
transaction sur ses seuls informations ou d'une volonté du terminal
d'obtenir une vérifiation en-ligne (le terminal applique lui aussi un
risk management qui lui est propre, un commerçant peut par exemple
forcer la connexion pour toute opération dépassant un montant X).

la carte et le terminal conversent alors avec le réseau inter-bancaire
comme briévement décrit par le lien fourni.

La question que l'on peut légitimement se poser est de savoir
pourquoi cela n'est pas utilisé par TOUS les terminaux ?

commençons par noter que tous les terminaux désirant une vérification
en-ligne peuvent l'obtenir; les faiblesses observables ne résultentdonc
pas d'un système opaque géré par des méchants incapables mais seulement
de la responsabilité de chaque participant.

coté opérateur de terminaux, certains ne peuvent pas se permettre une
telle vérification - par exemple un péage auto-routier où la fluidité du
traffic prime sur le reste; d'autres choississent d'y renoncer car la
perte pour transactions invalides (fausses cartes, comptes bloqués, ...)
est inférieure au cout de terminaux en-ligne (c'est la cas d'automates
de paiement de parking percevant des sommes moyennes de 5 à 10 euros).

coté utilisteur, nous ne souhaitons pas non plus une vérification en
ligne systématique - même si certaines banques présentent cette option,
par tapage publicitaire, comme le génial moyen de "savoir où j'en suis
avec mon compte" - car l'opération est nécessairement plus lente qu'une
opération off-line.

ici l'historique joue certes un role (et je ne prétends pas qu'il faille
perdurer dans l'erreur si erreur grave il y avait), nous pouvons par
exemple comparer le système français (basé sur une carte à puce opérant
son propre risk management) et le système US entièrement en-ligne (car
basé sur des cartes à piste magnétiques); le système CB a permis le
déploiement assez rapide et homogène sur tout le territoire d'un système
inter-opérable pour toutes les banques avec un faible taux d'arnaque, la
contre-partie est que la plupart des clients des services bancaires (le
commerçant) est mal ou sous équipé en terminal efficace (les terminaux
UMTS de Ingénico doivent représenter qlq pour-cents de leurs ventes), la
plupart vous laissant planté suur place plusieurs minutes quand "le
boitier doit se connecter"; le système (les systèmes!!) US a vu de son
coté la multiplication des réseaux privés concurentiels (de Visa et
MasterCard mais aussi propre à une enseigne bancaire) pouvant imposer de
disposer de plusieurs comptes (car chacun de ces prestataires n'est pas
présent partout) ou générant des frais d'opérations non négligeables
lorsque qu'une opération est sous-traitée à un réseau concurrent.

pour revenir à votre question, en fait en tant qu'utilisateur de cartes
de crédit, nous souhaiterions qu'elle ne réalise que des opérations
hors-ligne lorsque nous l'utilisons mais qu'elle bascule en tout
en-ligne dès qu'elle est volée, sur ce point les technos seront toujours
criticables servant de bouc-émissaire à la responsabilité de l'utilisateur.

Sylvain.

Vous avez filtré cet utilisateur ! Consultez son message

ast wrote on 20/01/2006 13:17:

Bonjour,

J'ai toujours lu que l'authentification de la CB était statique,
c'est à dire qu'elle se limite à la vérification par le terminal
de paiement d'une signature numérique.
Cette authentification statique n'empèche pas la réalisation de
clones.

la CB (telle que définie par le GIE CB) n'a jamais été que statique; sa
remplaçante aux normes EMV non plus.

l'utilisation d'une carte de crédit peut se faire selon 3 modes, et donc
on peut distinguer 3 attaques / 3 clones possibles.

- le niveau 0 est la simple utilisation du numéro de compte encodé dans
la piste magnétique (et/ou embossé sur le recto), ce fonctionnement est
celui de certains automates type péage ou paiement de parking où le
porteur ne saisit pas son code PIN. les clones se contente d'utiliser un
numéro de compte valide et les attaques sont identiques à celles faites
via internet par exemple.
(la petite histoire veut que suite à la présentation de la toute
première carte à puce, des opérations illégales ont été enregistrées sur
le compte de cette carte qui avait été exhibé et zoomé à souhait)

- le mode off-line est l'obtention par la carte d'une autorisation de
paiement, cette autorisation est calculé après vérification du code
porteur sur des éléments incluant date, montant, identifiant vendeur.
la carte applique alors *son* /card risk management/ pour déterminer si
elle autorise spontanément / directement la transaction ou non. pour
cela elle prends en compte différents paramètres dont le montant de la
transaction en cours, le nombre de transactions réalisées depuis la
dernière connexion à la banque, le montant cumulé de ces transactions
(les seuils de ces derniers paramètres étant fixés par la banque avant
la fabrication de la carte).
les attaques possibles dans ce mode sont nées de la publication de
certaines clés sur le net et de la lenteur du GIE à opter pour une
crypto digne (ne plus utiliser un cryptogramme simple DES).

il faut comprendre ici que la carte décide si elle vous fait crédit ou
non; elle n'a aucun moyen de connaitre la situation de votre compte,
peut être celui-ci vient d'être vidé ou même clos; cependant elle
utilisera souvent ce mode car c'est ainsi que vous -utilisateur- voulez
la voir fonctionner. (cf plus bas)

- le mode on-line résulte d'un refus par la carte d'autoriser la
transaction sur ses seuls informations ou d'une volonté du terminal
d'obtenir une vérifiation en-ligne (le terminal applique lui aussi un
risk management qui lui est propre, un commerçant peut par exemple
forcer la connexion pour toute opération dépassant un montant X).

la carte et le terminal conversent alors avec le réseau inter-bancaire
comme briévement décrit par le lien fourni.

La question que l'on peut légitimement se poser est de savoir
pourquoi cela n'est pas utilisé par TOUS les terminaux ?

commençons par noter que tous les terminaux désirant une vérification
en-ligne peuvent l'obtenir; les faiblesses observables ne résultentdonc
pas d'un système opaque géré par des méchants incapables mais seulement
de la responsabilité de chaque participant.

coté opérateur de terminaux, certains ne peuvent pas se permettre une
telle vérification - par exemple un péage auto-routier où la fluidité du
traffic prime sur le reste; d'autres choississent d'y renoncer car la
perte pour transactions invalides (fausses cartes, comptes bloqués, ...)
est inférieure au cout de terminaux en-ligne (c'est la cas d'automates
de paiement de parking percevant des sommes moyennes de 5 à 10 euros).

coté utilisteur, nous ne souhaitons pas non plus une vérification en
ligne systématique - même si certaines banques présentent cette option,
par tapage publicitaire, comme le génial moyen de "savoir où j'en suis
avec mon compte" - car l'opération est nécessairement plus lente qu'une
opération off-line.

ici l'historique joue certes un role (et je ne prétends pas qu'il faille
perdurer dans l'erreur si erreur grave il y avait), nous pouvons par
exemple comparer le système français (basé sur une carte à puce opérant
son propre risk management) et le système US entièrement en-ligne (car
basé sur des cartes à piste magnétiques); le système CB a permis le
déploiement assez rapide et homogène sur tout le territoire d'un système
inter-opérable pour toutes les banques avec un faible taux d'arnaque, la
contre-partie est que la plupart des clients des services bancaires (le
commerçant) est mal ou sous équipé en terminal efficace (les terminaux
UMTS de Ingénico doivent représenter qlq pour-cents de leurs ventes), la
plupart vous laissant planté suur place plusieurs minutes quand "le
boitier doit se connecter"; le système (les systèmes!!) US a vu de son
coté la multiplication des réseaux privés concurentiels (de Visa et
MasterCard mais aussi propre à une enseigne bancaire) pouvant imposer de
disposer de plusieurs comptes (car chacun de ces prestataires n'est pas
présent partout) ou générant des frais d'opérations non négligeables
lorsque qu'une opération est sous-traitée à un réseau concurrent.

pour revenir à votre question, en fait en tant qu'utilisateur de cartes
de crédit, nous souhaiterions qu'elle ne réalise que des opérations
hors-ligne lorsque nous l'utilisons mais qu'elle bascule en tout
en-ligne dès qu'elle est volée, sur ce point les technos seront toujours
criticables servant de bouc-émissaire à la responsabilité de l'utilisateur.

Sylvain.

Jean-Marc Desperrier

20/01/2006 à 16:11

ast wrote:

J'ai toujours lu que l'authentification de la CB était statique, c'est à dire
qu'elle se limite à la vérification par le terminal de paiement d'une signature
numérique. Cette authentification statique n'empèche pas la réalisation de
clones.

On parle bien de l'authentification, et sur l'authentification, c'est
tout à fait vrai.

Or je viens de trouver un article qui affirme qu'il y a bien une
authentification
dynamique, mais que celle-ci n'est utilisée que lorsque il y a un appel
à un centre de controle. [...]

[...] La carte calcule alors, à l'aide de la fonction f de chiffrement du DES
(ou du triple DES depuis 1999) [...]

Il y a un problème de vocabulaire, cette phase là n'est pas considéré
comme de l'authentification, mais comme la transaction de paiement.

Et cela c'est conforme à ce qui a toujours été dit, car quand on parle
des clones de carte, on précise aussi que ces clones de cartes ne
marchent que quand le terminal est "off-line", ne se connecte pas au
centre pour vérification.

La question que l'on peut légitimement se poser est de savoir pourquoi
cela n'est pas utilisé par TOUS les terminaux ?

C'est utilisé par tous les terminaux, ce n'est pas fait pour toutes les
transactions.
Quand le terminal se connecte pour demander une autorisation, il fait
cette opération. La valeur secrète doit circuler jusque la banque
émettrice de la carte qui seule peut vérifier et malheureusement c'est
long, et le réseau serait incapable d'absorber la charge si toutes les
transactions étaient réalisées ainsi.

Cf : http://www.bibmath.net/crypto/moderne/cb.php3
qui redit quasiment la même chose que le site que tu cite, mais est
peut-être un peu plus claire.

*core*administrator

20/01/2006 à 16:49

On Fri, 20 Jan 2006 16:11:52 +0100, Jean-Marc Desperrier
wrote:

La question que l'on peut légitimement se poser est de savoir pourquoi
cela n'est pas utilisé par TOUS les terminaux ?

C'est utilisé par tous les terminaux,

En France, peut-être. Dans le reste du monde, non.

Il ne faut pas oublier que la dite carte doit pouvoir être
utilisée d'une manière compatible sur les terminaux de la plupart des
pays du monde. Or tous ces pays n'utilisent pas du tout le même
protocole. Il y a des pays qui utilisent entièrement les possibilités
de la puce, il y a des pays qui utilisent partiellement les
possibilités de la puce, il y a encore des pays qui n'utilisent pas du
tout la puce mais uniquement la bande magnétique (qui, donc, doit
rester là pour compatibilité), et il existe même encore quelques pays
(ou régions) qui utilisent le vieux sabot et le contrôle, éventuel,
par appel téléphonique.

De plus, dans certains cas, quand la somme est trop petite, il n'y a
même AUCUN controle de validité sur la carte. C'est le cas, par
exemple, dans certains parkings qui acceptent la CB comme sésame pour
entrer et sortir du dit parking. Le cout de la durée du parking étant
débité sur le compte lié à la CB. Il a été estimé, à tort ou à
raison, que le cout d'une liaison téléphonique serait prohibitif par
rapport à la dépense engendrée (par exemple 1 heure de parking pour
1,50 euro). Alors seul le numéro de carte et/ou le nom de
l'utilisateur sont lus (via la piste magnétique) et envoyés en fin de
journée au serveur central.

Jean-Marc Desperrier

20/01/2006 à 17:04

Richard wrote:

On Fri, 20 Jan 2006 16:11:52 +0100, Jean-Marc Desperrier
wrote:
La question que l'on peut légitimement se poser est de savoir pourquoi
cela n'est pas utilisé par TOUS les terminaux ?
C'est utilisé par tous les terminaux,

En France, peut-être. Dans le reste du monde, non.

Les pays en question ont d'autres moyens d'autentification.
En gros, à l'étranger, vous devez signer le ticket commerçant.

Hier chez mon dentiste pour ma couronne aussi. J'ai pas trop suivi, mais
je pense que la connexion pour authorisation, c'est trop chiant, donc
signature à la place.

[...]
De plus, dans certains cas, quand la somme est trop petite, il n'y a
même AUCUN controle de validité sur la carte.
[...] Alors seul le numéro de carte et/ou le nom de
l'utilisateur sont lus (via la piste magnétique) et envoyés en fin de
journée au serveur central.

On ne vérifie même pas la signature statique ? Ca ne demanderait aucune
connexion et ça serait déjà quelquechose.

Sylvain

20/01/2006 à 18:16

Richard wrote on 20/01/2006 16:49:

C'est utilisé par tous les terminaux,

En France, peut-être. Dans le reste du monde, non.

Il ne faut pas oublier que la dite carte doit pouvoir être
utilisée d'une manière compatible sur les terminaux de la
plupart des des pays du monde.

où /le monde/ signifie l'Europe (la vieille), les US et le Japon...
(inutile d'emmener votre CB en Afghanistan ni au Zimbabwe).

et même sur ces trois zones, la compatibilité n'est pas si transparente
(votre belle carte CB estampillée VISA n'a rien d'une application VISA
telle qu'utilisée aux USA, elle signifie simplement que votre banque a
transmis votre numéro de compte à VISA pour que celui-ci le rende
disponible pour vérification à ses adhérents); les applications
bancaires restent fortement nationales.

Or tous ces pays n'utilisent pas du tout le même protocole.

encore moins la même infrastructure (c'est là le point bloquant).

De plus, dans certains cas, quand la somme est trop petite, il n'y a
même AUCUN controle de validité sur la carte. [...]
Il a été estimé, à tort ou à raison, que le cout d'une liaison
téléphonique serait prohibitif par rapport à la dépense engendrée
[...] Alors seul le numéro de carte [..] sont lus ...

le problème n'est pas du tout lié au cout de l'appel téléphonique, mais
à 1) le temps de traitement de cet appel, 2) la sécurité du dispositif
de vérification - si c'est un automate sans surveillance au 15ième
sous-sol, il ne vaut mieux pas y mettre un sésame avec des clés de
vérifs sous peine de le voir fracturer illico (les moyens de vérif.
local allant de pair avec une vérif. en-ligne).

Sylvain.

*core*administrator

20/01/2006 à 19:13

On Fri, 20 Jan 2006 18:16:48 +0100, Sylvain wrote:

2) la sécurité du dispositif
de vérification - si c'est un automate sans surveillance au 15ième
sous-sol, il ne vaut mieux pas y mettre un sésame avec des clés de
vérifs sous peine de le voir fracturer illico (les moyens de vérif.
local allant de pair avec une vérif. en-ligne).

J'imagine que vous savez de quoi vous parlez mais je suis quand

même surpris de la raison citée ci-dessus car en fait il y a de par le
monde des milliers de terminaux dans des simples boutiques qu'une
personne mal intentionnée pourrait tout autant utiliser de la manière
décrite.

*core*administrator

20/01/2006 à 19:13

On Fri, 20 Jan 2006 17:04:37 +0100, Jean-Marc Desperrier
wrote:

On ne vérifie même pas la signature statique ?

Non. Du moins pas dans les parkings qui sont gérés par cette
société que je ne citerai pas (une quinzaine de parkings). Même la
période de validité n'est pas prise en compte (un essai a été fait
avec une "ancienne" carte dont la date d'expiration était dépassée).

Le terminal d'accès lit seulement la piste magnétique et y "prélève"
deux choses. Le numéro de la carte qui est alors transféré dans un
fichier avec l'heure d'entrée puis, plus tard, l'heure de sortie et le
cout du parking. Ensuite l'identification (nom, prénom) de
l'utilisateur qui ne sert qu'a..... afficher un message de bienvenue
sur le display du terminal. Il affiche "bienvenue, Mr Jean Dupont"
lors de l'entrée puis "au revoir, Mr Jean Dupont" lors de la sortie.

Toutes les nuits à 00h01 le serveur local se connecte au serveur
Banksys et transfert le fichier complet de la journée. Cette
communication LA est, elle, sécurisée.

Il faut dire qu'avec un cout de 1,5 euros de l'heure, dégressif, le
montant total par utilisateur dépasse très rarement 10 euros.

Sylvain

20/01/2006 à 20:51

Richard wrote on 20/01/2006 19:13:

J'imagine que vous savez de quoi vous parlez mais je suis quand
même surpris de la raison citée ci-dessus car en fait il y a de par le
monde des milliers de terminaux dans des simples boutiques qu'une
personne mal intentionnée pourrait tout autant utiliser de la manière
décrite.

de quel /terminaux/ parlez-vous ?

si c'est le terminal portable d'un commerçant, il contient son identité
bancaire permettant de recevoir les transactions de la journée ... ou de
créditer n'importe quel compte client à partir de son compte vendeur, je
pense qu'il n'a pas envie de le laisser trainer.

si une utilisation frauduleuse est faite avec ce terminal (sur un compte
marchant VAD (saisi du numéro de compte emprunté) ou compte CB
(utilisation d'une carte volée)), le commerçant est responsable de ces
transactions puisqu'elles atterrissent sur son compte, s'il ne veut pas
trop d'ennui, il ne laissera pas non plus trainer son terminal.

Sylvain.

Carte bancaire et authentification dynamique.

10 réponses

Veuillez sélectionner un problème