L'invention trouve une application particulièrement avantageuse dans le domaine de la téléphonie.

Dans le domaine de la téléphonie, il existe des systèmes d'administration de terminaux qui comportent un serveur d'administration et des modules de sécurité généralement embarqués dans des concentrateurs connectés auxdits terminaux. Un concentrateur comporte un ordinateur, plusieurs modules de sécurité et une carte électronique avec laquelle sont connectés lesdits modules.

Les terminaux sont appelés téléphones publics.

Un module de sécurité garantit la validité d'une carte utilisateur introduite dans un téléphone public, notamment grâce à une authentification de ladite carte. A cet effet, ladite carte comprend des données secrètes permettant de garantir sa validité. Les systèmes d'administration de téléphones publics ainsi que les données secrètes sont gérés par des opérateurs de téléphonie. Le concentrateur gère plusieurs modules de sécurité, en général une trentaine. Un module de sécurité ne gère qu'un seul téléphone public. La carte électronique permet d'administrer une communication entre les téléphones et le serveur d'administration.

Bien que ce dispositif permette une gestion d'un parc de téléphones publics, il présente l'inconvénient d'tre lourd à administrer.

De plus, le dispositif ainsi mis en place est coûteux pour les opérateurs de téléphonie.

Aussi, un problème technique à résoudre par l'objet de la présente invention est de proposer un procédé de gestion de données, par un module de sécurité, d'une carte utilisateur apte à tre introduite dans au moins un terminal, ladite carte étant soumise à au moins une authentification par ledit module de sécurité, ainsi qu'un module de sécurité, qui permettraient de gérer facilement un parc de terminaux, à moindre coût, et ce en allégeant le dispositif d'administration desdits terminaux.

Une solution au problème technique posé se caractérise, selon un premier objet de la présente invention, en ce que ledit procédé de gestion de données comporte les étapes selon lesquelles : -on introduit la carte dans un terminal, -on alloue, dans le module de sécurité, un canal logique audit terminal, à chaque authentification de la carte utilisateur, on mémorise dans un emplacement mémoire associé au canal logique, des données contextuelles relatives à l'étape d'authentification, ledit emplacement mémoire se trouvant dans une mémoire du module de sécurité, -on retire la carte du terminal.

Selon un second objet de la présente invention, cette solution se caractérise en ce que le module de sécurité comporte : -des moyens d'allocation d'un canal logique audit terminal dans lequel est introduite la carte, -un emplacement mémoire associé au canal logique apte à mémoriser des données contextuelles relatives à chaque étape d'authentification de la carte utilisateur, ledit emplacement mémoire se trouvant dans une mémoire du module de sécurité.

Ainsi, comme on le verra en détail plus loin, le procédé de gestion de données ainsi que le module de sécurité de l'invention, permettent de gérer plusieurs téléphones publics en parallèle au moyen d'un module de sécurité. A cet effet, on mémorise des données contextuelles définissant l'état dans lequel se trouve un ensemble de cartes utilisateurs à un instant donné lors d'une session de connexion desdites cartes, et ce, pour plusieurs téléphones, les données étant sauvegardées dans une mémoire du module de sécurité.

La description qui va suivre au regard des dessins annexés, donnée à titre d'exemple non limitatif, fera bien comprendre en quoi consiste l'invention et comment elle peut tre réalisée.

La figure 1 est un schéma montrant un module de sécurité, un terminal et une carte utilisateur pour la mise en oeuvre du procédé selon l'invention.

La figure 2 est un schéma du module de sécurité de la figure 1 comprenant plusieurs emplacements mémoire.

La figure 3 est un schéma montrant une première communication entre le module de sécurité et le terminal de la figure 1.

Les figures 4a, 4b, 4c, 4d et 4e sont des schémas représentant un emplacement mémoire du module de sécurité de la figure 2.

La figure 5 est un schéma montrant un emplacement mémoire du module de sécurité de la figure 2.

La figure 6 est un schéma montrant une deuxième communication entre le module de sécurité et le terminal de la figure 1.

Le présent exposé de l'invention a trait à l'exemple des cartes à circuit intégré. Par carte à circuit intégré, on entend tout objet portatif, carte au format ISO ou non, module d'identification abonné, étiquette électronique, badge, etc.

On notera que le terme « introduction » d'une carte dans un terminal, employé par la suite, signifie de manière générale

