FR2818767A1

FR2818767A1 - Logiciel de gestion d'objets logiciels pouvant etre utilise, notamment, comme explorateur de cartes a puce

Info

Publication number: FR2818767A1
Application number: FR0016913A
Authority: FR
Inventors: Frederic Cabaud
Original assignee: Individual
Current assignee: Individual
Priority date: 2000-12-22
Filing date: 2000-12-22
Publication date: 2002-06-28
Anticipated expiration: 2020-12-22
Also published as: FR2818767B1

Abstract

Logiciel de gestion d'objets logiciels pouvant être utilisé, notamment, comme Explorateur de cartes à puce. L'invention permet de gérer des objets logiciels et de pouvoir y accéder via un arbre informatique. L'invention permet également de pouvoir accéder à des cartes à puce de façon modulaire, (par exemple un objet logiciel par carte). Ce logiciel permet de générer du code informatique (langage C, C++, Java... ) à partir des objets logiciels. Ce logiciel (1) est constitué :- d'un gestionnaire d'objets logiciels (2) indépendant de toutes cartes à puce (3),- d'objets logiciels (4) : il s'agit d'objets pouvant contenir du code, des données et une arborescence. Un objet logiciel peut contenir, par exemple, de quoi gérer une carte à puce ou une partie de celle-ci. Ce concept est particulièrement adapté à :- La gestion d'objets logiciels (exemples : cryptographie, navigation... ),- La gestion de carte (s) à puce.Par exemple, depuis un micro-ordinateur.

Description

Paragraphe 1 : Indication du domaine technique de l'invention La présente invention concerne la gestion d'objets logiciels depuis un micro-ordinateur.

La notion de gestion visuelle d'objet logiciel existe déjà, néanmoins, la présente invention permet d'ajouter à un objet une notion d'arborescence.

Ainsi, il est possible d'explorer un ou plusieurs objets via une représentation graphique sous forme d'arbre.

Cette invention peut, entre autre, servir à explorer les cartes à puce. Si les exemples qui suivent font référence aux cartes à puce, ceci ne signifie pas que c'est la seule application possible.

Cette invention est indépendante de tout type : - d'ordinateur, - de matériel d'accès à une carte à puce (lecteur...), - de carte à puce avec ou sans contact, quelque-soit son protocole.

Paragraphe 2 : Indication de l'état technique antérieure faisant ressortir le problème technique posé.

Habituellement, les logiciels de gestion de cartes à puce sont spécialisés pour une application. Par exemple. il peut exister actuellement, un logiciel dédié à une application carte santé Vitale , un logiciel spécialisé dans la gestion d'une carte de fidélité ou encore un logiciel qui ne traite que la Télécarte .

Il n'existe pas de logiciel permettant de gérer de façon modulaire des applications concernant les cartes à puce, c'est à dire prévu pour ajouter ou enlever de façon simple le traitement d'une carte d'une carte, ceci avec, en plus, une vue arborescente par objet (des répertoires et des fichiers) et un générateur de code en langage C, C++, C# ou Java.

Paragraphe 3 : Exposé de l'invention Pour remédier à cet inconvénient, la présente invention est un logiciel qui fonctionne selon le principe d'un Jude-Box : Il y a une séparation entre : - le logiciel exécutable gestionnaire d'objet qui lit et interprète un ou plusieurs objets logiciels (la partie du jude-box qui va prendre les disques de musique, interprète leurs contenus et le transmet vers des haut-parleurs), - des objets logiciels qui sont des fichiers que l'on peut par exemple créer, ajouter, modifier, supprimer (dans l'exemple du jude-box, ce sont les disques de musique, que l'on peut enlever ou ajouter simplement).

Ainsi, il est possible, par exemple, de supprimer une application carte (un objet) et d'en ajouter une autre.

Le gestionnaire d'objet permet également de modifier un objet. Dans l'analogie avec le Jude-Box, c'est comme si le Jude-Box pouvait enregistrer du son et graver un disque.

