FR2835628A1 - Gestion de la mise a jour d'informations encodees en memoire - Google Patents

Gestion de la mise a jour d'informations encodees en memoire Download PDF

Info

Publication number
FR2835628A1
FR2835628A1 FR0201363A FR0201363A FR2835628A1 FR 2835628 A1 FR2835628 A1 FR 2835628A1 FR 0201363 A FR0201363 A FR 0201363A FR 0201363 A FR0201363 A FR 0201363A FR 2835628 A1 FR2835628 A1 FR 2835628A1
Authority
FR
France
Prior art keywords
data
memory
attribute
file
updating
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.)
Pending
Application number
FR0201363A
Other languages
English (en)
Inventor
Ilan Mahalal
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.)
Axalto SA
Original Assignee
Schlumberger Systemes 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 Schlumberger Systemes SA filed Critical Schlumberger Systemes SA
Priority to FR0201363A priority Critical patent/FR2835628A1/fr
Priority to CNB038029928A priority patent/CN100361165C/zh
Priority to BRPI0307114-6A priority patent/BR0307114A/pt
Priority to PCT/IB2003/000311 priority patent/WO2003065319A1/fr
Priority to JP2003564831A priority patent/JP4723187B2/ja
Priority to EP03701641A priority patent/EP1472656A1/fr
Priority to US10/502,823 priority patent/US7147167B2/en
Publication of FR2835628A1 publication Critical patent/FR2835628A1/fr
Pending 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
    • 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/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • 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

Landscapes

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

Abstract

La présente invention se rapporte à un système de mise à jour de données encodées stockées dans une mémoire d'un dispositif de traitement de données tel qu'une carte à puce. Dans ce système, les données sont représentées par une structure en arborescence en répertoires et fichiers selon une représentation objet. Selon l'invention, le système de mise à jour comprend un objet spécifique de référencement propre à référencer tout ou partie des attributs des données encodées en mémoire. Un microcontrôleur est alors programmé pour extraire de l'objet de référencement les informations propres à localiser le bloc de mémoire occupé par cet attribut, et mettre à jour ce bloc en le remplaçant par la nouvelle donnée préalablement encodée.

Description

