Méthodologie d’applications – Cartes à puces 

Methodologie d’applications – Chapitre quatre *** Standards et spécifications. ** Définitions : Selon l’ISO, « les standards sont des accords documentés contenant des spécifications techniques ou d’autres critères précis qui vont être utilisés comme règles, directives ou définitions de caractéristiques, pour qu’on soit sûre que le matériel, les produits, le procédé et les services sont adaptés à leur but ». Tandis qu’une spécification est une interprétation étroitement définie d’un standard. Il ne faut pas confondre entre standard et spécification, et sachez que les systèmes conformes à un standard ne sont pas obligatoirement inter-opérables. (on va revenir à cette interopérabilité en détail plus loin). Les standards évoluent, par exemple les standards courants autorisent une tension d’alimentation pour les cartes de 5 volts, mais, comme les gens ces jours-ci ont un énorme désir d’insérer leurs cartes, même dans un PC portable, le standard a évolué et les opérations à 3 volts sont permises maintenant sur les cartes. Les instituts de standardisation qui s’occupent des cartes sont : ISO International Standard Organisation, IEC International Electrotechnical Commission, CEN Comité Européen des Normes, ETSI European Telecommunication Standards Institute et BSI British Standards Institute. Pour notre étude, nous nous bornerons aux articles suivants: *– ISO-7810 caractéristiques physiques. *– ISO-7811 bandes magnétiques et gaufrages. (Tant qu’il y a des pays dans le monde qui utilisent la carte à bande magnétique sans puce, les ATMs en France resteront équipés avec des lecteurs bande magnétique et votre carte bancaire gardera cette fameuse bande, pour des raisons d’inter-opérabilité). *– ISO-7813 Financial transaction cards *– ISO-7816/1/2/3/4/5/6/7 Integrated Circuit Cards with contacts. *– ISO-8583 Interchange Message Specification. *– ISO-8731-1 Algorithmes for message Authentication. La spécification la plus intéressante et la plus importante est l’EMV. Des cartes conformes à l’EMV ont été commercialisée cette année, et on prévoit que les 12 millions Terminals installés dans le monde vont être conformes à l’EMV d’ici 10 ans. on va traiter cette spécification en détail. Une autre spécification importante de cartes à puce est la GSM. Elle a été développée en 1980 par l’ETSI, elle décrit les procédures d’autorisation digitales et d’authentification, et les programmes stockées dans la carte à puce appelée aussi SIM (Subscriber Identity Module). Une carte SIM peut être utilisée comme module de sécurité pour un terminal POS (Point OF Sale). La spécification GSM est générique pour l’industrie de télécommunication de la même façon que la spécification EMV est devenue générique pour le monde de services financiers. La différence entre GSM et EMV est que cette dernière a minimisé les facteurs de dépendance d’un hardware spécifique en utilisant des objets (données codées et structurées) et des commandes génériques. Tandis que GSM est très dépendante d’un hardware spécifique. L’idéal est que la spécification dépend moins de l’environnement et de la puce, et dépend plus de l’application elle-même. ** Interopérabilité. L’expansion du marché des cartes à puces et même le future des cartes multi-applications dépendent de l’interopérabilité (en hard et en soft). En effet, n’importe quel lecteur doit accepter n’importe quelle carte au niveau physique. Une fois la carte est dans le lecteur, les applications résidentes dans la carte (on-card applications) doivent pouvoir communiquer avec leurs contreparties résidentes dans les serveurs (off-card applications). On va considérer les trois niveaux de l’interopérabilité : 1) Interopérabilité physique : elle est déjà assurée pour toutes les cartes à puces avec contacts, tous les fabriquants ont adopté le standard 7816-1/2/3 en ce qui concerne l’interopérabilité physique. Une carte du fabriquant X est acceptée par un lecteur du fabriquant Y. Mais ce n’est pas le cas avec les cartes sans contacts, on espère que le nouveau standard ISO 14443 sera adopté par les fabriquants, ce qui facilitera l’expansion des combi-cartes. 2) Interopérabilité de la plate-forme : dans le futur proche, les émetteurs des cartes multi-application ne seront pas nécessairement eux-mêmes les fournisseurs d’application. Mais les fabriquants des cartes utilisent leurs propres OS, la structure de fichier même les commandes pour demander un service varient d’un constructeur à l’autre, (chacun a son propre langage assembleur pour contacter la carte et développer des applications). Même les fabriquants de lecteurs qui ont adopter l’ISO au niveau physique, ils ont pris des décisions propriétaires à propos des services offerts par le lecteur et la manière de commander ces servies. D’où la nécessité de l’interopérabilité au niveau de la plate-forme : *– Interopérabilité de « on-card platform » : Java card et MultOS ont brisé le couplage entre le système d’exploitation de la carte (COS) et l’application résidente dans la carte (on-card application). Il est maintenant possible qu’une application soit écrite par un tiers, (comme c’est le cas des « software providers » qui produisent des applications qu’on les pose sur le microsoft Windows). C’est l’âge d’or des software providers qui vont prendre le relais du développement des applications, et que les fabriquants des cartes aillent s’occuper de leur hardware. *– Interopérabilité de « off-card platform » : Open Card Framework (OCF) et PC/SC ont caché la diversité des plates-formes (des cartes et des lecteurs) de l’application « off-card ». à l’aide d’un ensemble de « card drivers » et des interfaces off-card standard, l’OCF et le PC/SC permettent à un tiers de développer une application off-card. Les solutions MultOS et Java. Celle de Microsoft, elle est comment ? 1) interopérabilité de l’application : elle permet l’interaction entre différentes applications. Les plus importantes spécifications à ce stade sont : EMV, GSM, SET : — EMV : l’interopérabilité des cartes de différents fabriquants et de différents émetteurs est le but recherché. — SET : est supporté par Visa, MasterCard et Europay. Il sécurise les communications des transactions des cartes sur internet : il définit le format des messages et les protocoles d’applications. — GSM : vous le connaissez déjà. Architecture et couches d’interopérabilité. ** 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 n’as pas envie d’apprendre ce langage, eh bien, MultOS propose un traducteur MEL/C. -*- Java se pose au-dessus du COS pour lui interpréter le langage abstrait Java de Sun (la carte garde sa langue maternelle). -*- MultOS est moins cher que Java, mais il est plus cher qu’un COS propriétaire. -*- 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 propriété de Mondex) -*- VISA a adopté java et demande à MasterCard de développer une interface au-dessus de MultOS pour qu’il parle Java. (Pas avant 18 mois, MasterCard a répondu) -*- MultOS occupe 14-16 k octet de ROM, Java occupe 8-13 k octets ROM mais par contre, Java a 2 problèmes : elle a besoin de 1 k bits de RAM (une telle carte vient de sortir, sinon, c’est comme tu mets un jinny dans une petite lampe), le 2ème problème, c’est que Java est conçu pour des CPU 32 bits, (une telle carte est trop chère pour l’instant) -*- 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. C’est exactement pareil à la bataille entre les standards VHS et Betamax des cassettes vidéo. Pour notre méthodologie, 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 s’intéresse plutôt à la structure commerciale, son produit, le MultOS, est orienté vers la nécessité d’un contrôle 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, c’est le « Smart Card for Widows ». Avec la collaboration de Schlumberger, Gemplus, Merryll lynch et Cable and Wireless, la version BETA est prévue janvier 1999. SC/Windows repose sur l’infrastructure PC/SC et offre les caractéristiques suivantes : -*- système à fichiers partagés (Multi-partition file system) : séparation physiques entre les fichiers de données, les applications appartenants à différents émetteurs peuvent coexister paisiblement sur une même carte. -*- Règles de contrôle d’accès : pour contrôler qui a accès aux fichiers de la carte. -*- Algorithmes cryptographiques « pluggable »  : permettant au développeur et au client de définir et concevoir le niveau de sécurité souhaitable. -*- Conformité aux standards de cartes déjà existants : supporte les commandes ISO 7816-4. On voit bien que ça correspond aux besoins des applications tels que : transactions sécurisées (débit, crédit), e-cash, programmes de fidélité, authentification auprès des réseaux sécurisés. 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 développer vos applications paisiblement dans l’environnement Windows NT et utiliser Visual Studio pour simuler et corriger vos applications et bonne chance. *** Méthodologie Comme on vient de voir, le développement des applications n’est plus monopolisé par les producteurs des cartes, ni par les grandes institutions émettrices : c’est aux providers d’applications de prendre la relève, et pourquoi pas toi ? Récapitulons les idées déjà traitées, et prenons les décisions suivantes : Application et système :

