These EMV

UNIVERSITE LIBANAISE SAINT-JOSEPH
(Facult de Gnie) dingnieur, ESIB)
UNIVERSITE
(Facult
Sous lgide de lagence des universits Francophones AUPELF-UREF
Diplmes dEtudes Approfondies Rseaux de tlcommunications
Cartes puces
par
CDT. EL JABI HASSAN
Soutenance le 21 Dcembre 1998 devant le jury compos de MM. Samir TOHME_________Prsident Maroun ASMAR__________Membre Imad MOUGHARBEL_____Membre Amjad HAJJAR___________Membre Mahmoud DOUGHAN____Membre Maroun CHAMOUN______Membre Nicolas ROUHANA_______Membre
Encadr par :_ . Ahmed SERHROUCHNI M
Universit St-Joseph Universit libanaise Rsum LES CARTES PUCES par Cdt El JABI Hassan Directeur de thse: Professeur TOHME Samir Dpartement de INF-RES
LINTEROPRABILITE DE PLATE-FORMES EST LE SUJET DE CONCOURS ENTRE INDUSTRIELS, CHACCUN VEUT IMPOSER SA SOLUTION COMME STANDARD. LE STANDARD ISO A RGL LINTEROPERABILIT PHYSIQUES, LES SPCIFICATIONS EMV, GSM ONT RGL LINTEROPERABILIT DAPPLICATION. ON A INTRODUIT LES DIFFRENTES ARCHITECTURES DES CARTE PUCES AU CHAPITRE 1, ON A VISIT LINITIATIVE PC/SC AU DEUXIME CHAPITRE MAIS ON A DTAILL ET EXPLICIT PEDAGOGIQUEMENT LES SPCIFICATIONS EMV AU TROISIME CHAPITRE. LE CINQUIME CHAPITRE, RACONTE LHISTOIRE DES STANDARDS ET DES SPCIFICATIONS, PUIS IL TRAITE LE PROBLME DINTEROPRABILIT DUNE MANIRE ACADMIQUE ET POUR TERMINER ON DONNE UNE METHODOLOGIE POUR DVELOPPER DES APPLICATIONS SUIVIE DUNE APPLICATION EXEMPLAIRE, TRAIT SOIGNEUSEMENT. VOUS ALLEZ DCOUVRIR , EN LISANT CETTE THSE, QUE LES METTEURS ET LES FABRIQUANTS NE SONT PLUS LES MAITRES DU JEU, CEUX SONT LES SOFTWARE PROVIDERS QUI VONT PRENDRE LE RELAIS.
ELJABI HASSAN Cartes puces
DEA
TABLE DES MATIRES
LES CARTES PUCES.............................................................................................................................1 INTRODUCTION......................................................................................................................................1 Les cartes puces et nous....................................................................................................................1 Evolution de lindustrie des cartes ......................................................................................................2 Producteurs et prix...............................................................................................................................3 Commerce lectronique :.....................................................................................................................4 ARCHITECTURE DE LA CARTE....................................................................................................................5 Carte micro contrleur :...................................................................................................................5 Carte mmoire :................................................................................................................................6 LES SPECIFICATIONS PC/SC.................................................................................................................8 INTRODUCTION......................................................................................................................................8 PROBLMATIQUE....................................................................................................................................8 LES OBJECTIFS.......................................................................................................................................9 LES SPCIFICATIONS PC/SC.....................................................................................................................9 Architecture du systme :.....................................................................................................................9 La carte puce (ICC) :......................................................................................................................10 Le terminal :.......................................................................................................................................12 ICC Resource Manager :...................................................................................................................13 Le SP(service Provider) :...................................................................................................................13
Le lecteur(IFD ou ICC reader device) :........................................................................................................12 LIFD handler :............................................................................................................................................12 Overview fonctionnel :................................................................................................................................13 Considrations dimplmentation :..............................................................................................................14 ICCSP :........................................................................................................................................................14 CSP(Cryptographic Service Provider) :.......................................................................................................14 Uses Interfaces Elements (UI): ...................................................................................................................15 Modle :.......................................................................................................................................................15 Recommandations :.....................................................................................................................................17
Application : ......................................................................................................................................15 Scurit et libert personnelle (privacy) :..........................................................................................16
LES SPCIFICATIONS EMV ET APPLICATIONS............................................................................19 INTRODUCTION ....................................................................................................................................19 Historique...........................................................................................................................................19 Oprations supportes........................................................................................................................19 Services et fonctionnalit...................................................................................................................20 LES SPCIFICATIONS EMV 96..............................................................................................................21 Part 1 - caractristiques lectromcaniques, interface logique, protocoles .....................................21
Interface lectromcanique :........................................................................................................................21 Session de carte :.........................................................................................................................................22 Transportation physique des caractres........................................................................................................23 Answer to reset............................................................................................................................................23 Protocoles de transmissions :.......................................................................................................................24
Part II- Donnes et commandes.........................................................................................................25 Part III- Slection dapplication........................................................................................................28 ..........................28 Part IV- Aspects de scurit...............................................................................................................28
Donnes et fichiers .....................................................................................................................................25 Commandes et rponses...............................................................................................................................26
Authentification statique :............................................................................................................................28 Authentification dynamique :.......................................................................................................................29 Messagerie scurise :.................................................................................................................................29
Annexes..............................................................................................................................................31 SPCIFICATIONS DUNE APPLICATION ICC POUR SYSTME DE PAYEMENT...........................................................35 Gnralit :........................................................................................................................................35
Mcanismes de scurit :.............................................................................................................................31 Exemple dchanges en mode T = 0 :..........................................................................................................31
DEA
Les fichiers de la carte puces..........................................................................................................36

Les donnes codes qui sont accessibles par la commande Read record :....................................................36 Les donnes codes qui sont accessibles par la commande Get data :..........................................................37 Les donnes accessible par la commande Get processing option :...............................................................37
Flux de transactions :.........................................................................................................................38 Les fonctions utilises pour le traitement de la transaction :.............................................................38
La fonction Initial application processing :............................................................................................39 La fonction Read application data :........................................................................................................40 La fonction Off-line data authentication :..............................................................................................41 La fonction Processing restriction :........................................................................................................43 La fonction Cardholder verification :.....................................................................................................43 La fonction Terminal risk management :...............................................................................................44 La fonction Terminal action analysis :...................................................................................................45 La fonction Card action analysis :..........................................................................................................46 La fonction Online processing :............................................................................................................47 Issuer -to- card script processing :...............................................................................................................48 La fonction Completion :.......................................................................................................................48
Codage de la commande Generate AC :............................................................................................48 Les donnes manquants ou errones dans la carte............................................................................49
Generate AC ( 1re mission) .....................................................................................................................48 Generate AC ( 2me mission) ...................................................................................................................49
METHODOLOGIE DAPPLICATIONS................................................................................................51 STANDARDS ET SPCIFICATIONS................................................................................................................51 Dfinitions :........................................................................................................................................51 Interoprabilit..................................................................................................................................52 Comparaison entre MultOS et Java Card :........................................................................................54 Solution Microsoft..............................................................................................................................55 MTHODOLOGIE ..................................................................................................................................56 APPLICATION.......................................................................................................................................58 Carte logistique pour larme :..........................................................................................................58
Objectif :......................................................................................................................................................58 Conception :................................................................................................................................................58 Recommandations :.....................................................................................................................................59 Dcisions :...................................................................................................................................................59 structure des fichiers :..................................................................................................................................60 Structure des donnes :................................................................................................................................61 Les registres EMV :.....................................................................................................................................61 Lapplication :.............................................................................................................................................61 Test :............................................................................................................................................................62
REFERENCES.............................................................................................................................................3
ii
DEA
REMERCIEMENTS
Lauteur voudrait avant tout remercier : M. Samir TOHME qui ma propos ce sujet de DEA, et accueilli dans son groupe de recherche lENST de PARIS. M . Ahmed SERHROUCHNI qui ma conseill, dirig et orient dans mon travail. M. Maroun ASMAR qui nous a offert cette opportunit et qui nous a encadr durant toute lanne.
iii
DEA
LEXIQUE
Authentification : pour sassurer que la carte appartient une famille de carte. Batch card : est fournie avec chaque lot de cartes, il contient la cl master key Carte puce : une carte , o un ou plusieurs circuits intgrs y sont encastrs, qui sert faire des traitements ou mmoriser des donnes. Concatnation : deux lments sont concatns par ladjonction des octets du deuxime la fin du premier . Une liste peut tre concatne par la concatnation la1er paire dlments de la liste pour former un nouvel lment, puis on recommence de nouveau jusqu ce quil ny a quun seul lment dans la liste . Cl prive : les algorithmes cryptographiques asymtriques sont dots dune paire de cls , lune est garde secrte , lautre est publie. La premire est la cl prive, elle sert dchiffrer le message que les autres ont chiffr avec la cl publique dj publie ( et cest seulement celui qui dtient la cl prive est capable de dchiffrer un tel message), et il sert aussi chiffrer des messages (ou leurs hashs) et a reprsente une signature que tout le monde peut dchiffrer avec la cl publique pour retrouver le document original(cest seulement celui qui dtient la cl prive est capable de faire un tel document chiffr). Cl publique : cest la deuxime cl dj publie, elle sert chiffrer des messages destins celui qui a la cl prive, et a sert dchiffrer une signature pour quon la compare au document original. Cls : sont utilises par les algorithmes cryptographiques pour : chiffrement/dchiffrement calculer des certificats et des signatures vrifier les certificats et les signatures messagerie scurise on distingue deux types dalgorithmes : cl secrte (DES, 3DES, ...) cl publique (RSA, DSA, Elliptique, ...) cls (types de ) : cl dauthentification :utilise par les commandes dauthentification cl dadministration : utilise pour calculer une cl administrative temporaire ou pour un message scuris.
iv
DEA
cl de paiement :utilise par les commandes de payements et pour calculer la cl de certification temporaire. cl de log :cest une cl de paiement qui peut tre utilise pour messagerie scurise cl de signature : cest une cl de paiement spcialise pour le calcule de signature. Certificat : est utilise pour valider une transaction de paiement. Codes secrets : sont utiliss pour protger : accs aux fichiers(read/write/update) fonctions financires(read balance/dbit/...) commandes administratives(create file/...) On peut prsenter le code secret (8 octets) la carte sous forme claire ou chiffr, elle le compare au code secret stock dans EFsc (4 octets seulement, alors votre code fonctionne si vous lintroduisez en majuscule ou en minuscule). Attention : seulement, un seul secret code est cr sous un DF. Cold Reset : on applique le Reset sur une puce non alimente, puis, on lalimente (en appliquant Vcc et CLK) tout en maintenant le Reset, puis on le relache. Cryptogramme : est utilis pour vrifier lintgrit dun message. Fabrication (phase de) : la mmoire de la carte est vide , on y crit le N de srie de la carte et la rfrence de lmetteur. Fonction : un processus accompli par une ou plusieurs commandes et les actions rsultantes, elle est utilise pour excuter toute ou une partie de la transaction Gaufrage (embossing) : caractres levs en relief de la surface de la carte. Hash : cest le rsultat de la fonction qui transforme un document en une suite de bit de longueur fixe (quelle que soit la longueur du document original), on suppose quon ne peut pas retrouver le document original partir dun Hash ni trouver un autre document qui donne ce mme Hash. Identification : aprs lauthentification, pour vrifier lidentit de la carte ( N de srie, identit du dtendeur,...) Initialisation (phase dinitialisation) : larchitecture de la carte est bien dfinie : des donnes sont crites dans la mmoire pour que la carte soit spcifique une application cration des codes secrets, gnration des cls. v
DEA
Intgrit des donnes : cest la proprit que les donnes ne sont pas altres ou dtruites dune manire illgale Intgrit (service d ): pour sassurer que le message na subi aucune altration entre la carte et le terminal. Interface Device : la partie du terminal dans laquelle on introduit la carte , appele Lecteur Non rpudiation : pour garantir que les transactions rclames reprsentent des transactions relles en ne laissant aucun marge pour rpudiation. Personnalisation (phase de) : on ajoute la carte des informations concernants le dtendeur de la carte : son nom, son N de souscription, son N de compte, ... Script : une ou une srie de commandes transmises par lmetteur dans le but dtre reues par la carte et dtre excutes en srie. Signature digitale : cest une transformation cryptographique asymtrique de donnes qui permet celui qui reoit les donnes , davoir une preuve de lorigine et de lintgrit des donnes. Et elle protge lenvoyeur et le receveur de donnes des contrefaons dun tiers. Scurit EMV : le service "scurit" est assur par les fonctions suivantes : authentification carte/terminal messagerie scurise pour la transmission des commandes administratives gnrations des certificats de payement et signatures utilisation des cryptogrammes pour les commandes de paiement Terminal : lquipement utilis en conjonction avec la carte pour excuter une transaction . Il comprend linterface device(IFD) et dautres composants et interfaces tels quun serveur de communications. Transaction financire : cest lacte entre le dtendeur de la carte et un marchand ou un acqureur pour changer des biens ou services contre paiement. Warm Reset : cest le reset quon excute sur une carte en tat de marche (alimente et connecte lhorloge).
vi
DEA
vii
DEA
LISTE DES ABREVIATIONS
AAC : Application Authentication Cryptogram. AAR : Application Authorisation Referral. AC : Application Cryptogram. ACK : acknowledgement. ADF : Application Definition File. AEF : Application Elementary File. AFL : Application File Locator. AID : Application Identifier. APDU : Application Protocol Data Unit ARPC : Authorisation Response Cryptogram. ARQC : Authorisation Request Cryptogram ATC : Application Transaction Counter. ATM : Automated Telling Machine. ATR : Answer to Reset. BER : Basic Encoding Rule. C-APDU : Commande APDU. CDOL : Card Risk Management Data Object List. CLA : Octet de classe dans une message de commande. CLK : Clock ou horloge. C-TPDU : Commande TPDU CVM : Cardholder Verification Method DDF : Directory Definition File. DDOL : Dynamic Data Authentication Data Object List. DEA : Data Encryption Algorithm. DES : Data Encryption Standard. DF : Dedicated File ou fichier ddi. DIR : Directory ou Rpertoire. ECC : Elliptic Curve Cryptosystems (systme cl publique). EF : Elementary File ou fichier lmentaire. E/S : Entre/Sortie. etu : Elementary Time Unit. FCI : File Control Information.
viii
DEA
f : la frquence. GND : Ground, la terre ou la masse. IC : Integrated circuit ou circuit intgr. ICC : Integrated circuit card ou carte puce. IFD : Interface Device (voir lexique) ou lecteur. INS : Octet Instruction dans le message commande. ISO : International Organisation for Standardisation. MAC : Message Authentication Code.(transformation cryptographique symtrique ) MF : Master File . PCMCIA : Personal Computer Memory Card International Association PDOL : Processing Data Object List. POS : Point Of Sale. PSE : Payment System Environment. PTS : Protocol Type Selection. R-APDU : Rponse APDU. RFU : Reserved for Future Use. RID : Registered Application Provider Identifier. RSA : Algorithme cryptographiques cl publique. RST : Reset. R-TPDU : Rponse TPDU. SFI : Short File Identifier. SW1 : Status word one SW2 : Status word two. TAL : Terminal Application Layer. TC : Transaction Certificate. TDOL : Transaction certificate Data Object List. TLV : Tag, Length, Value. TPDU : Transport Protocol Data Unit. TTL : Terminal Transport Layer. TVR : Terminal Verification Result. Vcc : Supply voltage ou tension dalimentation. Vpp : Programming voltage.
ix
DEA
Chapitre 1
LES CARTES PUCES
Introduction. Les cartes puces et nous. Les cartes puces ont commenc envahir la plupart des secteurs de notre vie : dans le domaine public : on cite les permis de conduire lectroniques et les cartes daide sociale (welfare) aux tats unis , les cartes de scurit sociale et dassurance maladie(78millions cartes mises en Allemagne et bientt en France) ,... Dans le domaine priv : tlcommunication : les cartes GSM. Montique : les cartes bancaires dont les applications vont du dbit, crdit, purses lectroniques , aux programmes de loyaut aux grands magasins . Scurit : les cartes daccs un systme informatique ou aux btiments. Pages : TV payant , dcodeurs des chanes satellites .
On prvoit que les cartes puce vont remplacer les tickets de voyages, ce qui faciliterait les programmes de loyaut aux compagnies ariennes . Beaucoup dautre application vont voir le jour , et on ne voit pas de limite ces applications que celle de notre imagination. Est-ce que Roland MORENO et la socit INNOVATRON , qui ont dpos leur brevet de carte semi-conducteurs en 1974 , ont-ils imagin ces applications de nos jours ? Aujourd'hui, cest la course aux cartes multi-prestataires (appeles aussi multifonctions, multi-applications, multi-branded, multiissuer...) . Quelle que soit la nomenclature, la tendance est de remplacer les cartes dans votre portefeuille par une carte unique sur laquelle coexistent plusieurs applications appartenants plusieurs institutions. Mais il y a deux contraintes : contrainte technique : on est limit 25 mm 2 de puce encarte selon le standard ISO-7816 . Mais le progrs technique est promettant , on est maintenant 30 k Octets dEEPROM . Il y a aussi dautres solutions : cartes multipuces , carte optique puce (ISO-11693/4), carte puce
DEA
avec barres codes bi- dimensionnelles ou carte puce ayant un certain disque souple encastr . contrainte logistique : les consquences de perte dune carte contenant trop d informations sont graves : il faut du temps et des nerfs dacier pour rcuprer le rcuprable (carte de crdit, permis de conduire, assurance maladie, ...) et on perd lirrcuprable (points de fidlit Monoprix, points de loyaut FNAC, kilomtres vols avec Air France, units prpayes France Telecom, et le pire la monnaie prpaye Mondex). Evolution de lindustrie des cartes . 1974 : brevet dpos par Roland MORENO et la socit INNOVATRON portant sur un systme bas sur lutilisation de cartes semi-conducteurs . 1976 : CII Honeywell-Bull a pris la licence de brevet INNOVATRON et ont adopt le terme carte microcalculateur . 1979 : premire carte compose de deux puces (3870 et 2716) . Rsultat dune coopration entre BULL et MOTOROLA. 1981 : premire carte microcontrleur monochip chez BULL (lanctre de la gamme CP8 ). 1982 : projet IPSO du GIE carte mmoire (cr en 1980 par la DGT et par des tablissements financiers) , on a test 3 types de cartes (BULL, Philips-Data systems et Flonic-Schlumberger) et cest la carte CP8 de BULL qui a t retenue. 1983 : France Telecom lance sa tlcarte puce. 1984 : BULL et PHILIPS signent un accord permettant ce dernier dutiliser le composant BULL/MOTOROLA. Aujourdhui : plus dun milliard de cartes puces sont lances par 23000 metteurs dans le monde. La demande augmente de 40% chaque anne. Les gens sont plus laise lgard de cette nouvelle ide de stocker la monnaie en un format autre que celui de billets et de pices. Cest vraiment grce aux efforts des associations des cartes de crdit internationales : ils ont fait des cartes de crdit un outil de confiance et fiable, ils ont convaincu les commerants adopter leur systme de paiement (sauf en Atlanta 1996, voir plus loin). Europay , MasterCard et Visa ont formul des techniques (EMV) pour cartes et lecteurs pour compatibilit. spcifications assurer leur
Lindustrie de tlcommunications dploie la majorit des cartes puces pour lutilisation en GSM , radio mobile et PCS (personal communication service) . En effet cette carte sert lidentification scurise et au paiement des appels. On croit que cette industrie de cellulaire a sauv celle des cartes puces. En effet les producteurs des cartes sont en majorit europens 2
DEA
et surtout franais (Gemplus, Bull, Schlumberger) et leur expansion aux Etats unis et en Australie est freine par celle des Personal Electronic Tokens . (Dallas a vendu des millions de ses i-buttons et java rings en Australie , en Russie et mme en Chine. Swatch lance cette anne ses montres contact/contactless en extrme orient).
Les concurrents de la carte puce.
Producteurs et prix. Aujourdhui , une carte puce synchrone cd mmoire (tlcarte par exemple) cote moins que 3 FF et on prvoit que a va tomber audessous de 2 FF dici la fin du sicle . Une carte puce asynchrone cd microcontrleur (carte bleue par exemple) cote entre 30 et 40 FF et a doit descendre moins de 20 FF dans cette priode. Tandis quune carte puce multifonctions dote dun co-processeur cryptographique cote plus que 60 FF (cest un nouveau produit quand mme). Plusieurs facteurs ont contribu cette rduction de prix : Laugmentation du nombre des cartes produites. La diminution du prix de la puce (cest normal , elle a diminu de taille). L'avance technologique dans la production. les fabriquants de semi-conducteurs : Hitachi, Motorolla, SGT Thomson, Siemens, NEC, ... les fabricants de cartes puce : BULL, Gemplus-Datacard, Giesecke&Devrient, ODS, Orga, Sclumberger, ... les fabriquants de lecteurs : Dassault, Hypercom, GPT, IBM, Ingenius, OKI, Schlumberger, Toshiba, Thyron, Verifone/HP, ...
Les principaux participants lindustrie des cartes puces sont :
DEA
concepteurs dapplication (software) : De la rue, Digicash, FMNT, IBM, Siemens... concepteurs de Masque et OS : BULL CP8, Gemplus, G&D, ODS, Orga, Racom, Setec OY, SCS, Toppam-Moore, US3, ... les metteurs de cartes puces : American Express, Visa, First Union Bank, Gouvernement dAllemagne, US Military, Shell oil, Bell Canada, Banque de Montral, ...
Certaines compagnies soccupent de tout : Siemens par exemple, fabrique la puce, produit la carte, conoit lOS, le masque, lapplication et le software de scurit . De toute faon, la plupart des fabricants de cartes puces conoivent leur propre systme dexploitation COS ( Card Operating System par analogie Disc Operating System DOS), ils le font adapt leur puce et orient vers une application bien dtermine. Par exemple, la carte BULL CP8 la plus rpandue est sans conteste la M4, dont la version B0 nest autre que la carte bancaire franaise puce, mais une nouvelle gnration commence dj prendre le relais sous la forme du nouveau masque B0(B0est proprit de la communaut bancaire). Il est facile de distinguer les cartes B0 des cartes B0par le fait que ces dernires portent normalement une puce position ISO (dite centre ) et ne possdant que 6 contacts au lieu de 8. Une banque peut acheter la carte chez nimporte quel producteur , en lui demandant de le masquer avec B0. Notons que s'il y a quelques dizaines de producteurs de cartes puces, il y a une centaine de socits qui conoivent des masques .
Commerce lectronique : Le commerce lectronique est une transaction montaire lectronique sans papier ( pas de signatures, pas de chques, pas de reu, pas de facture rien de cela et mme, il nest pas obligatoire que le marchand et le client se rencontrent. En effet, dans une telle transaction, la monnaie lectronique est transfre dune manire scurise sur les lignes de communications, et par consquence les comptes sont ajusts automatiquement. La carte puces est la cl lectronique qui va ouvrir un monde de services, en effet la carte peut assurer les services suivants : lidentification du client la scurisation de la liaison de communication lauthentification de la formalit de paiement lintgrit des informations traversants le rseau
DEA
la non rpudiation
maintenant , avec VISA Cash, MasterCard Cash, Proton, ... la carte stocke des valeurs dans sa mmoire (stored-value card system). Alors, la carte assure un nouveau service qui est le porte-monnaie lectronique (appele aussi : e-cash ou electronic purse). Architecture de la carte Carte micro contrleur : Cest la carte intelligente (Smart Card SC), elle a un microprocesseur 8 bits (il y a des prototypes 32 bits GemXpresso par exemple), une mmoire RAM (128 256 octets), ROM (contenant des programmes fixes, cest le DOS de la carte), EEPROM (de 1 jusqu 64 k octets, cest le Hard disc de la carte) et un port E/S appel UART (Universal Asynchronous Receiver/ Transmiter) qui communique avec le monde extrieur selon des protocoles standardiss par lISO . La figure suivante nous montre les lments principaux dune puce (25 mm 2 ) :
CLK ROM OS, Mask. Vdd RAM scratch pad EEPROM rpertoires, fichiers, codes, donnes,
CPU
Vss
coprocess eur
Entre/Sor tie programma ble E/S 1
Tempo.
RESET
E/S 2 (option)
Elments principaux dune puce.
Les questions poses pour choisir une puce convenable : type et utilisation des mmoires (RAM, ROM, EEPROM). protocoles de communications vitesse (dbit) ncessit dun co-processeur. choix de lOS. choix du masque (la partie de lapplication rsidente dans le ROM ).
DEA
Pour obtenir le maximum de fonctionnalit en une surface de puce bien limite, il faut un compromis de choix entre diffrents types de mmoires(on ne peut pas avoir tout), et attention, un co-processeur est quip dune ROM et un masque. Les commandes ISO dune telle carte sont :
Select_file Log_Record s Envelope Read_Binary Update_Rec ord Write_Binary Get_Data Update_Bin Erase_Bina ary ry Put_Data Verify Read_Recor ds Get_Challen ge Write_Recor ds Get_Respon se
Manage_Channel
Internal_Authenticate
External_authenticate
Les commandes ISO.
On va traiter seulement les cartes avec contacts, les cartes sans contacts (ISO-10536, 5 mm de distance entre la carte et le lecteur ) et les cartes remote coupling (ISO 1443, 5 m de distance entre la carte et le lecteur)sont intressantes pour des applications telles que: accs au transport public ou aux lieux de travail (contrle dheures dentre et de sortie des employs ) et a ncessite un mcanisme danticollision comme en LAN. Et comme on va traiter lEMV qui est orient transaction bancaire, il est vident quon ne va pas utiliser de telles cartes pour faire une transaction bancaire collectives 5 mtres de lATM ! Notons que les cartes hybrides (contact/contactless) ne sont pas encore standardises. Carte mmoire : Les cartes mmoires ou synchrones taient conues pour emmagasiner des informations ou des valeurs , elles sont utilises pour des applications tels que cartes de tlphones prpayes et jeter : Tlcarte T1G : cest la tlcarte actuelle en France, elle est quipe par lune des puces suivantes : ET1001 (1983), TMS3561 (1986) de Texas ou TS1001 (1987) de SGS-Thomson. Toutes ces puces sont 8 contacts. Tlcarte T2G (2me gnration) : France Telecom a imagin en 1989 de passer en CMOS, aprs une phase dexprimentation sur 100000 cartes fin 1993, ladaptation de lensemble du parc de publiphone cartes est maintenant acheve. Excute linsu de la plupart des usagers, cette opration se traduira un jour par la premption des T1G encore en circulation. Ces nouvelles Tlcartes sont quipes dune puce ST1332 ou ST1303 (Thomson) 6 contacts, sa mmoire est du type EEPROM (celle de T1G est EPROM). Grce un mcanisme dauthentification par certificat et calcul de signature partir des cls secrtes internes, la T2G est plus sres que la T1G. La 3me gnration est apparue au Canada et aux tats unis (toujours sans microprocesseur). Une telle carte fournit au
DEA
lecteur du tlphone un PIN , et cest loprateur concern ( AT&T, MCI, Bell, ...) qui va authentifier la carte et procder la decrmentation.
DEA
Chapitre 2
LES SPECIFICATIONS PC/SC

Personal Computer/Smart Card
Introduction. La carte puces est une plate-forme scuris idale pour les applications ncessitant une haute scurit et une fonctionnalit de confidence . Outre que la carte puce ICC est un quipement de stockage scuris pour informations sensibles tels que : cls prives , numros de comptes , mots de passe , informations mdicales , ...elle est dote dune fonction de traitement autonome capable de grer ces informations sans les exposer au monde extrieur .Ce qui est vraiment important pour certaines applications telles que : gnration des signatures digitales , utilisation des cls prives pour authentification , traitement des reprsentations lectroniques des valeurs (monnaies lectroniques , crdits prpays ), ...
ICC
Stockage
Traiteme
Cls Numro de Mots de

passe comptes
Gnration Utilisation
des cls privs des signatures digitales
Information ...
mdicales
Traitement ...
des valeurs
Schma fonctionnel de la carte puce(ICC)
Problmatique Le groupe de travail PC/SC constitu de CP8(Bull) , HP , Microsoft , Schlumberger et Simens a dvelopp ces spcifications pour faciliter lInteroprabilit ncessaire, voire la compatibilit de technologie des cartes puce (ICC) avec lenvironnement PC. En effet, lutilisation de la carte puce (ICC) dans lenvironnement PC est marque par manque dinteroprabilit sur plusieurs niveaux :
DEA
Pas de standard pour linterface PC/ lecteur (Interface Device IFD). Donc une application crite pour un lecteur X est incomprhensible un lecteur Y. Lutilisateur est alors oblig de changer son lecteur, chaque fois quil utilise une nouvelle application. Pas de standard pour interface de programmation haut niveau pour les fonctionnalits connues des ICCs . Ce qui rend les applications, dpendantes de limplmentation spcifiques de lICC c d une application qui fonctionne avec un ICC, ne peut ltre avec une version amliore de ce mme ICC. Lencapsulation des interfaces ICC permet plusieurs applications de partager le software de linterface bas niveau.
Les objectifs. Cette spcification cherche raliser les objectifs suivants : Maintenir les standards relatifs lICC et au PC dj existants. Indpendance de la plate-forme. Indpendance du vendeur (produit). Indpendance de lapplication.(Le software de lapplication reste le mme avec lavance technologique).
Les spcifications PC/SC. Architecture du systme : ICC-Aware Application Service Provider ICC Ressource Manager
Canal E/S :
Handl er RS
232 Lecteu r
Handl er
PS/2 Lecteu r
Handl er
USB Lecteu r
IFD
I C C
IFD
I C C
IFD
I C C
Une carte(ICC) Architecture du systme
dans
son
lecteur(IFD)
DEA
La carte puce (ICC) : la carte puce - cette fameuse carte en plastique de la taille d'une carte de crdit avec un microprocesseur encastr - est une plateforme scurise qui offre une varit de service , allant du stockage scuris des donnes jusquaux services cryptographiques. Daprs ces spcifications , la carte puce doit tre conforme physiquement et lectriquement au standard de lISO 7816-1,2,3 . Cest dire , ils reprennent exactement les recommandations ISO7816 mais avec les restrictions suivantes :
Pas de voltage de programmation
PP
.( lICC exigeant
nest pas conforme ces spcifications. Si elle doit tre isole lectriquement).
PP
est prsente,
Seulement, les protocoles suivants sont conformes : T=0 , T=1 et Synchrone(optionnelle). LIFD refuse nimporte quel protocole par dfaut sil nest pas conforme. Les caractres en tat de transite sur le port E/S sont de 10 bits :1 start bit (bas), 8 bits de donnes et 1 bit de parit.
Et ils ajoutent aux recommandations ISO-7816 les recommandations suivantes : Les lecteurs loading contacts sont recommands .(Les lecteurs swiping contacts ne sont pas interdits). La tension dalimentation est 5 V , c est au lecteur de dtecter la prsence des cartes 3 V. Lorsque le comit de lISO 7816 dterminera les mthodes, cette spcification sera mise jour. On recommande labsence de TA2 dans lATR.( LICC peut ngocier la mode dopration). On na pas besoin que la carte demande lauthentification du monde extrieur, car le PC appartient au dtenteur de la carte. Lorganisation (Mapping) des APDUs en protocole T=0 ou T=1 est la responsabilit de l ICC et du TTL/SP(la couche Transport du Service Provider). Le sous-systme IFD supporte la couche liaison de donnes :il dtecte les erreurs de parits (T=0), les erreurs de protocole et perte de synchronisation(T=1), il essaye la retransmission 3 fois , si a ne marche pas il informe le SP. (C'est le niveau transport).Tandis quen ISO 7816 ou en EMV cest la responsabilit du transmetteur(T=0) ou de TTL(T=1) cd on ne trouve pas cette discrimination entre la couche transport et celle de liaison de donnes.
On comparant avec lISO-7816 on note les nuances suivantes :
10
DEA
Les commandes sont toujours du lecteur vers la carte , cest le SP qui les gnre la demande de lapplication. LIFD doit traiter ces commandes C-TPDU (la commande et les donnes associes en un seul bloque ) LIFD met seulement lentte de la commande (CLA, INS, P1, P2, P3)et attend loctet de procdure :si cest un ACK, il commence envoyer les donnes tapes par tapes , mais si cest un SW1= 0x6x ou 0x9x, il lenvoie au SP pour interprtation. Ce qui diffre cette spcification de lISO 7816-4 et de lEMV.
On retrouve ici le mme scnario : Une fois la carte insre , le lecteur lui applique un RESET froid, la carte rpond en mettant une trame ATR(Answer To Reset) dune faon : asynchrone, semi-duplex et une dure de bit (etu ou elementary time unit) = 372/f avec 1<f<5 MHz. Cette trame ATR dfinit le protocole de transmission, la convention du codage (directe ou inverse) et les paramtres(dbit, espacement entre caractre, ngociabilit du protocole,...) : Si la carte (ICC) retourne une squence ATR non conforme, le lecteur (IFD) est oblig quand mme continuer avec le protocole et les paramtres y existants par dfaut. Si la carte (ICC) ne retourne pas une squence ATR , alors 2 cas se prsentent : 1. 2. La carte est mal insre ou bien elle est en panne. L'application ne supporte pas ce type de cartes (cartes synchrones par exemples). Le lecteur (IFD) doit envoyer RM le message cette carte ne fonctionne pas . Cest le RM qui gre le problme. Reset
Une fois la carte est insre, le lecteur (IFD) lui applique le signal RESET en mme temps quil la met sous tension. Ngociation du type de protocole: Si le lecteur est quip de loption slection explicite du type de protocole, il envoi cette requte PTS.
IFD
RESET ATR
Requte PTS Rponse PTS
Rponse RESET La carte met la ICC squence ATR dfinissant sa mode demploi:type de carte, protocole utilis, convention, dbit,.... La convention directe: le 0 logique est 0 V, le 1 logique cest +V, le bit le moins signifiant de loctet est envoy en premier. La convention indirecte:cest le contraire carte synchrone: carte mmoire. Carte asynchrone: carte microprocesseur
11

Handshacking et ngociation du protocole utiliser durant cette transaction.
DEA
Le terminal : Dans ces spcifications, la fonctionnalit du terminal (aussi appel sous systme IFD) est diffrente d'autres spcifications .En effet le sous-systme IFD consiste en : Une interface avec la carte puce. Un canal E/S contrl par un driver des E/S du ct PC. Un software IFD handler dans le PC.
Le lecteur(IFD ou ICC reader device) : LIFD joue le rle dune interface physique travers laquelle la carte puce communique avec le PC : laide de ses contacts lectriques, il assure lalimentation, lhorloge et une ligne E/S la carte puce. Il communique avec le PC travers un canal E/S. En effet laccs physique au PC se fait par le biais du port srie(RS232), du port clavier(PS/2), du port USB ou du port PCcard(PCACIA). Le protocole de communication de lIFD avec le PC est de 3 couches :
Couche de fonctions Couche de contrle
Software du client driver de lquipement E/S
Commandes et rponses de lIFD
Les fonctions de lIFD contrle du Canal E/S
Paquets de donnes
Couche physique
Contrleur du canal E/S
bits
Contrleur du canal E/S
Ct PC
Ct Lecteur
Protocole de communication entre PC et Lecteur .
LIFD handler : Ce software, lanc dans le PC , il fait implmenter un standard indpendant du hardware et une interface indpendante du canal E/S dans le sous-systme IFD. Le sous-systme IFD est responsable des 2 couches physique et liaison de donnes : Un IFD intelligent (supportant la couche liaison de donnes T=0 et T=1) ncessite un simple IFD handler. Tandis quun IFD moins 12
DEA
intelligent (ne supportant que la couche physique) ncessite un handler supportant la couche liaison des donnes T=0 et T=1, et la gestion des erreurs, etc... Le flux dinformations entre le SP et le sous-systme IFD est indiqu par la figure
ICC Service Provider

T=0 C/R T=1 INF Info/Ngo
Couche application (ISO 7816-4) Couche transport (organisation des APDU)
Soussystme IFD
Flux entre lecteur et SP.
Couche liaison des donnes (ISO 7816-3) Couche physique (ISO 7816-3)
ICC Resource Manager : Cest le responsable de la gestion des autres ressources relevant lICC dans le systme, et il supporte laccs contrle lIFD et lICC ( travers lIFD). Il rsout 3 problmes basiques dans la gestion daccs plusieurs IFDs et ICCs : Il est responsable de lidentification et le traking des ressources. Il est responsable de lallocation de ressources. Il supporte les primitives de transaction daccs aux services existants dans un ICC donn.
Le systme doit avoir un et un seul ICCRM. Le SP(service Provider) : Overview fonctionnel : Trois classes de service sont implmentes dans la plupart des ICCs : Services de fichier. Services dauthentification. Services cryptographiques.
Ces services ont une fonctionnalit en commun .Par consquent, il est trs intressant de standardiser des interfaces ces services pour que la maintenance et le dveloppement dapplication deviennent plus aiss. Ces spcifications dfinissent de telles interfaces, aussi bien quune interface standard pour contrler laccs un ICC.
13
DEA
Il y a dautres services qui refltent les besoins dans certains domaines dapplications spcifiques (EMV, GSM, ...). Ces spcifications industrielles doivent standardiser ces interfaces. Cette architecture supporte laddition de telles interfaces. Considrations dimplmentation : Le rle de la SP est de faire abstraction des dtails dimplmentation du niveau ICC, et de les exposer dune manire standard pour que le software de lapplication puisse y accder facilement. En particulier ,ces dtails liminent le besoin dun dveloppeur dapplication davoir une connaissance des commandes de mapping et des paramtres de codage associs aux protocoles T=0 et T=1 de lISO. Ces interfaces exposes par le SP doivent tre dveloppes dans le contexte dune plate-forme donne. Il est possible dimplmenter les interfaces ainsi dfinies dune manire convenable pour lutilisation des langages de programmation orients procdures (C, Pascal,...) aussi bien pour des langages de programmation orients objets (C++, Java,...). Le SP est divis en 2 sous composants : ICCSP : Il est responsable de lexposition des services non cryptographiques aux interfaces du plus haut niveau .Cette exposition doit inclure des interfaces communes(gestion des connexions de lICC, services dauthentification et daccs fichier) et des interfaces dfinies par le vendeur.
ICCSP
Interface gestion de
connexions
Mcanismes de connexion et disconnexion de lICC.
Recherche dun fichier par le fichiers nom. cration, ouverture et annulation de fichier. Ecriture/Lecture dans fichier. fermeture dun fichier. gestion des attributs dun fichier. Les interfaces.
Interface accs aux
Interface
authentification
vrification du dtenteur de la carte. authentification de lICC. authentification de lapplication la carte.
CSP(Cryptographic Service Provider) : Il isole les services de cryptographie .(pour rpondre aux rgulations dimportation et exportation imposes par les gouvernements). Le CSP encapsule laccs la fonctionnalit de cryptographie apporte par un ICC spcifique travers des interfaces de programmation de haut niveau. Les interfaces dfinies dans ces spcifications sont pour les services gnrale de cryptographie :
14
DEA
gnration des cls gestion des cls signatures digitales hachages (condenst du message) services de chiffrement bulk import et exportation des cls
Uses Interfaces Elements (UI): LICCSP et le CSP napportent aucun lment UI. Alors, le SP doit implmenter des UIs pour la gestion de CHV(si CHV existe)et pour des services tels que : gestion de PIN et mot de passe. accs administratif dsactivation). la fonctionnalit du CHV(activation et
authentification du dtenteur de la carte.
Modle : Le SP convient au modle PC individuel et au modle client/serveur. Et si on a plusieurs SP, cest le RM qui aide lapplication choisir le SP convenable.
PC client Root HUB 3 HUB 2
Souris
HUB
HUB Lecteur Lecteur Lecteur Clavier
Souris
Tlphone
Haut parleur
Diffrentes configurations de lecteurs (USB) :1.spar, 2.compos, 3.dpendant.
Application : Cette partie dcrit comment une application peut utiliser les fonctions apportes par lICC. En utilisant les 2 couches ICCRM et ICCSP ,une application peut utiliser les fonctions de la carte avec un certain degr dindpendance dun lecteur (IFD) spcifique, ou dune carte (ICC) 15
DEA
spcifique. Un dveloppeur dapplication na plus besoin de tenir compte daucune composante de gestion de lICC ou de lIFD. Il peut accder aux diffrents services en utilisant un API ou bien une interface modle objet tel que C++, Java, ...Donc cest bien une plateforme indpendante .
ICC-ware application
Requtes Rponse
ICC application
APDU
SP
OS
... ... ... ... .
IFD
T=0 T=1
contrleur
Ct systme
Ct carte
Echanges entre les 2 parties dune application (oncard et offcard)
Cdt Eljab i Hass an 1234 5678 9
Scurit et libert personnelle (privacy) : Notons que ces spcifications assument que les services et les fonctions apports par lICC servent aux programmes dapplications du dtenteur de la carte sur son PC. Dans cet environnement ,les donnes du PC , qui doivent tre stockes dans la carte, sont en texte clair. De mme, les donnes que le PC cherche dans la carte sont en clair aussi. Cest pour cette raison la messagerie scurise dfinie par lISO/IEC7816-4 nest pas utilise ici. De toute faon, le vendeur peut implmenter la messagerie scurise pour quil puisse rpondre aux besoins dune industrie spcifique. Le but de ce document est la protection des donnes au profit de lutilisateur .On assume ici que les donnes emmagasines dans la carte appartiennent lutilisateur et doivent lui tre accessible (dans certain cas, cet accs est indirect, par exemple :la cl prive qui est utilise pour la signature digitale). Ceci est en contraste avec les mcanismes dfinis pour les standards spcifiques aux industries. Ces standards sont orients la protection des donnes au profit de linstitut mettrice.
16
DEA
Recommandations : La ncessit des fonctionnalits suivantes : 1) 2) 3) Identification et authentification Intgrit, confidentialit, non rpudiation. Stockage scuris . a oblig le groupe OC/SC proposer les recommandations suivantes : Services cryptographiques : les algorithmes reconnus sont Hachage : SHA-1 (160 bits) et MD5 (128 bits). Signature digitale : RSA (cls de 512 bits min.) et DSA ( K p de 512-1024 bits, Ks de 160 bits). Echange de cls : RSA, Diffie-Helman. Chiffrement symtrique : RC2, RC4, DES, IDEA, SAFER. Services dauthentification : les protocoles reconnus sont : Authentification du dtendeur un lointain serveur : Shared Secret Challenge-Response Protocol SSCRP, et Enhanced SSCRP. Authentification du dtendeur la carte : CHV. Authentification de lapplication la carte : SSCRP. Authentification vendeur. de la carte : comme dfinie par le
Services de stockage : comme dfinie par lISO7816-4 : Fichiers de type : MF, DF, EF. Contrle daccs : ALW(always, pas de restriction), NEV(never, inaccessible), CHV(cardholder verification, la commande est excutable dans le fichier slectionn si le dtendeur introduit le bon code CHV, sinon lapplication se bloque aprs 3 essais par exemple), APP(application verification, la commande est excutable dans le fichier slectionn si lapplication sest bien authentifie auprs de la carte par SSCRP). Fichiers spciaux : EF spciaux (EFchv , ...), Fichiers obligatoires (MF, ...), fichiers cryptographiques (EFcls ). Les commandes : 31 commandes sont recommandes,( y inclut les 18 commandes ISO ) : Commandes de scurit : Verify, Change_Code, Unblock, Get_Challenge, Internal_Auth, External_Auth, User_Auth, Invalidate, Rehabilitate.
17
DEA
Commandes cryptographiques : Load_Pub_Key, Load_Priv_Key, Generate_Key, Get_Pub_Key, Delete_Key, Load_Data, Sign_Data, Load_Verify_Key, Verify_Signature, Load_Export_Key, Export_Key, Import_Key, Hash_Data. Commandes administratives : Create_File, Delete_File, Select, Read_Binary, Get_Response, Get_Data, Write_Binary, Update_Binary, Put_Data.
18
DEA
Chapitre trois
LES SPCIFICATIONS EMV ET APPLICATIONS
Introduction Historique. Depuis 1994, EMV, le consortium form d'Europay (groupe de banques europens metteurs de cartes) avec Mastercard et Visa a bel et bien travaill sur des spcifications communes pour cartes puces, terminaux et applications . En juin 1996 , la version 3.0 de ces spcifications a vue le jour : un vrai chef-duvre de 3 volumes traitant les caractristiques physiques et lectriques de la carte et du terminal, larchitecture du terminal supportant les cartes multiapplications et une spcification pour une application traitant les transactions crdit/dbits. Malheureusement , pas de spcifications communes pour une application porte-monnaie lectronique. Mais le terminal peut traiter diffrents schmas de porte-monnaie lectroniques. MasterCash de MasterCard et VisaCash de VISA Conformment ces spcifications EMV, Europay a lanc sa carte prpay CLIP en juin 1996 en Espagne, Visa a lanc sa carte prpaye durant les jeux olympiques dAtlanta (t 1996) et ctait un vrai chec (de point de vue marketing). Les porte-monnaie lectroniques MasterCash de MasterCard et VisaCash de VISA ont t installes sur une mme carte EMV lance New York City. La moralit de cette exprience : il est possible de mettre plusieurs applications appartenant au mme metteur (carte de crdit Visa + carte prpay Visa + VisaCash ) sur une mme carte EMV, mais pour des applications appartenants des metteurs diffrents il fallait une plate-forme multi-issuer : MasterCard a labor le Multos , Tandis que Visa a fait parti pris en proposant lopen 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 . Oprations supportes. Une carte puces conforme EMV supporte les oprations suivantes : Slection dune application : la carte doit avoir au moins 6k ROM,3k EEPROM et 128 RAM pour quelle puisse supporter une deuxime application.
19
DEA
Options de traitement : en utilisant les donnes propritaires de lmetteur qui se trouvent dans un ADF , la carte peut refuser une transaction en jugeant son type ou la somme mise en jeu. Vrification du dtenteur de la carte : possibilit de vrifier le PIN en mode offline (locale cd non connecte au rseau) et possibilit de bloquer et de dbloquer une application sur la carte (chaque application a son propre PIN ). Authentification statique : si la mmoire est suffisante pour stocker le certificat de la cl publique de lmetteur et les donnes signes de lapplication. Sinon la transaction doit se faire online . Authentification dynamique : quelle que soit la taille de la mmoire , mais la carte a ventuellement besoin dun 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 conscutives dpasse une certaine limite. Ceci permet lmetteur de faire sa gestion de risque indpendamment du terminal et en plus la carte peut garder une certaine somme open to buy en mode offline. Cryptogrammes dapplication : le chiffrement cl secrte reconnu et utilis par lEMV est le DES. Services et fonctionnalit. On a introduit la carte puce , dans les spcifications PC/SC , comme une plate-forme de stockage et de traitement. Tandis que cette carte est prsente, dans les spcifications GSM, comme une plate-forme dote des fonctions pour rendre des services (voir le tableau ).
Fonctions
Chiffreme nt
Signatur e
Contrle Intgrit Authentificat daccs ion mutuelle
Bourrage
Services Authentificati on Contrle daccs Confidentialit Secret du flux Intgrit Non rpudiation X X X X X X X X X X X X
Tableau 1 Liste exhaustive des services de scurit et des fonctions permettant de les assurer [LAM 89].
20
DEA
Ici , dans les spcifications EMV , on va lintroduire comme une plateforme capable de prendre des dcisions. a en surplus des fonctions qui rendent des services.
Les spcifications EMV 96. Part 1 - caractristiques lectromcaniques, interface logique, protocoles . Interface lectromcanique : Ceux sont les mmes spcifications de lISO 7816-2 mais les anciennes cartes qui ont besoin dun voltage de programmation Vpp=21 volts ne sont plus conformes ici dans ces spcifications , et si le contact C6 existe, il doit tre lectriquement isol. Les contacts C4 et C8 sont optionnels . remarque : les spcifications PC/SC prvoient une utilisation future pour C4 et C8 (une carte full duplex par exemple), et on les dnote RFU , tandis quici ils sont optionnels.
Bande magntique:
3 pistes, 79/40/107caractres Vcc RST CLK Opt GND N/U E/S Opt.
Zone de gaufrage
Position des contacts sur une carte ISO(85x54x0,8mm)
C1 C2 C3
Alimentation (Vcc) Remise zro (RST) Horloge (CLK)