<Desc/Clms Page number 1>
Gestion de la mise à jour d'informations encodées en mémoire.
Domaine technique
La présente invention se rapporte à la gestion de la mise à jour d'informations encodées et stockées en mémoire. L'invention s'applique tout particulièrement à la gestion d'informations de sécurité stockées dans une mémoire d'un objet portatif (token en anglais). L'exemple choisi pour l'illustration de l'invention sera celui de la carte à puce.
L'invention s'applique tout particulièrement aux dispositifs portatif incluant une application WIM (WAP Identity Module). Cette application WIM généralement inclus dans une carte à puce réalise, sur requête d'un dispositif de traitement de données tel qu'un téléphone cellulaire, des opérations utilisant des clés publiques telles que des signatures électroniques ou l'encryptage de données, etc. Dans cette application WIM, les données sont stockées en mémoire conformément à la norme PKCS&num;15 (P K C S : Public-Key Cryptography Standards) définie et publiée par les laboratoires RSA incorporation pour la mise en place de Public Key Cryptography. Rappelons, à titre d'information, que Public Key Cryptography utilise une paire de clés, une clé public qui peut être divulgué à tout le monde, et une clé privée qui doit être gardée dans un endroit sûr et ne jamais être révélée. Cette norme utilise une structure de données orientée objet, c'est-à-dire une structure hiérarchique de classes d'objets triés par catégories.
Notons, à titre d'information, que le laboratoire RSA défini un ensemble de normes PKCS &num;n (n est l'identifiant de la norme ; RSA utilise un nombre entier pour identifier les différentes normes PKCS) propre à assurer une interopérabilité des données dans des systèmes informatiques hétérogènes. Ces différentes normes (PKCS&num;1,..., PKCS&num;15) définissent les types de données et les algorithmes utilisés en cryptographie de clé publique. En particulier, la norme PKCS&num;15 se rapporte aux informations de cryptologie stockée sur des objets portatifs aptes à stocker des données persistantes.
On se reportera à la documentation RSA décrivant ces différentes normes.
Ce document est disponible à l'adresse internet suivante : http : //www. rsasecurity. com.
<Desc/Clms Page number 2>
Etat de la technique
D'une manière générale, la cryptographie utilise une clef privée à laquelle seul un utilisateur a accès et une clef publique qui peut être publiée ou distribuée à la demande pour l'utilisation de ceux souhaitant communiquer avec l'utilisateur.
Une partie souhaitant communiquer avec l'utilisateur obtiendra tout d'abord un certificat portant la clé publique de l'utilisateur, certificat qui peut être obtenu à partir d'une autorité de certification.
Les données relatives aux clés et certificats sont représentées par une structure en arborescence en répertoires et fichiers. Dans cette structure, on trouve généralement deux types de fichiers : - les fichiers de type DF contenant des informations de contrôle de fichier et comporte éventuellement de la mémoire disponible, - et les fichiers de type EF sont des fichiers élémentaires.
Dans la présente demande, nous ne détaillerons pas les conditions d'accès définies à chaque niveau de la structure de fichier de la carte et pour des groupes de fonctions agissant sur les fichiers.
Plus précisément, le format PKCS&num;15 définie quatre classes d'objets subordonnées à la racine. Ces classes sont : - la classe Clé, - la classe certificats, - la classe authentification, - et la classe données.
Ces classes incluent elles-mêmes des sous-classes. Par exemple, la classe dite Clé comprend trois classes appelées : classe clé privée classe clé secrète classe clé publique
Chaque objet appartenant à une classe comprend des attributs. Un arbre comprend donc généralement une pluralité d'objets répartis dans l'arbre.
Tous ces objets et répertoires sont représentés selon la norme ASN. 1 (ASN. 1 Abstract Syntax Notation) ISO/IEC 8824 publiée par l'institut ANSI
<Desc/Clms Page number 3>
(American National Standards Institute). Cette norme décrit la syntaxe propre à décrire des objets de données complexes.
Ces objets sont ensuite encodés selon des règles DER (Distinguished Encoding Rules) définies dans la même norme ASN. 1. Ces règles d'encodage définissent l'encodage des objets en séquences d'octets. Il n'y a pas lieu ici de décrire davantage cette Norme ASN. 1, celle-ci ne faisant pas l'objet de l'invention.
Une fois l'encodage réalisé, une application externe à la carte, par exemple un lecteur de carte, peut lire les données encodées stockées sur la carte à partir du répertoire PKCS&num;15 (la racine) et trouve à partir de l'arborescence décrite précédemment la façon d'utiliser les clés, les certificats, et des applications stockées dans la carte.
Cet encodage a généralement lieu lors de la personnalisation de la carte.
Après personnalisation, il est parfois nécessaire de mettre à jour certains attributs de l'arbre. Cette mise à jour présente d'énormes difficultés. En effet, une mise à jour à partir d'un lecteur comprend deux étapes principales : - Premièrement, l'ensemble des données encodées doit être décodé, - Deuxièmement, une fois la mise à jour réalisée, il faut à nouveau encoder toutes ces données.
Ces deux étapes sont à renouveler à chaque fois qu'au moins un attribut d'un objet doit être mis à jour.
L'invention
Un but de l'invention est de simplifier la procédure de mise à jour des données encodées sur la carte.
A cet effet, la carte comprend en mémoire un objet spécifique de référencement propre à référencer tout ou partie des attributs des données encodées en mémoire. Selon l'invention, une mise à jour comprend les étapes suivantes : - une étape propre à extraire de l'objet de référencement les informations propres à localiser le bloc de mémoire occupé par cet attribut,
<Desc/Clms Page number 4>
- une étape de mise à jour de ce bloc en le remplaçant par la nouvelle donnée préalablement encodée.
Il n'est plus nécessaire comme dans le passé de décoder l'ensemble des données encodées et, une fois la mise à jour réalisée, d'encoder de nouveau toutes ces données. Maintenant, grâce à l'objet de référencement, on peut mettre à jour qu'une partie des données encodées. On extrait les informations de localisation de l'objet de référencement pour localiser la donnée encodée à mettre à jour. Il suffit alors d'encoder la nouvelle donnée et de la stocker à l'endroit où l'ancienne donnée se trouvait. La procédure de mise à jour est largement simplifiée.
L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés.
Dans les dessins
La figure 1 est une vue d'un système informatique sur lequel peut s'appliquer l'invention.
La figure 2 est une vue schématique d'un exemple d'arborescence des fichiers de la carte.
La figure 3 est une vue schématique de l'organisation des données en mémoire.
La figure 4 est une vue d'un exemple de réalisation d'un objet de référencement.
La figure 5 est un algorithme illustrant les différentes étapes d'un exemple de réalisation.
Description d'un exemple de réalisation
Pour simplifier la description, les mêmes éléments illustrés dans les dessins portent les mêmes références.
<Desc/Clms Page number 5>
La figure 1 est une vue simplifiée d'un système informatique sur lequel l'invention peut être mise en oeuvre. Ce système comprend une carte à puce CAR et un lecteur de carte à puce RDR. Ce lecteur peut être incorporé dans calculateur tel qu'un téléphone cellulaire, un assistant électronique, etc. Rappelons qu'un calculateur, également appelé ordinateur par l'homme du métier, est une machine programmable capable d'effectuer un traitement de l'information.
Dans notre exemple de réalisation, le lecteur de carte à puce est incorporé dans un téléphone cellulaire.
Rappelons qu'une carte à puce inclut un module électronique (non représenté). Le module comprend un microcontrôleur et des contacts pour communiquer avec l'extérieur. Le microcontrôleur comprend, en général : - un microprocesseur pour l'exécution de commandes, - des mémoires non volatiles ROM (Read Only Memory) appelée aussi mémoire morte, mémoire dont le contenu est fixé en usine et ne peut donc être modifié. On peut donc y inscrire par exemple un algorithme de chiffrement, le système d'exploitation, des interfaces programmatiques (API), etc. ; des mémoires non volatiles, par exemple EEPROM, appelée aussi mémoire morte reprogrammable. Cette mémoire est, en général, utilisée pour y enregistrer les données spécifiques à chaque carte comme par exemple l'identité du détenteur de la carte, les autorisations d'accès aux services, les systèmes de fichiersdes programmes applicatifs de la carte, etc, - des mémoires volatiles RAM, espace de travail pour l'exécution des jeux de commandes de la carte, - des organes de sécurité, prenant en compte la tension d'alimentation, la vitesse d'horloge, etc., - un bus de données reliant l'ensemble, - un bus BUS d'entrée-sortie pour communiquer, dans notre exemple de réalisation, avec le lecteur RDR. La carte
<Desc/Clms Page number 6>
La carte stocke en mémoire diverses informations. Une application WIM stockée dans cette mémoire réalise des opérations sur requête du téléphone cellulaire. Par exemple, lorsque le téléphone cellulaire nécessite une signature, il transmet une commande à l'application WIM pour que celle-ci réalise la signature et retourne au téléphone la signature demandée. Notons que la clé privée qui est utilisée pour réalisée la signature n'est jamais divulguée.
Cette application WIM utilise une pluralité de clé privée stockée dans la carte. Le téléphone doit alors indiquer, lorsqu'il requiert une signature à l'application, la clé à sélectionner pour l'opération cryptographique. Le téléphone lit tout d'abord l'arbre à partir de la racine PKCS&num;15 jusqu'aux noeuds associés aux clés privés pour y trouver le nombre de clés privées disponibles dans l'application WIM et l'identificateur de chaque clé.
Ces données sont stockées en mémoire sous forme de structure arborescente. La figure 2 est un schéma illustrant cette structure. Dans notre exemple, cet arbre comprend des fichiers de type DF et des fichiers EF (fichiers élémentaires) en ses noeuds. Le fichier DF est nommé PKCS&num;15 et constitue la racine de l'arbre. Ce fichier PKCS&num;15 a des noeuds subordonnés, dont un noeud nommé EF (ODF) qui est un fichier élémentaire qui contient des pointeurs vers d'autres fichiers élémentaires notamment des pointeurs vers - un fichier élémentaire nommé EF (PrKDF) contient toutes les informations concernant les clés privées dans l'application WIM, - un fichier élémentaire nommé EF (PuKDF) dédié aux clés publiques, - un fichier élémentaire nommé EF (CDF) dédié aux certificats, - etc.
Chaque fichier EF (PrKDF), EF (PuKDF), et EF (CDF) contient en général un répertoire d'objets PKCS&num;15 d'une classe particulière. Le contenu du fichier EF (ODF) est conforme à la syntaxe ASN. 1.
L'écriture d'un objet dans le fichier élémentaire EF (PrKDF) correspondant à une clé privée peut être la suivante :
<Desc/Clms Page number 7>
value PKCS15PrivateKey : : = privateRSAKey : { commonObjectAttributes { label"AUT-KEY", flags {private}, authld'01'H
Figure img00070001

}, classAttributes { iD'6754C890FD57453289AB9076E64245BC6D709FE7'H, usage {encrypt, decrypt, sign, verify}, keyReference 1 }, typeAttributes { value indirect : path : { path'0012'H
Figure img00070002

}, modulusLength 1024 } }
A la lecture de ce fichier, on s'aperçoit que chaque objet comprend une pluralité d'attributs. En autres, dans ce fichier, on trouve les attributs suivants : - L'attribut Label qui porte la valeur AUT-KEY - L'attribut Flag dont la valeur est {private}. La valeur {private} indique que cet attribut est protégé contre des accès non autorisés. En effet, sur une carte à circuit intégré, les accès (en lecture, en écriture, en utilisation, etc. ) aux objets dits privés sont définis par des objets
<Desc/Clms Page number 8>
d'authentification. Une condition d'accès peut être la saisie d'un code PIN connu par l'utilisateur.
- L'attribut Authld qui comporte la valeur'Ol'H désignant l'identifiant du code PIN qui protège l'utilisation de la présente clé.
- L'attribut ClassAttibute. iD est l'identifiant de la clé. Dans notre exemple c'est une valeur binaire qui est la valeur obtenue par une fonction de hachage cryptographique telle que la fonction SHA-1 de la clé publique.
Pour plus de détails sur cette fonction, on se reportera la norme FIPS 180-
1. La fonction de hachage n'est pas essentielle dans la présente demande.
-'L'attribut Usage qui a quatre valeurs {encrypt, decrypt, sign, verify} signifiant que cette clé n'est utilisée que pour l'encryptage, le décryptage, la signature de document, et la vérification d'une signature.
- Des attributs qui donnent des informations sur le chemin d'accès à la clé. Dans notre exemple, cette clé est accessible via un chemin d'accès donné par'0012'H et a une longueur de 1024 octets.
Dans notre exemple de réalisation, ce fichier est créé pendant la phase personnalisation de la carte à puce. Rappelons que la personnalisation est une étape du cycle de vie des cartes qui consiste à
Lorsque tous les fichiers sont écris, l'ensemble est encodé selon la norme DER. Le résultat de l'encodage est stocké en mémoire.
Comme on l'a vu dans l'introduction, le problème est qu'une fois l'encodage réalisé, une mise à jour d'un ou de plusieurs attributs présente un coût considérable en terme de calcul et en terme de complexité de l'algorithme de mise à jour.
Selon l'invention, on crée des objets de référencement, dont la valeur des attributs vont renseigner sur le référencement en mémoire de tout ou partie des attributs des objets PKCS&num;15. Ces objets de référencement vont ensuite être utilisés par des programmes qui s'exécutent dans le dispositif (carte à puce dans
<Desc/Clms Page number 9>
cet exemple) ou dans le lecteur de la carte. Dans notre exemple de réalisation, cet objet de référencement est créé à la personnalisation de la carte à puce.
La figure 3 est une vue schématique et générale de l'organisation des données d'un fichier EF (PrKDF) après encodage. En général, toutes les données de la mémoire sont concaténées, c'est-à-dire qu'elles sont stockées les unes à la suite des autres. Dans ce fichier chaque attribut à une longueur L, c'est-à-dire un nombre d'octets. La position de chaque attribut dans un fichier EF peut aussi être déterminée par l'intermédiaire d'un compteur OFF qui représente en nombre d'octets, la distance entre le debut du fichier EF (PrKDF) et le 1 er octet de l'attribut.
Par exemple, dans ce fichier EF (PrKDF), un premier attribut ATT1 a une longueur L12 octets. Cet attribut est le premier attribut référencé dans le fichier (EF, PrKDF) ; il a donc un compteur OFF1 égal à 0. L'attribut suivant ATT2 a une longueur L23 octets et son compteur OFF2 est égal au L12. De même, l'attribut ATT3 a une longueur L34 octets et a une compter de L12+L23, et ainsi de suite.
Le référencement peut être réalisé de plusieurs façons. Dans notre exemple de réalisation, on a choisi d'utiliser les attributs suivants : - un attribut type d'objet (par exemple privateRSAKey) - un attribut désignant l'instance concernée pour ce type d'objet, - un attribut pour désigner le nom de l'attribut, - un attribut compteur OFF ayant pour fonction de localiser dans le fichier (par exemple EF (PrKDF)) le bloc de données associées à cet attribut - un attribut Longueur ayant pour fonction de fournir la longueur de l'attribut en question..
Il existe naturellement différents moyens de localisation dans un fichier. Par exemple, on peut utiliser, au lieu et place des attributs Compteur et Longueur)), l'adresse de début et de fin du bloc de données occupé par cet attribut.
La figure 4 est un exemple d'un objet de référencement. Sur cette figure, les attributs sont représentés sous forme de table.
<Desc/Clms Page number 10>
Dans cette table sont stockées les cinq attributs mentionnés ci-dessus.
Dans notre exemple de réalisation, nous nous intéressons à la mise à jour des attributs Label et ClassAttributes. iD stockés dans le fichier EF (PrKDF) défini cidessus. Nous supposerons que l'objet à modifier est la première instance enregistrée avec le type privateRSAKey dans le fichier EF (PrKDF).
Naturellement, l'arbre PKCS&num;15 peut stocker d'autres instances de même type et d'autres fichiers incluant des objets ayant des attributs. Le principe de l'invention s'applique de la même façon à toutes ces instances et tous ces fichiers.
La première rangée concerne l'attribut ClassAttributes. iD. Pour cet attribut, - La première colonne de la table identifie le type d'objet. Dans notre exemple, le type de l'objet est privateRSAkey .
- La seconde colonne indique que l'instance concernée est la première instance du type privateRSAkey . Naturellement, cette colonne n'a lieu d'être que s'il y a plus d'une instance de ce type dans l'arbre.
- La troisième colonne indique son nom Label .
- La quatrième colonne indique le fichier concerné EF (PrKDF) dans lequel est stocké l'attribut ClassAttributes. iD.
- Le cinquième attribut donne le compteur qui est de 15 octets dans notre exemple.
- Et le sixième attribut qui donne la longueur de l'attribut en octets. Dans notre exemple, cet attribut est fixé à 20 octets.
Dans notre exemple illustré, pour des raisons de sécurité, cette table ne doit pas être accessible en écriture. De préférence, les attributs Compteur et Longueur sont fixés indépendamment de la longueur des valeurs des attributs à mettre jour.
En d'autres mots, pour chaque attribut référencé dans la table, on fixe une longueur déterminée qui ne pourra être modifiée. Cette longueur déterminée comprend un nombre d'octets tel qu'il sera suffisant pour stocker des attributs de longueur plus ou moins longue.
La figure 5 est un algorithme illustrant les principales étapes du procédé appliquées à notre exemple de réalisation. Supposons que la mise à jour concerne
<Desc/Clms Page number 11>
l'attribut Label dans le fichier EF (PrKDF) de type privateRSAKey et que la nouvelle valeur de cet attribut soit AUT-KEY2 .
Les étapes sont les suivantes :
Etape 1 :
Une première étape ET1 consiste à se munir de la nouvelle valeur à mettre à jour dans le fichier EF (PrKDF).
Etape 2 :
Une deuxième étape ET2 consiste par l'intermédiaire d'une commande incluse dans le téléphone cellulaire à transmettre la nouvelle valeur de l'attribut Label à la carte pour une mise à jour. De façon à identifier l'attribut dans la table, celui-ci pouvant se trouver dans plusieurs fichiers de l'arbre à la fois, la commande inclus aussi les attributs ClassAttributes. iD et l'instance concernée privateRSAkey . Un programme d'ordinateur présent dans le téléphone cellulaire a pour fonction de transmettre une commande de mise à jour vers la carte.
Etape 3
Lors d'une troisième étape ET3, la carte reçoit et traite la commande. Un programme d'ordinateur stocké dans la carte est activé dès réception de la commande de mise à jour issue du téléphone cellulaire. Ce programme pointe ensuite sur l'objet de référencement pour localiser en mémoire l'attribut Label .
Etape 4
Lors d'une quatrième étape ET4, l'objet de référencement fourni le compteur de 110 et la longueur de 20
Etape 5
Une cinquième étape ET5 consiste à encoder cette nouvelle valeur AUTKEY2 et à l'écrire à l'endroit indiqué.
Figure img00110001
Lorsque la mise à jour concerne l'attribut ClassAttribute. iD , la procédure est la même avec une étape supplémentaire ET4bis. Comme on l'a vu précédemment, dans notre exemple illustré, cet attribut est obtenu en utilisant la
<Desc/Clms Page number 12>
fonction cryptographique SHA-1. L'encodage de l'étape 4 est donc précédé d'une étape de hachage de la valeur de l'attribut ClassAttribute. iD .
Un autre exemple pourrait être la génération d'une nouvelle paire de clé publique dans la carte à puce. Dans notre exemple, le hash de la clé publique est utilisée comme identifiant de la clé dans les objets PKCS&num;15. Après la génération de paire de clés, les objets PKCS&num;15 correspondants doivent être mis à jour par la nouvelle valeur hachée de la clé publique. Puisque la valeur hachée de la clé publique est de longueur fixe, l'application stockée dans la carte qui génère la nouvelle paire de clé publique a besoin uniquement de retrouver toutes les instances de la clé publique hachée à remplacer parmi les objets PKCS&num;15 ; l'application utilise l'objet spécifique de référencement pour retrouver ces instances. Une fois les instances retrouvées, celles-ci sont mises à jour par les nouvelles valeurs.
D'une manière générale, l'invention a pour objet un système de mise à jour de données encodées stockées dans une mémoire d'un dispositif de traitement de données tel qu'une carte à puce, lesdites données étant représentées par une structure en arborescence en répertoires et fichiers selon une représentation objet, caractérisé en ce qu'il comprend - un objet spécifique de référencement propre à référencer tout ou partie des attributs des données encodées en mémoire, - et en ce qu'il comprend un microcontrôleur programmé pour - extraire de l'objet de référencement les informations propres à localiser le bloc de mémoire occupé par cet attribut, - et mettre à jour ce bloc en le remplaçant par la nouvelle donnée préalablement encodée.
Cet objet de référencement est stocké en mémoire dans le dispositif de traitement de données. On a vu dans notre exemple de réalisation que cet objet de référencement est protégé en écriture pour des raisons de sécurité évidente ; cette
<Desc/Clms Page number 13>
protection en écriture assure que les données de référencement stockées dans cette mémoire ne seront pas modifiées.
Le microcontrôleur programmer pour la mise à jour peut se trouver indifféremment sur le dispositif de traitement de données, ou sur un outil externe connecté au dispositif de traitement de données.
Dans notre exemple de réalisation, ledit objet de référencement comprend des données persistantes, c'est-à-dire qu'elles restent inchangées même en cas de coupure de l'alimentation. Dans notre exemple, même lorsque la carte est retirée de son lecteur, c'est-à-dire lorsqu'elle n'est donc plus alimentée, cet objet est stocké en mémoire et ne peut être modifié.
D'autre part, on a vu que ledit objet de référencement comprend des attributs. Dans notre exemple de réalisation, on a défini cinq attributs. On s'aperçoit que trois attributs suffisent à identifier - le fichier, par exemple le fichier EF (PrKDF), - l'attribut, par exemple l'attribut ClassAttributes. iD à mettre à jour dans de ce fichier, - et la localisation, par exemple par le couple de valeur (compteur,
Longueur), de cet attribut dans le fichier en question.
Il en résulte un procédé de mise à jour de données encodées stockées dans une mémoire d'un dispositif de traitement de données tel qu'une carte à puce, caractérisé en ce qu'il comprend : - une étape préalable de création d'un objet spécifique de référencement de façon à référencer tout ou partie des attributs des données encodées en mémoire, et en ce qu'une mise à jour comprend les étapes suivantes : - une étape propre à extraire de l'objet de référencement les informations propres à localiser le bloc de mémoire occupé par cet attribut, - une étape de mise à jour de ce bloc en le remplaçant par la nouvelle donnée préalablement encodée.
<Desc/Clms Page number 14>
De préférence, cet objet spécifique de référencement est créé lors de la personnalisation de la carte à puce.
L'invention a aussi pour objet un programme d'ordinateur pour la mise à jour de données encodées stockées dans une mémoire d'un dispositif de traitement de données tel qu'une carte à puce, ledit programme comprenant des instructions de code de programme pour l'exécution des étapes de mise à jour telles que définies précédemment, ledit programme étant exécuté par l'intermédiaire d'un microcontrôleur du système de mise à jour tel que défini précédemment. On a vu aussi que ce programme réalise un traitement de mise à jour qui peut être réalisé indifféremment par un microcontrôleur situé sur la carte ou sur un outil externe connecté à la carte. Cet outil externe peut être par exemple un lecteur d'un téléphone mobile auquel est connecté la carte à puce.
L'invention représente un gain considérable de calcul, de taille de stockage et réduit largement la complexité de l'algorithme de mise à jour.
<Desc/Clms Page number 15>
ANNEXE H écriture du fichier EF(PrKDF) selon la norme PKCS&num;15 et ASN1 value PKCS15PrivateKey : : = privateRSAKey : { commonObjectAttributes { label"AUT-KEY", flags {private}, authld'01'H
Figure img00150001

}, classAttributes { iD'0011111111111111111111111111111111111100'H, usage {encrypt, decrypt, sign, verify }, keyReference 1
Figure img00150002

}, typeAttributes { value indirect : path : { path'0012'H
Figure img00150003

}, modulusLength 1024 } } value PKCS15PrivateKey : : = privateRSAKey : { commonObjectAttributes { label"NR-KEY", flags {private}, authid'02'H
Figure img00150004

}, classAttributes { iD'0022222222222222222222222222222222222200'H,
<Desc/Clms Page number 16>
usage {nonRepudiation}, keyReference 2
Figure img00160001

h typeAttributes { value indirect : path : { path'0012'H }, modulusLength 1024 } } Après encodage de ce fichier, on obtient : Record length (hexa) : 41 303F3010 OC074155 542D4B45 59030207 80040101 301 D0414 00111111 11111111 11111111 11111111 11111100 030201 E2 020101 A1 OC300A30 04040200 12020204 00 Record length (hexa) : 41 303F300F OC064E52 2D4B4559 03020780 04010230 1 E041400 2222222222222222 22222222 22222222 22220003 03060040 020102A1 OC300A30 04040200 12020204 00 EF (PrKDF) file length : 82 II) Ecriture du fichier EF (UnusedSpace) selon la norme PKCS&num;15 et ASN1 value PKCS15UnusedSpace : : = { path { path'6200'H, index 0, length 1500
Figure img00160002

},
<Desc/Clms Page number 17>
authid'01'H } Après encodage de ce fichier, on obtient : Record length (hexa) : 12 3010300B 04026200 02010080 0205DC04 0101 EF (UnusedSpace) file length : 12 III) Ecriture du fichier EF (DODF) selon la norme PKCS&num;15 et ASN1 value PKCS15Data : : = opaqueDO : { commonObjectAttributes { flags {private, modifiable}, authld'01'H
Figure img00170001

}, classAttributes { applicationOI D {2 23 43 1 2 1} }, typeAttributes indirect : path : { path'5108'H, index 0, length 176 } } value PKCS15Data : : = opaqueDO : { commonObjectAttributes { flags {private, modifiable}, authid'01'H
<Desc/Clms Page number 18>
Figure img00180001

} s classAttributes { applicationOID {2 23 431 22} }, typeAttributes indirect : path : { path'5109'H, index 0, length 176 } } Après encodage de ce fichier, on obtient : Record length (hexa) : 23 30213007 030206CO 04010130 07060567 2B010201 A10D300B 04025108 02010080 0200BO Record length (hexa) : 23 30213007 030206CO 04010130 07060567 2B010202 A10D300B 04025109 02010080 0200BO EF (DODF) file length : 46 IV) Ecriture du fichier EF (CDF) selon la norme PKCS&num;15 et ASN1 value PKCS15Certificate : : = x509Certificate : {
Figure img00180002

commonObjectAttributes { label"User Auth Certificate File", flags {modifiable}
Figure img00180003

}, classAttributes { iD'00111111111111111111111111111111111111 OO'H, authority FALSE,
<Desc/Clms Page number 19>
requestld { idType 5,
Figure img00190001

idValue PKCS151dentifier :'492C1 FF42D87C376789444E8EC309C67C97B8D25'H } }, typeAttributes {
Figure img00190002

value indirect : path : { path'6001'H, index 0, length 704
Figure img00190003

} } } value PKCS15Certificate : : = x509Certificate : {
Figure img00190004

commonObjectAttributes { label"User NR Certificate File", flags {modifiable}
Figure img00190005

}, classAttributes { iD'0022222222222222222222222222222222222200'H, authority FALSE,
Figure img00190006

requestld { idType 5, idValue PKCS151dentifier :'492C1 FF42D87C376789444E8EC309C67C97B8D25'H } }, typeAttributes { value indirect : path : {
<Desc/Clms Page number 20>
path'6002'H, index 0, length 704 } } } value PKCS15Certificate : : = x509Certificate : { commonObjectAttributes { label"User Auth Certificate URL", flags {modifiable}
Figure img00200001

}, classAttributes { iD'0011111111111111111111111111111111111100'H, authority FALSE, requestid { idType 5,
Figure img00200002

idValue PKCS151dentifier :'492C1 FF42D87C376789444E8EC309C67C97B8D25'H } }, typeAttributes { value indirect : url :"http : //baseAddress/certs ? ih=Oi+06/g..." } } value PKCS15Certificate : : = x509Certificate : { commonObjectAttributes { label "User NR Certificate URL", flags {modifiable}
Figure img00200003

}, classAttributes
<Desc/Clms Page number 21>
{ iD'0022222222222222222222222222222222222200'H, authority FALSE,
Figure img00210001

requestld { idType 5, idValue PKCS151dentifier :'492C1 FF42D87C376789444E8EC309C67C97B8D25'H } }, typeAttributes { value indirect : url :"http : //baseAddress/certs ? ih=Oi+06/g..." } } Après encodage de ce fichier, on obtient : Record length (hexa) : 68 30663020 OC1 A5573 65722041 75746820 43657274 69666963 61746520 46696C65 030206403031041400111111 11111111 11111111 11111111 1111110030190201 05041449 2C1 FF42D 87C37678 9444E8EC 309C67C9 7B8D25A1 OF300D30 OB040260 01020100 800202CO Record length (hexa) : 66 3064301 E OC185573 6572204E 52204365 72746966 69636174 65204669 6C650302 06403031 04140022 22222222 22222222 22222222 22222222 22003019 02010504 14492C1F F42D87C3 76789444 E8EC309C 67C97B8D 25A10F30 OD300B04 02600202 01008002 02CO Record length (hexa) : AO 30819D30 1FOC1955 73657220 41757468 20436572 74696669 63617465 2055524C 0302064030310414001111111111111111111111111111111111110030190201 05041449 2C1 FF42D 87C37678 9444E8EC 309C67C9 7B8D25A1 47304516 43687474 703A2F2F 62617365 41646472 6573732F 63657274 733F6968 3D4F692B 30362F67 3975574E 66777977 42344343 6D343147 79523845 3D736E3D 4F6F7230 36673D3D Record length (hexa) : 9E 30819B30 1 DOC1755 73657220 4E522043 65727469 66696361 74652055 524C0302
<Desc/Clms Page number 22>
06403031 04140022 22222222 22222222 22222222 22222222 22003019 02010504 14492C1F F42D87C3 76789444 E8EC309C 67C97B8D 25A14730 45164368 7474703A 2F2F6261 73654164 64726573 732F6365 7274733F 69683D4F 692B3036 2F673975 574E6677 79774234 43436D34 31477952 38453D73 6E3D4F6F 72303741 3D3D EF (CDF) file length : 20C V) Ecriture du fichier EF (ODF) selon la norme PKCS&num;15 et ASN1
Figure img00220001