« coopération ». L'invention concerne aussi bien une carte avec une interface à contacts qui nécessite une introduction physique dans le terminal, qu'une carte avec une interface sans contacts qui sont à mme de dialoguer avec le terminal sans contacts physiques avec ce dernier (par radiofréquence...) ou encore une carte comportant les deux interfaces.

Sur la figure 1 est représenté un module SAM de sécurité, un terminal P et une carte utilisateur CARD. Le terminal P est un téléphone public. Le module SAM comprend une mémoire comportant au moins un emplacement mémoire M. Préférentiellement, la mémoire du module de sécurité SAM est une mémoire non volatile EEPROM.

Préférentiellement, le module de sécurité SAM comporte plusieurs emplacements mémoire M. Comme le montre la figure 2, avantageusement, les emplacements mémoire M sont placés de manière contiguë dans un fichier CHANNEL de la mémoire non volatile EEPROM, et, un compteur chronologique RECMAN est associé à un emplacement mémoire M ainsi qu'une zone CN d'attribution. La zone CN d'attribution ainsi que le compteur chronologique RECMAN ont des valeurs initiales respectives V1 et V2. Le module de sécurité SAM comporte également au moins un fichier ISSUER comprenant une clef maître MASTER et un compteur cumulatif CBCPT d'unités.

Avantageusement, le module comporte plusieurs fichiers ISSUER.

Chaque fichier ISSUER correspondant à un type de cartes émises.

Lorsqu'un utilisateur veut téléphoner, il introduit sa carte CARD dans le téléphone public P. Avant d'initier une communication, on effectue une première authentification A au moyen du module SAM de sécurité, par l'intermédiaire du téléphone P puis on établit la communication.

La première authentification A comprend les étapes décrites ci- après, comme le montre la figure 3.

Dans une première étape, on lit un identifiant ID de la carte utilisateur, ledit identifiant étant unique pour chaque carte.

Dans une seconde étape, on recherche un canal logique LC disponible et on alloue, dans le module de sécurité SAM, un canal logique pour le téléphone public P dans lequel la carte utilisateur CARD se trouve. Préalablement à l'allocation, on recherche un canal logique LC au moyen d'une première commande GETCHANNELSTATUS envoyée à partir du téléphone public P au module de sécurité SAM. Un canal logique LC comporte un identifiant NB. Ledit module renvoie une liste de tous les canaux utilisés, avantageusement leur identifiant NB. On déduit les canaux qui sont disponibles et on choisit un des canaux disponibles. Après l'allocation, on associe un emplacement mémoire M au canal logique LC en inscrivant l'identifiant NB du canal logique LC alloué dans la zone CN d'attribution de l'emplacement mémoire M choisi. Ainsi, l'emplacement mémoire M n'est plus libre.

La durée de vie de la mémoire non volatile EEPROM dépend du nombre d'inscriptions effectuées. Afin d'éviter d'associer un emplacement mémoire M de la mémoire non volatile EEPROM à un canal logique LC, par exemple, dans un ordre croissant, et par suite de toujours utiliser les mmes emplacements, on utilise le compteur chronologique RECMAN de chaque emplacement mémoire M de la manière décrite ci-après. Lorsqu'on ferme un canal logique LC, on incrémente la valeur du compteur chronologique RECMAN de l'emplacement mémoire M associé, par rapport à la valeur maximum de tous les compteurs chronologiques des emplacements mémoire M.

L'emplacement mémoire M le plus ancien est celui dont la valeur du compteur chronologique RECMAN est la plus petite. Ainsi, on associe le plus ancien emplacement mémoire M libre à un canal logique LC.

Comme le montre la figure 4a, le fichier CHANNEL comporte quatre emplacements mémoire M1, M2, M3 et M4 utilisés. Leurs compteurs

chronologiques RECMAN ont une valeur d'initialisation V2 égale à zéro.

