Spécifications Europay, Mastercard et Visa EMV et applications

Les spécifications EMV et applications – 6 Chapitre trois : *** Introduction ** Historique. Depuis 1994, EMV, le consortium formé d’Europay (groupe de banques européens émetteurs de cartes) avec Mastercard et Visa a bel et bien travaillé sur des spécifications communes pour cartes à puces, terminaux et applications. En juin 1996, la version 3. 0 de ces spécifications a vue le jour : un vrai chef-d’œuvre de 3 volumes traitant les caractéristiques physiques et électriques de la carte et du terminal, l’architecture du terminal supportant les cartes multi-applications et une spécification pour une application traitant les transactions crédit/débits. Malheureusement, pas de spécifications communes pour une application porte-monnaie électronique. Mais le terminal peut traiter différents schémas de porte-monnaie électroniques. MasterCash de MasterCard et VisaCash de VISA Conformément à ces spécifications EMV, Europay a lancé sa carte prépayé CLIP en juin 1996 en Espagne, Visa a lancé sa carte prépayée durant les jeux olympiques d’Atlanta (été 1996) et c’était un vrai échec (de point de vue marketing). Les porte-monnaie électroniques MasterCash de MasterCard et VisaCash de VISA ont été installées sur une même carte EMV lancée à New York City. La moralité de cette expérience : il est possible de mettre plusieurs applications appartenant au même émetteur (carte de crédit Visa + carte prépayé Visa + VisaCash) sur une même carte EMV, mais pour des applications appartenants à des émetteurs différents il fallait une plate-forme multi-issuer : MasterCard a élaboré le Multos, Tandis que Visa a fait parti pris en proposant l’open plate-forme qui se repose sur Javacard, notons ici que javacard est le concurrent de Multos. Citons ici que Dallas (constructeur de boutons à puces) a élaboré le MAOS qui se repose aussi sur javacard. ** Opérations supportées. Une carte à puces conforme EMV supporte les opérations suivantes : * Sélection d’une application : la carte doit avoir au moins 6k ROM, 3k EEPROM et 128 RAM pour qu’elle puisse supporter une deuxième application. * Options de traitement : en utilisant les données propriétaires de l’émetteur qui se trouvent dans un ADF, la carte peut refuser une transaction en jugeant son type ou la somme mise en jeu. * Vérification du détenteur de la carte : possibilité de vérifier le PIN en mode offline (locale càd non connectée au réseau) et possibilité de bloquer et de débloquer une application sur la carte (chaque application a son propre PIN). * Authentification statique : si la mémoire est suffisante pour stocker le certificat de la clé publique de l’émetteur et les données signées de l’application. Sinon la transaction doit se faire online. * Authentification dynamique : quelle que soit la taille de la mémoire, mais la carte a éventuellement besoin d’un co-processeur pour signature RSA. * Gestion de risque de la carte : La carte peut faire passer la transaction en mode online quand la somme atteint un plafond ou si le nombre de transactions offline consécutives dépasse une certaine limite. Ceci permet à l’émetteur de faire sa gestion de risque indépendamment du terminal et en plus la carte peut garder une certaine somme « open to buy » en mode offline. * Cryptogrammes d’application : le chiffrement à clé secrète reconnu et utilisé par l’EMV est le DES. ** Services et fonctionnalité. On a introduit la carte à puce, dans les spécifications PC/SC, comme une plate-forme de stockage et de traitement. Tandis que cette carte est présentée, dans les spécifications GSM, comme une plate-forme dotée des fonctions pour rendre des services (voir le tableau).

Tableau 1 Liste exhaustive des services de sécurité et des fonctions permettant de les assurer [LAM 89]. Ici, dans les spécifications EMV, on va l’introduire comme une plate-forme capable de prendre des décisions. Ça en surplus des fonctions qui rendent des services. *** Les spécifications EMV ’96. ** Part 1 – caractéristiques électromécaniques, interface logique, protocoles. * Interface électromécanique : Ceux sont les mêmes spécifications de l’ISO 7816-2 mais les anciennes cartes qui ont besoin d’un voltage de programmation Vpp=21 volts ne sont plus conformes ici dans ces spécifications, et si le contact C6 existe, il doit être électriquement isolé. Les contacts C4 et C8 sont optionnels. Remarque : les spécifications PC/SC prévoient une utilisation future pour C4 et C8 (une carte full duplex par exemple), et on les dénote RFU, tandis qu’ici ils sont optionnels. Position des contacts sur une carte ISO (85x54x0, 8mm)

