Application ICC pour système de payement – Spécifications

By 13 May 2012

*** Spécifications d’une application ICC pour système de payement

Généralité :

Cette spécification définit les procédures du terminal et de l’ICC qui sont nécessaires pour effectuer une transaction de payement dans un environnement de change international.

Elle couvre

:*– mapping : organisation des données dans les fichiers.
*– le flux de transaction.
*– traitement de l’exception.
*– codage des données

On remarque que :

*-*- Cette application est évidemment orientée transaction monétaire : débit, crédit, porte-monnaie (purse) électronique, . . . en modes online et offline. Mais rien n’empêche de mettre à point une application transactionnelle mais non monétaire conformément à ces spécifications.
*-*- Ces spécifications nous montrent l’intérêt des commandes spécifiques EMV (CLA=8x).
*-*- La carte est en mesure de prendre des décisions.

Les fichiers de la carte à puces

Les données sont organisées dans les fichiers selon le besoin de l’institut émettrice, avec les restrictions suivantes :

*– Tous les fichiers accessibles par la commande Read record :
*-*- doivent utiliser un identificateur de fichier SFI (avec 1 SFI 10).
*-*- doivent être linéaires.
*-*- peuvent contenir plusieurs enregistrements. Chaque enregistrement est limité à 254 octets, y compris les 2 champs étiquette et longueur.
*-*-  chaque enregistrement est codé et structuré selon les normes de l’EMV. L’étiquette est 70.
*-*- doivent contenir seulement des données codées selon BER-TLV.
*-*- inconditionnellement accessible à la lecture, et peuvent avoir des conditions d’accès pour la mise à jour.

*– Les fichiers, ayant un SFI compris entre 11 et 20, sont réservés aux données propriétaires du système de payement individuel.
*– Les fichiers, ayant un SFI compris entre 21 et 30, sont réservés aux données propriétaires de l’institution émettrice.
*– Le pointeur de fichier de l’application AFL indique les fichiers et les enregistrements qui doivent être traités par la transaction. Tout d’abord, ce pointeur doit indiquer l’enregistrement contenant les données (codées BER-TLV) nécessaires à l’Authentification des données en mode off-line. Dans le cas où la carte ne supporte que des transactions en mode on-line, l’existence de cet enregistrement est optionnelle.

Les données codées qui sont accessibles par la commande Read record :

étiquette valeur présence
5F24 date d’expiration de l’application. obligatoire
5A numéro « primaire » de compte de l’application. obligatoire
8C 1ère liste des données de la gestion de risque de la carte. obligatoire
8D 2ème liste des données de la gestion de risque de la carte obligatoire
8F index de la clé publique de l’autorité de certification. Optionnel*
90 certificat de la clé publique de l’institution émettrice. Optionnel*

* La présence de ces données est obligatoire dans les cartes supportant l’Authentification des données en mode off-line.

Les données codées qui sont accessibles par la commande Get data :

étiquette valeur présence
9F36 compteur de transactions de l’application. obligatoire
9F17 compteur des essais de PIN. Optionnel
9F13 registre du dernier ATC on-line Optionnel

Le terminal retrouve ces données en appliquant la commande Get data à la carte.

Si l’institution émettrice ne souhaite pas exécuter la fonction « vérification de la vitesse du terminal », la carte n’aura pas besoin de supporter la commande Get data.
De toute façon, le terminal peut avoir accès au compteur des transactions ATC en utilisant la commande Generate AC.

Les données accessibles par la commande Get processing option :

étiquette valeur présence
82 liste des fonctions supportées AIP obligatoire
94 pointeur de fichiers de l’application obligatoire

Le terminal retrouve ces données en envoyant la commande Get processing option à la carte.

La donnée AIP spécifie les fonctions de l’application que la carte supporte. Alors le terminal doit exécuter seulement ces fonctions.

La plupart des bits de cette donnée sont réservés pour le future. Quand on ajoute une nouvelle fonction, on doit consacrer un bit de l’AIP pour indiquer que la carte supporte cette nouvelle fonction. Par exemple : Authentification dynamique de données en mode off-line basée sur une clé symétrique.

Flux de transactions :

Voici un exemple d’organigramme qu’un terminal peut suivre :
flux de transactions - organigramme qu’un terminal peut suivre

Lire le mémoire complet ==> (Les cartes à puces)
Mémoire de fin d’études
Diplômes d’Etudes Approfondies – Réseaux de télécommunications