Tableau 2
C5 C6 C7
Terre (GND) Non utilis E/S (I/O)
CLK : la carte doit oprer correctement avec une horloge de 1 5 Mhz.(a correspond un dbit de 9600 bps).
21
DEA
Remarque : on sait bien que les cartes de nos jours vont avec une frquence dhorloge suprieure 5 MHz et un dbit de 115200 bps, Eh bien les anciennes ne sont pas dsavantages avec ces spcifications. 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 systme de repli automatique (automatic fallback) des tlcopieurs (fax), o une ancienne fax (9600 bps) peut communiquer avec une nouvelle fax (33600bps) en obligeant cette dernire descendre au mme niveau que la premire. a se fait laide dune ATR spcifique (mcanisme de double reset) ou par la commande switch protocol SWTPR dont lAPDU est le suivant : 80 14 P1 P2 00. P1=vitesse demande en Bauds (115200 bps par exemple) + la frquence exacte en Hz. P2= le nouveau protocole. Session de carte : Cette session comprend 4 tapes : 1. 2. insertion de lICC dans lIFD (a active un microswitch), connexion et activation des contacts. lIFD applique un reset froid, la carte rpond par un ATR (answer to reset) qui sert prsenter la carte au lecteur (sa performance, le protocole utilis, la convention utilise,...) et comme a la communication stablit. Rappelons ici qu'une carte bleue utilise la convention inverse, protocole T=0, le masque B0 et lancienne carte bleue AFNOR (ancienne norme franaise o la puce tait au coin suprieur gauche ) avait l'ancienne masque B0. Excution de la transaction. Dsactivation des contacts et enlvement de la carte. Avis personnel : On verra par la suite que le terminal peut prendre la dcision darrter la session nimporte quel instant et de passer directement la dernire tape . La carte puce peut aussi demander larrt de la session nimporte quel instant. Et bien sure le dtenteur de la carte peut carrment enlever sa carte nimporte quel instant (sauf dans le cas o le lecteur est du type qui avale la carte) , le terminal doit dtecter cette action (par le biais du microswitch) et terminer cette session .Sinon , un autre dtenteur peut arriver au bon moment au bon endroit et il insre sa carte dans le bon trou et paf il se trouve en plein milieu dune session qui ne lui appartient pas. Imaginons quon insre une fausse carte (un circuit imprim de mme taille que la carte puce , il sert prolonger les contacts de lIFD vers lextrieur), et si lautre bout de cette fausse carte on met un commutateur lectronique (technologie MOS de prfrence) qui sert basculer le bus entre une vraie carte puce et un portable (laptop). 22
3. 4.
DEA
Un autre portable (ou le mme) est branch en parallle(des composants optolectroniques de faible consommation feront laffaire) sur le bus traversant le circuit imprim. Ce portable joue le rle 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 dtermin au cours dune session : par exemple , aprs que le terminal a authentifi la carte , le portable peut remplacer la carte .(si un va et vient est ncessaire, il faut que la carte reste alimente durant toute la manipulation). On peut mme imaginer un montage o le moniteur bascule le bus de tel faon que le portable remplacera le terminal. Il prend la relve et continue la transaction avec la carte. Ce qui est intressant cest 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 dintroduire un faux code secret plusieurs fois. On va voir dans la suite les procdures dauthentification introduites par lEMV : elles compliquent la vie aux hackers, mains rien nest impossible . Je suggre lutilisation dun dtecteur de prsence de ce type de fausse carte qui mesure linductance des fils entre les contacts de lIFD et ceux de la carte. De toute faon, la messagerie scurise rsout ce problme (CLA= x4) : En effet , une cl de session est gnre et change sous forme chiffre laide dune cl RSA stocke dans la carte. Tant que l'hacker ne connat pas les cls stockes dans la carte , le systme de scurit est presque parfait ( on est proche du One Time Pad si on oublie que quelquun peut accder aux cls stockes). Transportation physique des caractres. Durant le handshaking, la dure dun bit est etu=372/f secondes, o f est en hertz et doit tre comprise entre 1 et 5 Mhz . Aprs l'ATR, cette dure devient etu= F/D.f. Un caractre est compos de 10 bits conscutifs :1 start bit + 8 bits de donnes + 1 bit de parit . Answer to reset Ayant subi le reset, la carte rpond par une chane doctets appele ATR. Ces octets convoient des informations, au terminal, dfinissants certaines caractristiques de la communication qui va tre tablie entre la carte et le terminal. Exemple : Si la carte supporte seulement le protocole T=0, lATR 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 lextra guardtime requis.
23
DEA
Protocoles de transmissions : deux types de protocoles sont dfinis ici :le protocole T=0(semiduplex, orient caractre), et le protocole T=1(semi-duplex, orient bloc). La carte EMV doit supporter, au moins, lun des deux. Le terminal doit supporter les deux. Ces protocoles sont dfinis suivant le modle couches : 1. 2. 3. 4. Couche physique : soccupe des changes des bits, elle est commune aux 2 protocoles. Couche liaison des donnes : divise en sous couches : structuration des caractres, commune aux 2 protocoles. change des caractres , spcifique T=0. dtection et correction derreur, spcifique T=0. change des blocks , spcifique T=1. dtection et correction derreur, spcifique T=1. Couche transport: soccupe de la transmission des messages, orients application, spcifiques chaque protocole. Couche application : soccupe de lchange des messages conformment un protocole dapplication qui est commun aux 2 protocoles de transmission. Une commande est toujours mise de la couche application du terminal TAL vers la carte par lintermdiaire de la couche transport TTL (le rle de la couche liaison nest pas trop prcis comme il lest en PC/SC). En effet la TAL met un C-APDU, form dune entte de 5 octets et des ventuelles donnes, qui sera organis par la TTL en un C-TPDU (voir plu loin).
C-APDU= command application protocol data unit CLA classe de linstruction : +ISO/EMV +claire/chiffr e INS code de linstruction P1 paramtre additionnel spcifique linstruction P2 P3 paramtre longueur des additionnel donnes spcifique mises ou linstruction des donnes prvues
Tableau 3 Entte 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 propritaire EMV. 0x instruction ISO. 8x instruction propritaire EMV. x0 message clair. x4 message chiffr, nutilisant pas le codage BER-TLV. xC message chiffr, codage BER-TLV, lentte de la commande est inclut dans le calcul du MAC. Le 5me octet P3=
24
DEA