Dans cet exemple, on incrémente de un la valeur d'un compteur chronologique RECMAN. Comme le montre la figure 4b, on libère le canal associé au troisième emplacement M3. Son compteur RECMAN3 est incréments de un et vaut un. Comme le montre la figure 4c, On libère le canal associé au deuxième emplacement M2. Son compteur RECMAN2 est incréments de un par rapport au troisième compteur. Sa valeur est deux. On libère le canal associé au quatrième emplacement mémoire M4, son compteur RECMAN4 vaut trois, comme le montre la figure 4d. enfin, on alloue un canal logique LC d'identifiant NB3 et on associe le plus ancien emplacement mémoire M libre, soit, comme le montre la figure 4e, le troisième emplacement mémoire M3. Ainsi, le procédé de la présente invention permet, d'une part, d'éviter de toujours choisir un mme emplacement mémoire M pour y inscrire des données comme nous le verrons par la suite, et, d'autre part, de ne pas tre restreint au nombre d'emplacements mémoire M pour le choix d'identifiants de canaux logiques LC à allouer. On peut ainsi avoir le choix entre, par exemple, deux cent cinquante cinq identifiants de canal LC tout en n'ayant que dix emplacements mémoire M.

Bien entendu, ce procédé de gestion de la mémoire décrit ci- dessus, peut s'appliquer à tout autre application que celle de la téléphonie.

Dans une troisième étape, dans le module de sécurité SAM, on recalcule la clef secrète KEY de la carte CARD, à partir de l'identifiant ID de ladite carte et d'une clef maître MASTER dudit module SAM. Cette étape est également appelée étape de diversification de clef. Afin de choisir la clef maître MASTER, dans le module SAM, un fichier ISSUER est sélectionné lors de l'étape de lecture de l'identifiant de la carte utilisateur, la corrélation étant faîte entre le type de cartes et la clef maître au moyen de l'identifiant de ladite carte utilisateur.

L'allocation du canal logique LC et la diversification de clef se font au moyen d'un deuxième commande DIVERSIFYKEY envoyée à partir du téléphone public P au module de sécurité SAM. Ladite deuxième commande prend en compte notamment l'identifiant NB du canal alloué au téléphone public P, un identifiant ALGOID2 d'un algorithme de diversification ALG02, un identifiant de la clef maître MASTER utilisée et le cas échéant un diversifiant RAND.

Dans une quatrième étape, comme le montre la figure 5, on mémorise dans l'emplacement mémoire M associé au canal logique LC alloué, les données contextuelles DATA relatives à l'étape d'authentification A. les données contextuelles DATA comprennent un identifiant ALGOID1 d'un algorithme de signature ALGO1, l'identifiant ID de la carte utilisateur CARD, l'identifiant de la clef maître MASTER utilisée, la clef diversifiée KEY, un abaque ABACUS de la carte utilisateur CARD, et, des données d'état STATE.... L'abaque ABACUS a une première valeur VO. Il permet de comptabiliser les unités utilisées dans la carte utilisateur CARD, les données d'états STATE permettent de gérer dans le module de sécurité SAM une séquence de commandes afin de mémoriser l'état du module SAM à un instant donné, et ce pour un canal logique LC donné. Ainsi, suivant l'état dans lequel on est, on sait quelles sont les commandes autorisées et dans quel état on se trouve après l'exécution d'une des commandes selon le résultat de ladite exécution. Selon un mode de réalisation particulier, le module SAM comporte une table dans laquelle on attribue à chaque état un numéro et un ensemble d'octets. Une commande autorisée est représentée par un des octets. Le premier quartet de l'octet comprend le numéro de l'état dans lequel on se trouve après exécution de la commande, s'il n'y a eu aucune erreur. Le deuxième quartet comprend le numéro de l'état dans lequel on se trouve lorsqu'il y a eu une erreur (non représenté).

Si un autre utilisateur utilise une deuxième carte CARD dans un deuxième pupliphone P, on peut valider la deuxième carte au moyen du module SAM, par exemple, après une première authentification d'une première carte utilisateur. Les données contextuelles de la première carte ne sont pas perdues, on peut continuer à gérer la première carte.

Le procédé de ladite invention, permet ainsi, grâce à cette gestion de données contextuelles par le module de sécurité SAM, d'exécuter différentes sessions d'authentification en parallèle, une session d'authentification correspondant à une durée d'appel et par suite de gérer de multiples téléphones publics P au moyen du module de sécurité SAM, un téléphone public P ayant un canal logique LC alloué et un emplacement mémoire M associé.

