*** 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 : 