Fonctions utilisées pour le traitement de la transaction EMV

Les fonctions utilisées pour le traitement de la transaction : Les spécifications EMV décrivent toute la fonctionnalité, en dehors de la couche application, y compris la sélection d’application. Les fonctions décrites ici supposent que la sélection de l’application a été déjà faite. Le reste de cette section s’intéresse au dialogue terminal – carte au niveau des fonctions logiques de l’application. Ces fonctions font appel aux registres suivants : Côté terminal : le TSI (information sur l’état de la transaction) et le TVR (résultat de la vérification faite par le terminal). Durant l’exécution des fonctions, les bits de ces deux registres seront affectés par les résultats obtenus. Le terminal prendra sa décision en tenant compte des valeurs définitives de ces deux registres. Côté carte : l’AIP (la liste des fonctions supportées par la carte) et l’ AFL (la liste des fichiers et des enregistrements contenant les données nécessaires à l’application en cours). Il est formellement interdit au terminal d’aller farfouiller dans des données non citées par cette liste. En effet, cette carte supporte plusieurs applications càd il y a des données concernants autres applications que celle en cours d’exécution. On voit ici qu’une carte multi-application (EMV) convient bien à une seule institution émettrice. Tandis qu’une carte multi-issuer a besoin de firewall entre les applications appartenant à des émetteurs différents. (MAOS, MULTOS, JAVACARD, Open platform, . . . ). La fonction « Initial application processing » : Le terminal doit exécuter cette fonction de traitement juste après la fonction de « sélection de l’application ». Le terminal met à zéro tous les bits des registres TSI et TVR, puis il informe la carte du début d’une nouvelle transaction en lui envoyant la liste des informations nécessaires à cette transaction (PDOL) par le biais de la commande Get processing option. La carte répond en lui envoyant la liste des fonctions qu’elle supporte (AIP) et la liste des numéros des enregistrements nécessaire à la transaction ainsi que les numéros abrégés (SFI) des fichiers contenants ces enregistrements (AFL). Les fonctions. Description : La carte peut supporter plusieurs applications. Le terminal exécute la fonction « sélection de l’application », la carte lui passe le nom du fichier de l’application choisie (AID), et lui précise s’il doit exécuter une commande autre que Select pour y accéder (command to perform). Le terminal établie une liaison avec ce fichier ADF en émettant une commande Select {AID} : 00 A4 04 00 Lc (AID) 00. La carte répond en envoyant le FCI (avec SW1, SW2=90 00 si tout va bien). Le terminal extrait la liste PDOL du FCI, il émet la commande Get processing option à la carte en y incluant les données demandées {PDOL} : 80 A8 00 00 Lc {PDOL} 00. Le message réponse de la carte est : 80 L AIP, AFL, SW1, SW2. Si SW1, SW2 =90 00 tout va bien Si SW1, SW2 =62 81 Alerte, il faut répéter la commande Si SW1, SW2 =69 85 Erreur, la transaction ne peut pas être exécutée avec cette application, le terminal doit éliminer cette application et revenir à la fonction « sélection » pour choisir une autre application. La fonction « Read application data » : Cette fonction doit être exécuter immédiatement après la fonction « Initiate application processing ». en effet, le terminal ayant reçu AFL, il doit lire tous les fichiers et enregistrement pointés par ce dernier. (chaque élément de cette liste contient un numéro abrégé de fichier élémentaire SFI et les numéros des enregistrements N°E qui doivent être lus dans ce fichier. Le terminal émet la commande Read record vers la carte : 00 B2 N°E SFI 00, et il répète cette commande autant de fois qu’il y ait des numéros dans la liste AFL. Le message réponse de la carte est structuré conformément à BER-TLV :70, L, {données}, SW1, SW2. Le fameux AIP est un registre à 2 octets, chaque bit indique la fonction supportée :

Application interchange profile AIP. La fameuse AFL est une liste sans délimitation de N° de fichiers (SFI) et de N° d’enregistrements dans ces fichiers. Chaque élément de la liste est formé de 4 octets :

AFL : c’est La liste des enregistrements qui doivent être lus par le terminal en utilisant la commande Read record. La fonction « Off-line data authentication » : Cette fonction peut être exécuté par le terminal, dans n’importe quel ordre, après l’initiation de l’application et avant l’analyse d’action du terminal. La disponibilité des données nécessaires à cet authentification est optionnelle, leurs présence est indiquée dans AIP (liste des fonctions supportées par la carte). Si la carte et le terminal supportent tous les 2 l’authentification off-line, le terminal doit l’exécuter (il exécute la statique ou la dynamique, mais pas tous les deux), le résultat est reporté dans le bit correspondant du TSI. Si cet authentification n’est pas supportée par l’un des deux, le terminal doit noter ça dans le bit correspondant du TVR. L’entrée de ce processus est formée par les enregistrements pointés par AFL (càd la sortie du processus précédents « Read application data »), suivis par les éléments données identifiés par leur étiquette « 9F4A ». Seulement les enregistrement identifiés par la liste AFL comme participants à l’authentification off-line doivent être traités. L’authentification des données statiques off-line authentifie les données statiques stockées par l’institut émettrice dans la carte :

Les données nécessaires à l’authentification statique L’authentification des données dynamiques off-line authentifie les données résidente dans la carte et les données issues du terminal et de la carte :

Les données nécessaire à l’authentification statique La fonction « Processing restriction » : Cette fonction est exécutée par le terminal pour déterminer le degré de compatibilité entre l’application dans le terminal et l’application dans la carte. Elle peut être exécutée n’importe quand après la sélection de l’application et avant l’analyse d’action du terminal. ça comprend la vérification de la compatibilité de : N° de version de l’application (si les versions sont différentes dans le terminal et la carte, le bit correspondant dans le registre TVR sera mis à 1). Le contrôle d’utilisation de l’application, par exemple : si le terminal est un ATM, il doit vérifier que le bit « valid at ATM » est à 1 dans le registre AUC (application usage control). si le terminal n’est pas un ATM, il doit vérifier que le bit « valid at terminal other than ATM » est à 1. de même le terminal doit vérifier l’état des bits : « valid for domestic cash transaction », « valid for international cash transaction », « valid for international goods », etc. . . La date d’expiration de l’application : si la date <à la date d’expiration de la carte, le bit correspondant dans TVR doit être mis à 1. La fonction « Cardholder verification » : Cette fonction de vérification du détenteur de la carte peut être exécutée n’importe quand après la sélection de l’application et avant l’analyse d’action du terminal. Elle sert à vérifier que la personne présentant la carte est bien la personne à qui à laquelle cette application dans la carte a été émise. L’aptitude de la carte à supporter au moins une méthode de vérification est indiquée dans AIP. Si le bit correspondant à une méthode est à 1, le terminal doit utiliser la liste CVM attribuée à cette méthode. La liste CVM se trouve dans la carte, elle contient une donnée de 3 parties : X : 4 octets, indiquant une somme d’argent. Y : 4 octets, indiquant une somme d’argent. CVR : une liste contenant des données élémentaires de 2 octets chacune : 1er octet :code d’une méthode de vérification (CVM code). 2ème octet :code de condition (CVM condition code). Le bit « CV was performed » de TSI sera mis à 1. Les résultats obtenus doivent être reportés dans TVR. Les bits affectés par cette fonction : TVR

Les bits de TVR qui sont affectés par la fonction «Cardholder verification » La fonction « Terminal risk management » : Cette partie de la gestion du risque est exécuté par le terminal pour protéger l’acquéreur, l’institution émettrice et le système d’une éventuelle fraude : Le terminal passe en mode online (connecté au réseau) périodiquement pour assurer la protection contre les menaces qui ne sont pas décelable dans l’environnement offline. Le terminal passe aussi en mode on-line pour obtenir l’autorisation de l’émetteur dans le cas d’une transaction de grande valeur. Cette gestion peut être exécuté à n’importe quel moment avant l’émission de la commande « Generate AC ». Bien sûr que cette gestion n’est exécutable que si le bit « terminal risk management is supported » du registre AIP est à 1. Cette gestion consiste à : – contrôler le plafond de l’application : si la somme le dépasse alors le bit correspondant dans TVR doit être mis à 1. – choisir une transaction aléatoirement : si la somme mise en jeu par cette transaction dépasse un certain seuil et elle est toujours inférieur au plafond alors le terminal tire au sort pour passer en mode on-line. La probabilité de réussite de ce tirage au sort doit être proportionnelle à la somme. – contrôler la vitesse : après un certain nombre de transaction en mode off-line (limite inférieur de nombre de transaction off-line consécutive) le terminal doit passer en mode on-line s’il la supporte. Main une fois la limite supérieur est dépassée, le terminal doit arrêter la transaction s’il n’est pas capable de passer en mode on-line. Pour faire ce contrôle, le terminal émet la commande Get data pour lire les registres ATC et last online ATC de la carte, puis il soustrait le 2ème du 1er pour obtenir le nombre de transactions commises par cette carte sans passer en mode online. (si le terminal trouve que le 2ème registre est nul il doit mettre le bit « new card » à1 dans le TVR. Le bit « terminal risk management was performed » de TSI sera mis à 1. Les résultats obtenus doivent être reportés dans TVR. Les bits affectés par cette fonction : TVR

Les bits de TVR qui sont affectés par la fonction «Terminal risk management » La fonction « Terminal action analysis » : Le terminal, ayant exécuté sa gestion de risque et tous les autres fonctions liées à la transaction offline (le client et le marchand ont introduit tous les données), prendra sa 1ère décision :cette transaction est approuvée offline, refusée offline ou doit être exécutée online. approuvée offline :Le terminal émet à la carte une commande Generate AC pour lui demander un TC. (le message commande :80 AE P1 00 Lc {data} 00 les bits b8, b7 du paramètre P1 sont 0 et 1 respectivement)
refusée offline : Le terminal émet à la carte une commande Generate AC pour lui demander un AAC. (c’est le même message avec b8, b7=0, 0). Cette AAC peut être présentée à l’émetteur comme preuve que la carte était présente durant la transaction). doit être exécutée online : Le terminal émet à la carte une commande Generate AC pour lui demander un ARQC. (c’est le même message avec b8, b7=1, 0). Cette fonction peut être exécutée à n’importe à n’importe quel instant durant la transaction, ça élimine le traitement non nécessaire. Par exemple si le bit « failure of cardholder verification » est mis à 1alors le terminal peut passer tout de suite à l’analyse d’action. Le terminal prend sa décision préliminaire en se basant sur le contenu du registre TVR, sur les préférences de l’émetteur et sur les préférences de l’acquéreur : 3 données « codes d’action de l’émetteur » peuvent être mises dans la carte, elles reflètent les préférences de l’émetteur en terme d’action à prendre suivant le contenu du TVR. 3 données « codes d’action de l’acquéreur » peuvent être mises dans le terminal, elles reflètent les préférences de l’acquéreur en terme d’action à prendre suivant le contenu du TVR. Le terminal traite les codes d’action en paires, par exemple :si pour une valeur donnée du TVR, l’un des 2 codes d’actions (celui de l’émetteur ou celui de l’acquéreur) propose le refus de la transaction offline, le terminal doit choisir le refus. et si l’un des 2 codes d’action propose le passage en mode online, l’émetteur doit respecter ce choix. La fonction « Card action analysis » : La décision de la carte, que ça soit online ou offline, est spécifiée par sa réponse à la commande Generate AC issue du terminal. Cette fonction est obligatoire dans n’importe quelle transaction, que la carte fait ou ne fait pas sa propre gestion de risque. La carte peut faire sa propre gestion de risque pour protéger l’émetteur d’une éventuelle fraude ou d’un risque de débit excessif. Comme résultat à cette gestion, elle prendra sa décision : achever la transaction en mode offline, en mode online, demander une consultation ou refuser la transaction. approuver la demande du terminal d’exécuter la transaction en mode offline, elle lui envoi un TC. exécuter la transaction en mode online, elle lui envoi un ARQC. demander une consultation (la carte soumet un message de conseille à l’émetteur lui informant d’une situation exceptionnelle), elle lui envoi un AAR. refuser la transaction, elle lui envoi un AAC. Lorsque cette fonction est achevée, le terminal mettra à 1 le bit correspondant dans TSI. N. B. : Un AAC peut indiquer soit le rejet de cette transaction, soit une restriction due à cet environnement. si, par exemple, la carte retourne un AAC avec les bits b3b2b1=001 du CID (cryptogramme information data), ça veut dire que la restriction est due à la carte. si le bit b4=1 du CID, le terminal doit envoyer un message de conseil à l’émetteur (PIN try limit exceeded, par exemple). La fonction «  Online processing » : Cette fonction est exécutée suite à la réception du ARQC émis par la carte en réponse à la commande Generate AC. Une connexion est établie entre le terminal et l’émetteur à travers le réseau (mode online)ce qui permet à l’émetteur de revoir et d’autoriser ou rejeter les transactions qui sont en dehors des limites acceptable. Le terminal adresse un message de demande d’autorisation à l’émetteur. Ce message peut inclure l’ARQC de la carte. La réponse « message d’autorisation » envoyée par l’émetteur peut contenir des données d’authentification (étiquette 91). si la carte supporte ces données d’authentification (ça doit être indiqué dans le AIP), le terminal doit les renvoyer à la carte dans une commande External authenticate. Si la réponse de la carte est autre que SW1SW2=9000, le terminal est obligé de mettre à 1 le bit « Authentification was unsucceful ». si la carte ne supporte pas ces données d’authentification, ça voudrait dire que la carte a combiné la fonction d’authentification de l’émetteur avec la commande Generate AC, dans ce cas le terminal ne doit pas envoyer la commande External authenticate. si l’émetteur n’envoie pas des données d’authentification, le terminal n’émettrait pas la commande External authenticate. La carte ne doit pas exécuter plus qu’une seule commande External authenticate par transaction. Si le terminal lui envoi plus qu’une, elle doit répondre à la deuxième (et aux suivantes) par SW1SW2=6985. Après l’exécution de cette fonction, et si le terminal a émis la commande Generate AC il mettra à 1 le bit « Issuer authentification was performed » dans le TSI. Commandes et Réponses pour l’authentification en mode online. Issuer -to- card script processing : Le message réponse d’autorisation issue de l’émetteur supporte des commandes scripts adressées à la carte par l’intermédiaire du terminal. Si ces commandes existent, le terminal doit les transmettre à la carte, une après l’autre sous forme des APDU, sans les comprendre. (déblocage du PIN, chargement d’une clé, . . . ). Ces scripts sont organisées sous forme d’une donnée structurée portant l’étiquette 71 (scripts à traiter avant la dernière commande Generate AC) ou l’étiquette 72 (scripts à traiter après la dernière commande Generate AC). La fonction « Completion » : Cette fonction d’achèvement termine le traitement de la transaction. C’est la dernière fonction dans le traitement de la transaction (le traitement du script peut être fait après cette fonction d’achèvement). La carte indique sa volonté de terminer le traitement de la transaction en retournant un TC ou un AAC en réponse à la 1ère ou à la 2ème commande Generate AC. Si le terminal décide de passer en mode online, l’achèvement doit se faire à l’émission de la 2ème commande Generate AC. Codage de la commande Generate AC : Les paramètres de la commande Generate AC fournissent au terminal 3 options :demander un TC, un ARQC ou un AAC. La carte peut répondre à la 1ère commande Generate AC par un TC, un ARQC, un AAR ou un AAC. Tandis qu’à la 2ème commande Generate AC elle ne peut répondre que par un TC ou un AAC. Generate AC (1ère émission). Le terminal émet la commande Generate AC pour faire savoir sa décision à la carte : -*- s’il suggère la mode offline, il demande à la carte un TC, elle répond par : — TC (OK) — AAR (elle a besoin de chuchoter à l’émetteur) — ARQC (elle suggère le passage en mode online) — AAC (sorry, bye) -*- s’il suggère la mode online, il demande à la carte un ARQC, elle répond par : — AAR (elle a besoin de chuchoter à l’émetteur) — ARQC (OK) — AAC (sorry, bye) -*- s’il rejette la transaction, il demande à la carte un AAC, elle répond par : — AAC (OK, bye) Generate AC (2ème émission). Le terminal – ayant reçu une autorisation de l’émetteur (traitement en mode online), ou bien un approuve ou un rejet (consultation des tables IAC) – émettra sa 2ème commande Generate AC pour demander : -*- un TC (il a obtenu un approuve), la carte répondra par un : — TC (OK) — AAC (sorry, bye) -*- un AAC (il a obtenu un refus), la carte doit répondre par un : — AAC (ok, bye) Les données manquants ou erronées dans la carte Si c’est une donnée obligatoire, le terminal est obligé de terminer la transaction. Autrement il met à 1 le bit « ICC data missing » dans le TVR. Modèle EMV à couches 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