Tableau 2 CLK : la carte doit opérer correctement avec une horloge de 1 à 5 Mhz. (Ça correspond à un débit de 9600 bps). Remarque : on sait bien que les cartes de nos jours vont avec une fréquence d’horloge supérieure à 5 MHz et un débit de 115200 bps, Eh bien les anciennes ne sont pas désavantagées avec ces spécifications. En effet, la carte doit avertir le lecteur de sa performance durant la session de handshacking (ATR), et si le terminal est capable de passer à ces grandes vitesses, il le fera. Ça nous rappelle le système de repli automatique (automatic fallback) des télécopieurs (fax), où une ancienne fax (9600 bps) peut communiquer avec une nouvelle fax (33600bps) en obligeant cette dernière à descendre au même niveau que la première. Ça se fait à l’aide d’une ATR spécifique (mécanisme de double reset) ou par la commande « switch protocol » SWTPR dont l’APDU est le suivant : 80 14 P1 P2 00. P1=vitesse demandée en Bauds (115200 bps par exemple) + la fréquence exacte en Hz. P2= le nouveau protocole. * Session de carte : Cette session comprend 4 étapes : 1. insertion de l’ICC dans l’IFD (ça active un microswitch), connexion et activation des contacts. 2. l’IFD applique un reset à froid, la carte répond par un ATR (answer to reset) qui sert à présenter la carte au lecteur (sa performance, le protocole utilisé, la convention utilisée, . . . ) et comme ça la communication s’établit. Rappelons ici qu’une carte bleue utilise la convention inverse, protocole T=0, le masque B0 et l’ancienne carte bleue AFNOR (ancienne norme française où la puce était au coin supérieur gauche) avait l’ancienne masque B0. 3. Exécution de la transaction. 4. Désactivation des contacts et enlèvement de la carte. – Avis personnel : On verra par la suite que le terminal peut prendre la décision d’arrêter la session à n’importe quel instant et de passer directement à la dernière étape. La carte à puce peut aussi demander l’arrêt de la session à n’importe quel instant. Et bien sure le détenteur de la carte peut carrément enlever sa carte à n’importe quel instant (sauf dans le cas où le lecteur est du type qui avale la carte), le terminal doit détecter cette action (par le biais du microswitch) et terminer cette session. Sinon, un autre détenteur peut arriver au bon moment au bon endroit et il insère sa carte dans le bon trou et paf il se trouve en plein milieu d’une session qui ne lui appartient pas. Imaginons qu’on insère une fausse carte (un circuit imprimé de même taille que la carte à puce, il sert à prolonger les contacts de l’IFD vers l’extérieur), et si à l’autre bout de cette fausse carte on met un commutateur électronique (technologie MOS de préférence) qui sert à basculer le bus entre une vraie carte à puce et un portable (laptop). Un autre portable (ou le même) est branché en parallèle (des composants optoélectroniques de faible consommation feront l’affaire) sur le bus traversant le circuit imprimé. Ce portable joue le rôle de moniteur pour nous exhiber la transaction et pour commander le commutateur au moment propice. Ce montage nous permet de remplacer une carte par un portable ou une carte par une autre carte à un moment déterminé au cours d’une session : par exemple, après que le terminal a authentifié la carte, le portable peut remplacer la carte. (si un va et vient est nécessaire, il faut que la carte reste alimentée durant toute la manipulation). On peut même imaginer un montage où le moniteur bascule le bus de tel façon que le portable remplacera le terminal. Il prend la relève et continue la transaction avec la carte. Ce qui est intéressant c’est que si tu émets une fausse APDU, la carte te corrige avec ses octets de statut SW1, SW2. Mais par contre, il y a des manoeuvres qui font bloquer la carte comme si on essaye d’introduire un faux code secret plusieurs fois. On va voir dans la suite les procédures d’authentification introduites par l’EMV : elles compliquent la vie aux hackers, mains rien n’est impossible. Je suggère l’utilisation d’un détecteur de présence de ce type de fausse carte qui mesure l’inductance des fils entre les contacts de l’IFD et ceux de la carte. De toute façon, la messagerie sécurisée résout ce problème (CLA= x4) : En effet, une clé de session est générée et échangée sous forme chiffrée à l’aide d’une clé RSA stockée dans la carte. Tant que l’hacker ne connaît pas les clés stockées dans la carte, le système de sécurité est presque parfait (on est proche du One Time Pad si on oublie que quelqu’un peut accéder aux clés stockées). * Transportation physique des caractères. Durant le handshaking, la durée d’un bit est etu=372/f secondes, où f est en hertz et doit être comprise entre 1 et 5 Mhz. Après l’ATR, cette durée devient etu= F/D. f. Un caractère est composé de 10 bits consécutifs :1 start bit + 8 bits de données + 1 bit de parité. * Answer to reset Ayant subi le reset, la carte répond par une chaîne d’octets appelée ATR. Ces octets convoient des informations, au terminal, définissants certaines caractéristiques de la communication qui va être établie entre la carte et le terminal. Exemple : Si la carte supporte seulement le protocole T=0, l’ATR sera TS, T0, TB1, TC1. TS indique une convention directe ou inverse, T0 indique le nombre des octets historiques, TB1 concerne la Vpp, TC1 indique l’extra guardtime requis. * Protocoles de transmissions : deux types de protocoles sont définis ici :le protocole T=0 (semi-duplex, orienté caractère), et le protocole T=1 (semi-duplex, orienté bloc). La carte EMV doit supporter, au moins, l’un des deux. Le terminal doit supporter les deux. Ces protocoles sont définis suivant le modèle à couches : 1. Couche physique : s’occupe des échanges des bits, elle est commune aux 2 protocoles. 2. Couche liaison des données : divisée en sous couches : 2– structuration des caractères, commune aux 2 protocoles. 2– échange des caractères, spécifique à T=0. 2– détection et correction d’erreur, spécifique à T=0. 2– échange des blocks, spécifique à T=1. 2– détection et correction d’erreur, spécifique à T=1. 3. Couche transport: s’occupe de la transmission des messages, orientés application, spécifiques à chaque protocole. 4. Couche application : s’occupe de l’échange des messages conformément à un protocole d’application qui est commun aux 2 protocoles de transmission. Une commande est toujours émise de la couche application du terminal TAL vers la carte par l’intermédiaire de la couche transport TTL (le rôle de la couche liaison n’est pas trop précis comme il l’est en PC/SC). En effet la TAL émet un C-APDU, formé d’une entête de 5 octets et des éventuelles données, qui sera organisé par la TTL en un C-TPDU (voir plu loin). UUUUuu