CLA
Lc la longueur des donnes mises avec cette commande. Le longueur maximale des donnes prvues en rponse cette commande.
INS P1 P2 Lc Donne s Le
Tableau 4 C-APDU contenant des donnes et prvoyant aussi.
La carte doit rpondre en mettant un octet de procdure : INS : cest un ACK, (TTL ; soit prt recevoir le reste des donnes ou je suis prt recevoir le reste des donnes). cest un AC , (TTL ; soit prt recevoir le IN S : K prochain octet de donnes ou loctet prochain doit tre transfr par TTL). 60 : TTL doit fournir un temps dattente supplmentaire. 6x ou 9x (sauf 60) : cest un mot de statut SW1 : TTL ; attends : un autre octet de procdure (ou le 2 me mot de statut SW2) va suivre. Cette rponse sera renvoye TAL par TTL sous forme dun R-APDU :
R-APDU= Donnes
Tableau 5
SW1
SW2
Part II- Donnes et commandes Donnes et fichiers . Donnes : Nous appelons : une donne lmentaire la plus petite pice dinformation identifiable par un nom, description du contenu, un format et un codage. Une donne code TLV sera note donne , elle est constitue dune tiquette Tag , dune longueur Length et dune valeur Value. La valeur V peut tre constitue dune donne lmentaire ou bien dune ou plusieurs donnes : Une donne , encapsulant une donne lmentaire , est appele donne primitive .
25
DEA
Une donne , encapsulant une ou plusieurs donnes , est appele donne structure . Une Template est le contenu du champ valeur V dune telle donne structure . Des enregistrements ou Records sont des Templates contenants une ou plusieurs donnes primitives et/ou des donnes structures . Fichiers : Les donnes structures , contenues dans des fichiers de donnes accessibles la carte, seront stockes en Templates appeles Enregistrements (Records). Lorganisation des fichiers est dduite de lISO 7816-4 cd elle suit une structure hirarchique (arborescence) compose de trois catgories de fichiers : MF (Master File) : larborescence. rpertoire principal, racine de
DF (Dedicated File) : rpertoire, il contient des EFs, soit dautres DFs. EF (Elementary File) : un fichier qui contient des donnes. Une application ayant La structure des fichiers quon va dcrire est appele PSA (Payment System Applications ) . Cette PSA est vue du terminale comme un arbre accessible travers une structure de rpertoire . Chaque branche de larbre est un ADF (Application Definition File) . Un ADF est le point dentre un ou plusieurs AEFs (Application Elementary File ) . Un ADF et ses propres fichiers de donnes AEF sont vus comme tant sur la mme branche de larbre. On voit bien que cette structure est conforme celle de lISO , en notant que lADF est un cas particulier de DF .(On rappelle ici quune spcification spcifie un sous ensemble dun standard , donc une carte EMV est obligatoirement ISO-7816, et une carte GSM (SIMM) est srement ISO-7816 et jinsiste ici que lexception confirme la rgle si vous me montrer une carte SIMM plug-in.). Commandes et rponses. Commandes : On distingue 3 types de commandes :
1. 2. 3.
Administratives : pour administrer une carte puce (select file, read record, ...). Dauthentification : seules les cls dauthentification peuvent tre utilises (intAuth, ExtAuth,...). De paiement : un certificat est utilis pour valider une transaction de paiement, un cryptogramme est utilis pour vrifier lintgrit de la transmission (sign, read balance, debit, ...).
26
DEA
voici une liste des commandes traites en dtails dans les spcifications EMV , ils vont servir, par la suite, dans les spcifications dune application de paiement. La purse nest pas encore standardise, on ne voit pas ici les commandes tels que SelPK, RdBal, ... (les 5 dernires commandes sont les seuls commandes ISO utilises dans lapplication EMV qui va suivre, pour connatre les autres commandes ISO voir table ? ? ?).
CLA 8C/84 8C/84 8C/84 80 80 80 8C/84 00 00 00 00 00 INS 1E 18 16 AE CA A8 1A 82 88 B2 A4 20 Le sens APPLICATION BLOCK APPLICATION UNBLOCK CARD BLOCK GENERATE APPLICATION CRYPTOGRAMME GET DATA GET PROCESSING OPTION PERSONAL IDENTIFICATION NUMBER CHANGE/UNBLOCK EXTERNAL AUTHENTICATE INTERNAL AUTHENTICATE READ RECORD SELECT VERIFY
Tableau 6 Les commandes traites par EMV 96 version 3.0
Rponses : Les mots de statut SW1,SW2 sont retournes par la couche TTL la couche TAL dans nimporte quel message rponse et ils dnotent ltat de traitement de la commande :
SW1,SW2 termin normal alerte avort excution vrification 67xx to 6Fxx
61xx 9000
62xx
63xx 64xx
65xx
27
DEA
Les rponses
Part III- Slection dapplication. Le terminal dtermine la liste des applications communes avec la carte, puis il en choisit une soit : en affichant la liste, le dtenteur en choisit une. en choisissant lapplication la plus prioritaire de la liste.
Select PSE DDF
Slection du DDF 1PAY.SYS.DDF01
Get Response La carte envoie le FCI du DDF Read Record (0201h) La carte envoie la liste des ADFs Select ADF Get Response La carte envoie le FCI Lapplication est choisie Cdt Eljabi Hassan 123456789
Slection dapplication
Part IV- Aspects de scurit. Lauthentification offline (en mode local, cd sans contacter lmetteur ) est avantageuse, car chaque communication avec lmetteur cotera le marchant 5FF et cest pourquoi il refuse la carte pour les oprations infrieurs 100FF. Les spcifications EMV ont dfinie 2 types dauthentification offline : Statique et dynamique. Authentification statique : Elle est excute par le terminal, en utilisant la signature digitale, pour vrifier que les donnes de la carte ne sont pas falsifies. En effet, la carte fournit le terminal :
la cl publique de lmetteur certifie par la cl prive de lautorit de certification 28
DEA
signature digitale avec tous les donnes indiques par lAFL.
Le terminal, possdant la cl publique de lautorit de certification, vrifie que la cl publique de lmetteur a t bel et bien certifie par la cl prive de lautorit de certification. puis il procde vrifier la signature digitale des donnes de la carte en utilisant la cl publique de lmetteur. Authentification dynamique : cela suppose que la carte est dote de lalgorithme RSA cl publique (normalement, un coprocesseur est ncessaire ). La carte sauthentifie auprs du terminal (comme en authentification statique ) et en plus , elle signe toutes les donnes de la transaction, y inclut la somme.( a revient signer toutes les identifies par la liste DDOL ). La carte fournit le terminal :