Enfin, dans une dernière étape, on envoie un nombre aléatoire RAND à la carte, on mémorise ledit nombre aléatoire dans 1'emplacement mémoire M associé au canal logique LC alloué, on calcule dans la carte un cryptogramme en cryptant la clef secrète KEY au moyen notamment de l'algorithme de signature ALGO1, du nombre aléatoire RAND, et, on envoie le cryptogramme au module de sécurité SAM (non représenté). Dans ledit module SAM, on vérifie la valeur du cryptogramme au moyen de la clef secrète KEY recalculée lors de la troisième étape.

Ainsi, la première authentification A effectuée, la communication peut tre établit. L'abaque ABACUS de la carte est actualisé suivant le nombre d'unités utilisé lors de la communication. On lit la valeur de l'abaque ABACUS afin de vérifier que ledit abaque a bien été actualisé.

Par la suite, on effectue une deuxième authentification A qui correspond à la dernière étape de la première authentification A décrite précédemment.

Ladite deuxième authentification A prend en compte la valeur de l'abaque ABACUS lue précédemment, l'identifiant ALGOID 1 de

l'algorithme de signature ALGO1 utilisé et l'identifiant ID de la carte, qui ont été sauvegardés dans 1'emplacement mémoire M. Dans le cas où on utilise le mme nombre aléatoire RAND, les étapes concernant ledit nombre aléatoire ne sont pas utiles puisque ce dernier est mémorisé dans l'emplacement mémoire M.

Par la suite, on mémorise dans l'emplacement mémoire M associé au canal logique LC alloué, les données contextuelles DATA telles que la nouvelle valeur VN de l'abaque ABACUS, les nouvelles données d'état STATE, et, si nécessaire, le nouveau nombre aléatoire RAND généré, lesdites nouvelles données d'état remplaçant les anciennes. Il en est de mme pour le nouveau nombre aléatoire RAND, le cas échéant. Si une mise hors-tension du module SAM survient, on effectue de nouveau ladite deuxième authentification A.

Cette deuxième authentification A permet de vérifier qu'aucun fraudeur n'a utilisé de carte pirate pour téléphoner. En effet, si un utilisateur introduit une carte frauduleuse, le cryptogramme calculé par ladite carte et renvoyé au module SAM est erroné puisque différent de celui calculé dans ledit module SAM. L'identifiant de la carte frauduleuse est différent de celui de la carte valide antérieurement introduite dans le téléphone public P, ainsi que la valeur de l'abaque ABACUS.

Lorsque la communication est terminée, on retire la carte CARD du téléphone public P. Le canal logique LC alloué n'est plus utile. Aussi, on ferme le canal logique LC associé au terminal P. A cet effet, on initialise la zone CN d'attribution de 1'emplacement mémoire M associé avec la valeur V 1 dtinitialisation et on met à jour le compteur chronologique RECMAN. Le cas échéant, on efface les données contextuelles DATA dans 1'emplacement mémoire M associé au canal logique LC que l'on libère.

Le procédé de la présente invention comporte un avantage selon lequel on comptabilise, dans le module de sécurité SAM, le nombre d'unités utilisées par type de cartes, de manière optimisée. En effet, comme le montre la figure 6, au lieu d'effectuer une mise à jour à chaque unité utilisée, il suffit de mettre à jour le compteur cumulatif CBCPT d'unités d'un fichier ISSUER du module SAM en soustrayant la nouvelle valeur VN de l'abaque ABACUS de la carte de la première valeur VO dudit abaque, la nouvelle valeur VN étant mémorisée dans 1'emplacement mémoire M après chaque nouvelle deuxième authentification A. Lorsque la soustraction a été faîte, on remplace la première valeur VO par la deuxième valeur VN mémorisée, pour la deuxième authentification A suivante. Cette mise à jour est déclenchée au moyen d'une troisième commande INCBILLING prenant en compte un identifiant de canal NB correspondant à un fichier ISSUER et téléphone public P utilisé, ladite commande étant envoyée à partir du téléphone public P au module SAM.

On notera que lorsqu'un téléphone public P comprend ledit module de sécurité SAM, la gestion de canaux décrites ci-dessus ne s'applique pas puisqu'un seul canal logique est utilisé, et, les données contextuelles DATA sont mémorisées dans une mémoire volatile RAM.

Bien entendu, l'invention n'est nullement limitée au domaine de la téléphonie, elle peut s'étendre à d'autres domaines dans lesquels est mis en oeuvre un système d'administration de terminaux, tels que par exemple un système d'administration de parcmètres.