Le gestionnaire d'objet peut, par ailleurs, permettre d'afficher une fenêtre contenant une vue sous forme d'arbre qui permet d'avoir accès à des zones en imposant un ordre d'accès à celles-ci.

Par défaut, seule la racine de l'arbre est visible, puis à chaque zone correctement accédée (par exemple, sur une lecture, sur une présentation de code confidentielle ou encore sur un calcul cryptographique...) une branche de l'arbre s'ouvre.

Paragraphe 4 : La figure 1 illustre le fonctionnement de l'invention Le logiciel (1) se décompose-en : - un gestionnaire d'objet (s) (2) qui est un exécutable dont le but est :
De lire et d'interpréter le contenu d'objets logiciels (exécution de code, appel de fonction, gestion d'arbre, accès à une carte à puce (3)...),
D'écrire dans des objets,
De gérer une fenêtre explorateur (affichage d'une vue arborescente).

- des objets logiciels (4) : il s'agit de fichiers informatiques qui contiennent du code et des données. Certains objets peuvent être spécialisés dans la gestion d'une carte ou d'une partie d'une carte : dans ce cas, ils sont appelés des"objets cartes".

Certains objets peuvent également contenir une vue arborescente.

En plus de la gestion modulaire d'application carte, le gestionnaire d'objet permet de mettre à disposition ces données : * Affichage (5), * Ecriture sur une unité de stockage (6), par exemple, un disque dur, une disquette...

Paragraphe 5 : Exposé détaillé Paragraphe 5.1 : Le gestionnaire d'objet Paragraphe 5.1. 1 : L'interface Homme Machine
L'ouverture d'un objet : Il est possible d'ouvrir un objet grâce à une icône ou un menu déroulant ce qui provoque : - L'ouverture d'une fenêtre de sélection de fichiers. A ce niveau, il est possible d'annuler la demande l'ouverture d'un objet.

- L'ouverture d'une fenêtre qui corresponds à l'objet désiré. Il s'agit d'une fenêtre qui affiche tous les enregistrements de l'objet ouvert
La gestion des objets ouverts : Le gestionnaire d'objet tient à jour une Liste des objets ouverts)).

Il est à noter que : - Lors de l'exécution du code d'un objet, un autre objet peut être ouvert via l'interpréteur de commande.

Pour fermer un objet, il suffit de fermer la fenêtre de cet objet.

Dans tous les cas d'ouverture et de fermeture, le gestionnaire d'objet met à jour la Liste des objets ouverts .

Paragraphe 5. 1. 2 : L'interpréteur de commande Cet interpréteur de commande, sur demande d'exécution : - l'enregistrement, - Interprète le champ Access suivant la valeur du préfixe du champ Name :

<tb>
<tb> Préfixe <SEP> du <SEP> champ <SEP> <SEP> Name <SEP> <SEP> Interprétation <SEP> du <SEP> champ <SEP> <SEP> Access <SEP>
<tb> <SEP> LOG <SEP> <SEP> Calcul.
<tb>

<SEP> PHYS~" <SEP> Accès <SEP> physique <SEP> au <SEP> lecteur <SEP> de <SEP> carte <SEP> à <SEP> puce.
<tb>

<SEP> GET~ <SEP> <SEP> Demande <SEP> de <SEP> données <SEP> à <SEP> l'utilisateur.
<tb>

<SEP> SERVICE~" <SEP> Service <SEP> : <SEP> c'est <SEP> le <SEP> début <SEP> d'une <SEP> fonction.
<tb>
Calcul :

<tb>
<tb> Champs <SEP> <SEP> Name <SEP> <SEP> Champs <SEP> <SEP> Access <SEP> <SEP> Champs <SEP> <SEP> Data <SEP> <SEP> en <SEP> décimal
<tb> LOG-VARIABLE1 <SEP> 3*4 <SEP> 12
<tb> LOG-VARIABLE2 <SEP> OxOA <SEP> 10 <SEP> (Ox <SEP> pour <SEP> de <SEP> l'hexadécimal)
<tb> LOG~VARIABLE3 <SEP> LOG~VARIABLE1+ <SEP> 22
<tb> LOG~VARIABLE2
<tb> LOG~VARIABLE4 <SEP> SERVICE~EXAMPLE <SEP> Valeur <SEP> retoumée <SEP> par <SEP> le <SEP> service
<tb> EXAMPLE
<tb>
Accès physique au lecteur de carte à puce :

<tb>
<tb> Champs <SEP> <SEP> Name <SEP> <SEP> Champs <SEP> Champs <SEP> <SEP> Data <SEP>
<tb> <SEP> Access <SEP>
<tb> PHYSRESETANSWER <SEP> Non <SEP> applicable <SEP> Réponse <SEP> au <SEP> reset <SEP> d'une <SEP> carte <SEP> suivant <SEP> la <SEP> norme
<tb> ISO17816-3
<tb> PHYS~VARIABLE1 <SEP> Apdu <SEP> Résultat <SEP> d'une <SEP> commande <SEP> de <SEP> type <SEP> Apdu <SEP> suivant
<tb> ( <SEP> 01020403 ) <SEP> la <SEP> norme <SEP> ISO7816.
<tb>

Attention, <SEP> il <SEP> existe <SEP> des <SEP> champs <SEP> Sw1 <SEP> et <SEP> Sw2
<tb> contenant <SEP> les <SEP> valeurs <SEP> des <SEP> ces <SEP> données
<tb> retournées <SEP> par <SEP> la <SEP> carte <SEP> (voir <SEP> la <SEP> norme).
<tb>
Demande de données à l'utilisateur. :

<tb>
<tb> Champs <SEP> <SEP> Name <SEP> <SEP> Champs <SEP> Champs <SEP> <SEP> Data <SEP>
<tb> <SEP> Access <SEP>
<tb> GET~VARIABLE1 <SEP> EnterData(200, <SEP> 1, <SEP> Données <SEP> entrées <SEP> au <SEP> clavier.
<tb>

4,
<tb> LOG~TXT~PIN)
<tb>
La fenêtre reste présente durant la valeur du premier paramètre exprimée en secondes.

Exemple: 200 secondes.

Le second paramètre indique si les données sont affichées ou pas : affichage d'astérisque : 1 ou pas : 0.

Le troisième paramètre est le nombre de digits attendus. Le dernier paramètre est le message à afficher à l'utilisateur : par exemple : Saisissez votre Code confidentiel .

Service :

<tb>
<tb> Champs <SEP> <SEP> Name <SEP> <SEP> Champs <SEP> <SEP> Access <SEP> <SEP> Champs <SEP> <SEP> Data <SEP>
<tb> SERVICE~EXAMPLE <SEP> Non <SEP> applicable. <SEP> Non <SEP> applicable.
<tb>
Dans ce cas, l'interpréteur de commande sait qu'un service appelé EXAMPLE commence. Un service est une fonction qui retourne une chaîne de caractère. S'il n'y a pas d'erreur, alors la

chaîne vaut OK sinon elle indique l'erreur : par exemple Code faux . Dans la liste des enregistrements, un service se déroule jusqu'à ce que : un nouveau service soit déclaré, - une arborescence soit déclarée (voir le préfixe (NODE~ plus loin), - une fin de fichier soit détectée.

Paragraphe 5.1.3 : L'Explorateur Ouverture de la fenêtre Explorateur : Sur sélection du bouton explorateur, le gestionnaire d'objet : -Vérifiequef'enregistrementNODE)) NOM DU FICHIER est présent.

S'il est absent, cette erreur est affichée et les actions suivantes ne sont pas réalisées.

- Parcours l'objet l'Arbre : A chaque noeud NODE~... , il lit et mémorise le champ Nb of children c'est le nombre de noeuds descendants.

Le noeud de départ est, bien entendu, le noeud NODE- NOM DU FICHIER .

Le parcours de l'arbre (la lecture des noeuds) se fait jusqu'à ce que la fin de l'objet (fin de fichier) soit atteinte.

Entre chaque enregistrement de type noeud peuvent se trouver des enregistrements de type fichier . Dans ce cas, il s'agit des feuilles de l'arbre et le préfixe est FILE- .

Par analogie, avec un disque dur, les noeuds sont vus comme des répertoires et les fichiers... comme des fichiers.

En résumé, L'arbre contient : * les noeuds et leurs hiérarchies, * pour chaque noeud : la liste des fichiers du noeud .

- Affiche la fenêtre de l'explorateur. Elle se décompose en plusieurs parties : - L'arbre qui correspond à l'arborescence précédemment mémorisée.

A l'ouverture de la fenêtre de l'explorateur l'arbre est représenté fermé.

Sur un click (souris) sur la racine de cet arbre (NODE~ NOM DU
FICHIER ), le premier noeud s'ouvre.

- Les données du noeud qui contient les données associées au dernier noeud ouvert, - la liste des fichiers du noeud qui contient le nom des fichiers contenus dans le noeud ouvert, - Les données du fichier qui contient les données associées au dernier fichier ouvert,

Ouverture d'un noeud (NODE EXAMPLE NODE) Lors de l'ouverture d'un noeud (click souris) sur le noeud associé dans le menu Arbre : - L'enregistrement dont le champ Name porte le nom NODE-EXAMPLE-NODE (EXAMPLE-NODE étant le noeud à ouvrir) est lu dans l'objet.

- Le champ Access de cet enregistrement est lu, il indique le service à exécuter.

- Si le service s'est exécuté correctement (compte-rendu OK ) alors : * Au niveau graphique le noeud est ouvert (la branche associée est affichée), * La liste de fichiers du noeud est affichée, pour cela # Le champ ListOfFields a été lu pour connaître la liste des données à afficher dans la fenêtre Les données du noeud .

* Les différents noms des noeuds enfants ont été extraits, un

point-virgule délimite les chaînes de caractères dans le champ ListOfFields .

- Si le service ne s'est exécuté correctement (compte-rendu différent de OK ) alors : * Au niveau graphique le noeud n'est pas ouvert (la branche associée est affichée), * L'erreur (le compte-rendu) est affichée dans l'exporateur.

Ouverture d'un fichier (FILE EXAMPLE FILE) Lors de l'ouverture d'un fichier (click souris) sur le nom de fichier associé dans la liste du noeud : - L'enregistrement dont le champ Name porte le nom NODE-EXAMPLE-NODE (EXAMPLENODE étant le noeud à ouvrir) est lu.

- Si le service s'est exécuté correctement (compte-rendu OK ) alors le champ ListOfFields est lu pour connaître la liste des données à afficher dans la fenêtre Les données du fichier .

Paragraphe 5.1. 4 : Le générateur de code En fonction du préfix du champ Access, (voir paragraphe L'interpréteur de commande), le générateur interprète le type de commande et le code à générer.

Si aucune commande n'est trouvée, il cherche une chaîne de caractère, dans ce cas c'est un calcul qui est généré. Si aucune chaîne de caractère n'est détectée alors le générateur

de code décrit une constante.

En langage C et C++, les variables déclarées avec le format Hex ou Dec sont des unsigned long. Celle ayant le format Str ou Asc sont des chaînes de caractère en C et des classes AnsiString en C++ Les variables ou fonctions déclarée avec le champ Exported à Faux sont déclarées static en langage C et privées (private) en C++.

Paragraphe 5. 2 : Le ou les Objet (s) Paragraphe 5. 2. 1 : But
Il s'agit de fichiers informatiques, qui peuvent être copiés, renommés, détruits....

Indépendamment du gestionnaire d'objet. Ils contiennent une liste d'enregistrements dont les champs sont détaillés par la suite.

Paragraphe 5.2. 2 : Champs Chaque enregistrement (chaque ligne) est une commande exécutable.

Les champs sont les suivants :

<tb>
<tb> Nom <SEP> But
<tb> Name <SEP> Nom <SEP> de <SEP> l'enregistrement
<tb> Access <SEP> Comment <SEP> renseigner <SEP> le <SEP> champ <SEP> Data
<tb> Data <SEP> Valeur <SEP> du <SEP> champ
<tb> Sw1 <SEP> Etats <SEP> d'une <SEP> carte <SEP> à <SEP> puce <SEP> Sw1
<tb> Sw2 <SEP> Etats <SEP> d'une <SEP> carte <SEP> à <SEP> puce <SEP> Sw2
<tb> Object <SEP> Nom <SEP> d'un <SEP> autre <SEP> objet, <SEP> utilisé <SEP> via <SEP> le <SEP> champ <SEP> Access
<tb> Exported <SEP> Indique <SEP> si <SEP> l'enregistrement <SEP> est <SEP> accessible <SEP> par <SEP> un <SEP> autre <SEP> objet <SEP> ou <SEP> pas
<tb> Format <SEP> Format <SEP> du <SEP> champ <SEP> Data <SEP> : <SEP> <SEP> Hex <SEP> , <SEP> <SEP> Dec <SEP> , <SEP> <SEP> Str <SEP> <SEP> ou <SEP> <SEP> Asc <SEP>
<tb> Nb <SEP> of <SEP> children <SEP> Nombre <SEP> de <SEP> branche <SEP> (s) <SEP> du <SEP> noeud <SEP> courant
<tb> ListOfFields <SEP> Nombre <SEP> de <SEP> fichier <SEP> (s) <SEP> dans <SEP> le <SEP> noeud <SEP> courant
<tb> Test <SEP> Indique <SEP> un <SEP> test <SEP> à <SEP> réaliser <SEP> pour <SEP> savoir <SEP> si <SEP> le <SEP> champ <SEP> Access <SEP> doit <SEP> être
<tb> gérer
<tb> Comments <SEP> Commentaires
<tb>

Paragraphe 5.2. 3 : Fenêtre d'affichage des objets Ces fenêtres sont ouvertes par le gestionnaire d'objets. Elles affichent une table indiquant au niveau des lignes, les enregistrements et au niveau des colonnes, les champs. Des ascenseurs verticaux et horizontaux permettent d'accéder aux lignes et respectivement aux colonnes.

Paragraphe 6 : Exemples d'utilisation Exemple d'utilisation 1 Calcul simple sans accès à une carte à puce Un service SERVICE~PRODUIT est appelé et permet de remonter le résultat du produit de deux paramètres.

Variable Résultat Appel du service

LOG COMPORTEMENT OK SERVICE PRODUIT (4, 5) LOGPRODU) T 20 LOGRESULTAT SERVICE~PRODUIT PAR~IN~PAR1 4
PAR~IN~PAR2 5 LOG~RESULTAT 20 PAR~IN~PAR1*PAR~IN~PAR2 SERVICE~SUIVANT

Il est à noter que le service PRODUIT ne remonte pas d'erreur.

Dans ce cas le compte-rendu OK est déduis automatiquement S'il avait fallu retourner une erreur, (par exemple, pour le cas d'un service SERVICE-QUOTIENT , un dénominateur nul pourrait être une erreur), le champ Access, peut remonter Mauvais paramètre avec l'instruction Return("Mauvais paramètre") dans le champ Access. Cette erreur peut être remontée en testant le paramètre dans le champ Test . Dans ce cas, ce champ peu contenir, par exemple: PAR~IN~PAR2, == ,0.

Exemple d'utilisation 2 : Identification d'une carte à puce Si une carte à puce A est identifiée le résultat du service IDENTIFICATION sera OK : Variable Résultat Appel du service Objet LOGCOMPORTEMENT OK SERVICE-IDENTIFICATION Carte-A Il est à noter qu'il doit exister un fichier Carte~A comportant un service SERVICE~IDENTIFICATION . Ce service peut, par exemple, contenir plusieurs enregistrements : - un dont le Nom est PHYSRESETANSWER pour mettre la carte sous tension (ou accéder à sa réponse au reset) - un dont le Nom peut être PHYSJDENT avec un accès à la carte : champ Access valant Apdu ( 01020304 ).

Si une carte à puce B n'est pas identifiée le résultat du service IDENTIFICATION peut indiquer l'origine du problème :

Variable Résultat Appel du service Objet LOG-COMPORTEMENT Non identifiée SERV)CE) DENT) F) CAT) 0 CarteB Remarque Non identifiée est un exemple de compte-rendu que le service Identification peut remonter. Par ailleurs, ce service n'est pas détaillé.