value PKCS150bjects : : = privateKeys : path : { path'5101'H } value PKCS150bjects : : = certificates : path : { path'5103'H } value PKCS150bjects : : = trustedCertificates : path : { path'5104'H } value PKCS150bjects : : = usefulCertificates : path : { path'5105'H } value PKCS150bjects : : = dataObjects : path : { path'5106'H
Figure img00220002

} value PKCS150bjects : : = authObjects : path : {
<Desc/Clms Page number 23>
Figure img00230001

path'5107'H } Record length (hexa) : 8 A0063004 04025101 Record length (hexa) : 8 A4063004 04025103 Record length (hexa) : 8 A5063004 04025104 Record length (hexa) : 8 A6063004 04025105 Record length (hexa) : 8 A7063004 04025106 Record length (hexa) : 8 A8063004 04025107 EF (ODF) file length : 30 VI) Ecriture du fichier EF (CDF) selon la norme PKCS&num;15 et ASN1 value PKCS15Certificate : : = wtisCertificate : { commonObjectAttributes { label"Entrust. net Test WAP CA", flags {} }, classAttributes
<Desc/Clms Page number 24>
{ iD'D4C6D9234AEF75233 FB5B5BF4427FCFBC55C40E3'H, authority TRUE, requestld { idType 5, idValue PKCS151dentifier :'D4C6D9234AEF75233FB5B5BF4427FCFBC55C40E3'H } }, typeAttributes { value indirect : path : { path'6101'H, index 0, length 431 } } } Après encodage de ce fichier, on obtient : Record length (hexa) : 67 A365301C OC17456E 74727573 742E6E65 74205465 73742057 41502043 41030100 30340414 D4C6D923 4AEF7523 3FB5B5BF 4427FCFB C55C40E3 0101 FF30 19020105 0414D4C6 D9234AEF 75233FB5 B5BF4427 FCFBC55C 40E3A10F 300D300B 04026101 02010080 0201 AF EF (CDF) file length : 67 VII) Ecriutre du fichier EF (AODF) selon la norme PKCS&num;15 et ASN1 value PKCS15Authentication : : = pin : { commonObjectAttributes { label"PIN-G",
<Desc/Clms Page number 25>
Figure img00250001

flags {private, modifiable} }, classAttributes { authld'01'H }, typeAttributes { pinFlags { case-sensitive, local, initialized, needs-padding, disable-allowed}, pinType ascii-numeric, minLength 4, storedLength 8, pin Reference 1 J padChar'FF'H, path { path'OOOO'H } } } value PKCS15Authentication : : = pin : {
Figure img00250002

commonObjectAttributes { label"PIN-NR", flags {private, modifiable}
Figure img00250003

}, classAttributes { authld'02'H }, typeAttributes { pinFlags {case-sensitive, local, l, initialized, needs-padding }, pinType ascii-numeric, minLength 4, storedLength 8,
<Desc/Clms Page number 26>
pin Reference 2, padChar'FF'H, path { path'0100'H } } } Après encodage de ce fichier, on obtient : Record length (hexa) : 32 3030300B OC055049 4E2D4703 0206C030 03040101 A11C301A 030307CC 800A0101 02010402 01088001 010401 FF 30040402 0000 Record length (hexa) : 32 3030300C OC065049 4E2D4E52 030206CO 30030401 02A 11830 19030202 CCOA0101 02010402 01088001 020401FF 30040402 0100
EF (AODF) file length : 64