sa cl publique certifie par la cl prive de lmetteur
la cl publique de lmetteur certifi par la cl prive de lautorit de certification signatures digitales de toutes les donnes de la transaction. (donnes statiques de la carte, donnes dynamiques du terminal ).
Le terminal, possdant la cl publique de lautorit de certification, vrifie que la cl publique de lmetteur a t bel et bien certifie par la cl prive de lautorit de certification. Connaissant la cl publique de lmetteur, il vrifie que la cl publique de la carte est bien certifi par lmetteur. puis il procde vrifier les signatures digitales des donnes en utilisant la cl publique de la carte. Remarque : si la carte et le terminal supportent, tous les deux, les deux types dauthentification offline statique et dynamiques, ils doivent excuter la dynamique. Messagerie scurise : Lobjectif est dassurer la confidentialit et lintgrit des donnes et lauthentification de lmetteur :
les deux services intgrit des donnes et authentification de lmetteur, sont assurs par la fonction MAC . le service confidentialit des donnes est assur par la fonction chiffrement du champs des donnes. format 1 : o le champs des donnes de la commande est cod BER-TLV , lentte de la commande est intgr dans le calcul du MAC. La classe CLA=xC. format 2 : le champs de donnes nutilise pas le codage BERTLV. CLA=x4.
On distingue deux formats de messagerie scurise :
29
DEA
Une cl de session MAC , est drive de la cl unique MAC Master key, pour chaque session. Transaction online : La figure nous montre une telle transaction, ctait le cas avec les cartes bande magntique : 1- achat. 2- demande dautorisation. 3demande dautorisation. 4- rponse dautorisation. 5- enregistrement de la transaction 6- rponse dautorisation. 7- transmission des transactions au clearing center. 8- le compte du marchand est crdit. 9- le compte du dtendeur est dbit. Transaction offline/online : La figure nous montre une telle transaction, a dpend de la dcision de la carte , ou bien traitement offline (comme une purse cd on suppose quil y de la monnaie stocke dans la carte, de toute faon cest un risque prendre pou conomiser une communication ), ou bien online (la dcision est : il est temps pour communiquer avec lmetteur, payons la communication. Lmetteur va accder toutes les transactions commises par cette carte en mode offline, il met jour ses fichiers ) : 1- achat. 2- demande dautorisation ou dcision de la carte. 3- demande dautorisation. 4- rponse dautorisation. 5rponse dautorisation. 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 crdit. 10- le compte du dtendeur est dbit.
Card Clearing center 9 Autorisatio n center 4 Emetteur 3 2 5 ... ... ... ... . Marchand Acqureur 6 7 Acquiring center 8
Cdt Eljab i Hass an 1234 Dtendeur 5678 9
Traitement dune transaction online
30
ELJABI HASSAN
A Autorisatio n center
Card Clearing center
DEA
9 Acquiring center
Cartes puces
8 4
Emetteur 3 5
Acqureur 7 2
Cdt Eljab i Hass an 1234 Dtendeur 5678 9
... ... ... 6 ... . Marchand
Traitement dune transaction online/offline selon la dcision de la carte.
Annexes. Mcanismes de scurit : Les mcanismes reconnus sont :