Exemple d'utilisation 3 : Authentification d'une carte à puce A par une autre carte à puce B Ceci nécessite 3 objets - Un objet Authentification, - Un objet carte à puce A (carte à authentifier) : appelé aussi objet A, - Un objet carte à puce B (carte servant à authentifier) : appelé aussi objet B.

Il est possible, par exemple, de réaliser l'algorithme suivant dans l'objet Authentification.

Demande de données à l'objet B. Il peut disposer d'un service appelé par exemple INIT~AUTHENTIFICATION qui peut demander un nombre aléatoire à la carte A.

Demande de signature de ces données à l'objet A. Il peut disposer d'un service appelé par exemple AUTHENTIFICATION qui peut demander une signature sur le nombre aléatoire.

Demande d'authentification de cette signature (donc de la carte A) par la carte B. L'objet B reçoit la signature et la transmet à la carte B qui authentifie cette signature.

Paragraphe 7 : Applications industrielles possibles On peut constater au travers des exemples précédents que ce logiciel est susceptible d'applications indutrielles pour - Effectuer des calculs (l'exemple du produit de deux nombres est bien sur simpliste). Il est possible de réaliser du traitement de l'information, de la cryptographie, ect...

- En ce qui concerne les cartes à puce, le champ des applications est immense. cartes de santé, cartes bancaires, cartes de fidélité, cartes prépayées, porte- monnaie électronique, cartes d'accès logique à un réseau, notamment < ntemet... Cette liste n'est pas exhaustive.