Claims (10)

  1. Revendications 1-Dispositif de traitement de données, en particulier une carte à puce, stockant en mémoire des données encodées représentées par une structure en arborescence en répertoires et fichiers selon une représentation objet, caractérisé en ce qu'il comprend - un objet spécifique de référencement propre à référencer tout ou partie des attributs des données encodées en mémoire, - et en ce que la mise à jour des données encodées est gérée par un microcontrôleur programmé pour - extraire de l'objet de référencement les informations propres à localiser le bloc de mémoire occupé par cet attribut, - et mettre à jour ce bloc en le remplaçant par la nouvelle donnée préalablement encodée.
  2. 2. Dispositif selon la revendication 1, caractérisé en ce que l'accès audit objet de référencement est protégé en écriture dans le dispositif de traitement de données
  3. 3. Dispositif selon la revendication 1 ou 2, caractérisé en ce que ledit objet de référencement comprend des données persistantes.
  4. 4. Dispositif selon la revendication 1, caractérisé en ce que l'objet de référencement comprend des attributs identifiant - le fichier (EF (PrKDF)), - l'attribut (ClassAttributes. iD) à mettre à jour dans de ce fichier, - et la localisation (compteur, Longueur) de cet attribut dans le fichier en question.
  5. 5-Procédé de mise à jour de données encodées stockées dans une mémoire d'un dispositif de traitement de données tel qu'une carte à puce, lesdites données étant représentées par une structure en arborescence en répertoires et fichiers selon une représentation objet, caractérisé en ce qu'il comprend :
    <Desc/Clms Page number 28>
    - une étape préalable de création d'un objet spécifique de référencement de façon à référencer tout ou partie des attributs des données encodées en mémoire, et en ce qu'une mise à jour comprend les étapes suivantes : - une étape propre à extraire de l'objet de référencement les informations propres à localiser le bloc de mémoire occupé par cet attribut, - une étape de mise à jour de ce bloc en le remplaçant par la nouvelle donnée préalablement encodée.
  6. 6. Procédé de mise à jour selon la revendication 5, caractérisé en ce que, après création de l'objet de référencement et avant mise à jour des données encodées, une étape consiste à protéger ledit objet de référencement en écriture dans le dispositif de traitement de données.
  7. 7. Procédé selon la revendication 5, caractérisé en ce que l'étape préalable de création d'un objet spécifique de référencement est réalisée pendant la phase de personnalisation du dispositif de traitement de données.
  8. 8. Programme d'ordinateur pour la mise à jour de données encodées stockées dans une mémoire d'un dispositif de traitement de données tel qu'une carte à puce, ledit programme comprenant des instructions de code de programme pour l'exécution des étapes de mise à jour telles que définies dans la revendication 5.
  9. 9. Programme d'ordinateur selon la revendication 8, caractérisé en ce que l'exécution des étapes de mise à jour est réalisée sur la carte à puce.
  10. 10. Programme d'ordinateur selon la revendication 8, caractérisé en ce que l'exécution des étapes de mise à jour est réalisée par un outil externe connecté à la carte à puce.
