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. 
| si votre application nécessite : | alors utilisez : |
| a- un bas prix | carte à mémoire à jeter |
| b- un type de mémoire : | |
| où on doit écrire, effacer et réécrire | EEPROM, RAM |
| où on doit écrire | EPROM, RAM |
| où les données sont figées | ROM |
| c- un protocole de communication : | |
| synchrone | carte à mémoire |
| asynchrone | carte à microcontrôleur |
| d- une capacité de traitement : | |
| authentification rapide des clés de sécurité | co-processeur |
| algorithmes compliqués (RSA par exemple) | co-processeur |
| rapide | processeur unique |
| vérification de PIN | processeur unique/mémoire |
| pas de traitement | carte à mémoire |
| e- un système d’exploitation (COS): | |
| fermé ou propriétaire | développez votre COS |
| conforme à ISO 7816 | achetez COS courant |
| ouvert | MultOS, Java ou SC/Windows |
| f- un Masque : | |
| conforme à ISO 7816 | achetez |
| fermé ou propriétaire | développez |
| g- une structure de fichier : | |
| à accès rapide | hiérarchique |
| données communes partagées | relationnel |
| non structurées | orienté objet |
| h- une vitesse de traitement : | |
| conforme à ISO 7816 | de 1 à 5 MHz |
| tous les autres | dépend du terminal |
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 :
| si votre application nécessite : | Alors utilisez : |
| Long life | sheet offset |
| grand nombre de cartes | sheet offset |
| petit nombre/basse qualité | injection molding |
| carte de haute qualité | sheet offset |
| cartes à jeter | injection molding |
Implémentation du système :
| si votre application nécessite : | Alors utilisez : |
| communication à haut débit | cartes avec contacts |
| communication : bas débit | cartes sans contacts |
| une ou plusieurs applications | mémoire et COS convenable |
| protection contre la fraude | crypto co-processeur |
| haut niveau de sécurité | crypto co-processeur |
| volume de la mémoire | ça dépend de l’application |
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 :
| si votre application nécessite : | Alors utilisez : |
| des longs registres | la puce convenable |
| communication à haute vitesse | fréquence d’horloge non ISO |
| des registres de stockage | mémoire de taille convenable |
| anti-contrefaçon | puce résistante au tripotage |
*** 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 
– 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