le DES et 3DES pour le chiffrement cl symtrique.
le RSA pour le chiffrement cl publique (asymtrique ).
Exemple dchanges en mode T = 0 : Les exemples suivants illustrent des changes de donnes et des octets de procdures entre la couche transport TTL du terminal et la carte ICC. Notons que : Les octets de procdures 60 et ACK = Ins illustrs ici. [ Data(x)] signifie x octets de donnes . Dn est la longueur de la donne que la carte veut envoyer au n me transfre durant la commande en cours. Lc : nombre doctets envoys du terminal la carte dans la commande. Le : nombre maximum doctets que le terminal prvoit dans la rponse de la carte.(avec Le=00 signifie 256 octets) Licc : nombre exact doctets dans la carte quelle va envoyer dans sa rponse. commande 1er cas :
TAL TTL ICC
C-APDU { CLA, INS, P1, P2, 00 }
ne sont pas
C-TPDU [ CLA, INS, P1, P2, 00 ]
31
Processus Termin

SW1, SW2 [ 90 00 ]
DEA
R-APDU [ 90 00 ]
commande 2me cas : ( Le = Licc )

TAL TTL ICC
C-APDU { CLA, INS, P1, P2, 00 } Le terminal prvoit 256 octets de la part de la carte Terminal, soit prt!
C-TPDU [ CLA, INS, P1, P2, 00 ] Ack [ INS ] R-TPDU [ Data(Licc)], 90 00
R-APDU {[ Data(Licc)], 90 00}
TTL vrifie que le nombre doctets est bien 256. Puis elle les envoi TAL
( Le > Licc )
TAL TTL ICC
C-APDU { CLA, INS, P1, P2, 00 }
C-TPDU [ CLA, INS, P1, P2, 00 ] SW1, SW2 [ 6C Licc ] C-TPDU [ CLA, INS, P1, P2, Licc] Ack [ INS ] [ Data(Licc)] SW1, SW2 [ 90 00 ] Processus Termin
Terminal, soit prt!
TTL vrifie que le nombre doctets est bien Licc. Puis elle les envoi TAL
Commande 3me cas :

TAL
C-APDU {CLA,INS,P1,P2,Lc, [Data(Lc)]}
TTL
ICC
SW1, SW2 [ 6C Licc ] Terminal, je suis prt! TTL envoi les donnes de longueur Lc Processus Termin
C-TPDU [ CLA, INS, P1, P2, Lc ] Ack [ INS ] C-TPDU [ Data(Lc)]
R-APDU 90 00
SW1, SW2 [ 90 00 ]
32
DEA
Commande 4me cas :

TAL
Le terminal envoi Lc octets et prvoit recevoir 256 octets C-APDU {CLA,INS,P1,P2,Lc, [Data(Lc)],00}
TTL
ICC
C-TPDU [ CLA, INS, P1, P2, Lc ] ACK [ INS ] C-TPDU [ Data(Lc)] SW1, SW2 [ 61 Licc ] Get response [ 00, C0, 00, 00, Licc] TTL envoi les donnes de longueur Lc ICC dclare la longueur exacte de ses donnes Licc
{C0,[ Data(Licc)], 90 00}
Commande 2me cas, en utilisant les octets de procdure 61 et 6C : (Le = Licc )

TAL
Le terminal envoi une commande et prvoit recevoir 256 octets C-APDU {CLA, INS, P1, P2, 00}
TTL
ICC
ICC dclare que D1 est la longueur des donnes de la 1re squence Soit prt voici D1 octets D2 est la longueur e de la 2m squence Processus rpt n fois TTL vrifie que le nombre doctets est bien 256. Puis elle les envoi TAL
C-TPDU [ CLA, INS, P1, P2, 00 ] SW1, SW2 [ 61 D1 ] Get response [ 00, C0, 00, 00, D1] {C0,[ Data(D1)], 61 D2} Get response [ 00, C0, 00, 00, Dn]
{C0,[ Data(Dn)], 90 R-APDU 00} {[ Data(D1+D2+...+Dn)], 90 00}
(Le > Licc ) :

TAL
Le terminal envoi une commande et prvoit recevoir 256 octets C-APDU {CLA, INS, P1, P2, 00}
TTL
ICC
C-TPDU [ CLA, INS, P1, P2, 00 ] SW1, SW2 [ 6C Licc ] C-TPDU [ CLA, INS, P1, P2, Licc ] SW1, SW2 [ 61 D1 ]
Mais non coutes, je nai que Licc octets envoyer TTL corrige la commande et prvoit Licc octets
33

Get response [ 00, C0, 00, 00, D1] {C0,[ Data(D1)], 61 D2} Get response [ 00, C0, 00, 00, Dn] {C0,[ Data(Dn)], 90 R-APDU 00} {[ Data(D1+D2+...+Dn)], 90 00}
DEA
Soit prt voici D1 octets D2 est la longueur e de la 2m squence Processus rpt n fois TTL vrifie que le nombre doctets est bien Licc. Puis elle les envoi TAL
Les changes (7 exemples)en terme dAPDU
Commande 4me cas en utilisant SW = 61 (Le > Licc )

TAL
Le terminal envoi Lc octets et prvoit recevoir 256 octets C-APDU {CLA,INS,P1,P2,Lc, [Data(Lc)],00}
TTL
ICC
C-TPDU [ CLA, INS, P1, P2, Lc ] Ack [ INS ] C-TPDU [ Data(Lc)] SW1, SW2 [ 61 D1 ] Get response [ 00, C0, 00, 00, D1] {C0,[ Data(D1)], 61 D2} Get response [ 00, C0, 00, 00, Dn] Terminal, je suis prt!
Soit prt voici D1 octets D2 est la longueur e de la 2m squence Processus rpt n fois
{C0,[ Data(Dn)], 90 R-APDU 00} {[ Data(D1+D2+...+Dn)], 90 00}
Commande 4me cas avec alerte (62 xx ou 63 xx) :

TAL
C-APDU {CLA,INS,P1,P2,Lc, [Data(Lc)],00}
TTL
ICC
C-TPDU [ CLA, INS, P1, P2, Lc ]
34
DEA
Ack [ INS ] C-TPDU [ Data(Lc)] SW1, SW2 [ 61 Licc ] Get response [ 00, C0, 00, 00, Licc] R-APDU {[ Data(Licc)], 62 xx} {C0,[ Data(Licc)], 62 xx} TTL doit faire passer le message dalerte avec les donnes TAL
Les APDUs(2 autres exemples).
Spcifications dune application ICC pour systme de payement Gnralit : Cette spcification dfinit les procdures du terminal et de lICC qui sont ncessaires pour effectuer une transaction de payement dans un environnement de change international. Elle couvre : mapping :organisation des donnes dans les fichiers. le flux de transaction. traitement de lexception. codage des donnes
On remarque que : Cette application est videmment oriente transaction montaire :dbit, crdit, porte-monnaie (purse) lectronique, ... en modes online et offline. Mais rien nempche de mettre point une application transactionnelle mais non montaire conformment ces spcifications. Ces spcifications nous montrent spcifiques EMV (CLA=8x). lintrt des commandes
35
DEA
La carte est en mesure de prendre des dcisions . Les fichiers de la carte puces Les donnes sont organises dans les fichiers selon le besoin de linstitut 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 linaires. 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 lEMV. Ltiquette est 70 . doivent contenir seulement des donnes codes selon BER-TLV. inconditionnellement accessible la lecture , et peuvent avoir des conditions daccs pour la mise jour. Les fichiers , ayant un SFI compris entre 11 et 20, sont rservs aux donnes propritaires du systme de payement individuel. Les fichiers , ayant un SFI compris entre 21 et 30, sont rservs aux donnes propritaires de linstitution mettrice. Le pointeur de fichier de lapplication AFL indique les fichiers et les enregistrements qui doivent tre traits par la transaction. Tout dabord ,ce pointeur doit indiquer lenregistrement contenant les donnes (codes BER-TLV) ncessaires lAuthentification des donnes en mode off-line .Dans le cas o la carte ne supporte que des transactions en mode on-line, lexistence de cet enregistrement est optionnelle. record :
Les donnes codes qui sont accessibles par la commande Read
tique tte
5F24 5A 8C 8D 8F
valeur
date dexpiration de lapplication.
prsen ce
obligato ire numro primaire de compte de obligato lapplication. ire re 1 liste des donnes de la gestion de obligato risque de la carte. ire me 2 liste des donnes de la gestion de obligato risque de la carte ire index de la cl publique de lautorit de Optionne l* certification. 36
DEA
90
certificat de la cl linstitution mettrice.
publique
de Optionne
l*
* La prsence de ces donnes est obligatoire dans les cartes supportant lAuthentification des donnes en mode off-line.
Les donnes codes qui sont accessibles par la commande Get data :
tique tte
9F36 9F17 9F13
valeur
compteur de transactions lapplication. compteur des essais de PIN. registre du dernier ATC on-line
le terminal retrouve ces donnes en appliquant la commande Get data la carte.
prsen ce
de obligato ire Optionn el Optionn el
Si linstitution mettrice ne souhaite pas excuter la fonction vrification de la vitesse du terminal , la carte naura pas besoin de supporter la commande Get data . De toute faon, le terminal peut avoir accs au compteur des transactions ATC en utilisant la commande Generate AC . Les donnes accessible par la commande Get processing option :
tique tte
82 94
valeur
liste des fonctions supportes AIP pointeur de fichiers de lapplication
Le terminal retrouve ces donnes en envoyant la commande Get processing option la carte.
prsen ce
obligato ire obligato ire
La donne AIP spcifie les fonctions de lapplication que la carte supporte . Alors le terminal doit excuter seulement ces fonctions . La plupart des bits de cette donne sont rservs pour le future . Quand on ajoute une nouvelle fonction ,on doit consacrer un bit de lAIP pour indiquer que la carte supporte cette nouvelle fonction. Par exemple : Authentification dynamique de donnes en mode off-line base sur une cl symtrique.
37
DEA
Flux de transactions : Voici un exemple dorganigramme quun terminal peut suivre :