Le logiciel peut également être utilisé dans des applications informatiques n'utilisant pas de cartes à puce, comme, par exemple, gérer des données informatiques sur un réseau ou un système informatique. La partie gérant une arborescence y est appropriée.

Ce logiciel est évolutif : il est possible de rajouter des commandes dans l'interpréteur de commandes afin de répondre à des besoins industriels particuliers.

Claims

REVENDICATIONS

1 ) Procédé d'exploration de cartes électroniques (1) pouvant être utilisé, notamment, comme Explorateur de cartes à puce (3) caractérisé par la séparation entre : - un fichier exécutable : le gestionnaire de fichiers objets (2) qui interprète des commandes contenus dans des fichiers objets (4) et peut gérer, notamment afficher, l'arborescence de ces objets.

- des fichiers objets (4) qui peuvent contenir du code, des données et une arborescence (des noms de répertoires et de fichiers).

2 ) Procédé d'exploration de cartes électroniques selon la revendication 1 caractérisé par l'affichage sous forme arborescente des données d'une carte à puce.

3 ) Procédé d'exploration de cartes électroniques selon la revendication 1 caractérisé par le fait que le gestionnaire de fichiers objets n'a aucune connaissance de la gestion d'une carte en particulier.

4 ) Procédé d'exploration de cartes électroniques selon l'une quelconque des revendications précédentes est caractérisé par la possibilité de créer de nouveaux objets logiciels permettant de gérer de nouvelles cartes.

5 ) Procédé d'exploration de cartes électroniques selon les revendications 1 et 3 caractérisé par la possibilité d'authentifier des données, (par exemple contenu dans une ou plusieurs cartes à puce) ou une carte à puce, par un algorithme, par exemple contenu dans une ou plusieurs cartes à puce.

6) Procédé d'exploration de cartes électroniques selon les revendications 1 et 3 caractérisé par la possibilité de générer du code informatique en langage C, C++, C# et Java, à partir des fichiers objets logiciels.

7) Produit programme d'ordinateur caractérisé parce qu'il comporte des moyens pour la mise en oeuvre du procédé selon l'une queconque des revendications de une à six.