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).
| FonctionsServices | Chiffrement | Signature | Contrôle d’accès | Intégrité | Authentification mutuelle | Bourrage |
| Authentification | X | X | X | |||
| Contrôle d’accès | X | |||||
| Confidentialité | X | |||||
| Secret du flux | X | X | ||||
| Intégrité | X | X | X | |||
| Non répudiation | X | X |
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. 
| C1 | Alimentation (Vcc) | C5 | Terre (GND) |
| C2 | Remise à zéro (RST) | C6 | Non utilisé |
| C3 | Horloge (CLK) | C7 | E/S (I/O) |
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
| C-APDU= | CLA | INS | P1 | P2 | P3 |
| command application protocol data unit | classe de l’instruction :+ISO/EMV +claire/chiffrée | code de l’instruction | paramètre additionnel spécifique à l’instruction | paramètre additionnel spécifique à l’instruction | longueur des données émises ou des données prévues |
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.
| CLA | INS | P1 | P2 | Lc | Données | Le |
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 
| R-APDU= | Données | SW1 | SW2 |
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 ? ? ?).
| CLA | INS | Le sens |
| 8C/84 | 1E | APPLICATION BLOCK |
| 8C/84 | 18 | APPLICATION UNBLOCK |
| 8C/84 | 16 | CARD BLOCK |
| 80 | AE | GENERATE APPLICATION CRYPTOGRAMME |
| 80 | CA | GET DATA |
| 80 | A8 | GET PROCESSING OPTION |
| 8C/84 | 1A | PERSONAL IDENTIFICATION NUMBER CHANGE/UNBLOCK |
| 00 | 82 | EXTERNAL AUTHENTICATE |
| 00 | 88 | INTERNAL AUTHENTICATE |
| 00 | B2 | READ RECORD |
| 00 | A4 | SELECT |
| 00 | 20 | VERIFY |
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 : 