Initier lapplicatio n Lire les donnes de lapplicatio n
Authentification des donnes Traitement de restrictions Vrification du dtenteur de la carte
Gestion de risque du terminal
Analyse daction du terminal Analyse daction de la carte

Dcisio n finale
On-line
Traitement de lapplication on-line et Authentification de lmetteur
Off-line
Achveme nt
Traitement du script
Les fonctions utilises pour le traitement de la transaction : Les spcifications EMV dcrivent toute la fonctionnalit, en dehors de la couche application, y compris la slection dapplication. Les fonctions dcrites ici supposent que la slection de lapplication a t dj faite. Le reste de cette section sintresse au dialogue terminal - carte au niveau des fonctions logiques de lapplication. Ces fonctions font appel aux registres suivants : Ct terminal : le TSI (information sur ltat de la transaction) et le TVR (rsultat de la vrification faite par le terminal). Durant lexcution des fonctions , les bits de ces deux registres seront affects par les rsultats obtenus. Le terminal prendra sa dcision en tenant compte des valeurs dfinitives de ces deux registres. 38
DEA
Ct carte : l AIP (la liste des fonctions supportes par la carte) et l AFL (la liste des fichiers et des enregistrements contenant les donnes ncessaires lapplication en cours).Il est formellement interdit au terminal daller farfouiller dans des donnes non cites par cette liste. En effet, cette carte supporte plusieurs applications cd il y a des donnes concernants autres applications que celle en cours dexcution . On voit ici quune carte multi-application(EMV) convient bien une seule institution mettrice. Tandis quune carte multi-issuer a besoin de firewall entre les applications appartenant des metteurs diffrents.(MAOS , MULTOS , JAVACARD , Open platform , ...). La fonction Initial application processing : Le terminal doit excuter cette fonction de traitement juste aprs la fonction de slection de lapplication . Le terminal met zro tous les bits des registres TSI et TVR , puis il informe la carte du dbut dune nouvelle transaction en lui envoyant la liste des informations ncessaires cette transaction (PDOL) par le biais de la commande Get processing option. La carte rpond en lui envoyant la liste des fonctions quelle supporte (AIP) et la liste des numros des enregistrements ncessaire la transaction ainsi que les numros abrgs (SFI) des fichiers contenants ces enregistrements (AFL).
Les fonctions.
FONCTION slection dapplication Rsulta t AID nom de lADF
RHM
Interaction
MF
DDF1
DIR A
FONCTION initiate application process AID est le nom de notre fichier dapplication (ADF), y jetons un coup dil . Le fichier ADF nous apparat comme un fichier contenant des donnes encapsules dans son FCI. Ah, la carte a besoin de mes donnes concatenes suivant un format PDOL. OK, je te les passe et tu me passes tes donnes concernant lapplication. AIP, AFL Rsulta F t onctions supportes(AIP) adresse des donnes (AFL). FONCTION Read application data
Notre ADF Select {AID} FCI , SW1, SW2 EF EF
Autre ADF
Autre ADF
EF
EF
FCI
Get processing option{PDOL} AIP, AFL, SW1, SW2.
FCI={FCI template, DF name, FCI proprietary template, et en option: PDOL, application priority indicator, ...}
39
DEA
Description : La carte peut supporter plusieurs applications. Le terminal excute la fonction slection de lapplication , la carte lui passe le nom du fichier de lapplication choisie (AID),et lui prcise sil doit excuter une commande autre que Select pour y accder(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 rpond 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 donnes demandes {PDOL} : 80 A8 00 00 Lc {PDOL} 00. Le message rponse 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 rpter la commande Si SW1, SW2 =69 85 Erreur, la transaction ne peut pas tre excute avec cette application, le terminal doit liminer cette application et revenir la fonction slection pou choisir une autre application. La fonction Read application data : Cette fonction doit tre excuter immdiatement aprs la fonction Initiate application processing . en effet , le terminal ayant reu AFL , il doit lire tous les fichiers et enregistrement points par ce dernier. ( chaque lment de cette liste contient un numro abrg de fichier lmentaire SFI et les numros des enregistrements NE qui doivent tre lus dans ce fichier. Le terminal met la commande Read record vers la carte : 00 B2 NE SFI 00, et il rpte cette commande autant de fois quil y ait des numros dans la liste AFL. Le message rponse de la carte est structur conformment BERTLV : 70, L ,{donnes}, SW1, SW2.
40
DEA
Le fameux AIP est un registre 2 octets , chaque bit indique la fonction supporte :
OCTET 1 OCTET 2
b8
init.
b7
authentificatio n Statique supporte
b6
authentificati on dynamique supporte
b5
vrification du dtenteur de carte supporte
b4
traitement de risque faire par le terminal
b3
authentificati on de lmetteur supporte
b 2
RFU
b1
RFU
b1...... b8
R F U
Application interchange profile AIP.
La fameuse AFL est une liste sans dlimitation de N de fichiers (SFI) et de N denregistrements dans ces fichiers. Chaque lment de la liste est form de 4 octets :
SFI du 1er fichier contenant des enregistrements lire N du 1er enregistrement lire dans ce fichier nombre denregistrements concernants lire dans ce fichier lauthentification offline N du dernier enregistrement
...
SFI du dernier fichier contenant des enregistrements lire
...
N du 1er enregistrement lire dans ce fichier
...
N du dernier enregistrement
...
nombre denregistrements concernants lire dans ce fichier lauthentification offline
AFL : cest 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 excut par le terminal ,dans nimporte quel ordre, aprs linitiation de lapplication et avant lanalyse daction du terminal. La disponibilit des donnes ncessaires cet authentification est optionnelle, leurs prsence est indique dans AIP (liste des fonctions supportes par la carte). Si la carte et le terminal supportent tous les 2 lauthentification offline, le terminal doit lexcuter (il excute la statique ou la dynamique , mais pas tous les deux) , le rsultat est report dans le bit correspondant du TSI.
41
DEA
Si cet authentification nest pas supporte par lun des deux , le terminal doit noter a dans le bit correspondant du TVR. Lentre de ce processus est forme par les enregistrements points par AFL (cd la sortie du processus prcdents Read application data ), suivis par les lments donnes identifis par leur tiquette 9F4A . Seulement les enregistrement identifis par la liste AFL comme participants lauthentification off-line doivent tre traits. Lauthentification des donnes statiques off-line authentifie les donnes statiques stockes par linstitut mettrice dans la carte : tiquette 8F 90 93 92 9F32 valeur
index de la cl publique de lautorit de certification certificat de la cl publique de linstitution mettrice les donnes statiques signes de lapplication le reste de la cl publique de linstitution mettrice exposant de la cl publique de linstitution mettrice
Les donnes statique ncessaire lauthentification
Lauthentification des donnes dynamiques off-line authentifie les donnes rsidente dans la carte et les donnes issues du terminal et de la carte : tiquette 8F 90 92 9F32 valeur
index de la cl publique de lautorit de certification certificat de la cl publique de linstitution mettrice le reste de la cl publique de linstitution mettrice exposant de la cl publique de linstitution mettrice
42
DEA
9F46 9F47 9F48 9F49
certificat de la cl publique de la carte exposant de la cl publique de la carte le reste de la cl publique de la carte la liste DDOL des donnes ncessaires pour lauthentification d es donnes dynamiques
Les donnes statique ncessaire lauthentification
La fonction Processing restriction : Cette fonction est excute par le terminal pour dterminer le degr de compatibilit entre lapplication dans le terminal et lapplication dans la carte. Elle peut tre excute nimporte quand aprs la slection de lapplication et avant lanalyse daction du terminal . a comprend la vrification de la compatibilit de : N de version de lapplication (si les versions sont diffrentes dans le terminal et la carte , le bit correspondant dans le registre TVR sera mis 1). Le contrle dutilisation de lapplication , par exemple : si le terminal est un ATM , il doit vrifier que le bit valid at ATM est 1 dans le registre AUC (application usage control). si le terminal nest pas un ATM, il doit vrifier que le bit valid at terminal other than ATM est 1. de mme le terminal doit vrifier ltat des bits :
international goods , valid for domestic cash transaction , valid for international cash transaction , valid for
etc...
La date dexpiration de lapplication : si la date < la date dexpiration de la carte , le bit correspondant dans TVR doit tre mis 1.
La fonction Cardholder verification : Cette fonction de vrification du dtenteur de la carte peut tre excute nimporte quand aprs la slection de lapplication et avant lanalyse daction du terminal. Elle sert vrifier que la personne prsentant la carte est bien la personne qui laquelle cette application dans la carte a t mise. Laptitude de la carte supporter au moins une mthode de vrification est indique dans AIP . Si le bit correspondant une mthode est 1 , le terminal doit utiliser la liste CVM attribue cette mthode . 43
DEA
La liste CVM se trouve dans la carte , elle contient une donne de 3 parties : X : 4 octets, indiquant une somme dargent . Y : 4 octets, indiquant une somme dargent . CVR : une liste contenant des donnes lmentaires de 2 octets chacune : 1er octet :code dune mthode de vrification (CVM code). 2me octet :code de condition (CVM condition code). Le bit CV was performed de TSI sera mis 1. Les rsultats obtenus doivent tre reports dans TVR .Les bits affects par cette fonction : TVR
vrificatio n choue bit CVM non reconnu PIN demand, pas de clavier PIN demand, clavier prsent, mais PIN non introduite limite dessai de PIN dpass e PIN introduit on-line
Les bits de TVR qui sont affects par la fonction Cardholder verification
La fonction Terminal risk management : Cette partie de la gestion du risque est excut par le terminal pour protger lacqureur, linstitution mettrice et le systme dune ventuelle fraude : Le terminal passe en mode online (connect au rseau) priodiquement pour assurer la protection contre les menaces qui ne sont pas dcelable dans lenvironnement offline. Le terminal passe aussi en mode on-line pour obtenir lautorisation de lmetteur dans le cas dune transaction de grande valeur.
Cette gestion peut tre excut nimporte quel moment avant lmission de la commande Generate AC . Bien sr que cette gestion nest excutable que si le bit terminal risk management is supported du registre AIP est 1. Cette gestion consiste : contrler le plafond de lapplication : si la somme le dpasse alors le bit correspondant dans TVR doit tre mis 1. choisir une transaction alatoirement : si la somme mise en jeu par cette transaction dpasse un certain seuil et elle est toujours infrieur au plafond alors le terminal tire au sort pour passer en mode on-line . La probabilit de russite de ce tirage au sort doit tre proportionnelle la somme.
44
DEA
contrler la vitesse : aprs un certain nombre de transaction en mode off-line (limite infrieur de nombre de transaction off-line conscutive) le terminal doit passer en mode on-line sil la supporte. Main une fois la limite suprieur est dpasse, le terminal doit arrter la transaction sil nest pas capable de passer en mode on-line. Pour faire ce contrle, le terminal met la commande Get data pour lire les registres ATC et last online ATC de la carte , puis il soustrait le 2me du 1er pour obtenir le nombre de transactions commises par cette carte sans passer en mode online.(si le terminal trouve que le 2me 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 rsultats obtenus doivent tre reports dans TVR .Les bits affects par cette fonction : TVR
transaction exceed floor limit transaction selected randomly for online upper consecutif offline limit exceeded lower consecutif offline limit exceeded
Les bits de TVR qui sont affects par la fonction Terminal risk management
La fonction Terminal action analysis : Le terminal, ayant excut sa gestion de risque et tous les autres fonctions lies la transaction offline (le client et le marchand ont introduit tous les donnes ) , prendra sa 1re dcision :cette transaction est approuve offline, refuse offline ou doit tre excute online. approuve 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 paramtre P1 sont 0 et 1 respectivement)
refuse offline : Le terminal met la carte une commande Generate AC pour lui demander un AAC.(cest le mme message avec b8,b7=0,0). Cette AAC peut tre prsente lmetteur comme preuve que la carte tait prsente durant la transaction). doit tre excute online : Le terminal met la carte une commande Generate AC pour lui demander un ARQC. (cest le mme message avec b8,b7=1,0).
Cette fonction peut tre excute nimporte nimporte quel instant durant la transaction , a limine le traitement non ncessaire . Par exemple si le bit failure of cardholder verification est mis 1alors le terminal peut passer tout de suite lanalyse daction.
45
DEA
Le terminal prend sa dcision prliminaire en se basant sur le contenu du registre TVR, sur les prfrences de lmetteur et sur les prfrences de lacqureur : 3 donnes codes daction de lmetteur peuvent tre mises dans la carte , elles refltent les prfrences de lmetteur en terme daction prendre suivant le contenu du TVR. 3 donnes codes daction de lacqureur peuvent tre mises dans le terminal, elles refltent les prfrences de lacqureur en terme daction prendre suivant le contenu du TVR. Le terminal traite les codes daction en paires , par exemple :si pour une valeur donne du TVR , lun des 2 codes dactions (celui de lmetteur ou celui de lacqureur) propose le refus de la transaction offline , le terminal doit choisir le refus. et si lun des 2 codes daction propose le passage en mode online , lmetteur doit respecter ce choix.
La fonction Card action analysis : La dcision de la carte , que a soit online ou offline ,est spcifie par sa rponse la commande Generate AC issue du terminal. Cette fonction est obligatoire dans nimporte 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 protger lmetteur dune ventuelle fraude ou dun risque de dbit excessif . Comme rsultat cette gestion , elle prendra sa dcision : achever la transaction en mode offline , en mode online , demander une consultation ou refuser la transaction. approuver la demande du terminal dexcuter la transaction en mode offline, elle lui envoi un TC. excuter la transaction en mode online , elle lui envoi un ARQC. demander une consultation (la carte soumet un message de conseille lmetteur lui informant dune situation exceptionnelle), elle lui envoi un AAR. refuser la transaction , elle lui envoi un AAC. Lorsque cette fonction est acheve , 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
46
DEA
le bit b4=1 du CID , le terminal doit envoyer un message de conseil lmetteur (PIN try limit exceeded , par exemple). La fonction Online processing : Cette fonction est excute suite la rception du ARQC mis par la carte en rponse la commande Generate AC . Une connexion est tablie entre le terminal et lmetteur travers le rseau (mode online )ce qui permet lmetteur de revoir et dautoriser ou rejeter les transactions qui sont en dehors des limites acceptable. Le terminal adresse un message de demande dautorisation lmetteur . Ce message peut inclure lARQC de la carte . La rponse message dautorisation envoye par lmetteur peut contenir des donnes dauthentification (tiquette 91). si la carte supporte ces donnes dauthentification (a doit tre indiqu dans le AIP), le terminal doit les renvoyer la carte dans une commande External authenticate .Si la rponse 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 donnes dauthentification , a voudrait dire que la carte a combin la fonction dauthentification de lmetteur avec la commande Generate AC , dans ce cas le terminal ne doit pas envoyer la commande External authenticate . si lmetteur nenvoie pas des donnes dauthentification , le terminal nmettrait pas la commande External authenticate . La carte ne doit pas excuter plus quune seule commande External authenticate par transaction . Si le terminal lui envoi plus quune , elle doit rpondre la deuxime (et aux suivantes) par SW1SW2=6985. Aprs lexcution 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.
Cet ARQC sert authentifier la carte auprs de lmetteur
Emetteu r
.... .... .... .
Terminal
1re Generate AC
Cdt Eljab i Hass an 1234 5678 Carte 9
Authentification request message{ARQC}
ARQC, SW1 SW2
47
e 2m
External authenticate{IAD}
Ou bienAC{IAD} Generate
Cet IAD contient un cryptogramm e qui sert authentifier lmetteur auprs de la
DEA
Authentification response message{IAD}
Commandes et Rponses pour lauthentification en mode online.
Issuer -to- card script processing : Le message rponse dautorisation issue de lmetteur supporte des commandes scripts adresses la carte par lintermdiaire du terminal. Si ces commandes existent , le terminal doit les transmettre la carte, une aprs lautre sous forme des APDU, sans les comprendre.(dblocage du PIN, chargement dune cl, ...). Ces scripts sont organises sous forme dune donne structure portant ltiquette 71(scripts traiter avant la dernire commande Generate AC) ou ltiquette 72(scripts traiter aprs la dernire commande Generate AC). La fonction Completion : Cette fonction dachvement termine le traitement de la transaction. Cest la dernire fonction dans le traitement de la transaction (le traitement du script peut tre fait aprs cette fonction dachvement). La carte indique sa volont de terminer le traitement de la transaction en retournant un TC ou un AAC en rponse la 1re ou la 2me commande Generate AC . Si le terminal dcide de passer en mode online , lachvement doit se faire lmission de la 2me commande Generate AC. Codage de la commande Generate AC : Les paramtres de la commande Generate AC fournissent au terminal 3 options :demander un TC, un ARQC ou un AAC. La carte peut rpondre la 1re commande Generate AC par un TC, un ARQC, un AAR ou un AAC. Tandis qu la 2me commande Generate AC elle ne peut rpondre que par un TC ou un AAC . Generate AC ( 1re mission) . Le terminal met la commande Generate AC pour faire savoir sa dcision la carte : sil suggre la mode offline , il demande la carte un TC , elle rpond par : TC (OK) 48
DEA
AAR (elle a besoin de chuchoter lmetteur) ARQC (elle suggre le passage en mode online) AAC (sorry, bye) sil suggre la mode online , il demande la carte un ARQC , elle rpond par : AAR (elle a besoin de chuchoter lmetteur) ARQC (OK) AAC (sorry, bye) sil rejette la transaction, il demande la carte un AAC , elle rpond par : AAC (OK, bye) Generate AC ( 2me mission) . Le terminal - ayant reu une autorisation de lmetteur ( traitement en mode online), ou bien un approuve ou un rejet (consultation des tables IAC) - mettra sa 2me commande Generate AC pour demander :
un TC (il a obtenu un approuve), la carte rpondra par un : TC (OK) AAC (sorry, bye) un AAC (il a obtenu un refus), la carte doit rpondre par un : AAC (ok, bye)
Les donnes manquants ou errones dans la carte Si cest une donne obligatoire , le terminal est oblig de terminer la transaction. Autrement il met 1 le bit ICC data missing dans le TVR .
49

Application 1: carte de crdit Plan des applications
DEA Application
3: carte daccs
Application 2: purse
Processing Restriction
Cardholder Verification
Initiate Application Processing Plan des fonctions
Read Application Data
Offline Data Authenticati on
Internal Verify Authenti cate Comman des ISO Read Record Get Data Comman des EMV Get Processi ng Option
Select Plan des commandes
TVR
ADF PDOL AFL AIP
FCI
TSI
Note pad
AUC
Plan des donnes structures Couche physique
Modle EMV couches

Cot terminal Cot carte
50
DEA
Chapitre quatre
METHODOLOGIE DAPPLICATIONS
Standards et spcifications. Dfinitions : Selon lISO , les standards sont des accords documents contenant des spcifications techniques ou dautres critres prcis qui vont tre utiliss comme rgles , directives ou dfinitions de caractristiques, pour quon soit sre que le matriel, les produits, le procd et les services sont adapts leur but . Tandis quune spcification est une interprtation troitement dfinie dun standard. Il ne faut pas confondre entre standard et spcification, et sachez que les systmes conformes un standard ne sont pas obligatoirement inter-oprables. (on va revenir cette interoprabilit en dtail plus loin). Les standards voluent, par exemple les standards courants autorisent une tension dalimentation pour les cartes de 5 volts, mais ,comme les gens ces jours-ci ont un norme dsir dinsrer leurs cartes, mme dans un PC portable, le standard a volu et les oprations 3 volts sont permises maintenant sur les cartes. Les instituts de standardisation qui soccupent des cartes sont : ISO International Standard Organisation, IEC International Electrotechnical Commission, CEN Comit Europen des Normes, ETSI European Telecommunication Standards Institute et BSI British Standards Institute . Pour notre tude, nous nous bornerons aux articles suivants: ISO-7810 caractristiques physiques. ISO-7811 bandes magntiques et gaufrages.(Tant qu'il y a des pays dans le monde qui utilisent la carte bande magntique sans puce, les ATMs en France resteront quips avec des lecteurs bande magntique et votre carte bancaire gardera cette fameuse bande, pour des raisons dinter-oprabilit). ISO-7813 Financial transaction cards ISO-7816/1/2/3/4/5/6/7 contacts. Integrated Circuit Cards with
ISO-8583 Interchange Message Specification. ISO-8731-1 Algorithmes for message Authentication.
51
DEA
La spcification la plus intressante et la plus importante est lEMV . Des cartes conformes lEMV ont t commercialise cette anne, et on prvoit que les 12 millions Terminals installs dans le monde vont tre conformes lEMV dici 10 ans. on va traiter cette spcification en dtail. Une autre spcification importante de cartes puce est la GSM. Elle a t dveloppe en 1980 par lETSI , elle dcrit les procdures dautorisation digitales et dauthentification, et les programmes stockes dans la carte puce appele aussi SIM (Subscriber Identity Module). Une carte SIM peut tre utilise comme module de scurit pour un terminal POS (Point OF Sale). La spcification GSM est gnrique pour lindustrie de tlcommunication de la mme faon que la spcification EMV est devenue gnrique pour le monde de services financiers. La diffrence entre GSM et EMV est que cette dernire a minimis les facteurs de dpendance dun hardware spcifique en utilisant des objets (donnes codes et structures) et des commandes gnriques. Tandis que GSM est trs dpendante dun hardware spcifique. Lidal est que la spcification dpend moins de lenvironnement et de la puce , et dpend plus de lapplication elle-mme. Interoprabilit. Lexpansion du march des cartes puces et mme le future des cartes multi-applications dpendent de linteroprabilit (en hard et en soft). En effet, nimporte quel lecteur doit accepter nimporte quelle carte au niveau physique. Une fois la carte est dans le lecteur, les applications rsidentes dans la carte (on-card applications) doivent pouvoir communiquer avec leurs contreparties rsidentes dans les serveurs (off-card applications) . On va considrer les trois niveaux de linteroprabilit : 1) Interoprabilit physique : elle est dj assure pour toutes les cartes puces avec contacts, tous les fabriquants ont adopt le standard 7816-1/2/3 en ce qui concerne linteroprabilit physique. Une carte du fabriquant X est accepte par un lecteur du fabriquant Y. Mais ce nest pas le cas avec les cartes sans contacts, on espre que le nouveau standard ISO 14443 sera adopt par les fabriquants, ce qui facilitera lexpansion des combi-cartes. Interoprabilit de la plate-forme : dans le futur proche, les metteurs des cartes multi-application ne seront pas ncessairement eux-mmes les fournisseurs dapplication. Mais les fabriquants des cartes utilisent leurs propres OS, la structure de fichier mme les commandes pour demander un service varient dun constructeur lautre ,(chacun a son propre langage assembleur pour contacter la carte et
2)
52
DEA
dvelopper des applications). Mme les fabriquants de lecteurs qui ont adopter lISO au niveau physique, ils ont pris des dcisions propritaires propos des services offerts par le lecteur et la manire de commander ces servies. D'o la ncessit de linteroprabilit au niveau de la plate-forme : Interoprabilit de on-card platform : Java card et MultOS ont bris le couplage entre le systme dexploitation de la carte (COS) et lapplication rsidente dans la carte (on-card application).Il est maintenant possible quune application soit crite par un tiers , (comme cest le cas des software providers qui produisent des applications quon les pose sur le microsoft Windows). Cest lge dor des software providers qui vont prendre le relais du dveloppement des applications , et que les fabriquants des cartes aillent soccuper de leur hardware. Interoprabilit de off-card platform : Open Card Framework (OCF) et PC/SC ont cach la diversit des plates-formes (des cartes et des lecteurs) de lapplication off-card . laide dun ensemble de card drivers et des interfaces off-card standard, lOCF et le PC/SC permettent un tiers de dvelopper une application off-card.
Applicat ion Machine Virtuelle Operati ng System
Java
Langage propritaire
MEL, C
Java Card
OS propritaire
OS propritaire
MULTOS
La puce
ISO 7816
ISO 7816
ISO7 816
Ctait Solution Solution solutions MultOS et Java. Celle de Microsoft, Java Les comme a MultOS
elle est comment ?
1)
interoprabilit de lapplication : elle permet linteraction entre diffrentes applications. Les plus importantes spcifications ce stade sont : EMV, GSM, SET : EMV : linteroprabilit des cartes de diffrents fabriquants et de diffrents metteurs est le but recherch. 53
DEA
SET : est support par Visa, MasterCard et Europay. Il scurise les communications des transactions des cartes sur internet : il dfinit le format des messages et les protocoles dapplications. GSM : vous le connaissez dj.
Interopr abilit dapplica tion Interopr abilit de Plateforme Interopr abilit physique
EMV, SET, GSM

