FR2793979A1

FR2793979A1 - Procede de gestion de donnees par un module de securite

Info

Publication number: FR2793979A1
Application number: FR9906308A
Authority: FR
Inventors: Frederic Mayance
Original assignee: Schlumberger Systemes SA
Current assignee: Axalto SA
Priority date: 1999-05-18
Filing date: 1999-05-18
Publication date: 2000-11-24
Anticipated expiration: 2019-05-18
Also published as: EP1192795A2; CN1143517C; WO2000070842A3; CN1353905A; WO2000070842A2; FR2793979B1

Abstract

L'invention concerne 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é. L'invention se caractérise en ce que ledit procédé comporte des é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. L'invention s'applique, en particulier, à la téléphonie.

Description

PROCEDE DE GESTIONDE DONNEES PARUN MODULE DE SECURITE La présente invention concerne 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é.

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é, qui permettrait 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 l'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.

Ainsi, comme on le verra en détail plus loin, le procédé de gestion de données de l'invention permet 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 figure1 est un schéma montrant un module de sécurité, un terminal et une carte utilisateur.

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

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

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 figure5 est un schéma montrant un emplacement mémoire du module de sécurité de la figure 2.

La figure6 est un schéma montrant une deuxième communication entre le module de sécurité et le terminal de la figure1. Sur la figure1 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 VI. 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 authentificationA 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 authentificationA comprend les étapes décrites ci- après, comme le montre la figure3.

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 identifiantNB. Ledit module renvoie une liste Z-1 de tous les canaux utilisés, avantageusement leur identifiantNB. 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'identifiantNB 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 mêmes 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 Ml, 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 carial associé au troisième emplacement M3. Son compteur RECMAN3 est incrémenté 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émenté 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 même emplacement mémoire M poury 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 modulede 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'identifiantNB 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 etle cas échéant un diversifiant RAND.

Dans une quatrième étape, comme le montre la figure5, on mémorise dans l'emplacement mémoire M associé au canal logique LC alloué, les données contextuellesDATA relativesà l'étape d'authentificationA. les données contextuellesDATA 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'ily a eu une erreur (non représenté).

Si un autre utilisateur utilise une deuxième carte CARD dans un deuxième pupbliphone 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 l'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 cn,ptogramme au moyen de la clef secrète KEY recalculée lors de la troisième étape. Ainsi, la première authentificationA 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 authentificationA qui correspondà la dernière étape de la première authentificationA décrite précédemment.

Ladite deuxième authentificationA prend en compte la valeur de l'abaque ABACUS lue précédemment, l'identifiant ALGOID1 de l'algorithme de signature ALGO1 utilisé et l'identifiant ID de la carte, qui ont été sauvegardés dans l'emplacement mémoire M. Dans le cas où on utilise le même nombre aléatoire RAND, les étapes concernant ledit norribre 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é a-Li canal logique LC alloué, les données contextuellesDATA 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 même pour le nouveau nombre aléatoire RAND, le cas échéant. Si une mise hors-tension du module SAM sur-vient, on effectue de nouveau ladite deuxième authentificationA.

Cette deuxième authentificationA 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 l'emplacement mémoire M associé avec la valeur Vl d'initialisation et on metà jour le compteur chronologique RECMAN. Le cas échéant, on efface les données contextuellesDATA dans l'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'-Liiiités utilisées par type de cartes, de manière optimisée. En effet, comme le montre la figure6, 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 l'emplacement mémoire M après chaque nouvelle deuxième autlientification A. Lorsque la soustraction a été faîte, on remplace la prcmière valeur VO par la deuxième valeur VN mémorisée, pour la dei-i,,.Ième authentificationA suivante. Cette miseà jour est déclenchée au i-noyen d'une troisième commande INCBILLING prenant en compte un identifiant de canalNB 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 con-,extuelles DATA sont mémorisées dans une mémoire volatile RAM.

Claims

REVENDICATIONS 1 - Procédé de gestion de données, par un module de sécurité (SAM), d'une carte (CARD) utilisateur apteà être introduite dans au moins un terminal (P), ladite carte étant soumiseà au moins une authentification(A) par ledit module de sécurité (SAM), caractérisé en ce qu'il comporte les étapes selon lesquelles - on introduit la carte (CARD) dans un terminal (P), - on alloue, dans le module de sécurité (SAM), un canal logique (LC) audit terminal (P), - à chaque authentification(A) de la carte utilisateur (CARD), on mémorise dans un emplacement mémoire (M) associé au canal logique (LC) des données contextuelles(DATA) relativesà l'étape d'authentification(A), ledit emplacement mémoire (M) se trouvant dans une mémoire du module de sécurité (SAM), - on retire la carte (CARD) du terminal (P). 2- Procédé selon la revendication1, caractérisé en ce que la mémoire du module de sécurité (SAM) est une mémoire non volatile (EEPROM). 3 - Procédé selon les revendications1 ou 2, caractérisé en ce qu'on associe le plus ancien emplacement mémoire (M) libreà un canal logique (LC). 4- Procédé selon l'une des revendications précédentes, caractérisé en ce qu'un compteur chronologique (RECMAN) est associéà un emplacement mémoire (M). 5 - Procédé selon les revendications3 et 4, caractérisé en ce l'emplacement mémoire (M) le plus ancien est celui dont la valeur du compteur chronologique (RECMAN) est la plus petite. 6 - Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comporte une étape supplémentaire selon laquelle: - préalablementà l'allocation, on recherche un canal logique (LC) au moyen d'une première commande (GETCHANNELSTATUS). 7 - Procédé selon l'une des revendications précédentes, caractérisé en ce que le module de sécurité (SAM) comporte plusieurs emplacements mémoire (M). 8 - Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comporte une étape supplémentaire selon laquelle: - on ferme le canal logique (LC) associé au terminal (P). 9 - Procédé selon la revendication8, caractérisé en ce que 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). 10 - Procédé selon l'une des revendications précédentes, caractérisé en ce qu'on associe un emplacement mémoire (M)à un canal logique (LC) en inscrivant un identifiant(NB) du canal logique (LC) alloué dans une zone (CN) d'attribution de l'emplacement mémoire (M).