FR0201363A 2002-02-01 2002-02-01 Gestion de la mise a jour d'informations encodees en memoire Pending FR2835628A1 (fr)

Priority Applications (7)

Application Number Priority Date Filing Date Title
FR0201363A FR2835628A1 (fr) 2002-02-01 2002-02-01 Gestion de la mise a jour d'informations encodees en memoire
CNB038029928A CN100361165C (zh) 2002-02-01 2003-01-31 存储器中的编码数据的更新管理
BRPI0307114-6A BR0307114A (pt) 2002-02-01 2003-01-31 dispositivo de processamento de dados, em particular um cartão inteligente, método para atualizar dados codificados armazenados em uma memória de um dispositivo de processamento de dados, tal como um cartão inteligente e programa de computador para atualizar dados armazenados em uma memória de um dispositivo de processamento de dados, tal como um cartão inteligente
PCT/IB2003/000311 WO2003065319A1 (fr) 2002-02-01 2003-01-31 Gestion de mise a jour de donnees codees dans une memoire
JP2003564831A JP4723187B2 (ja) 2002-02-01 2003-01-31 メモリ内の符号化データの更新管理
EP03701641A EP1472656A1 (fr) 2002-02-01 2003-01-31 Gestion de mise a jour de donnees codees dans une memoire
US10/502,823 US7147167B2 (en) 2002-02-01 2003-01-31 Update management for encoded data in memory

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0201363A FR2835628A1 (fr) 2002-02-01 2002-02-01 Gestion de la mise a jour d'informations encodees en memoire