Tableau 3 Entête de C-APDU Le 1er octet CLA =le demi octet droite indique si le message est claire ou chiffré, celui de gauche indique si la commande est ISO ou propriétaire EMV. * 0x instruction ISO. * 8x instruction propriétaire EMV. * x0 message clair. * x4 message chiffré, n’utilisant pas le codage BER-TLV. * xC message chiffré, codage BER-TLV, l’entête de la commande est inclut dans le calcul du MAC. Le 5ème octet P3= * Lc la longueur des données émises avec cette commande. * Le longueur maximale des données prévues en réponse à cette commande.

Tableau 4 C-APDU contenant des données et prévoyant aussi. La carte doit répondre en émettant un octet de procédure : * INS : c’est un ACK, (TTL ; soit prêt à recevoir le reste des données ou je suis prêt à recevoir le reste des données). *  : c’est un , (TTL ; soit prêt à recevoir le prochain octet de données ou l’octet prochain doit être transféré par TTL). * 60 : TTL doit fournir un temps d’attente supplémentaire. * 6x ou 9x (sauf 60) : c’est un mot de statut SW1 : TTL ; attends : un autre octet de procédure (ou le 2ème mot de statut SW2) va suivre. Cette réponse sera renvoyée à TAL par TTL sous forme d’un R-APDU :