et pensez toujours à la sécurité de votre système et des échanges des données. Souvenez-vous qu’il 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 périodiquement – corruption intentionnelle des messages : pensez à la signature digitale. – corruption des données internes : ça se fait par une méthode de déduction, il introduit un bit d’erreur dans le processeur qui exécute le chiffrage, puis en étudiant les résultats de l’erreur, il déduit des informations concernant l’algorithme et les clés. – manipulation directe : les cartes à puces actuelles sont immunes à ce genre de tripotage (variation de la tension d’alimentation, lecture des mémoires physiquement) – attaque extérieure : les 5 contacts de la carte ou du lecteur constituent la cible préférée des Hackers. Fabrication :

Implémentation du système :

pensez toujours à la conformité au standard, et avant de lancer votre application pensez à la simulation et à l’émulation (consultez votre fabriquant de cartes, et si vous avez choisi PC/Windows votre PC fera l’affaire). Conception fonctionnelle :

*** Application. Comme on vient de voir, il vous est possible d’écrire votre propre application et l’exécuter sur vos propres cartes (si vous êtes une grande société) ou tout simplement, vous pouvez l’introduire sur les cartes d’un autre émetteur (en lui payant la licence). On va considérer une application imaginaire, et on va essayer de l’exécuter : ** Carte logistique pour l’armée : Chaque militaire de l’armée possède une carte d’identité qu’il garde précieusement, mais par contre, il lui arrive souvent de perdre les reçus qu’il signe auprès des différents magasins des casernes où il mute durant sa vie professionnel. En effet, lorsqu’il joint l’armée pour la première fois, il fait le tour des magasins de la caserne où il a été admis : le lit, les draps, l’uniforme, . . . du magasin A ; le fusil, les munitions, la pelle, . . . du magasin B ; l’outillage (s’il est technique) du magasin C ; le bureau, la babas, . . . du magasin D (s’il 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 reçus) et il emporte le reste à la nouvelle caserne où il commence à signer des reçus auprès des magasins A, B, C, D, . . . de la nouvelle caserne. A la retraite, ayant perdu la moitié de ses reçus, il se présente au Quartier Général et il se surprend : des casernes ont été détruites, des documents ont été perdus, des copies de reçus qui n’ont pas été mises à jour (et malheureusement il a perdu sa copie où les équipements rendus ont été barrés) et c’est le vrai Loto ou bien il en profite ou bien il paye ce qu’il n’a pas pris. * Objectif : On va proposer d’encarter une puce sur la carte d’identité de chaque militaire, et une base de données, au QG, mise à jour régulièrement et dupliquée. *Conception : Cette carte à puce va remplacer les reçus, elle comporte des fichiers correspondants à chaque type de magasins, et contenants des records de tous les équipements en possession du détendeur de la carte. Le magasinier possède un Terminal « Wallet » comportant un lecteur et une base de donnée : un fichier G de ce qu’il a reçu du QG, un autre fichier F comportant l’inventaire de tout ce qu’il a fourni et à qui il l’a fournie et un fichier R de tout ce qu’il lui reste dans le magasin. 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 d’une autre caserne (celui-ci doit ajouter ces équipements à son fichier G comme si il les a reçu 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 c’est au QG de les gérer. Pour le QG : il possède équipements qui sont distribués dans les différents magasins  et sur toutes les cartes à puces . La base de données du QG est bien dupliquée : une copie chez lui et l’autre distribuée 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 exécuter ces transactions Offline et ils vont établir la connexion Online périodiquement pour informer le QG de tout ce qui s’est passé (on appelle ça Stock and Forward). Si une carte est perdue, le QG peut émettre une autre (parce qu’il a un dupliquât des informations de la carte perdue), et si la base de donnée du QG est corrompue, on peut la restituer à partir des données des Wallets ou à partir de l’ensemble des cartes à puces. * Recommandations : on recommande que les données de la carte soient accessibles à la lecture sans protection (seulement, l’authentification est nécessaire) et que l’écriture et la modification des données ne sont pas possibles qu’en présence du détendeur de la carte (card holder verification CHV) :un détendeur peut, par simple insertion de sa carte dans un lecteur portable, contempler le contenu de sa carte. Et l’officier logistique de la caserne peut ramasser les cartes et accéder à la lecture pour reconstituer la base de donnée perdue du QG. On recommande aussi d’utiliser un matériel standardisé : on veut une variété de fournisseurs de cartes et une multitude de fabriquants de lecteurs, et un outillage de développement « developpement tool kit » pour concevoir « to design » l’application et la simuler avec un langage évolué et connu. On réclame l’interopérabilité totale : une application écrite aujourd’hui doit opérer avec les nouvelles générations des lecteurs et les versions des cartes de demain. * Décisions : – Cartes : le PVC est le matériel plus répandu, le plus malléable pour le gaufrage, et le moins chers. Mais on va proposer l’ABS 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 la mémoire dépend du type d’authentification offfline choisie (la statique nécessite une mémoire plus grande que la dynamique) et dépend du nombre d’application qu’on va mettre dans la carte. De toute façon, une simulation sur un prototype fixera les idées. – COS, Masque, Machine virtuelle : pour des raisons académiques, on va choisir EMV. Ça va assurer Interopérabilité physique et celle de l’application. Celle de la plate-forme ne sera pas assurée que par MultOS, JavaCard ou SC/Windows. Ces deniers ne sont pas encore compatible EMV (MultOS vient de paraître cette année, JavaCard 2 a toujours des problèmes d’ici la fin du siècle et SC/Windows ne sera pas commercialisé ce siècle et il se repose sur l’infrastructure PC/SC qui lui manque l’interface EMV). – Lecteur : les lecteurs EMV ont commencé a paraître (cette année, De la rue a lancé ses lecteurs conformes EMV part I en Angleterre). * structure des fichiers : vous venez de recevoir un lot de cartes prépersonnalisées avec leur batch card contenant le master key MK. La clé système Ks de chaque carte est une diversification de MK avec le N° de série de la carte. Cette clé K, vous permettra de personnaliser la carte. Exemple de carte prépersonnalisée. Avec cette clé Ks vous définissez votre fichier application ADF1 et tous les EFs qui en découlent EFdata, EFclés de chiffrement, EFcodes secrets (remplissez les descripteurs de fichiers). Et un fichier personnel EF (3F03) accessible en lecture et protégé en écriture par Ks. Carte personnalisée. * Structure des données : Chaque équipement militaire a un numéro de code de 16 digits. Le numéro de série de l’équipement (s’il existe) ne dépasse pas les 12 digits et peut comporter des lettres. On va convertir le code ASCII de ces chiffres et lettres en Hexadécimal. Par exemple : « 1234 Paris » devient 01 02 03 04 50 41 52 49 53. On va coder les données en TLV, le champs valeur V sera divisé en 3 partie : 16 octets pour « le numéro de code », 12 octets pour « le numéro de série » et 2 octets pour le « nombre ». A savoir que s’il existe un numéro de série, on doit mettre les 2 octets « nombre » à 00 00h, et s’il n’existe pas on doit remplir les 12 octets avec des zéros hexadécimaux. * Les registres EMV : on va remplir les registres définies par la spécification EMV par les paramètres de notre application :
– la liste PDOL doit comporter le N° de série du terminal et la référence du magasinier. – le pointeur des Records AFL doit comporter les SFI des fichiers données EFsdata et le numéro de fichier EF info. personnelles (le terminal doit savoir remplir le fichier F) – le registre AIP doit comporter les fonctions supportées par la carte : authentification dynamique, CHV, traitement de risque à faire par l’émetteur (le terminal doit faire son traitement de risque par rapport aux transactions qu’il a exécuté avec toutes les cartes, la carte est supposée mise à jour). – les codes d’actions de l’émetteur à remplir dans le terminal, pas besoin de remplir ces codes dans la carte, car dans notre cas l’armée est l’émetteur et l’acquéreur en même temps. * L’application : Pour éliminer toute possibilité de fraude, il faut que la transaction soit balancée immédiatement, en effet la transaction se fait en présence 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 quelqu’un retire la carte au milieu de la transaction ! que se passe-t-il ? si votre stratégie est d’effacer la donnée du fournisseur et puis l’inscrire chez le receveur, alors le résultat d’un retrait de la carte est la perte de la donnée. Et si vous aimez l’autre stratégie, càd inscrire la donnée chez le receveur puis l’effacer de chez le fournisseur, le résultat sera un équipement figurant dans l’inventaire 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. N’hésitez pas à utiliser les commandes ISO telles que : update_record, read_recrd, write_record après avoir fait une commande select file. Pour éviter toute contrefaçon de la part du magasinier, faites exactement comme si ce terminal est un POS : le magasinier tape sur son clavier l’opération, le militaire regarde bien tout ce qui est affiché, et s’il est d’accord il tape soigneusement son PIN. Le programme que vous venez d’écrire émet la commande Verify pour comparer ce PIN à celui dans EF chv, et si le résultat est positif et si le magasinier a déjà tapé son code secret (une autre commande Verify a déjà comparé ce code à celui existant dans EF code secret pour autoriser l’écriture), alors la modification du fichier, telle qu’elle est affichée, aura lieu. * Test : Avec le Developpement tool kit, vous simulez, vous tripoter, pour tester votre prototype. Ce tool kit peut être propriétaire 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. 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 Référence schlumberger (cryptoflex OS). MPCOS-EMV de Gemplus. Electronic payement System O’Mahony- Peirce- Tewani. FAQ (cryptography) RSA laboratory. Smart Cards Dreifus- Monk. La carte à mémoire France Telecom. PC et carte à puce Gueule. Balance of power Ovum. inc Lire le mémoire complet ==> (Les cartes à puces) Mémoire de fin d’études Diplômes d’Etudes Approfondies – Réseaux de télécommunications