Publications (1)

Publication Number Publication Date
FR2835628A1 true FR2835628A1 (fr) 2003-08-08

Family

ID=27619906

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0201363A Pending FR2835628A1 (fr) 2002-02-01 2002-02-01 Gestion de la mise a jour d'informations encodees en memoire

Country Status (7)

Country Link
US (1) US7147167B2 (fr)
EP (1) EP1472656A1 (fr)
JP (1) JP4723187B2 (fr)
CN (1) CN100361165C (fr)
BR (1) BR0307114A (fr)
FR (1) FR2835628A1 (fr)
WO (1) WO2003065319A1 (fr)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2511366A1 (fr) * 2005-06-30 2005-10-16 Thierry Moreau Methode de gestion de cryptogramme et de cryptoperiode par cles d'ancrage de confiance
US8935771B2 (en) * 2006-11-06 2015-01-13 Safenet, Inc. System, method, and computer security device having virtual memory cells
AU2009200139B2 (en) 2008-01-15 2012-02-16 Aristocrat Technologies Australia Pty Limited A method of processing a user data card, an interface module and a gaming system
US20100329458A1 (en) * 2009-06-30 2010-12-30 Anshuman Sinha Smartcard, holder and method for loading and updating access control device firmware and/or programs
US9491624B2 (en) * 2011-12-09 2016-11-08 Verizon Patent And Licensing Inc. Public key cryptography for applications requiring generic bootstrap architecture
CN102625309A (zh) * 2012-01-18 2012-08-01 中兴通讯股份有限公司 访问控制方法及装置
CN102945206B (zh) * 2012-10-22 2016-04-20 大唐微电子技术有限公司 一种基于智能卡的对象存储访问方法及智能卡
IT201800005510A1 (it) 2018-05-18 2019-11-18 Procedimento per la generazione di dati personalizzati di profile package in carte a circuito integrato, corrispondente sistema e prodotto informatico
IT201900009543A1 (it) 2019-06-19 2020-12-19 St Microelectronics Srl Procedimento per la generazione di dati personalizzati di profile package in carte a circuito integrato, corrispondente sistema e prodotto informatico
CN111054082B (zh) * 2019-11-29 2023-10-13 珠海金山数字网络科技有限公司 Unity资源数据集编码的方法

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2611289A1 (fr) * 1987-02-20 1988-08-26 Toshiba Kk Dispositif electronique portatif
EP0354793A2 (fr) * 1988-08-12 1990-02-14 Hitachi Maxell Ltd. Carte à circuit intégré et méthode pour réécrire son programme
EP0540095A1 (fr) * 1991-10-30 1993-05-05 Philips Composants Et Semiconducteurs Microcircuit pour carte à puce à mémoire programmable protégée
WO1994024673A1 (fr) * 1993-04-13 1994-10-27 Jonhig Limited Ecriture de donnees dans une memoire remanente
FR2752072A1 (fr) * 1996-08-01 1998-02-06 Solaic Sa Carte a circuit integre comportant des fichiers classes selon une arborescence
WO1998009257A1 (fr) * 1996-08-30 1998-03-05 Gemplus S.C.A. Systeme et procede pour charger des applications dans une carte a puce
EP0949595A2 (fr) * 1998-03-30 1999-10-13 Citicorp Development Center, Inc. Méthode et système pour la gestion des applications pour une carte à puce multifonctionnelle
WO2001001357A1 (fr) * 1999-06-25 2001-01-04 Giesecke & Devrient Gmbh Procede pour faire fonctionner un support de donnees conçu pour executer des programmes fonctionnels rechargeables

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5276903A (en) * 1988-08-12 1994-01-04 Hatachi Maxell, Ltd. Method for rewriting partial program data in an IC card and apparatus therefor
JPH0250787A (ja) * 1988-08-12 1990-02-20 Hitachi Maxell Ltd Ｉｃカード及びそのプログラム書換え方式
JPH0250786A (ja) * 1988-08-12 1990-02-20 Hitachi Maxell Ltd Ｉｃカード及びそのプログラム書換え方式
JP3231467B2 (ja) * 1993-03-24 2001-11-19 大日本印刷株式会社 Ｃｐｕを内蔵した情報記録媒体
KR0127029B1 (ko) * 1994-10-27 1998-04-01 김광호 메모리카드와 그 기록, 재생 및 소거방법
DE19536548A1 (de) * 1995-09-29 1997-04-03 Ibm Vorrichtung und Verfahren zur vereinfachten Erzeugung von Werkzeugen zur Initialisierung und Personalisierung von und zur Kommunikation mit einer Chipkarte
JPH09106376A (ja) * 1995-10-11 1997-04-22 Dainippon Printing Co Ltd 携帯可能情報記録媒体
EP0790551A1 (fr) * 1996-02-16 1997-08-20 Koninklijke KPN N.V. Méthode pour modifier le jeu d'instruction d'une carte à puce
US6094721A (en) * 1997-10-31 2000-07-25 International Business Machines Corporation Method and apparatus for password based authentication in a distributed system
JP4051510B2 (ja) * 1998-07-16 2008-02-27 ソニー株式会社 データ記憶装置およびデータ記憶方法

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2611289A1 (fr) * 1987-02-20 1988-08-26 Toshiba Kk Dispositif electronique portatif
EP0354793A2 (fr) * 1988-08-12 1990-02-14 Hitachi Maxell Ltd. Carte à circuit intégré et méthode pour réécrire son programme
EP0540095A1 (fr) * 1991-10-30 1993-05-05 Philips Composants Et Semiconducteurs Microcircuit pour carte à puce à mémoire programmable protégée
WO1994024673A1 (fr) * 1993-04-13 1994-10-27 Jonhig Limited Ecriture de donnees dans une memoire remanente
FR2752072A1 (fr) * 1996-08-01 1998-02-06 Solaic Sa Carte a circuit integre comportant des fichiers classes selon une arborescence
WO1998009257A1 (fr) * 1996-08-30 1998-03-05 Gemplus S.C.A. Systeme et procede pour charger des applications dans une carte a puce
EP0949595A2 (fr) * 1998-03-30 1999-10-13 Citicorp Development Center, Inc. Méthode et système pour la gestion des applications pour une carte à puce multifonctionnelle
WO2001001357A1 (fr) * 1999-06-25 2001-01-04 Giesecke & Devrient Gmbh Procede pour faire fonctionner un support de donnees conçu pour executer des programmes fonctionnels rechargeables