Tableau 5 ** Part II- Données et commandes * Données et fichiers. *– Données : Nous appelons : une « donnée élémentaire » la plus petite pièce d’information identifiable par un nom, description du contenu, un format et un codage. Une donnée codée TLV sera notée « donnée », elle est constituée d’une étiquette Tag, d’une longueur Length et d’une valeur Value. La valeur V peut être constituée d’une donnée élémentaire ou bien d’une ou plusieurs « données » : Une « donnée », encapsulant une donnée élémentaire, est appelée « donnée primitive ». Une « donnée », encapsulant une ou plusieurs « données », est appelée « donnée structurée ». Une Template est le contenu du champ valeur V d’une telle « donnée structurée ». Des enregistrements ou Records sont des Templates contenants une ou plusieurs « données primitives » et/ou des « données structurées ». *– Fichiers : Les « données structurées », contenues dans des fichiers de données accessibles à la carte, seront stockées en Templates appelées Enregistrements (Records). L’organisation des fichiers est déduite de l’ISO 7816-4 càd elle suit une structure hiérarchique (arborescence) composée de trois catégories de fichiers : * MF (Master File) : répertoire principal, racine de l’arborescence. * DF (Dedicated File) : répertoire, il contient des EFs, soit d’autres DFs. * EF (Elementary File) : un fichier qui contient des données. Une application ayant La structure des fichiers qu’on va décrire est appelée PSA (Payment System Applications). Cette PSA est vue du terminale comme un arbre accessible à travers une structure de répertoire. Chaque branche de l’arbre est un ADF (Application Definition File). Un ADF est le point d’entrée à un ou plusieurs AEFs (Application Elementary File). Un ADF et ses propres fichiers de données AEF sont vus comme étant sur la même branche de l’arbre. On voit bien que cette structure est conforme à celle de l’ISO, en notant que l’ADF est un cas particulier de DF. (On rappelle ici qu’une spécification spécifie un sous ensemble d’un standard, donc une carte EMV est obligatoirement ISO-7816, et une carte GSM (SIMM) est sûrement ISO-7816 et j’insiste ici que l’exception confirme la règle si vous me montrer une carte SIMM plug-in. ). * Commandes et réponses. *– Commandes : On distingue 3 types de commandes : 1. Administratives : pour administrer une carte à puce (select file, read record, . . . ). 2. D’authentification : seules les clés d’authentification peuvent être utilisées (intAuth, ExtAuth, . . . ). 3. De paiement : un certificat est utilisé pour valider une transaction de paiement, un cryptogramme est utilisé pour vérifier l’intégrité de la transmission (sign, read balance, debit, . . . ). Voici une liste des commandes traitées en détails dans les spécifications EMV, ils vont servir, par la suite, dans les spécifications d’une application de paiement. La purse n’est pas encore standardisée, on ne voit pas ici les commandes tels que SelPK, RdBal, . . . (les 5 dernières commandes sont les seuls commandes ISO utilisées dans l’application EMV qui va suivre, pour connaître les autres commandes ISO voir table ? ? ?).

