Brevet FR2835628A1 — publié le 20030808

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. 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 (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, - 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. 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 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 : value PKCS15PrivateKey : : = privateRSAKey : { commonObjectAttributes { label"AUT-KEY", flags {private}, authld'01'H }, classAttributes { iD'6754C890FD57453289AB9076E64245BC6D709FE7'H, usage {encrypt, decrypt, sign, verify}, keyReference 1 }, typeAttributes { value indirect : path : { path'0012'H }, 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 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 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. 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 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é. 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 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 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. 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. 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 }, classAttributes { iD'0011111111111111111111111111111111111100'H, usage {encrypt, decrypt, sign, verify }, keyReference 1 }, typeAttributes { value indirect : path : { path'0012'H }, modulusLength 1024 } } value PKCS15PrivateKey : : = privateRSAKey : { commonObjectAttributes { label"NR-KEY", flags {private}, authid'02'H }, classAttributes { iD'0022222222222222222222222222222222222200'H, usage {nonRepudiation}, keyReference 2 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 }, 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 }, 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 } 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 : { commonObjectAttributes { label"User Auth Certificate File", flags {modifiable} }, classAttributes { iD'00111111111111111111111111111111111111 OO'H, authority FALSE, requestld { idType 5, idValue PKCS151dentifier :'492C1 FF42D87C376789444E8EC309C67C97B8D25'H } }, typeAttributes { value indirect : path : { path'6001'H, index 0, length 704 } } } value PKCS15Certificate : : = x509Certificate : { commonObjectAttributes { label"User NR Certificate File", flags {modifiable} }, classAttributes { iD'0022222222222222222222222222222222222200'H, authority FALSE, requestld { idType 5, idValue PKCS151dentifier :'492C1 FF42D87C376789444E8EC309C67C97B8D25'H } }, typeAttributes { value indirect : path : { path'6002'H, index 0, length 704 } } } value PKCS15Certificate : : = x509Certificate : { commonObjectAttributes { label"User Auth Certificate URL", flags {modifiable} }, classAttributes { iD'0011111111111111111111111111111111111100'H, authority FALSE, requestid { idType 5, 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} }, classAttributes { iD'0022222222222222222222222222222222222200'H, authority FALSE, 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 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 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 } value PKCS150bjects : : = authObjects : path : { 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 { 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", 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 : { commonObjectAttributes { label"PIN-NR", flags {private, modifiable} }, classAttributes { authld'02'H }, typeAttributes { pinFlags {case-sensitive, local, l, initialized, needs-padding }, pinType ascii-numeric, minLength 4, storedLength 8, 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 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. 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. Dispositif selon la revendication 1 ou 2, caractérisé en ce que ledit objet de référencement comprend des données persistantes. 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-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 : - 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. 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. 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. 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. 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. 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.