Also Published As

Publication number Publication date
EP1472656A1 (fr) 2004-11-03
US20050127188A1 (en) 2005-06-16
US7147167B2 (en) 2006-12-12
CN1625759A (zh) 2005-06-08
WO2003065319A1 (fr) 2003-08-07
CN100361165C (zh) 2008-01-09
JP4723187B2 (ja) 2011-07-13
BR0307114A (pt) 2007-03-20
JP2005516317A (ja) 2005-06-02

Similar Documents

Publication Publication Date Title
FR2681165A1 (fr) Procede de transmission d&#39;information confidentielle entre deux cartes a puces.
FR2606909A1 (fr) Systeme de traitement pour un appareil electronique portatif, tel qu&#39;une carte a circuit integre
EP2786317B1 (fr) Ecriture de données dans une mémoire non volatile de carte à puce
EP0475837A1 (fr) Procédé de gestion d&#39;un programme d&#39;application chargé dans un support à microcircuit
EP0531194A1 (fr) Procédé d&#39;authentification de données
FR2835628A1 (fr) Gestion de la mise a jour d&#39;informations encodees en memoire
FR2686171A1 (fr) Carte a memoire de masse pour microordinateur avec facilites d&#39;execution de programmes internes.
EP3293637A1 (fr) Gestion d&#39;index dans une mémoire flash
WO2001099064A1 (fr) Controle d&#39;acces a un moyen de traitement de donnees
FR2823330A1 (fr) Procede et systeme de gestion de donnees destinees a etre stockees dans une memoire, par exemple du code d&#39;une application charge dans une carte a puce programmable
FR2795835A1 (fr) Procede de verification de transformateurs de codes pour un systeme embarque, notamment sur une carte a puce
FR2810480A1 (fr) Traitement de donnees avec une cle
EP1029312A1 (fr) Procede de gestion securise d&#39;une memoire
EP2901291B1 (fr) Procédé de gestion des ressources mémoire d&#39;un dispositif de sécurité, tel qu&#39;une carte à puce, et dispositif de sécurité mettant en oeuvre ledit procédé.
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
EP0974131B1 (fr) Procede d&#39;interpretation dynamique de donnees pour une carte a puce
FR2747813A1 (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
EP1547005B2 (fr) Carte à microcircuit dont les performances peuvent être modifiées après personnalisation
FR2809847A1 (fr) Procede de personnalisation electrique de carte a puce
EP2304559B1 (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
WO2016189227A1 (fr) Marquage en filigrane de la photo d&#39;un document identitaire electronique lors de sa lecture
FR2815434A1 (fr) Procede de verification de coherence de codes destines a un systeme embarque, notamment une carte a puce
FR3097994A1 (fr) Modification d&#39;une mémoire d&#39;un microprocesseur sécurisé
EP3188032B1 (fr) Stockage de données dans une mémoire flash
WO2014135526A1 (fr) Système et procédé de gestion d&#39;au moins une application en ligne, objet portable utilisateur usb et dispositif distant du système