Tableau 6 Les commandes traitées par EMV ‘96 version 3. 0 *– Réponses : Les mots de statut SW1, SW2 sont retournées par la couche TTL à la couche TAL dans n’importe quel message réponse et ils dénotent l’état de traitement de la commande : Les réponses ** Part III- Sélection d’application. Le terminal détermine la liste des applications communes avec la carte, puis il en choisit une soit : – en affichant la liste, le détenteur en choisit une. – en choisissant l’application la plus prioritaire de la liste. Sélection d’application ** Part IV- Aspects de sécurité. L’authentification offline (en mode local, càd sans contacter l’émetteur) est avantageuse, car chaque communication avec l’émetteur coûtera le marchant 5FF et c’est pourquoi il refuse la carte pour les opérations inférieurs à 100FF. Les spécifications EMV ont définie 2 types d’authentification offline : Statique et dynamique. * Authentification statique : Elle est exécutée par le terminal, en utilisant la signature digitale, pour vérifier que les données de la carte ne sont pas falsifiées. En effet, la carte fournit le terminal : – la clé publique de l’émetteur certifiée par la clé privée de l’autorité de certification – signature digitale avec tous les données indiquées par l’AFL. Le terminal, possédant la clé publique de l’autorité de certification, vérifie que la clé publique de l’émetteur a été bel et bien certifiée par la clé privée de l’autorité de certification. puis il procède à vérifier la signature digitale des données de la carte en utilisant la clé publique de l’émetteur. * Authentification dynamique : cela suppose que la carte est dotée de l’algorithme RSA à clé publique (normalement, un coprocesseur est nécessaire). La carte s’authentifie auprès du terminal (comme en authentification statique) et en plus, elle signe toutes les données de la transaction, y inclut la somme. (ça revient à signer toutes les identifiées par la liste DDOL). La carte fournit le terminal : – sa clé publique certifiée par la clé privée de l’émetteur – la clé publique de l’émetteur certifié par la clé privée de l’autorité de certification – signatures digitales de toutes les données de la transaction. (données statiques de la carte, données dynamiques du terminal). Le terminal, possédant la clé publique de l’autorité de certification, vérifie que la clé publique de l’émetteur a été bel et bien certifiée par la clé privée de l’autorité de certification. Connaissant la clé publique de l’émetteur, il vérifie que la clé publique de la carte est bien certifié par l’émetteur. puis il procède à vérifier les signatures digitales des données en utilisant la clé publique de la carte. Remarque : si la carte et le terminal supportent, tous les deux, les deux types d’authentification offline statique et dynamiques, ils doivent exécuter la dynamique. * Messagerie sécurisée : L’objectif est d’assurer la confidentialité et l’intégrité des données et l’authentification de l’émetteur : – les deux services intégrité des données et authentification de l’émetteur, sont assurés par la fonction MAC. – le service confidentialité des données est assuré par la fonction chiffrement du champs des données. On distingue deux formats de messagerie sécurisée : – format 1 : où le champs des données de la commande est codé BER-TLV, l’entête de la commande est intégré dans le calcul du MAC. La classe CLA=xC. – format 2 : le champs de données n’utilise pas le codage BER-TLV. CLA=x4. Une clé de session MAC, est dérivée de la clé unique MAC Master key, pour chaque session. -*- Transaction online : La figure nous montre une telle transaction, c’était le cas avec les cartes à bande magnétique : 1- achat. 2- demande d’autorisation. 3- demande d’autorisation. 4- réponse d’autorisation. 5- enregistrement de la transaction 6- réponse d’autorisation. 7- transmission des transactions au clearing center. 8- le compte du marchand est crédité. 9- le compte du détendeur est débité. -*- Transaction offline/online : La figure nous montre une telle transaction, ça dépend de la décision de la carte, ou bien traitement offline (comme une purse càd on suppose qu’il y de la monnaie stockée dans la carte, de toute façon c’est un risque à prendre pou économiser une communication), ou bien online (la décision est : il est temps pour communiquer avec l’émetteur, payons la communication. L’émetteur va accéder à toutes les transactions commises par cette carte en mode offline, il met à jour ses fichiers) : 1- achat. 2- demande d’autorisation ou décision de la carte. 3- demande d’autorisation. 4- réponse d’autorisation. 5- réponse d’autorisation. 6- enregistrement de la transaction chez le marchand. 7- transmission des transactions quotidiennement (store and forward) 8- transmission des transactions au clearing center. 9- le compte du marchand est crédité. 10- le compte du détendeur est débité. Traitement d’une transaction online Traitement d’une transaction online/offline selon la décision de la carte. ** Annexes. * Mécanismes de sécurité : Les mécanismes reconnus sont : – le DES et 3DES pour le chiffrement à clé symétrique. – le RSA pour le chiffrement à clé publique (asymétrique). * Exemple d’échanges en mode T = 0 : Les exemples suivants illustrent des échanges de données et des octets de procédures entre la couche transport TTL du terminal et la carte ICC. Notons que : — Les octets de procédures 60 et ACK = ne sont pas illustrés ici. — [Data (x)] signifie x octets de données. — Dn est la longueur de la donnée que la carte veut envoyer au transfère durant la commande en cours. — Lc : nombre d’octets envoyés du terminal à la carte dans la commande. — Le : nombre maximum d’octets que le terminal prévoit dans la réponse de la carte. (avec Le=00 signifie 256 octets) — Licc : nombre exact d’octets dans la carte qu’elle va envoyer dans sa réponse. -*- commande 1er cas : -*- commande 2ème cas : (Le = Licc) (Le > Licc) Commande 3ème cas : Commande 4ème cas : Commande 2ème cas, en utilisant les octets de procédure 61 et 6C : (Le = Licc) (Le > Licc) : Les échanges (7 exemples) en terme d’APDU Commande 4ème cas en utilisant SW = 61  (Le > Licc) Commande 4ème cas avec alerte (62 xx ou 63 xx) : Les APDUs (2 autres exemples). 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