FR 2815445 A1 20020419 FR 0013340 A 20001018 PROCEDE D'EMULATION POUR GERER UN LECTEUR DE CARTE A PUCE INCOMPATIBLE AVEC UN ENVIRONNEMENT L'invention concerne les lecteurs de carte à puce fonctionnant suivant le standard"EMV"et susceptibles d'être utilisés dans un environnement de standard "PCSC"et, plus particulièrement, un procédé d'émulation de l'environnement PCSC pour gérer le lecteur de standard EMV. Par l'acronyme"EMV", on se réfère à un standard connu sous l'expression anglo-saxonne"Europay Mastercard and Visa"et par l'acronyme"PCSC", on se réfère à un standard connu sous l'expression anglo-saxonne "Personal Computer-Smart Card". Les cartes à microcircuits ou cartes à puces sont par exemple utilisées pour effectuer des transactions, notamment monétaires, et fonctionnent suivant des règles strictes en vue de garantir la sécurité des transactions. Ces règles sont respectées lorsque la carte à puce et le lecteur fonctionnent suivant le standard"EMV". Or, le lecteur de carte à puce au standard EMV peut être amené à être utilisé en association avec un ordinateur personnel qui serait connecté, par exemple, à un réseau de type INTERNET afin de réaliser des transactions électroniques. Cette association présente des incompatibilités au niveau de la communication avec la carte à puce. Il existe donc un besoin de pallier ces incompatibilités de manière à pouvoir utiliser un lecteur de carte à puce au standard EMV dans son association avec un ordinateur personnel qui peut communiquer avec une carte à puce selon le standard PCSC. A cet effet, l'invention prévoit que l'ordinateur personnel émule les fonctionnalités d'un lecteur au standard PCSC au niveau de la communication avec le lecteur de carte à puce, ce qui permet la communication entre le lecteur et l'ordinateur personnel. L'invention concerne donc un procédé d'émulation d'un lecteur de carte à puce fonctionnant selon le standard PCSC pour gérer un lecteur de carte à puce fonctionnant selon le standard EMV et communiquant avec la carte à puce selon le protocole T = 0, caractérisé en ce qu'il comprend les opérations suivantes consistant à : (a) déterminer les types d'échanges APDU pour lesquels il est nécessaire d'effectuer une émulation, (b) émuler le retour d'un mot d'état (SW1, SW2) en respectant les standards vers l'environnement PCSC, (c) lorsque le type d'échange APDU correspond à un Cas 2 tel que défini dans la norme ISO 7816-4, recevoir la commande C-APDU respectant le mot d'état, (d) lorsque le type d'échange APDU correspond à un Cas 4 tel que défini dans les standards, recevoir la commande GET-RESPONSE utilisant le mot d'état, (e) retourner R-APDU en réponse à C-APDU ou à GET-RESPONSE. Selon l'invention, les opérations (c) et (d) peuvent être réalisées dans l'ordre inverse. L'opération (c) peut être suivie de l'opération suivante consistant à : (Ci) émuler le retour d'un mot d'état (SW1, SW2) en respectant les standards vers l'environnement PCSC comme prévu lorsque le type d'échange APDU correspond à un Cas 4. L'opération (b) peut être remplacée par des opérations (b') et (bit) et l'opération (d) remplacée par une opération (d") consistant à : (b') émuler un état d'alarme, pouvant être relatif à l'application de la carte à puce, en envoyant vers l'environnement PCSC le mot d'état (SW1, SW2) respectant les standards, (d') recevoir la commande GET-RESPONSE paramétrée telle que le nombre d'octets attendus est nul, (b") émuler un mot d'état (SW1, SW2), en respectant les standards, vers l'environnement PCSC comme prévu lorsque le type d'échange APDU correspond au Cas 4. D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description suivante d'un exemple particulier de réalisation, ladite description étant faite en relation avec le dessin joint dans lequel : - la figure unique est un organigramme illustrant le procédé selon l'invention. L'ordinateur personnel avec lequel le lecteur de carte à puce au standard EMV doit communiquer comprend une interface de communication, appelé "IFD Handler" "IFD" étant l'acronyme pour l'expression anglo-saxonne "Interface Device". Selon l'invention, cette interface est utilisée pour émuler les fonctionnalités d'un lecteur au standard PCSC. Cette interface reçoit de l'application une commande C-APDU qui la transmet au lecteur, lequel en retour envoie une réponse R-APDU. APDU est l'acronyme de l'expression anglo-saxonne"Application Protocole Data Unit". Connaissant C-APDU, R-APDU et le fait que le protocole est du type T = 0, l'interface IFD est à même de déterminer s'il y a lieu de faire une émulation en fonction des cas qu'il peut détecter. Cette émulation doit être réalisée pour l'échange d'APDU du Cas 2 ou du Cas 4 de la norme ISO 7816-4 de laquelle le standard PCSC s'inspire, et ce pour une communication selon le protocole T = 0. L'état de départ est défini par l'état 10 de l'organigramme de la figure unique. L'étape 12 consiste à détecter s'il s'agit d'un Cas 2, ce cas étant caractérisé par le contenu de C-APDU, c'est-à-dire contenant un paramètre Le indiquant le nombre d'octets des données de R-APDU et ne contenant pas de données en entrée. Dans ce cas, l'interface doit émuler le retour d'un mot d'état constitué de deux octets de valeur SW1=6C et SW2=Lx, Lx étant le nombre d'octets des données de R-APDU. En retour, il reçoit une répétition de C-APDU avec Le=Lx. En réponse à cette nouvelle commande, on est en mesure de renvoyer le R-APDU avec le même nombre Lx d'octets. Si le Cas 2 n'est pas détecté par l'étape 12, l'étape 14 permet de détecter le Cas 4 qui est caractérisé par le paramètre Le et la présence de données d'entrée dans C-APDU. Dans ce cas, l'interface doit émuler le retour d'un mot d'état constitué de deux octets de valeur SW1=61 et SW2=Lx. En retour, il reçoit une commande appelée"GET-RESPONSE"qui comprend un paramètre Le=Lx. En réponse à cette commande, l'interface renvoie le R-APDU précédemment reçu du lecteur. Si aucun des deux types d'échanges d'APDU, Cas 2 ou Cas 4, n'est détecté, il n'est pas nécessaire de faire une émulation et R-APDU est retourné sans émulation. Il est à noter que le Cas 2 peut être traité en passant par la phase d'émulation du Cas 2 avec Lx quelconque, puis la phase d'émulation du Cas 4 avec la valeur Lx adéquate. Après l'étape 16, on passe à l'étape 18, tel qu'indiqué en pointillés 30 sur la figure unique, avant d'aller à l'étape 20. Pour ce qui est du Cas 4, on peut émuler un état d'alarme 24 en passant par 26, tel que le prévoit la norme ISO 7816 ou EMV dans lequel SW1 = 62 ou 63, et SW2 = xx ou xx ou quelque chose en relation avec l'application dans la carte avec SW1 = 9x et SW2 = xx avec SW1 * 90 et SW2 * 00. En retour, il reçoit la commande GET-RESPONSE paramétrée telle que le nombre d'octets attendus est nul. L'émulation s'achève par l'étape 16, puis l'étape 20 via la liaison 28. La description qui vient d'être faite fait apparaître les étapes d'un procédé d'émulation qui comprend les opérations suivantes consistant à : (a) déterminer les types d'échanges APDU pour lesquels il est nécessaire d'effectuer une émulation, (b) émuler le retour d'un mot d'état (SW1, SW2) en respectant les standards vers l'environnement PCSC, (c) lorsque le type d'échange APDU correspond à un Cas 2 tel que défini dans la norme ISO 7816-4, recevoir la commande C-APDU respectant le mot d'état, (d) lorsque le type d'échange APDU correspond à un Cas 4 tel que défini dans les standards, recevoir la commande GET-RESPONSE utilisant le mot d'état, (e) retourner R-APDU en réponse à C-APDU ou à GET-RESPONSE. Dans ce procédé, les opérations (c) et (d) peuvent être dans l'ordre inverse. L'opération (c) peut être suivie de l'opération suivante consistant à : (Cl) émuler le retour d'un mot d'état (SW1, SW2), en respectant les standards, vers l'environnement PCSC comme prévu lorsque le type d'échange APDU correspond à un Cas 4. L'opération (b) peut être remplacée par les opérations (b') et (b") et l'opération (d) par l'opération (d') consistant à : (b') émuler un état d'alarme, pouvant être relatif à l'application de la carte à puce, en envoyant vers l'environnement PCSC le mot d'état (SW1, SW2) respectant les standards, (d') recevoir la commande GET-RESPONSE paramétrée telle que le nombre d'octets attendus est nul, (b") émuler un mot d'état (SW1, SW2) en respectant les standards vers l'environnement PCSC comme prévu lorsque le type d'échange APDU correspond au Cas 4. REVENDICATIONS 1. Procédé d'émulation d'un lecteur de carte à puce fonctionnant selon le standard PCSC pour gérer un lecteur de carte à puce fonctionnant selon le standard EMV et communiquant avec la carte à puce selon le protocole T = 0, caractérisé en ce qu'il comprend les opérations suivantes consistant à : (a) déterminer les types d'échanges (APDU) pour lesquels il est nécessaire d'effectuer une émulation, (b) émuler le retour d'un mot d'état (SW1, SW2) en respectant les standards vers l'environnement PCSC, (c) lorsque le type d'échange APDU correspond à un Cas 2 tel que défini dans la norme ISO 7816-4, recevoir la commande C-APDU respectant le mot d'état, (d) lorsque le type d'échange APDU correspond à un Cas 4 tel que défini dans les standards, recevoir la commande GET-RESPONSE utilisant le mot d'état, (e) retourner R-APDU en réponse à C-APDU ou à GET-RESPONSE. 2. Procédé selon la revendication 1, caractérisé en ce que les opérations (c) et (d) sont dans l'ordre inverse. 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que l'opération (c) est suivie de l'opération suivante consistant à : (Cl) émuler le retour d'un mot d'état (SW1, SW2) en respectant les standards vers l'environnement PCSC comme prévu lorsque le type d'échange APDU correspond à un Cas 4. 4. Procédé selon la revendication 1 ou 2, caractérisé en ce que l'opération (b) est remplacée par des opérations (b') et (bit) et l'opération (d) remplacée par une opération (d') consistant à : (b') émuler un état d'alarme, pouvant être relatif à l'application de la carte à puce, en envoyant vers l'environnement PCSC le mot d'état (SW1, SW2) respectant les standards, (d') recevoir la commande GET-RESPONSE paramétrée telle que le nombre d'octets attendus est nul, (bit) émuler un mot d'état (SW1, SW2), en respectant les standards, vers l'environnement PCSC comme prévu lorsque le type d'échange APDU correspond au Cas 4.