Java Card/MultOS et Microsoft??? Cdt Eljab i Hass an 1234 5678 9
Open Card Framework/PC/SC
ISO 7816
...... ...... . ... ... ... ... . ... ... ... ... . Systm
Carte
Lecteur
Architecture et couches dinteroprabilit.
Comparaison entre MultOS et Java Card : MultOS remplace le COS pour que la carte soit capable de parler MEL (MultOS Extension Langage) et si tu nas pas envie dapprendre ce langage ,eh bien , MultOS propose un traducteur MEL/C. Java se pose au-dessus du COS pour lui interprter le langage abstrait Java de Sun (la carte garde sa langue maternelle). MultOS est moins cher que Java, mais il est plus cher quun COS propritaire. MultOS est un produit Mondex(purse de MasterCard) confi un consortium but non lucratif MAOSCO (mais il te faut un certificat de mondex 25 centimes pour charger une application dans une carte, le C - to - MEL converter est toujours une proprit de Mondex) VISA a adopt java et demande MasterCard de dvelopper une interface au-dessus de MultOS pour quil parle Java. (Pas avant 18 mois, MasterCard a rpondu) MultOS occupe 14-16 k octet de ROM , Java occupe 8-13 k octets ROM mais par contre, Java a 2 problmes : elle a besoin de 1 k bits de RAM (une telle carte vient de sortir, sinon, cest 54
DEA
comme tu mets un jinny dans une petite lampe), le 2me problme, cest que Java est conu pour des CPU 32 bits, (une telle carte est trop chre pour linstant) Java de JavaSoft (SUN) est applaudie par Visa, BULL, Dallas(Java Ring), De la Rue, Geisecke&Devrient, Motorola, Schlumberger, Inside Technologies, Oberthur et Toshiba. Le consortium MAOSCO de MultOS est form de :Gemplus, Siemens, Hitachi, Dai Nippon, Mastercard/Mondex, Motorola, Geisecke&Devrient, Europay, Java attend le support de Microsoft, eh bien SUN a contribu PC/SC avec Microsoft. MultOS compte sur la rivalit et la concurrence entre SUN et Microsoft.
Cest exactement pareil la bataille entre les standards VHS et Betamax des cassettes vido. Pour notre mthodologie, on va proposer Java pour single companies implementing multi-application cards for integration into networks ( a annonc Mike Hendry chairman of smart card club finance forum) . Et comme MAOSCO sintresse plutt la structure commerciale , son produit , le MultOS, est orient vers la ncessit dun contrle central , on le propose pour companies wanting to set up third-party services or marketing arrangements ( a ajout Hendry). Solution Microsoft. Surprise, Microsoft a annonc au salon CARTES 98 au CNIT sa propre solution : ni MultOS ni Javacard, cest le Smart Card for Widows . Avec la collaboration de Schlumberger, Gemplus, Merryll lynch et Cable and Wireless , la version BETA est prvue janvier 1999. SC/Windows repose sur caractristiques suivantes : linfrastructure PC/SC et offre les
systme fichiers partags (Multi-partition file system) : sparation physiques entre les fichiers de donnes , les applications appartenants diffrents metteurs peuvent coexister paisiblement sur une mme carte. Rgles de contrle daccs : pour contrler qui a accs aux fichiers de la carte. Algorithmes cryptographiques pluggable : permettant au dveloppeur et au client de dfinir et concevoir le niveau de scurit souhaitable. Conformit aux standards de cartes dj existants : supporte les commandes ISO 7816-4 . On voit bien que a correspond aux besoins des applications tels que : transactions scurises (dbit, crdit), e-cash, programmes de fidlit , authentification auprs des rseaux scuriss. Quelle que soit la langue maternelle (COS) de votre carte , elle va parler Visual Basic 6.0 et Visual C++ 6.0, et vous pouvez dvelopper 55
DEA
vos applications paisiblement dans lenvironnement Windows NT et utiliser Visual Studio pour simuler et corriger vos applications et bonne chance. Mthodologie Comme on vient de voir , le dveloppement des applications nest plus monopolis par les producteurs des cartes, ni par les grandes institutions mettrices : cest aux providers dapplications de prendre la relve, et pourquoi pas toi ? Rcapitulons les ides dj traites , et prenons les dcisions suivantes : Application et systme : alors utilisez : carte mmoire jeter EEPROM, RAM EPROM, RAM ROM carte mmoire carte microcontrleur co-processeur co-processeur processeur unique processeur unique/mmoire carte mmoire dveloppez votre COS achetez COS courant
MultOS, Java SC/Windows ou
si votre application ncessite : a- un bas prix b- un type de mmoire : o on doit crire, effacer et rcrire o on doit crire o les donnes sont figes c- un protocole de communication : synchrone asynchrone d- une capacit de traitement : authentification rapide des cls de scurit algorithmes compliqus (RSA par exemple) rapide vrification de PIN pas de traitement e- un systme dexploitation (COS): ferm ou propritaire conforme ISO 7816 ouvert f- un Masque : conforme ISO 7816 ferm ou propritaire g- une structure de fichier : accs rapide donnes communes partages non structures h- une vitesse de traitement : conforme ISO 7816 tous les autres
achetez dveloppez hirarchique relationnel orient objet de 1 5 MHz dpend du terminal
56
DEA
et pensez toujours la scurit de votre systme et des changes des donnes. Souvenez-vous quil y a 5 types d'attaques : recherche exhaustive de la cl : a revient essayer toutes les combinaisons possible. Choisissez une longue-cl et pensez les changer priodiquement corruption intentionnelle signature digitale. des messages : pensez la
corruption des donnes internes : a se fait par une mthode de dduction, il introduit un bit derreur dans le processeur qui excute le chiffrage , puis en tudiant les rsultats de lerreur , il dduit des informations concernant lalgorithme et les cls. manipulation directe : les cartes puces actuelles sont immunes ce genre de tripotage (variation de la tension dalimentation, lecture des mmoires physiquement) attaque extrieure : les 5 contacts de la carte ou du lecteur constituent la cible prfre des Hackers. Fabrication : Alors utilisez : sheet offset sheet offset injection molding sheet offset injection molding
si votre application ncessite : Long life grand nombre de cartes petit nombre/basse qualit carte de haute qualit cartes jeter Implmentation du systme :
si votre application ncessite : communication haut dbit communication : bas dbit une ou plusieurs applications protection contre la fraude haut niveau de scurit volume de la mmoire
Alors utilisez : cartes avec contacts cartes sans contacts

