FR2765362A1 - Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires - Google Patents

Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires Download PDF

Info

Publication number
FR2765362A1
FR2765362A1 FR9707996A FR9707996A FR2765362A1 FR 2765362 A1 FR2765362 A1 FR 2765362A1 FR 9707996 A FR9707996 A FR 9707996A FR 9707996 A FR9707996 A FR 9707996A FR 2765362 A1 FR2765362 A1 FR 2765362A1
Authority
FR
France
Prior art keywords
file
link
files
target
security module
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR9707996A
Other languages
English (en)
Other versions
FR2765362B1 (fr
Inventor
Jerome Ajdenbaum
Patrice Hameau
Anne France Presa
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bull CP8 SA
Original Assignee
Bull CP8 SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull CP8 SA filed Critical Bull CP8 SA
Priority to FR9707996A priority Critical patent/FR2765362B1/fr
Priority to TW087109858A priority patent/TW434504B/zh
Priority to ARP980103062A priority patent/AR016092A1/es
Priority to EP98933716A priority patent/EP0944880A1/fr
Priority to BR9806014-7A priority patent/BR9806014A/pt
Priority to KR1019997001615A priority patent/KR20000068374A/ko
Priority to AU83439/98A priority patent/AU8343998A/en
Priority to PCT/FR1998/001344 priority patent/WO1999000774A1/fr
Priority to CA002264896A priority patent/CA2264896A1/fr
Priority to JP11505329A priority patent/JP2000503157A/ja
Priority to CN98800895A priority patent/CN1231042A/zh
Publication of FR2765362A1 publication Critical patent/FR2765362A1/fr
Priority to NO990893A priority patent/NO990893L/no
Application granted granted Critical
Publication of FR2765362B1 publication Critical patent/FR2765362B1/fr
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G06Q20/3576—Multiple memory zones on card
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0806—Details of the card
    • G07F7/0813—Specific details related to card security
    • G07F7/0826—Embedded security module
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
    • G06F12/1425—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block
    • G06F12/1441—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block for a range

Landscapes

  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un module de sécurité coopérant avec un dispositif de traitement de l'information et comportant des moyens de traitement de l'information et des moyens de stockage de l'information, ces derniers stockant plusieurs fichiers.Selon l'invention, le module de sécurité comprend :- des moyens de création de lien agencés pour créer un lien entre au moins un fichier principal (30) et un fichier auxiliaire (31), le fichier principal ayant un contenu déterminé (33) et étant rendu accessible aux moyens de traitement dans les moyens de stockage grâce à des données de localisation (RFC), les moyens de création de lien associant au fichier auxiliaire (31) lesdites données de localisation; et- des moyens de branchement agencés pour mettre à disposition des moyens de traitement, lorsque ceux-ci exécutent une demande d'accès visant à accéder au fichier auxiliaire (31), ledit contenu (33) du fichier principal (30) en utilisant lesdites données de localisation (RFC).

Description

Module de sécurité comportant des moyens de création de liens entre des fichiers
principaux et des fichiers auxiliaires
L'invention est relative à un module de sécurité agencé pour coopérer avec un dispositif de traitement de l'information et comportant des moyens de traitement de l'information et des moyens de stockage de l'information, les moyens de stockage stockant plusieurs fichiers.
Le terme "module de sécurité" doit être pris, soit dans son sens classique dans lequel il désigne un dispositif ayant vocation, dans un réseau de communication ou d'information, à être détenu par un organisme supervisant le réseau et à stocker de façon protégée des paramètres secrets et fondamentaux du réseau tels que des clés cryptographiques, soit comme désignant plus simplement un dispositif attribué à divers usagers du réseau et permettant à chacun d'eux d'avoir accés à celuici, ce dernier dispositif étant lui aussi susceptible de détenir des paramètres secrets. Le module de sécurité pourra prendre la forme d'un objet portatif du type carte à puce.
La présente invention concerne notamment les cartes à microcircuit et, plus généralement les objets portatifs dotés de circuits intégrés comportant au moins un microprocesseur, une mémoire morte (ROM) contenant un système d'exploitation de la carte et une ou plusieurs mémoires non volatiles, programmables par le microprocesseur. Ces mémoires non volatiles permettent de stocker des données et du code.Le microprocesseur contrôle le transfert des informations et, le cas échéant mémorise les données reçues de l'extérieur ou les lit pour les transmettre à l'extérieur. Ces objets possédent un ou plusieurs moyens de communication. Les mémoires peuvent être de technologie EPROM, EEPROM, FeRAM, SRAM ou
FLASH.
Grâce à l'évolution de la technologie, la taille de la mémoire ROM contenant le programme est de plus en plus importante ; ainsi les concepteurs de ce programme peuvent introduire de plus en plus de fonctions. Certaines de ces fonctions se rapportent directement à l'organisation de la mémoire programmable.
Cette mémoire, dont la taille a aussi augmenté, est organisée hiérarchiquement en fichiers indépendants, cette organisation est décrite notamment dans la norme ISO 78164.
De nos jours, les cartes peuvent servir à de multiples applications et pour cela elles possèdent souvent deux ou trois niveaux hiérarchiques appelés par exemple: CARTE, APPLICATION et SERVICE. A chaque niveau, les informations se rapportant à une meme affectation sont regroupées en fichiers, ces fichiers comprenant deux niveaux de stockage , à savoir des "REPERTOIRES" et, dans chaque répertoire, des informations de même nature stockées dans des "FICHIERS DE DONNEES
Cette architecture définie en plusieurs niveaux s'élabore généralement lors de la personnalisation de la carte, c'est-à-dire avant son utilisation. II est possible cependant de rajouter en utilisation d'autres répertoires ou d'autres fichiers de données , mais cela dépend de la place disponible restant dans la mémoire non volatile programmable. Cette mémoire étant de taille limitée, il est important de ne pas gaspiller d'emplacement et de définir lors de la personnalisation uniquement la place nécessaire et suffisante au bon fonctionnement des répertoires et des fichiers de données.
Un excellent moyen de ne pas perdre de place consiste à ne pas dupliquer les informations. Ainsi, il faut éviter que les mêmes informations utiles à plusieurs répertoires soient écrites de façon identique dans plusieurs endroits de la mémoire. Malheureusement, I'architecture hiérarchisée des répertoires empêche de partager un même fichier de données entre plusieurs répertoires. Si deux répertoires doivent posséder les mêmes informations, il n'existe à ce jour que la solution de créer deux fichiers de données comportant ces mêmes informations à l'intérieur. La présente invention résout ce problème en évitant la duplication d'informations communes, tout en conservant les liens hiérarchisés entre fichiers de données et répertoires.
Un autre problème est celui de la mise à jour de fichiers présents en plusieurs endroits de la mémoire : il faut en effet effectuer les modifications nécessaires en chaque endroit. Outre le fait que cette opération est longue, elle peut être perturbée par une interruption accidentelle du fonctionnement de la carte
avec pour conséquence probable une mise à jour incomplète de l'ensemble de ces fichiers , c'est-àlire une mise à jour de certains fichiers, et pas des autres. La cohérence entre tous ces fichiers ne serait plus assurée.
Par ailleurs, la structure en plusieurs niveaux peut pénaliser les temps d'accès à des fichiers de données ou répertoires de bas niveaux. En effet, pour atteindre des données d'un répertoire d'un niveau inférieur, il faut dans de nombreux cas sélectionner tous les répertoires principaux de niveau supérieur.
Par exemple, pour passer d'un répertoire à un autre de même niveau, il faut remonter une arborescence jusqu'à un premier répertoire commun puis redescendre, ceci en sélectionnant des répertoires intermédiaires. Ce mécanisme de sélection successive est lourd et pénalisant en temps.
La présente invention vise à résoudre ces différents problèmes : elle procure un moyen d'éviter la duplication en mémoire de données identiques; elle assure la cohérence d'informations partagées entre plusieurs fichiers ; enfin, elle optimise la recherche d'informations dans des répertoires distants, dans l'arborescence des fichiers de la mémoire.
Elle concerne à cet effet un module de sécurité du genre cité au début de l'exposé, qui comprend:
des moyens de création de lien agencés pour créer un lien entre au moins un fichier principal et un fichier auxiliaire, le fichier principal ayant un contenu déterminé et étant rendu accessible aux moyens de traitement dans les moyens de stockage grâce à des données de localisation, les moyens de création de lien associant au fichier auxiliaire lesdites données de localisation;
des moyens de branchement agencés pour mettre à disposition des moyens de traitement, lorsque ceux ci exécutent une demande d'accès visant à accéder au fichier auxiliaire, ledit contenu du fichier principal en utilisant lesdites données de localisation.
D'autres détails et avantages de la présente invention apparaîtront au cours ae La description suivante une forme ce réalisation préféré mais non limitative, au regard des dessins annexés sur lesquels:
La figure 1 présente une arborescence de plusieurs niveaux hiérarchiques dans une carte;
La figure 2 présente une organisation typique de répertoires et de fichiers de données dans une carte;
La figure 3 présente la structure détaillée de deux catégories fondamentales de fichiers utilisés dans l'invention;
La figure 4 est un organigramme détaillant les étapes d'une procédure de création de fichier selon l'invention ; et
La figure 5 est le schéma d'un module de sécurité auquel est destinée l'invention, coopérant avec un dispositif de traitement de l'information.
Le dispositif de traitement de l'information 51 représenté sur la figure 5 comprend de façon connue en soi un microprocesseur 52 auquel sont reliés une mémoire ROM 53, et une mémoire RAM 54, des moyens 55 pour coopérer, avec ou sans contact physique, avec un module de sécurité 58, et une interface de transmission 57 permettant au dispositif de traitement de l'information de communiquer avec un autre dispositif semblable, soit directement, soit au travers d'un réseau de communication.
Le dispositif 51 peut en outre être équipé de moyens de stockage tels que des disquettes ou disques amovibles ou non, de moyens de saisie (tels qu'un clavier etlou un dispositif de pointage du type souris) et de moyens d'affichage, ces différents moyens n'étant pas représentés sur la figure 5.
Le dispositif de traitement de l'information peut être constitué par tout appareil informatique installé sur un site privé ou public et apte à fournir des moyens de gestion de l'information ou de délivrance de divers biens ou services, cet appareil étant installé à demeure ou portable. II peut notamment s'agir aussi d'un appareil de télécommunications.
Par ailleurs, le module de sécurité 58 inclut des moyens de traitement de l'information 59, une mémoire non volatile 60, une mémoire volatile de travail RAM 64, et des moyens 63 pour coopérer avec le dispositif de traitement de l'information. Ce module est agencé pour définir, dans la mémoire 60, une zone secrète 61 dans laquelle des informations une fois enregistrées, sont inaccessibles depuis l'extérieur du module mais seulement accessibles aux moyens de traitement 59, et une zone libre 62 qui est accessible depuis l'extérieur du module pour une lecture etlou une écriture d'informations. Chaque zone de la mémoire non volatile 60 peut comprendre une partie non modifiable ROM et une partie modifiable EPROM, EEPROM, ou constituée de mémoire RAM du type "flash", c'est-à-dire présentant les caractéristiques d'une mémoire EEPROM avec en outre des temps d'accès identiques à ceux d'une RAM classique.
En tant que module de sécurité 58, on pourra notamment utiliser un microprocesseur à mémoire non volatile autoprogrammable, tel que décrit dans le brevet américain n" 4.382.279 au nom de la Demanderesse. Comme indiqué en colonne 1, lignes 13-25 de ce brevet, le caractère autoprogrammable de la mémoire correspond à la possibilité pour un programme fi situé dans cette mémoire, de modifier un autre programme fi situé également dans cette mémoire en un programme gj. Bien que les moyens à mettre en oeuvre pour réaliser cette autoprogrammation puissent varier selon la technique utilisée pour concevoir les moyens de traitement de l'information 59, on rappelle que, dans le cas où ces moyens de traitement sont constitués par un microprocesseur associé à une mémoire non volatile et selon le brevet précité, ces moyens peuvent inclure:
-des mémoires tampon de données et d'adresses, associées à la mémoire;
-un programme d'écriture dans la mémoire, chargé dans celle et contenant notamment les instructions permettant le maintien d'une part de la tension de programmation de la mémoire, et d'autre part des données à écrire et de leurs adresses, pendant un temps suffisant, ce programme d'écriture pouvant toutefois être remplacé par un automate d'écriture à circuits logiques.
Dans une variante, le microprocesseur du module de sécurité 58 est remplacé -ou tout du moins complété- par des circuits logiques implantés dans une puce à semi-conducteurs. En effet, de tels circuits sont aptes à effectuer des calculs, notamment d'authentification et de signature, grâce à de l'électronique câblée, et non microprogrammée. Ils peuvent notamment être de type ASIC (de l'anglais Application Specific Integrated Circuit ). A titre d'exemple, on peut citer le composant de la société SIEMENS commercialisé sous la référence SLE 4436 et celui de la société SGS-THOMSON commercialisé sous la référence ST 1335.
Avantageusement, le module de sécurité 58 sera conçu sous forme monolithique sur une seule puce.
En variante au microprocesseur à mémoire non volatile autoprogrammable décrit ci-dessus, le caractère sécuritaire du module de sécurité pourra résulter de sa localisation dans une enceinte inviolable.
La mémoire non volatile des cartes est organisée en fichiers qui peuvent être, comme rappelé précédemment, de deux types . répertoire ou fichier élémentaire de données. Chaque fichier élémentaire comprend un en-tête et un corps contenant des informations. Le niveau de hiérarchisation est précisé dans l'en-tête, on y trouve également les références du fichier, I'état ou phase de vie de
la carte, les conditions d'accés et la taille. En règle générale, I'en-tête contient l'ensemble des informations qui permettent de gérer les informations stockées dans le corps. Deux ou trois niveaux sont actuellement utilisés. En référence à la figure 1, et en général, le niveau supérieur est appelé "CARTE", et les niveaux inférieurs "APPLICATION" ou "SERVICE". On peut parfaitement envisager des cartes avec plus de trois niveaux; dans l'exemple cité, trois niveaux sont décrits.
A titre d'exemple, une même carte peut être utilisée pour diverses applications telles que : la banque, la municipalité, le dossier médical, le radiotéléphone cellulaire, qui sont représentées par des répertoires de niveau
APPLICATION. Dans l'application municipale, on trouve des parties telles que les transport publics, L'accès à la piscine et à la bibliothèque, le paiement du stationnement, qui sont représentées par des répertoires de niveau SERVICE.
La figure 2 illustre un exemple des liens hiérarchisés entre des fichiers dans la mémoire programmable d'une carte. Le répertoire CARTE contient deux répertoires APPLICATION 1 et 2 et le fichier élémentaire CI. Le répertoire
APPLICATION I contient deux répertoires SERVICE A1-S1 et A1-S2 et le fichier élémentaire Ai-l. Le répertoire SERVICE A1-S2 possède un seul fichier élémentaire de données : A1S1-1. Le répertoire APPLICATION 2 possède deux répertoires SERVICE A2-S1 et A2-S2. Le répertoire SERVICE A2-S1 possède deux fichiers élémentaires de données : A2S1-1 et A2SI -2. Le répertoire SERVICE
A2-S2 possède un fichier élémentaire de données : A2S2-1. Tous ces fichiers occupent une place non négligeable dans la mémoire limitée de la carte, il est donc important d'optimiser l'occupation mémoire et d'éviter de dupliquer les mêmes informations dans plusieurs emplacements différents.
Dans certains cas, les mêmes informations sont utilisées par deux répertoires différents. Par exemple, les coordonnées bancaires d'un individu porteur d'une carte: nom et adresse du porteur, nom et coordonnées de la banque, numéro de compte, information sur le crédit ...etc. peuvent être stockées dans un fichier élémentaire, inclus dans le répertoire correspondant à l'application bancaire, par exemple le fichier élémentaire Al-l dans le répertoire
APPLICATION 1, décrit dans la figure 2.
La carte peut aussi servir de carte-ville ; cette application est gérée par le répertoire APPLICATION 2. Elle permet notamment de payer les transports en commun, d'accéder à la bibliothèque municipale et à certaines activités culturelles payantes (théatre, cinéma...). Ces services sont gérés par les deux répertoires
SERVICE A2-S1 et A2-S2, hiérarchiquement dépendants du répertoire
APPLICATION 2. Lorsque la carte sert de moyen de paiement, pour payer par exemple les trajets effectués dans les transports en commun, I'argent est débité directement sur le compte bancaire dont les coordonnées sont précisées dans le fichier élémentaire Al-l. II faut donc rendre accessible depuis le répertoire
SERVICE A2-SI du répertoire APPLICATION 2, les informations du fichier élémentaire Al-i de APPLICATION 1. Cet accès est symbolisé par la flèche sur la figure 2. La solution consistant à reproduire les données n'est pas satisfaisante.
Un autre exemple concerne les clés secrètes et les codes confidentiels leurs valeurs peuvent être identiques lors de l'accès à différentes répertoires qui ne sont pas hiérarchiquement dépendants. Le problème est important si des clés de type RSA ( des inventeurs Rivest, Shamir et Adleman) stockées sur plus de 1024 bits sont utilisées. Un dernier exemple concerne les fichiers élémentaires de ratification : ces fichiers élémentaires servent à mémoriser les bonnes ou mauvaises présentations de clés ou codes. Le regroupement de plusieurs fichiers élémentaires de ratification correspondant à des clés différentes permet de gagner de la place et d'accroître la sécurité.
Une façon de réaliser l'invention consiste à créer et gérer des fichiers dits "Lien" dont le corps est confondu avec celui d'autres fichiers. L'invention consiste à pouvoir partager un même corps de fichier entre plusieurs fichiers. Ceci peut être réalisé en indiquant, soit dans l'en-tête du fichier, soit dans son corps, L'adresse où se situent effectivement les données.
Sur la figure 3, sont représentés deux fichiers, à savoir un fichier-cible 30 et un fichier-lien 31. La description qui suit concerne aussi bien le cas où ces fichiers sont des fichiers de données et celui où ils représentent des répertoires. Ces répertoires contiennent soit une arborescence de sous-répertoires donnant accès à des fichiers de données, soit des fichiers de données qui leur sont directement rattachés, soit les deux. Le terme données regroupe à la fois des données non exécutables et des données exécutables ou programmes.
Le fichiercible 30 est organisé, dans cet exemple, en deux parties comprenant un en-tête 32 et un corps 33. L'en-tête 32 inclut un premier groupe de paramètres connus en eux-mêmes, à savoir:
-un type, qui indique si le fichier est un répertoire ou bien un fichier de
données;
-un identifiant qui désigne le fichier au sein d'un répertoire qui le contient; il
s'agit par exemple d'un nom ou d'un numéro; et
-des conditions d'accès qui donnent une liste de droits d'accès à ce fichier
déterminé, pour tout usager : elles précisent par exemple si le fichier est
accessible ou non en lecture ou écriture ; de façon connue en soi, la
délivrance de ces droits peut être subordonnée à la présentation de clés ou
mots de passe.
L'en-tête 32 inclut un second groupe de paramètres qui sont spécifiques à l'invention, à savoir:
-un paramètre < Lien > qui peut prendre deux valeurs : soit la valeur 1, qui
indique que ce fichier est un fichier-lien soit la valeur 0 qui indique qu'il n'est
pas un fichier-lien; ici, ce paramètre a la valeur 0;
-un paramètre > Lien < qui peut prendre deux valeurs : soit la valeur 1, qui
indique que ce fichier est un fichier-cible, soit la valeur 0 qui indique qu'il
n'est pas un fichier-cible; ici, ce paramètre a la valeur i
-un paramètre A-Lien qui peut prendre deux valeurs : soit la valeur 1, qui
indique que ce fichier peut être lié à un fichier-lien , soit la valeur 0 qui l'en
empêche; et
-un paramètre CA-Lien qui définit des conditions de création que l'usager
devra respecter lorsqu'il voudra créer un lien entre ce fichier et un fichier
lien : elles pourront par exemple définir des clés ou mots de passe à
présenter par l'usager.
L'en-tête 32 comporte enfin une référence RC indiquant au microprocesseur de la carte une valeur binaire d'une adresse mémoire RC à partir de laquelle est stocké le corps 33 précité.
Dans une variante, le corps 33 est stocké en mémoire immédiatement à la suite de l'en-tête 32, de sorte que la mention de la référence RC n'est pas nécessaire.
Par ailleurs, si le fichier cible 30 est du type répertoire le corps 33 contient soit une arborescence de sous-répertoires donnant accès à des fichiers de données, soit des fichiers de données qui lui sont directement rattachés, soit les deux;
Si au contraire le fichier-cible 30 est du type fichier de données , le corps 33 contient un ensemble de données directement accessibles pour lecture ou modification, ou exécutables par le microprocesseur de la carte.
En variante,l'organisation du fichier-cible 30 pourra être différente de celle en deux parties (en-tête et corps) présentée sur la figure 3. Ainsi par exemple, les paramètres de l'en-tête 32 pourront être répartis en des endroits spécifiques du corps.
Quant au fichier-lien 31, il ne comprend qu'une seule partie, à savoir un entête qui présente la même structure que celui 32 du fichier-cible 30, mais a un contenu qui en diffère de la façon suivante:
-s'agissant d'un fichier-lien, et non d'un fichier-cible, les paramètres A-Lien et CA-Lien ne sont en général pas utilisés, sauf dans le cas particulier décrit plus loin;
-par ailleurs, la référence n'est pas celle relative à un éventuel corps rattaché au fichier-lien , mais une référence RFC précisant la localisation en mémoire d'un fichier-cible ainsi lié à ce fichier-lien. Dans cet exemple , c'est le fichier-cible 30. La référence RFC est soit de préférence physique et constituée par une valeur binaire d'une adresse mémoire à partir de laquelle est stocké le fichier-cible 32 précité, soit en variante logique et constituée par un chemin d'accès précisant les identifiants d'un ou plusieurs répertoires à partir desquels le fichier-cible 32 est accessible.
Dans le cas très particulier d'une gestion dynamique de la mémoire de la carte, celle-ci peut être ré-organisée par le microprocesseur afin d'optimiser l'occupation de la mémoire. L'emplacement des fichiers peut donc fluctuer, ainsi par conséquent que leurs adresses d'implantation. Dans ce cas, seule la référence logique du fichier-cible est facilement utilisable car les adresses physiques risquent de constamment changer. En prenant comme exemple le cas évoqué précédemment, la référence logique est: [CARTE g APPLICATION 1 e Fichier de données Ai-l].
II apparaît donc qu'un fichier-lien est dépourvu de corps, mais est lié à un fichier-cible déterminé, dont le corps sera ainsi mis à disposition du fichier-lien.
On notera que, dans un cas particulier, un second fichier-lien, différent du fichier-lien 31, pourrait être lié, non pas directement à un fichier-cible , mais par exemple au fichier-lien 31. La situation serait alors la suivante:
-la référence contenue dans le second fichier-lien serait celle du fichier-lien 31;
-le paramètre CA-Lien serait avantageusement utilisé dans l'en-tête du premier fichier-lien pour contrôler les conditions de création du second fichier-lien.
En fonctionnement, lors de la sélection d'un fichier par l'usager, un programme du microprocesseur lit son en-tête et teste son paramètre < Lien > . S'il est égal à 0, le fonctionnement est conforme à l'art antérieur : le corps estdirectement rattaché à cet en-tête.
Si < Lien > est égal à 1, le fichier est un fichier-lien. Le programme lit en conséquence la référence RFC de ce fichier-lien précisant l'adresse ou le chemin d'accès d'un fichier-cible contenant un corps indirectement rattaché à l'en-tête du fichier-lien. Avant de mettre à disposition de l'usager ou du microprocesseur le contenu du corps du fichier-cible , le programme effectue les vérifications suivantes, en consultant les en-têtes respectifs du fichier-lien et du fichier-cible:
-lors de la création du fichier-lien, il vérifie que le type du fichier-cible identifié est identique à celui du fichier-lien ; dans la négative, la procédure d'accès au fichier-lien est interrompue;
-lors de chaque accès au fichier-cible, il vérifie le respect des conditions d'accès selon une procédure qui sera précisée plus loin.
Ces vérifications étant effectuées, le programme poursuit sa procédure d'accès au contenu du fichier-lien.Si la taille du corps du fichier-cible est zéro octet , c'est-à-dire s'il ne contient rien, le programme s'interrompt et la carte renvoie un message d'erreur. Sinon, le programme recherche les informations contenues dans ce corps, à partir de l'adresse RC.. En reprenant l'exemple de la figure 2, on suppose que le fichier Al-l du répertoire de l'application 1 a été créé sous forme de fichier-cible, et que les fichiers A2S1-1, A2S1-2, A2S2-1 des répertoires service A2-S1 et A2-S2 ont été créés sous forme de fichiers-lien. En conséquence, la sélection d'un fichier-lien tel que A2S1-1 donnera accès au contenu du fichier-cible Ai-l.
Les conditions d'accès au corps du fichier-Cible, définies dans l'en-tête de celui-ci, doivent dans tous les cas être respectées, lors de l'exécution d'un lien entre fichier-lien et fichier-cible . Plusieurs stratégies sont possibles. La plus simple consiste à obéir aux conditions d'accès définies dans l'en-tête du fichier
Cible ainsi l'accès des informations dans le fichier-Cible via le fichier-lien n'est accordé que si les conditions d'accès du fichier-Cible sont respectées.
Une autre stratégie consiste à prendre en compte les conditions d'accès du fichier-Cible lors de la création du fichier-lien. II faut alors vérifier que les conditions d'accès inscrites dans l'en-tête du fichier-lien incluent toutes les conditions d'accès du fichier-Cible auquel il va être lié.
Une troisième stratégie est applicable lorsque les conditions d'accès s'expriment sous la forme d'une valeur binaire : elle consiste à cumuler les deux conditions d'accès. Concrètement, cette opération peut être réalisée en effectuant un ET logique entre les deux valeurs. L'accès des informations dans le fichier
Cible via le fichier-lien n'est accordé que si, à la fois, les conditions d'accès des fichiers-Cible et lien sont respectées.
A travers ces différentes stratégies, le lecteur comprend que l'objectif, au niveau du contrôle d'accès, consiste à proscrire toute possibilité de contourner les conditions d'accès d'un fichier en le liant à un fichier qui possède des conditions d'accès plus favorables. D'autres stratégies, connues de l'homme du métier, pourront être utilisées pour assurer la sécurité d'accès.
Un perfectionnement important concernant la sécurité consiste à utiliser le paramètre A-Lien d'un fichier-cible pour l'empêcher d'être lié à un autre fichier . Si la valeur de ce paramètre est "1", lors de la création d'un fichier-lien rattaché à ce fichier-cible ,l'opération est menée à bien et le contenu du corps du fichier-Cible est bien accessible par le fichier-lien. Si en revanche la valeur de ce champ est "O", ce fichier-cible ne peut être lié à aucun autre. Lors d'une tentative de création d'un fichier-lien désignant un fichier dont le champ A-Lien égal à "0", I'opération est refusée et la carte rend un message d'erreur.
Un problème se pose lors de l'effacement, c'est-à-dire de la suppression de fichiers Lien/Cible. Si un fichier-Cible est effacé, l'accès par des fichiers-Liens aux informations qu'il contenait n'est plus possible. Les conséquences d'un tel effacement ne sont donc pas uniquement limitées au répertoire qui contenait ce fichier, mais peuvent se répercuter dans d'autres répertoires. La solution consiste soit à interdire l'effacement du fichier-Cible auquel est rattaché un ou plusieurs fichiers-Lien, soit à avertir l'utilisateur de la carte que certains fichiers ne sont plus opérationnels après cet effacement. Un première méthode consiste donc à tester la valeur > Lien < . Si cette valeur est 1, le fichier que l'on est en train d'effacer est un fichier-Cible. L'opération est alors soit interdite, soit menée à bien mais avec un avertissement ; dans ce dernier cas, le terminal de commande de la carte doit effacer tous les fichiers-Lien liés au fichiercible effacé.
Pour effacer un fichier-Cible sans perturber le reste de la mémoire, il faut donc préalablement effacer tous les fichiers-Lien qui lui sont rattachés. Lorsque le dernier fichier-Lien est effacé, I'indicateur > Lien < prend la valeur "0": il ne s'agit donc plus d'un fichier-Cible. Un simple indicateur binaire n'est donc pas suffisant pour comptabiliser le nombre de fichiers-Lien sans devoir balayer chaque fois toute la mémoire non volatile de la carte . Une solution consiste à prévoir un compteur Cp-Lien à la place du paramètre > Lien < . Avantageusement, ce compteur est de 8 bits, ce qui autorise l'existence de 255 fichiers-Liens au maximum : ce nombre paraît largement suffisant pour des applications courantes. Ce compteur est incorporé dans l'en-tête du fichier-cible.
Lors de la création du fichier-cible, le compteur Cp-Lien est mis à "00". A chaque nouvelle création d'un fichier-Lien qui est rattaché au fichiercible , le compteur est incrémenté. A chaque effacement d'un fichier-Lien qui lui est rattaché, le compteur est décrémenté. Avantageusement, lors de la sélection de ce fichier-cible, la valeur du compteur peut être émise avec les autres information d'en-tête: I'utilisateur peut ainsi connaître le nombre de fichiers-Lien rattachés au fichier-cible sélectionné.
Pour résoudre le problème de l'effacement d'un fichier-Cible de façon plus adroite, le programme de la carte est équipé d'une commande, activable de l'extérieur de la carte, permettant d'échanger les statuts respectifs lien </R des en-têtes. Pour des raisons de sécurité, I'exécution de cette commande est soumise à la vérification des conditions d'accès définies dans l'en-tête de l'ancien fichier-cible, et éventuellement à la vérification des conditions de création de liens entre fichiers, définies par le paramètre CA-Lien dans le répertoire du nouveau fichier-cible . Lors de l'exécution de cette commande d'échange, la valeur du compteur CP-Lien de l'ancien fichier-Cible est mémorisée dans le compteur CP
Lien du nouveau fichier-Cible.
La figure 4 illustre un procédé de création d'un fichier, qu'il s'agisse d'un fichier-lien ou non. II inclut, outre des étapes spécifiques à l'invention et relatives au fichier-lien, certaines étapes connues en elles-mêmes et relatives à la création de tout fichier, quelle que soit sa nature. A l'étape 1, un ordre de création de fichier est reçu par la carte, accompagné de données de création : ces données définissent notamment le type et l'identifiant du fichier à créer et, s'il s'agit d'un fichier-lien, la référence RFC (figure 3) d'un fichier-cible auquel il doit être lié.
Ensuite, le système d'exploitation de la carte vérifie que la création d'un nouveau fichier est possible dans le répertoire actuel, appelé aussi "courant" (étape 2). En effet, la création d'un nouveau fichier est éventuellement soumise à la bonne présentation préalable de clés définies par les conditions d'accès de l'entête du répertoire courant. Puis, on vérifie qu'il reste suffisamment de mémoire dans le répertoire courant pour contenir le nouveau fichier (étape 3). Si un de ces tests est négatif, L'ordre de création est interrompu (étape 13), et la carte renvoie alors un message correspondant à l'origine de l'arrêt.
Le système d'exploitation teste ensuite s'il s'agit de la création d'un fichier normal ou de la création d'un fichier-Lien (étape 4). Une différence importante entre un fichier normal et un fichier-lien, et sur laquelle peut porter le test réside dans les données de création, et principalement dans l'indication précise de la localisation du fichier-Cible (adresse physique ou logique). Si ce n'est pas un fichier-Lien, le programme saute directement à l'étape 12 décrite ci-après. Dans le cas contraire, les informations correspondant au fichier-Cible désigné sont recherchées et analysées à l'étape 5 ; puis le système d'exploitation effectue un certain nombre de tests pour s'assurer que le lien entrele fichier-cible désigné et le fichier-lien à créer est possible.
Tout d'abord, on vérifie à l'aide des données de création que le fichier-Cible existe bien (étape 6). Si par contre, ces données ne correspondent à aucun fichier,
I'opération de création est interrompue et la carte envoie un message d'erreur (étape 13). A l'étape 7, le paramètre A-Lien du fichier Cible localisé est testé. Si sa valeur est "1", I'opération peut être menée à bien. Sinon, le fichier-Cible ne peut être lié à aucun autre. L'opération de création est alors interrompue et la carte envoie un message d'erreur. A l'étape 8, le système d'exploitation teste si les éventuelles clés définies dans les conditions de création du fichier-Lien, c'est à dire définies par le paramètre CA-Lien du fichier-Cible, ont été préalablement présentées. Si ce n'est pas le cas, I'opération de création est interrompue.
A l'étape 9, le système d'exploitation de la carte vérifie que les types de fichiers et les conditions d'accès aux informations sont compatibles. Pour cela, le paramètre TYPE du fichier-Cible est comparé à celui transmis dans les données de création. Si les valeurs sont différentes, ou du moins incompatibles, comme par exemple dans le cas d'un ordre de création visant à faire un lien entre un fichier de données et un répertoire, ou un lien entre un fichier de données de type "public" et un fichier de données de type "secret", alors l'opération de création est interrompue et la carte envoie un message d'erreur. Ce test est facultatif car une autre solution consiste à forcer les données reçues pour le fichier-Lien à créer, à la même valeur que celles du fichier Cible désigné: la compatibilité est dans ce cas certaine.
Enfin, un dernier test effectué porte sur les conditions d'accès aux informations contenues dans le fichier-Cible (étape). II s'agit d'éviter de contourner les conditions d'accès du fichier-Cible par un fichier-Lien qui possèderait des conditions d'accès plus favorables. Une des stratégies décrites précédemment consiste à interdire la création d'un fichier-Lien possédant des conditions d'accès moins restrictives que celles du fichier-Cible : I'opération de création est alors interrompue et la carte envoie un message d'erreur (étape 13).
Une autre stratégie consiste à aménager, et donc modifier, des conditions d'accès trop favorables du fichier-lien pour les rendre au moins aussi restrictives que celles du fichier-Cible. Dans ce cas, le test de l'étape 10 devient une opération de calcul avec modification, si besoin, des conditions d'accès transmises dans la commande.
Une fois les étapes de test franchies, la création du fichier-Lien peut intervenir. A l'étape 11, I'en-tête du fichier-Cible est mise à jour. Cela concerne principalement le paramètre > Lien < ou Cp-Lien. S'il s'agit du paramètre > Lien < , le programme vérifie qu'il possède la valeur à "1", ou sinon le met à cette valeur.
S'il s'agit au contraire du compteur Cp-Lien, celui-ci est incrémenté d'une unité.
Enfin à l'étape 12, un nouveau fichier est effectivement créé, et les valeurs des paramètres d'en-tête de ce fichier sont déterminées en mémoire de travail à partir des données de création. Ces valeurs sont écrites en mémoire programmable non volatile. Si c'est un fichier-Lien qui est créé, une référence liée à la localisation du fichier-Cible (adresse physique ou logique) est écrite. Une fois toutes ces étapes franchies, la carte rend un message d'état correct et le fichier nouvellement créé est opérationnel.
Le cas de la création d'un fichier-Cible ne sera pas détaillé, puisque, lors de sa création, ce fichier est analogue à un fichier classique. Ce n'est qu'au moment où il est lié à un fichier-lien qu'il devient un fichier-cible effectif.
Une application particulièrement intéressante de l'invention et relative aux répertoires-lien est celle où un répertoire porte-monnaie électronique est utilisé par la carte pour permettre des paiements. Ce répertoire contient des fichiers élémentaires contenant des clés, des zones débit-crédits, des zones de validation de mot de passe, etc... Un tel répertoire peut être utilisé dans diverses applications (transport, restaurant, centrale d'achats) : chacune d'elles doit donc contenir un répertoire-lien lié au répertoire porte-monnaie électronique, lequel devient alors un répertoire-cible.

Claims (6)

  1. REVENDICATIONS
    -des moyens de branchement agencés pour mettre à disposition des moyens de traitement, lorsque ceux-ci exécutent une demande d'accès visant à accéder au fichier auxiliaire (31), ledit contenu (33) du fichier principal (30) en utilisant lesdites données de localisation (RFC).
    -des moyens de création de lien agencés pour créer un lien entre au moins un fichier principal (30) et un fichier auxiliaire (31), le fichier principal ayant un contenu déterminé (33) et étant rendu accessible aux moyens de traitement dans les moyens de stockage grâce à des données de localisation (RFC), les moyens de création de lien associant au fichier auxiliaire (31) lesdites données de localisation
    1. Module de sécurité agencé pour coopérer avec un dispositif de traitement de l'information et comportant des moyens de traitement de l'information et des moyens de stockage de l'information, les moyens de stockage stockant plusieurs fichiers, caractérisé en ce qu'il comprend:
  2. 2. Module de sécurité selon la revendication 1, dans lequel le fichier auxiliaire (31) contient un paramètre ( < lien > ) indiquant qu'il contient des données de localisation d'un fichier principal (30).
  3. 3. Module de sécurité selon la revendication 1, dans lequel le fichier principal (30) contient un paramètre ( > lien < ) indiquant que ses données de localisation (RFC) sont associées à au moins un fichier auxiliaire (31).
  4. 4. Module de sécurité selon la revendication 3, dans lequel ledit paramètre ( > lien < ) est une valeur d'un compteur (Cp-Lien) agencé pour compter un nombre de fichiers auxiliaires.(31) qui sont liés à ce fichier principal (30).
  5. 5. Module de sécurité selon la revendication 1, dans lequel le fichier principal (30) contient un paramètre (A-Lien) indiquant si la mise à disposition de son contenu lors d'une demande d'accès au fichier auxiliaire (31) est autorisée ou non.
  6. 6. Module de sécurité selon la revendication 1, dans lequel le fichier principal (30) contient un paramètre (CA-Lien) définissant des conditions de création à respecter par les moyens de traitement lors de la création d'un lien avec un fichier auxiliaire (31) déterminé.
FR9707996A 1997-06-26 1997-06-26 Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires Expired - Fee Related FR2765362B1 (fr)

Priority Applications (12)

Application Number Priority Date Filing Date Title
FR9707996A FR2765362B1 (fr) 1997-06-26 1997-06-26 Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires
TW087109858A TW434504B (en) 1997-06-26 1998-06-19 The relation creation device of the security module concerning the relations between the principal sets of cards and auxiliary sets of cards
JP11505329A JP2000503157A (ja) 1997-06-26 1998-06-25 メインファイルと補助ファイルとの間にリンク生成手段を備えたセキュリティモジュール
BR9806014-7A BR9806014A (pt) 1997-06-26 1998-06-25 Módulo de segurança compreendendo meios de criação de ligações entre arquivos principais e arquivos auxiliares.
KR1019997001615A KR20000068374A (ko) 1997-06-26 1998-06-25 메인 파일과 보조 파일간의 링크를 생성하는 수단을 구비하는 보안 모듈
AU83439/98A AU8343998A (en) 1997-06-26 1998-06-25 Security module comprising means generating links between main files and auxi liary files
ARP980103062A AR016092A1 (es) 1997-06-26 1998-06-25 Un modulo de seguridad que incluye medios de creacion de nexo entre archivos principales y archivos auxiliares.
CA002264896A CA2264896A1 (fr) 1997-06-26 1998-06-25 Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires
EP98933716A EP0944880A1 (fr) 1997-06-26 1998-06-25 Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires
CN98800895A CN1231042A (zh) 1997-06-26 1998-06-25 有在主文件和辅助文件之间产生链接的方法的保密模块
PCT/FR1998/001344 WO1999000774A1 (fr) 1997-06-26 1998-06-25 Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires
NO990893A NO990893L (no) 1997-06-26 1999-02-25 Sikkerhetsmodul omfattende midler for generering av lenker mellom filer og hjelpefiler

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR9707996A FR2765362B1 (fr) 1997-06-26 1997-06-26 Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires

Publications (2)

Publication Number Publication Date
FR2765362A1 true FR2765362A1 (fr) 1998-12-31
FR2765362B1 FR2765362B1 (fr) 2001-08-17

Family

ID=9508465

Family Applications (1)

Application Number Title Priority Date Filing Date
FR9707996A Expired - Fee Related FR2765362B1 (fr) 1997-06-26 1997-06-26 Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires

Country Status (12)

Country Link
EP (1) EP0944880A1 (fr)
JP (1) JP2000503157A (fr)
KR (1) KR20000068374A (fr)
CN (1) CN1231042A (fr)
AR (1) AR016092A1 (fr)
AU (1) AU8343998A (fr)
BR (1) BR9806014A (fr)
CA (1) CA2264896A1 (fr)
FR (1) FR2765362B1 (fr)
NO (1) NO990893L (fr)
TW (1) TW434504B (fr)
WO (1) WO1999000774A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1764699A1 (fr) * 2004-06-14 2007-03-21 Sony Corporation Dispositif de gestion d'informations et procede de gestion d'informations
EP3435237A4 (fr) * 2016-03-23 2019-01-30 Sony Corporation Dispositif de traitement d'informations et procédé de traitement d'informations

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4565703B2 (ja) * 2000-05-16 2010-10-20 グローリー株式会社 データ記憶装置およびデータ記憶方法
JP5124733B2 (ja) * 2006-04-25 2013-01-23 キヤノンＩｔソリューションズ株式会社 サーバ装置および情報共有システムおよびプログラムおよび記録媒体
CN102306170A (zh) * 2011-08-23 2012-01-04 北京握奇数据系统有限公司 一种存储及处理智能卡公共信息的方法及装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0332117A2 (fr) * 1988-03-09 1989-09-13 Kabushiki Kaisha Toshiba Appareil électronique portatif
US4960982A (en) * 1987-04-09 1990-10-02 Mitsubishi Denki Kabushiki Kaisha IC card with secure mass storage memory
EP0666550A1 (fr) * 1994-02-08 1995-08-09 Eduard Karel De Jong Système d'échange de données avec des unités de traitement de données portatives
US5479509A (en) * 1993-04-06 1995-12-26 Bull Cp8 Method for signature of an information processing file, and apparatus for implementing it
US5497418A (en) * 1992-10-09 1996-03-05 Nagra Plus S.A. Data processing system having a set of memory cards
GB2295909A (en) * 1994-12-07 1996-06-12 Fujitsu Ltd Managing files shared by users

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3017736B2 (ja) * 1988-03-09 2000-03-13 株式会社東芝 携帯可能電子装置
JPH04373040A (ja) * 1991-06-21 1992-12-25 Fujitsu Ltd ファイル管理方式
JPH0756781A (ja) * 1993-08-20 1995-03-03 Fujitsu Ltd ファイル管理方式
JPH0778098A (ja) * 1993-09-08 1995-03-20 Fujitsu Ltd ファイル管理システム
JPH07262214A (ja) * 1994-03-18 1995-10-13 Hitachi Ltd リンク情報管理方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4960982A (en) * 1987-04-09 1990-10-02 Mitsubishi Denki Kabushiki Kaisha IC card with secure mass storage memory
EP0332117A2 (fr) * 1988-03-09 1989-09-13 Kabushiki Kaisha Toshiba Appareil électronique portatif
US5497418A (en) * 1992-10-09 1996-03-05 Nagra Plus S.A. Data processing system having a set of memory cards
US5479509A (en) * 1993-04-06 1995-12-26 Bull Cp8 Method for signature of an information processing file, and apparatus for implementing it
EP0666550A1 (fr) * 1994-02-08 1995-08-09 Eduard Karel De Jong Système d'échange de données avec des unités de traitement de données portatives
GB2295909A (en) * 1994-12-07 1996-06-12 Fujitsu Ltd Managing files shared by users

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1764699A1 (fr) * 2004-06-14 2007-03-21 Sony Corporation Dispositif de gestion d'informations et procede de gestion d'informations
EP1764699A4 (fr) * 2004-06-14 2010-07-28 Sony Corp Dispositif de gestion d'informations et procede de gestion d'informations
EP3435237A4 (fr) * 2016-03-23 2019-01-30 Sony Corporation Dispositif de traitement d'informations et procédé de traitement d'informations

Also Published As

Publication number Publication date
CA2264896A1 (fr) 1999-01-07
FR2765362B1 (fr) 2001-08-17
EP0944880A1 (fr) 1999-09-29
WO1999000774A9 (fr) 2007-07-26
TW434504B (en) 2001-05-16
NO990893L (no) 1999-03-17
KR20000068374A (ko) 2000-11-25
AU8343998A (en) 1999-01-19
CN1231042A (zh) 1999-10-06
BR9806014A (pt) 1999-10-13
NO990893D0 (no) 1999-02-25
WO1999000774A1 (fr) 1999-01-07
JP2000503157A (ja) 2000-03-14
AR016092A1 (es) 2001-06-20

Similar Documents

Publication Publication Date Title
CA2027344C (fr) Systeme de paiement ou de transfert d&#39;information par carte a memoire electronique porte monnaie
EP0990204B1 (fr) Carte a puce comprenant des moyens pour gerer une memoire virtuelle, procede et protocole de communication associes
FR2673476A1 (fr) Procede securise de chargement de plusieurs applications dans une carte a memoire a microprocesseur.
EP0018889A1 (fr) Procédé pour prolonger la validité d&#39;une zone de travail de la mémoire d&#39;un support d&#39;enregistrement
EP0565389A1 (fr) Procédé de personnalisation d&#39;une carte à puce
EP0089876A1 (fr) Procédé et dispositif de protection d&#39;un logiciel livré par un fournisseur à un utilisateur
FR2716021A1 (fr) Procédé et système de transaction par carte à puce.
FR2686171A1 (fr) Carte a memoire de masse pour microordinateur avec facilites d&#39;execution de programmes internes.
WO2001084512A1 (fr) Carte a puce multi-applicatives
FR2817055A1 (fr) Execution d&#39;une application dans un objet electronique portable a faible capacite de memoire
EP1388134A1 (fr) Procede et systeme de gestion de donnes destinees a etre stockees dans une carte a puce programmable
FR2765362A1 (fr) Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires
EP2912640B1 (fr) Procédé de gestion d&#39;identifiants dans une carte a circuit integré et carte a circuit integré correspondante
EP0838053B1 (fr) Procede et dispositif permettant a un programme fige de pouvoir evoluer
FR2806813A1 (fr) Systeme de gestion de memoire pour cartes a puce permettant a un utilisateur d&#39;avoir acces a certaines prestations dans le cadre notamment d&#39;une gestion informatisee des services de la ville
CA2046320C (fr) Procede de generation d&#39;un nombre aleatoire dans un systeme a objets portatifs electroniques, et systeme pour la mise en oeuvre du procede
WO1997040473A1 (fr) Systeme securise de controle d&#39;acces permettant l&#39;invalidation automatique de cles electroniques volees ou perdues et/ou le transfert d&#39;habilitation a produire des cles
EP2304559A1 (fr) Procédé de basculement entre deux versions d&#39;une même application au sein d&#39;un dispositif de traitement de l&#39;information et ledit dispositif
EP0687999B1 (fr) Carte à mémoire assurant la gestion des présentations successives et procédé de gestion de ces présentations
FR3136079A1 (fr) Méthode pour la gestion d’une zone de données sensible en mémoire FLASH
FR2789774A1 (fr) Procede de comparaison securise de deux registres memoire, et module de securite mettant en oeuvre ce procede
FR2795583A1 (fr) Module de securite
FR2770071A1 (fr) Systeme d&#39;identification de personnes
FR2833093A1 (fr) Procede d&#39;echange de blocs de donnees, procede d&#39;echange et de traitement de blocs de donnees, objet portatif, et automate pour la mise en oeuvre de procede
FR2864294A1 (fr) Carte a microcircuit multi-compte permettant la restriction d&#39;une fonctionnalite a un compte et procede de communication correspondant

Legal Events

Date Code Title Description
ST Notification of lapse