Brevet FR2833093A1 — publié le 20030606

Procédé d'échange de blocs de données, procédé d'échange et de traitement de blocs de données, objet portatif, et automate pour la mise en oeuvre des procédés. Domaine de l'invention L'invention concerne un procédé d'échange de blocs de données entre un objet portatif et un automate ainsi qu'un procédé d'échange et de traitement de blocs de données. L'invention s'applique à tout types d'échange de blocs de données entre un objet portatif et un automate. Ainsi des données peuvent être échangées pour être simplement lues. Par exemple dans le cadre d'application de type carte d'identité électronique ou l'on veut juste vérifier l'identité de l'utilisateur Ceci est également intéressant pour les applications de type contrôle d'accès. Des données peuvent être échangées également pour être modifiées ou traitées. C'est le cas notamment de toute opération de transaction. La transaction peut en particulier permettre la délivrance d'un bien ou d'un service. Une carte peut en effet comporter une information relative à une somme d'argent susceptible d'être débitée par le terminal qui délivre en contrepartie le bien ou service. L'invention concerne également un objet portatif et un automate pour la mise en oeuvre de ces procédés. Par objet portatif il faut entendre tout type d'objet portatif comprenant un microcircuit, par exemple, une carte à microcircuit sans contact ou à contacts. Par automate il faut entendre par exemple un lecteur de carte à microcircuit. Art antérieur Un objet portatif, en particulier une carte à microcircuit, contient différents fichiers permettant le stockage de données comme illustré à la figure 1. Certains fichiers de la carte contiennent des données non modifiables (ICC, ID, K1, K2) comme le numéro de la carte, l'identification du fabricant. D'autres fichiers contiennent des données modifiables (Fl, F2, F3,... Fn) lors d'un échange de données, notamment une transaction. Dans le domaine du portemonnaie électronique, une transaction correspond notamment à une opération de crédit ou de débit. Dans le cadre d'une application transport, une transaction correspond notamment à une validation ou à un rechargement d'abonnement d'un titre de transport. Lorsque que l'on insère la carte dans un terminal, le terminal envoie une pluralité de commandes pour modifier ces différents fichiers modifiables (Fl, F2, F3,... Fn). Ainsi un premier fichier FI est sélectionné puis il est lu et/ou modifié. Un deuxième fichier F2 est ensuite sélectionné puis il est lu et/ou modifié. Le processus continue ainsi jusqu'à avoir modifié tous les fichiers (Fl, F2, F3,... Fn) nécessaires à la transaction. Dans une dernière étape de confirmation de ces modifications, les modifications sont soient toutes validées en même temps soient toutes annulées. Par exemple la demande de brevet FR 2 777 371 propose un procédé permettant d'effectuer une pluralité de modifications de la mémoire d'une carte de manière indivisible. Elle propose qu'un tel procédé puisse être entièrement géré par la carte. Lorsque les données à modifier lors d'une transaction se trouvent dans des fichiers différents, la multiplication du nombre de fichiers à lire et à écrire augmente le temps de transaction. Cette augmentation du temps de transaction est liée notamment à l'ajout de commandes à envoyer à la carte comme, par exemple, une commande de sélection de fichiers. Lorsque les données à modifier sont contenues dans plusieurs fichiers et que, par exemple, une opération de transaction est interrompue juste après l'écriture relative à un débit dans un premier fichier, les fichiers suivants ne seront pas modifiés. Il manquera donc des informations relatives à la transaction. L'état de la carte sera incohérent car seul le premier fichier aura été modifié. La transaction ne pourra pas être valide du fait que certains fichiers n'auront pas été mis à jour, à moins de mettre en oeuvre un processus supplémentaire de restauration comme par exemple une étape de confirmation ou de nonconfirmation de toutes les modifications à la fois. Exposé de l'invention Un but de l'invention est de mettre en oeuvre un procédé d'échange de blocs de données entre un objet portatif et un automate qui soit plus rapide et plus fiable. Selon un premier aspect de l'invention un tel procédé d'échange de blocs de données (Dl,.. Di,... Dn) entre la mémoire d'un objet portatif, notamment une carte à microcircuit, et un automate muni d'une mémoire, lesdits blocs de données (Dl,.. Di,... Dn) comportant des blocs de données modifiables, est caractérisé en ce qu'il comprend les étapes suivantes : une étape de création d'un fichier unique (F) comprenant tous les blocs de données (Dl,.. Di,... Dn) modifiables ; une étape de lecture du fichier unique (F) dans laquelle le contenu du fichier (F) est copié dans la mémoire du terminal sous forme d'un fichier image (F'). Selon un deuxième aspect, l'invention concerne un procédé d'échange et de traitement de blocs de données (Dl,.. Di,... Dn) entre la mémoire d'un objet portatif, notamment une carte à microcircuit, et un automate muni d'une mémoire, lesdits blocs de données (Dl,.. Di,... Dn) comportant des blocs de données modifiables, qui est caractérisé en ce qu'il comprend les étapes suivantes : une étape de création d'un fichier unique (F) comprenant tous les blocs de données (Dl,.. Di,... Dn) modifiables ; une étape de lecture d'un fichier unique (F) dans laquelle le contenu du fichier (F) est copié dans le mémoire du terminal sous forme d'un fichier image (F') ; une étape d'écriture de données dans le fichier image (F') ; une étape de copie dans laquelle l'automate envoie à la carte un ordre unique d'écriture pour que le contenu du fichier (F') vienne remplacer le contenu du fichier unique (F) dans la mémoire de l'objet portatif. Selon un troisième aspect, l'invention concerne un objet portatif comprenant une mémoire comportant des blocs de données (Dl,.. Di,... Dn) apte à être transférés lors d'un échange de données entre ledit objet portatif et un automate, caractérisé en ce que lesdits blocs de données (Dl,.. Di,... Dn) sont contenus dans un fichier unique (F). Selon un quatrième aspect, l'invention concerne un produit de programme d'ordinateur pour un système de traitement de données, le produit de programme d'ordinateur comprenant un jeu d'instructions qui quand le jeu d'instruction est chargé dans le dispositif de traitement de données, amène le dispositif de traitement de données à effectuer les étapes du procédé d'échange de blocs de données selon l'invention. Avec l'invention, en créant un fichier unique F comprenant au moins toutes les données modifiables lors du traitement de données, le nombre de commandes à utiliser lors du traitement de donnée est limité. Une seule sélection de fichier est notamment nécessaire. Le procédé selon l'invention est donc plus rapide. D'autre part la modification des données se fait sur une copie du fichier unique F stockée dans le terminal. Les échanges entre l'objet portatif et l'automate sont donc moins fréquents. Les risques de perturbation du dialogue entre l'objet portatif et l'automate sont plus faibles. Le procédé selon l'invention est donc plus fiable. Dessins L'invention sera mieux comprise à la lecture de l'exposé non limitatif qui suit, rédigé au regard des dessins annexés, dans lesquels : - La figure 1 illustre une structure classique de fichiers. La figure 2 illustre la structure de fichiers selon l'invention Mode de réalisation de l'invention L'invention peut-être appliquée pour opérer par exemple une transaction entre une carte et un terminal. La figure 2 illustre une structure de fichiers selon l'invention. Elle montre un répertoire général MF contenant des fichiers et au moins un sous-répertoire DF. Le fichier ICC contient des informations relatives à la carte comme par exemple son numéro de série et l'identification du fabricant. Le fichier ID contient des informations relatives à l'utilisateur de la carte. Le fichier Kl contient des clés nécessaires à l'administration de la carte. Ces fichiers ne sont pas modifiables lors notamment d'une opération de transaction. Dans le sous répertoire DF se trouve un fichier F, un fichier K2 et un fichier PIN. Dans ce fichier unique F se trouvent au moins toutes les données nécessaires à la transaction. Le fichier K2 contient quant à lui, des clés permettant de contrôler l'accès à ce fichier F. Le fichier PIN contient le code PIN de la carte. Le corps de ce fichier est divisé en différentes parties. Il y a des champs de données (Dl,.. Di,.. Dn) et des cryptogrammes (Cl,.. Ci,.. Cn). A la suite de chacun des champs de données Dl, D2,... ou Dn est ajouté un cryptogramme Cl, C2,.. ou Cn respectivement calculés sur la base du contenu du champs de données correspondant. Le calcul du cryptogramme s'effectue par exemple en compressant le champ de données correspondant pour obtenir un résultat par exemple sur 8 octets. Ce résultat est ensuite crypté à l'aide d'une clé connue uniquement par le terminal. Cette clé n'est pas stockée dans la carte. Selon une alternative le fichier unique (F) comprend l'ensemble des blocs de données (Dl,.., Di,.. Dn) et un cryptogramme unique. Selon une autre alternative, pour des données non sécurisées, le fichier F unique comprend uniquement des blocs de données (Dl,.. Di, Dn). Finalement toutes les données modifiables lors d'une transaction sont regroupées dans un fichier unique F de la figure 1. Les cryptogrammes Cl, C2, ... Cn calculés sur la base du contenu de chaque champ de données Dl, D2, D3 y sont ajoutés. Selon une première alternative, le fichier unique F est crée, par exemple, lors de la personnalisation de la carte. La structure de données de la carte sera donc telle que, pour une application DF donnée, toutes les données modifiables sont regroupées dans un fichier unique F. Selon une seconde alternative, on peut également créer ce fichier unique F après la phase de personnalisation de la carte. Lors de l'insertion de la carte dans le terminal, ce dernier détecte la présence ou non d'un fichier unique F contenant toutes les données modifiables. Si ce fichier F n'existe pas, il est alors créé par concaténation des différents fichiers modifiables existant en un fichier unique F. Lors de l'insertion d'une carte munie d'une structure de fichiers selon l'invention, un programme mettant en oeuvre le processus comprenant les étapes suivantes va alors se dérouler. Lors d'une première étape dite d'identification de la carte, les fichiers ICC et ID sont lus. Cette étape d'identification comprend notamment la lecture d'un numéro de série et des informations sur l'utilisateur de la carte, Lors d'une seconde étape dite de sélection, un répertoire relatif à l'application DF que l'on souhaite utiliser est sélectionné. Il peut s'agir par exemple d'une application de type porte-monnaie électronique ou de type transport. Une fois le répertoire DF choisi seuls les fichiers contenus dans le répertoire DF seront désormais considérés. Lors d'une troisième étape dite d'authentification mutuelle de la carte et du terminal, le terminal s'assure qu'une vraie carte est présente lors d'une opération de débit ou de validation pour une application transport. Cette étape permet d'autre part à la carte de s'assurer de l'authenticité du terminal pour une opération de crédit d'un porte-monnaie électronique ou de rechargement d'une carte de transport. Si l'authentification échoue la carte est rejetée. Si l'authentification réussie l'accès au fichier unique F à modifier peut être autorisée, ce en utilisant les clés d'accès contenues dans le fichier K2. Lors d'une deuxième étape de sélection, le fichier unique F contenant au moins toutes les données nécessaires à une transaction est sélectionné. Lors d'une cinquième étape dite de lecture, les informations contenues dans le fichier unique F sont copiées sous forme d'un fichier image F'stocké dans une mémoire située dans le terminal. La mémoire du terminal est de préférence une mémoire tampon. Lors d'une sixième étape dite de contrôle, le terminal contrôle l'intégrité de chaque champs de données (Dl,.. Di,... Dn) contenu dans le fichier image F'. Pour cela, le terminal vérifie que chaque cryptogrammes (Cl,.. Ci,.. Cn) correspond bien au contenu du champ de données (Dl,.. Di,... Dn) auquel il est rattaché. Soit, par exemple, un fraudeur qui modifie le contenu d'un champ de données dans le cadre d'une application de type porte-monnaie électronique. La donnée correspondant à la valeur débitée peut-être notamment diminuée de sorte que le prix payé pour obtenir le bien ou service n'est pas le prix réel. Dans ce cas le cryptogramme ne correspondra plus avec son champ de données associé. L'intégrité des données est donc mieux garantie. Le traitement des données est donc plus fiable. Si le contrôle de l'intégrité des données est négatif la carte est rejetée. Si le contrôle est positif on peut procéder à l'étape de modification des données. Lors d'une septième étape dite d'écriture, les différents champ de données (Dl,.. Di,... Dn) du fichier image F'sont modifiés par le terminal selon la transaction à affectuée. Lors d'une huitième étape dite de calcul, des nouveaux cryptogrammes (Cl,.. Ci,.. Cn) correspondant aux champs de données (Dl,.. Di,... Dn) venant d'être modifiés sont calculés. Ce calcul s'effectue notamment en compressant le champ de donnée (Dl,.. Di,... Dn) associé pour obtenir par exemple un résultat sur 8 octets. Ce résultat est ensuite crypté à l'aide d'une clé connue uniquement par le terminal. Lors d'une neuvième étape dite de copie, le terminal envoie à la carte un ordre unique d'écriture pour que le contenu du fichier image F'vienne remplacer le contenu du fichier unique F sur la carte. La carte est de préférence munie d'un mécanisme de miroir mono commande. Un mécanisme de miroir mono commande est un mécanisme qui permet, en cas d'interruption de l'exécution d'une commande, que les anciennes données soient restaurées. Ceci est particulièrement avantageux notamment dans le cadre des cartes sans contact où il y a des risques inopinés de rupture de la communication entre la carte et le terminal. Par exemple dans le cas d'une carte sans contact, la zone dans laquelle la carte est active n'est pas toujours très bien déterminée. Alors, si l'exécution de l'ordre unique d'écriture du fichier image F'vers la mémoire de l'objet portatif est interrompue, ce simple mécanisme de miroir mono commande va permettre de restaurer les anciennes données. Ceci évite d'avoir à mettre en oeuvre un processus supplémentaire de sauvegarde et de restauration. Le procédé selon l'invention est donc plus simple. En effet, selon l'art antérieur, lorsque les données à modifier sont contenues dans plusieurs fichiers et que, par exemple, une opération de transaction est interrompue juste après l'écriture relative à un débit dans un premier fichier, les fichiers suivant ne seront pas modifiés. L'état de la carte sera incohérent car seul le premier fichier aura été débité. La transaction ne pourra pas être valide du fait que certains fichiers n'auront pas été mis à jour. Avec l'invention la modification des données se fait sur une copie F'du fichier F. Cette copie est située dans une mémoire du terminal, par exemple une mémoire tampon. Une fois la modification faite, un ordre d'écriture unique est envoyé à la carte par le terminal. La carte contient de préférence un mécanisme de miroir mono commande. Ainsi en cas d'interruption pendant la phase d'exécution de l'ordre unique d'écriture, les données sont soit entièrement écrites ou soit aucune donnée n'est écrite. Il est donc impossible de se trouver dans un état où des données partielles sont écrites. Le procédé de traitement de donnée selon l'invention est donc plus fiable. En outre lorsque les données à modifier lors d'une transaction se trouvent dans des fichiers différents, la multiplication de ce nombre de fichiers à lire et à écrire augmente le temps de modification des données. Cette augmentation du temps de modification est liée notamment à l'ajout de commandes à envoyer à la carte comme, par exemple, une commande de sélection de fichiers. En regroupant les différents blocs de données à modifier lors de la transaction dans un fichier unique, le nombre de commandes à utiliser est limité. Une seule sélection de fichier est notamment nécessaire. Le traitement de données selon l'invention est donc plus rapide. L'invention a été décrite dans le cadre d'opération de transaction entre une carte et un terminal. Plus généralement l'invention s'applique à tout types d'applications nécessitant l'écriture de plusieurs fichiers lors d'un processus d'échange et/ou de traitement de données. L'invention peut s'appliquer en particulier à tous les systèmes de traitement de données munis d'un mécanisme de miroir mono commande. Revendications 1. Procédé d'échange de blocs de données (Dl,.. Di,... Dn) entre la mémoire d'un objet portatif, notamment une carte à microcircuit, et un automate muni d'une mémoire, lesdits blocs de données (Dl,.. Di,... Dn) comportant des blocs de données modifiables, caractérisé en ce qu'il comprend les étapes suivantes : une étape de création d'un fichier unique (F) comprenant tous les blocs de données (Dl,.. Di,... Dn) modifiables ; une étape de lecture du fichier unique (F) dans laquelle le contenu du fichier (F) est copié dans le mémoire du terminal sous forme d'un fichier image (F'). 2. Procédé d'échange de blocs de données (Dl,.. Di,... Dn) selon la revendication précédente, caractérisé en ce que le fichier unique (F) est créé lors de la phase de personnalisation de la carte. 3. Procédé d'échange de blocs de données (Dl,.. Di,... Dn) selon la revendication 1, caractérisé en ce que le fichier unique (F) est crée après la phase de personnalisation de la carte, par concaténation desdits blocs de données dans le fichier unique F. 4. Procédé d'échange et de traitement de blocs de données (Dl,.. Di,... Dn) entre la mémoire d'un objet portatif, notamment une carte à microcircuit, et un automate muni d'une mémoire, lesdits blocs de données (Dl,.. Di,... Dn) comportant des blocs de données modifiables, caractérisé en ce qu'il comprend les étapes suivantes : une étape de création d'un fichier unique (F) comprenant tous les blocs de données (Dl,.. Di,... Dn) modifiables ; une étape de lecture d'un fichier unique (F) dans laquelle le contenu du fichier (F) est copié dans le mémoire du terminal sous forme d'un fichier image (F') ; une étape d'écriture de données dans le fichier image (F') ; une étape de copie dans laquelle l'automate envoie à la carte un ordre unique d'écriture pour que le contenu du fichier (F') vienne remplacer le contenu du fichier unique (F) dans la mémoire de l'objet portatif. 5. Procédé d'échange et de traitement de blocs de données (Dl,.. Di,... Dn) selon la revendication précédente, caractérisé en ce qu'il comprend en outre, avant l'étape d'écriture, une étape de contrôle de l'intégrité des données contenues dans le fichier (F') dans laquelle le terminal contrôle au moins un cryptogramme (Cl) contenus dans le fichier (F'). 6. Procédé d'échange et de traitement de blocs de données (Dl,.. Di,... Dn) selon la revendication 4 caractérisé en ce que dans l'étape de copie selon laquelle l'automate envoie à la carte un ordre unique d'écriture pour que le contenu du fichier (F') vienne remplacer le contenu du fichier unique (F) dans la mémoire de l'objet portatif, l'objet portatif est apte à mettre en oeuvre un mécanisme de miroir mono commande. 7. Objet portatif comprenant une mémoire comportant des blocs de données (Dl,.. Di,... Dn) apte à être transférés lors d'un échange de données entre ledit objet portatif et un automate, caractérisé en ce que lesdits blocs de données (Dl,.. Di,... Dn) sont contenus dans un fichier unique (F). 8. Objet portatif selon la revendication 7, caractérisé en ce que lesdits blocs de données (Dl,.. Di,... Dn) sont modifiables lors d'un échange de données. 9. Objet portatif selon la revendication 8, caractérisé en ce que le fichier unique comprend en outre des données non modifiables (K2). 10. Objet portatif selon la revendication 7, caractérisé en ce que ledit fichier unique (F) comprend en outre différents cryptogrammes (Cl,.., Ci,.. Cn) respectivement associés à des blocs de données (Dl,.. Di,... Dn). 11. Objet portatif selon la revendication 7, caractérisé en ce que ledit fichier unique (F) comprend en outre un cryptogramme associé au fichier unique (F) (non représenté dans les dessins). 12. Carte à microcircuit comprenant une mémoire comportant des blocs de données (Dl,.. Di,... Dn) apte à être transférés lors d'un échange de données entre ledit objet portatif et un automate, caractérisé en ce que lesdits blocs de données (dal,.. Di,... Dn) sont contenus dans un fichier unique (F). 13. Automate agencé pour opérer avec l'objet portatif selon la revendication 7. 14. Produit de programme d'ordinateur pour un système de traitement de données, le produit de programme d'ordinateur comprenant un jeu d'instructions qui quand le jeu d'instruction est chargé dans le dispositif de traitement de données, amène le dispositif de traitement de données à effectuer les étapes du procédé selon la revendication 1 ou 4.