mmoire et convenable COS
crypto co-processeur crypto co-processeur a dpend de lapplication
pensez toujours la conformit au standard, et avant de lancer votre application pensez la simulation et lmulation (consultez votre fabriquant de cartes , et si vous avez choisi PC/Windows votre PC fera laffaire). Conception fonctionnelle : Alors utilisez : la puce convenable frquence dhorloge si votre application ncessite : des longs registres communication haute vitesse
57
DEA
des registres de stockage anti-contrefaon
non ISO mmoire de taille convenable puce rsistante au tripotage
Application. Comme on vient de voir , il vous est possible dcrire votre propre application et lexcuter sur vos propres cartes (si vous tes une grande socit) ou tout simplement , vous pouvez lintroduire sur les cartes dun autre metteur (en lui payant la licence ). On va considrer une application imaginaire , et on va essayer de lexcuter : Carte logistique pour larme : Chaque militaire de larme possde une carte didentit quil garde prcieusement, mais par contre , il lui arrive souvent de perdre les reus quil signe auprs des diffrents magasins des casernes o il mute durant sa vie professionnel. En effet, lorsquil joint larme pour la premire fois, il fait le tour des magasins de la caserne o il a t admis : le lit, les draps, luniforme, ... du magasin A ; le fusil, les munitions, la pelle, ... du magasin B ; loutillage (sil est technique) du magasin C ; le bureau, la babas, ...du magasin D (sil est administratif ou officier) ; et ainsi de suite. Une fois mut, il doit rendre une partie(on barre les quipements rendus sur ses copies de reus) et il emporte le reste la nouvelle caserne o il commence signer des reus auprs des magasins A, B, C, D, ...de la nouvelle caserne. A la retraite, ayant perdu la moiti de ses reus, il se prsente au Quartier Gnral et il se surprend : des casernes ont t dtruites, des documents ont t perdus, des copies de reus qui nont pas t mises jour(et malheureusement il a perdu sa copie o les quipements rendus ont t barrs) et cest le vrai Loto ou bien il en profite ou bien il paye ce quil na pas pris. Objectif : On va proposer dencarter une puce sur la carte didentit de chaque militaire, et une base de donnes , au QG, mise jour rgulirement et duplique. Conception : cette carte puce va remplacer les reus, elle comporte des fichiers correspondants chaque type de magasins, et contenants des records de tous les quipements en possession du dtendeur de la carte. Le magasinier possde un Terminal Wallet comportant un lecteur et une base de donne : un fichier G de ce quil a reu du QG, un autre fichier F comportant linventaire de tout ce quil a fourni et qui il la fournie et un fichier R de tout ce quil lui reste dans le magasin. 58
DEA
Il faut que F+R=G mais on ne peut pas dire que la responsabilit du magasinier porte sur le fichier G, car les soldats mutent et rendent des quipements un autre magasinier dune autre caserne (celui-ci doit ajouter ces quipements son fichier G comme si il les a reu du QG). Donc le magasinier emprunte des quipements du QG et il les distribue aux militaires au nom du QG , et il les fait sortir de son inventaire G et cest au QG de les grer.
G Pour le QG : il possde quipements qui sont distribus dans les R F diffrents magasins et sur toutes les cartes puces . La base de donnes du QG est bien duplique : une copie chez lui et lautre distribue sur les cartes puces et sur les lecteurs Wallets .
Ces Wallets des magasiniers ne vont pas tablir une liaison online avec la QG pour chaque transaction (il y en a des centaines par jour), main ils vont excuter ces transactions Offline et ils vont tablir la connexion Online priodiquement pour informer le QG de tout ce qui sest pass (on appelle a Stock and Forward). Si une carte est perdue, le QG peut mettre une autre (parce quil a un dupliqut des informations de la carte perdue), et si la base de donne du QG est corrompue , on peut la restituer partir des donnes des Wallets ou partir de lensemble des cartes puces. Recommandations : on recommande que les donnes de la carte soient accessibles la lecture sans protection (seulement, lauthentification est ncessaire) et que lcriture et la modification des donnes ne sont pas possibles quen prsence du dtendeur de la carte (card holder verification CHV) : un dtendeur peut, par simple insertion de sa carte dans un lecteur portable, contempler le contenu de sa carte. Et lofficier logistique de la caserne peut ramasser les cartes et accder la lecture pour reconstituer la base de donne perdue du QG. On recommande aussi dutiliser un matriel standardis : on veut une varit de fournisseurs de cartes et une multitude de fabriquants de lecteurs , et un outillage de dveloppement developpement tool kit pour concevoir to design lapplication et la simuler avec un langage volu et connu. On rclame linteroprabilit totale : une application crite aujourdhui doit oprer avec les nouvelles gnrations des lecteurs et les versions des cartes de demain. Dcisions : Cartes : le PVC est le matriel plus rpandu, le plus mallable pour le gaufrage, et le moins chers. Mais on va proposer lABS ou le PET pour des raisons cologiques. Puces : puisque cette application est militaire on va choisir une puce avec coprocesseur cryptographique (RSA ou ECC), la taille de 59
DEA
la mmoire dpend du type dauthentification offfline choisie ( la statique ncessite une mmoire plus grande que la dynamique) et dpend du nombre dapplication quon va mettre dans la carte. De toute faon, une simulation sur un prototype fixera les ides. COS , Masque, Machine virtuelle : pour des raisons acadmiques, on va choisir EMV. a va assurer Interoprabilit physique et celle de lapplication. Celle de la plate-forme ne sera pas assure que par MultOS, JavaCard ou SC/Windows. Ces deniers ne sont pas encore compatible EMV( MultOS vient de paratre cette anne, JavaCard 2 a toujours des problmes dici la fin du sicle et SC/Windows ne sera pas commercialis ce sicle et il se repose sur linfrastructure PC/SC qui lui manque linterface EMV). Lecteur : les lecteurs EMV ont commenc a paratre ( cette anne, De la rue a lanc ses lecteurs conformes EMV part I en Angleterre ) .
structure des fichiers : vous venez de recevoir un lot de cartes prpersonnalises avec leur batch card contenant le master key MK. La cl systme Ks de chaque carte est une diversification de MK avec le N de srie de la carte. Cette cl K, vous permettra de personnaliser la carte.
MF 3F00
EF(Nsri
e)
3F02
EF (Ks) 3F01
Exemple de carte prpersonnalise.
Avec cette cl Ks vous dfinissez votre fichier application ADF1 et tous les EFs qui en dcoulent EFdata, EFcls de chiffrement , EFcodes secrets (remplissez les descripteurs de fichiers). Et un fichier personnel EF(3F03) accessible en lecture et protg en criture par Ks.
MF 3F00 EF(N srie) EF (Ks)
DDF1
0100
3F02
EFperson nel Nom, Prnom, Grade...
3F0 1
DIR A ADF 0200 application 1

EF(data ) 0201 EF codes sec.
EF cls chiff.
60
DEA
Carte personnalise.
Structure des donnes : Chaque quipement militaire a un numro de code de 16 digits. Le numro de srie de lquipement (sil existe) ne dpasse pas les 12 digits et peut comporter des lettres. On va convertir le code ASCII de ces chiffres et lettres en Hexadcimal. Par exemple : 1234 Paris devient 01 02 03 04 50 41 52 49 53. On va coder les donnes en TLV, le champs valeur V sera divis en 3 partie : 16 octets pour le numro de code , 12 octets pour le numro de srie et 2 octets pour le nombre . A savoir que sil existe un numro de srie , on doit mettre les 2 octets nombre 00 00h, et sil nexiste pas on doit remplir les 12 octets avec des zros hexadcimaux. Les registres EMV : on va remplir les registres dfinies par la spcification EMV par les paramtres de notre application : la liste PDOL doit comporter le N de srie du terminal et la rfrence du magasinier. le pointeur des Records AFL doit comporter les SFI des fichiers donnes EFsdata et le numro de fichier EF info.personnelles (le terminal doit savoir remplir le fichier F) le registre AIP doit comporter les fonctions supportes par la carte : authentification dynamique, CHV, traitement de risque faire par lmetteur (le terminal doit faire son traitement de risque par rapport aux transactions quil a excut avec toutes les cartes, la carte est suppose mise jour). les codes dactions de lmetteur remplir dans le terminal, pas besoin de remplir ces codes dans la carte , car dans notre cas larme est lmetteur et lacqureur en mme temps.
Lapplication : Pour liminer toute possibilit de fraude, il faut que la transaction soit balance immdiatement, en effet la transaction se fait en prsence des 2 parties (le client et le marchand), donc tout ce qui sort du terminal doit entrer dans la carte et inversement tout ce qui sorte de la carte doit entrer dans le terminal. Et si quelquun retire la carte au milieu de la transaction ! que se passe-t-il ? si votre stratgie est deffacer la donne du fournisseur et puis linscrire chez le receveur, alors le rsultat dun retrait de la carte est la perte de la donne. Et si vous aimez lautre stratgie, cd inscrire la donne chez le receveur puis leffacer de chez le fournisseur, le rsultat sera un quipement figurant dans linventaire
61
DEA
du fournisseur et dans celui du receveur. Conseil : utilisez un Flag associ chaque quipement en cours de transfert, une fois termin , vous effacer le Flag. Nhsitez pas utiliser les commandes ISO telles que : update_record, read_recrd, write_record aprs avoir fait une commande select file. Pour viter toute contrefaon de la part du magasinier, faites exactement comme si ce terminal est un POS : le magasinier tape sur son clavier lopration, le militaire regarde bien tout ce qui est affich ,et sil est daccord il tape soigneusement son PIN. Le programme que vous venez dcrire met la commande Verify pour comparer ce PIN celui dans EF chv, et si le rsultat est positif et si le magasinier a dj tap son code secret (une autre commande Verify a dj compar ce code celui existant dans EF code secret pour autoriser lcriture) , alors la modification du fichier, telle quelle est affiche, aura lieu. Test : Avec le Developpement tool kit , vous simulez, vous tripoter, pour tester votre prototype. Ce tool kit peut tre propritaire dans notre cas. Mais avec MultOS a sera le langage C ou MEL, avec Javacard 2 a sera le langage Java et avec SC/Wiondows a sera visual basic.
62
DEA
REFERENCES
EMV 96 version 3.0 june 30, 1996. PC/SC Draft 0.9 1997 (www.smartcardsys.com).
User guide CP8 BULL (TB100). Manuel de Rfrence schlumberger (cryptoflex OS). MPCOS-EMV de Gemplus. Electronic payement System OMahony- Peirce- Tewani. FAQ (cryptography) RSA laboratory. Smart Cards La carte mmoire PC et carte puce Balance of power Dreifus- Monk. France Telecom. Gueule. Ovum.inc

These EMV

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

These EMV

Uploaded by

Copyright:

Available Formats

UNIVERSITE LIBANAISE SAINT-JOSEPH

(Facult de Gnie) dingnieur, ESIB)

Sous lgide de lagence des universits Francophones AUPELF-UREF

Diplmes dEtudes Approfondies Rseaux de tlcommunications

CDT. EL JABI HASSAN

Encadr par :_ . Ahmed SERHROUCHNI M

ELJABI HASSAN Cartes puces

TABLE DES MATIRES

Application : ......................................................................................................................................15 Scurit et libert personnelle (privacy) :..........................................................................................16

ELJABI HASSAN Cartes puces

Les fichiers de la carte puces..........................................................................................................36

ELJABI HASSAN Cartes puces

ELJABI HASSAN Cartes puces

ELJABI HASSAN Cartes puces

ELJABI HASSAN Cartes puces

ELJABI HASSAN Cartes puces

ELJABI HASSAN Cartes puces

LISTE DES ABREVIATIONS

ELJABI HASSAN Cartes puces

ELJABI HASSAN Cartes puces

LES CARTES PUCES

ELJABI HASSAN Cartes puces

ELJABI HASSAN Cartes puces

Les concurrents de la carte puce.

Les principaux participants lindustrie des cartes puces sont :

ELJABI HASSAN Cartes puces

ELJABI HASSAN Cartes puces

Entre/Sor tie programma ble E/S 1

Elments principaux dune puce.

ELJABI HASSAN Cartes puces

Les commandes ISO.

ELJABI HASSAN Cartes puces

ELJABI HASSAN Cartes puces

LES SPECIFICATIONS PC/SC

Cls Numro de Mots de

Schma fonctionnel de la carte puce(ICC)

ELJABI HASSAN Cartes puces

Une carte(ICC) Architecture du systme

ELJABI HASSAN Cartes puces

Pas de voltage de programmation

On comparant avec lISO-7816 on note les nuances suivantes :

ELJABI HASSAN Cartes puces

ELJABI HASSAN Cartes puces

Couche de fonctions Couche de contrle

Software du client driver de lquipement E/S

Commandes et rponses de lIFD

Les fonctions de lIFD contrle du Canal E/S

Contrleur du canal E/S

Contrleur du canal E/S

Protocole de communication entre PC et Lecteur .

ELJABI HASSAN Cartes puces

ICC Service Provider

Couche application (ISO 7816-4) Couche transport (organisation des APDU)

ELJABI HASSAN Cartes puces

Interface accs aux

ELJABI HASSAN Cartes puces

authentification du dtenteur de la carte.

PC client Root HUB 3 HUB 2

HUB Lecteur Lecteur Lecteur Clavier

Diffrentes configurations de lecteurs (USB) :1.spar, 2.compos, 3.dpendant.

ELJABI HASSAN Cartes puces

... ... ... ... .

Echanges entre les 2 parties dune application (oncard et offcard)

Cdt Eljab i Hass an 1234 5678 9