FR3023941A1 - Procede de personnalisation d'une carte a microcircuit - Google Patents

Procede de personnalisation d'une carte a microcircuit Download PDF

Info

Publication number
FR3023941A1
FR3023941A1 FR1457021A FR1457021A FR3023941A1 FR 3023941 A1 FR3023941 A1 FR 3023941A1 FR 1457021 A FR1457021 A FR 1457021A FR 1457021 A FR1457021 A FR 1457021A FR 3023941 A1 FR3023941 A1 FR 3023941A1
Authority
FR
France
Prior art keywords
block
memory
code
personalization
phase
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
FR1457021A
Other languages
English (en)
Other versions
FR3023941B1 (fr
Inventor
Said Boukyoud
Michael Austria Albano
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.)
Idemia France SAS
Original Assignee
Oberthur Technologies 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 Oberthur Technologies SA filed Critical Oberthur Technologies SA
Priority to FR1457021A priority Critical patent/FR3023941B1/fr
Publication of FR3023941A1 publication Critical patent/FR3023941A1/fr
Application granted granted Critical
Publication of FR3023941B1 publication Critical patent/FR3023941B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • 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/355—Personalisation of cards for use
    • G06Q20/3558—Preliminary personalisation for transfer to user
    • 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
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G06F9/4451—User profiles; Roaming

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

Ce procédé de personnalisation d'une carte à microcircuit comporte : - une étape d'installation, dans au moins un premier bloc mémoire (CODE_BLOCK), d'un code exécutable n'ayant pas d'utilité après une phase de pré-personnalisation de ladite carte; et - après ladite phase de pré-personnalisation de ladite carte à microcircuit, une étape de réaffectation (E24) de la destination dudit au moins un premier bloc de mémoire (CODE_BLOCK) de sorte que d'autres données puissent être mémorisées dans ce bloc à la place dudit code exécutable.

Description

2 3 9 4 1 1 Arrière-plan de l'invention L'invention se situe dans le domaine de l'optimisation des ressources dans une carte à microcircuit.
On connaît en effet aujourd'hui des cartes à microcircuit dans lesquelles les codes exécutables sont mémorisés dans une mémoire morte, par exemple par le fondeur de la cade ; ces programmes sont donc ni modifiables, ni supprimables. L'EEPROM de telles cartes comporte généralement des données 10 créées dynamiquement par les programmes stockés en ROM. Comme ordre de grandeur, on peut retenir que la taille d'une mémoire ROM est comprise entre 160 et 380 Ko, celle d'une mémoire EEPROM entre 4 et 144 Ko. L'usage des mémoires non volatiles réinscriptibles de type Flash 15 dans de telles cartes devient plus fréquent. Dans des soucis d'optimisation, la Demanderesse a proposé, dans le document EP0921469 une carte à microcircuit dont le système d'exploitation est apte à gérer les ressources de mémoire pour réallouer des zones de mémoire vive ou de mémoire non-volatile reprogrammable de type Flash ou EEPROM. 20 Bien que très satisfaisante, cette solution ne permet pas de réutiliser des zones de mémoire dans lesquelles les fabricants mémorisent du code exécutable. L'invention vise notamment une solution à ce problème. 25 Objet et résumé de l'invention Plus précisément, l'invention vise un procédé de personnalisation d'une carte à microcircuit, ce procédé comportant : - une étape d'installation, dans au moins un premier bloc mémoire, d'un 30 code exécutable n'ayant plus d'utilité après une phase de pré-personnalisation de la carte; et - après cette phase de pré-personnalisation de la carte à microcircuit, une étape de réaffectation de la destination du premier bloc de mémoire de sorte que d'autres données puissent être mémorisées dans ce bloc à la 35 place du code exécutable précité. 3 0 2 3 9 4 1 2 Par réaffectation de la destination on comprend que le premier bloc de mémoire est effacé et/ou écrasé en tout ou partie pour contenir d'autres données. Corrélativement, l'invention vise aussi une carte à microcircuit 5 comportant des moyens de gestion de mémoire pour réaffecter, après une phase de pré-personnalisation de ladite carte à microcircuit, la destination d'au moins un premier bloc de mémoire dans lequel était initialement mémorisé du code exécutable n'ayant plus d'utilité après la phase de pré-personnalisation, de sorte que d'autres données puissent être mémorisées 10 dans ce bloc à la place de ce code exécutable. Ainsi, et d'une façon générale, l'invention propose de rendre disponible, toute ou partie de la mémoire occupée par le code exécutable nécessaire à la pré-personnalisation de la carte, ce code étant devenu inutile (ou mort) à l'issue de cette phase. 15 Par exemple, une fois les objets créés, le code nécessaire à la création de ces objets qui n'a plus d'utilité peut être supprimé. L'invention permet ainsi de concevoir des cartes avec moins de mémoire et donc moins chère à fonctions égales. Dans un mode préféré de réalisation, les moyens de gestion de 20 mémoire sont des mis en oeuvre par un système d'exploitation de la carte à microcircuit. Dans un mode particulier de réalisation, la phase de pré-personnalisation comporte la création d'au moins un conteneur de fichier, ce conteneur comportant un en-tête de fichier et une place mémoire 25 réservée pour recevoir des données de personnalisation, au moins un de ces conteneurs étant mémorisé dans un bloc d'une mémoire tampon destiné à être déplacé dans le premier bloc mémoire après la phase de pré-personnalisation. La taille réservée pour recevoir les données de personnalisation 30 peut prendre sa valeur finale au moment du transfert dans CODE_BLOCK, et donc avoir une valeur temporaire quand le conteneur est dans TEM P_BLOCK. Dans un mode particulier de réalisation, le procédé selon l'invention comporte, après l'étape de réaffectation, une étape de déplacement des 35 données contenues dans le bloc de mémoire tampon vers au moins un premier bloc mémoire dans lequel était initialement mémorisé du code 3 0 2 3 9 4 1 3 exécutable n'ayant plus d'utilité après la phase de pré-personnalisation de la carte. Dans un mode particulier de réalisation, le procédé selon l'invention comporte une étape d'écriture de données de personnalisation dans la 5 place mémoire réservée d'un conteneur de fichier. Dans un mode particulier de réalisation du procédé selon l'invention, l'en-tête de fichier mémorisé dans un bloc de mémoire tampon comporte l'adresse à laquelle il devra être déplacé dans un premier bloc mémoire.
Dans un mode particulier de réalisation, ces données de personnalisation comportent des clefs secrètes ou des données biométriques. Les données contenues dans la zone mémoire réaffectée ne sont pas nécessairement supprimées, elles peuvent être écrasées. Mais dans un mode préféré de réalisation, l'étape de réaffectation comporte une étape de suppression du code exécutable n'ayant plus d'utilité après la phase de pré-personnalisation de la carte. L'étape de réaffectation peut être déclenchée sur réception d'un moyen de déclenchement, par exemple, une commande APDU. Cette 20 commande peut être envoyée au lieu de personnalisation de la carte, en utilisant un lecteur de carte. Selon un autre mode de réalisation, le moyen de déclenchement peut être un signal électrique ou électromagnétique, généré par exemple lors de la mise sous tension de la carte. Dans un mode particulier de réalisation, la carte à microcircuit selon 25 l'invention comporte un bloc mémoire de données utilisateurs, et, au cours de la phase de pré-personnalisation, on crée automatiquement dans le bloc de mémoire tampon, les conteneurs de fichiers dont la place mémoire réservée excède la place mémoire disponible dans le bloc mémoire de données utilisateurs. 30 Ce mode de réalisation permet de stocker des données utilisateurs dans le bloc de mémoire tampon avant la réaffectation de la destination du premier bloc de mémoire. On augmente ainsi l'espace mémoire disponible pour les données utilisateurs. 35 302 3 9 4 1 4 Brève description des dessins D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description et des figures annexées de variantes de 5 réalisation de l'invention données à titre d'exemple indicatif et non limitatif, et de : - la figure 1 représente sous forme d'organigramme les principales étapes d'un procédé de personnalisation d'une carte à microcircuit conforme à un mode particulier de réalisation ; 10 - les figures 2A et 2B représentent l'état de la mémoire de la carte à microcircuit de la figure 1 avant et après la phase de pré-personnalisation. Description détaillée d'un mode de réalisation 15 Nous allons maintenant décrire en référence à la figure 1 les principales étapes d'un procédé de personnalisation d'une carte à microcircuit 10 conforme à un mode particulier de réalisation de l'invention.
Comme représenté à la figure 2, la carte à microcircuit 10 comporte un processeur 12, un système d'exploitation 14, et des moyens 16 de communication avec un lecteur non représenté. Ce procédé comporte une phase préliminaire E10 de génération de code au cours de laquelle on identifie les modules logiciels MOD qui n'auront plus d'utilité après la phase de pré-personnalisation de la carte à microcircuit, le code exécutable de ces modules pouvant être supprimé à la fin de la phase de pré-personnalisation pour libérer la place mémoire occupée par ce code exécutable, celle-ci pouvant ainsi être réutilisée. Cette phase préliminaire E10 de conception peut être réalisée 30 manuellement ou automatiquement dès lors que l'on sait automatiquement repérer les modules logiciels dont les codes exécutables ne sont plus utiles après. Il peut en particulier et notamment s'agir des modules de création de codes PIN, des modules de création (CreateFileQ), de déplacement 35 (MoveFileQ) et de destruction (DeleteFile()) de fichiers, des modules d'allocation (malloc()) et de libération (free()) de mémoire, ...
Cette phase préliminaire E10 est suivie par une étape E12 de marquage des modules logiciels identifiés. Dans le mode de réalisation décrit ici, cette étape de marquage consiste à insérer dans le code source du module une instruction destinée au compilateur pour placer ce code 5 dans un bloc réservé à cet effet. Dans le mode de réalisation décrit ici, cette étape de marquage consiste à spécifier une classe dans les propriétés du code source du module : userclass (CODE=BLOCK) 10 Au cours d'une étape E14, on définit le bloc dans lequel les codes exécutables destinés à être ultérieurement supprimés doivent être mémorisés. Dans le mode de réalisation décrit ici, tous ces codes exécutables MOD sont placés dans un même bloc « CODE_BLOCK » compris dans la 15 plage d'adresses [C:OxA400-C:OxFFFF] mais en variante plusieurs blocs, contigus ou non, peuvent être utilisés à cet effet. Cette étape E14 consiste à donner une instruction au linker, du type : CODE_BLOCK(C:OxA400-C:OxFFFF) 20 Les fichiers sources sont ensuite compilés au cours d'une étape E16. Cette étape génère, comme de façon connue, un fichier de « mapfile », permettant de connaître la taille effectivement occupée par le code MOD dans le bloc « CODE_BLOCK », 14D4H dans cet exemple : BASE START END USED MEMORY CLASS C :000000H C :00A400H C :00FFFFH 0014D4H CODE_BLOCK Dans l'exemple décrit ici, la taille du bloc « CODE_BLOCK » qui 25 pourra être réalloué après personnalisation est de 5332 octets (correspondant à la valeur hexadécimale 14D4). Conformément à l'invention, les données qui sont destinées à être déplacées dans le bloc « CODE_BLOCK » après la phase de pré-personnalisation sont temporairement mémorisées dans un bloc de 30 mémoire tampon, ci-après référencé « TEMP_BLOCK », de la mémoire non-volatile réinscriptible (étape E18). Elles seront déplacées dans le bloc « CODE_BLOCK » après la phase de pré-personnalisation, quand les codes exécutables initialement placés dans ce bloc « CODE_BLOCK » n'auront plus d'utilité.
302 3 9 4 1 6 Dans le mode de réalisation décrit ici, les données mémorisées temporairement dans le bloc de mémoire tampon « TEMP_BLOCK » peuvent être compressées ; elles peuvent par exemple être placées sous forme compressée dans une zone ZO d'un conteneur CONT, ce conteneur 5 comportant un en-tête H dans lequel on enregistre l'adresse à laquelle les données doivent être déplacées dans le bloc mémoire après la phase de pré-personnalisation. D'autres données peuvent être mémorisées, comme de façon connue, dans un bloc REGULAR_BLOCK 10 La figure 2A représente la carte à micro-circuit avant la phase de pré-personnalisation. Après la pré-personnalisation (étape E20) le code exécutable contenu dans le bloc CODE_BLOCK n'a plus d'utilité. Dans le mode de réalisation décrit ici, on place la carte à micro-15 citrcuit dans un lecteur afin de lui envoyer une commande APDU (étape E22), la réception de cette commande par le système d'exploitation de la carte déclenchant (E26) la décompression et le déplacement des données comprises dans la zone ZO de chaque conteneur vers le bloc CODE_BLOCK à l'adresse contenue dans l'en-tête H de ce conteneur.
20 Cette opération consistant à réaffecter ainsi la destination du bloc CODE_BLOCK après la pré-personnalisation permet d'optimiser les ressources mémoires de la carte à microcircuit. La figure 2B représente la carte à micro-circuit à la fin de la phase de pré-personnalisation.
25 Il apparaît que le code exécutable MOD a été supprimé que le bloc CODE_BLOCK comporte maintenant les données qui étaient compressés dans la zone ZO sous forme décompressée (ZO*). Cette étape de réaffectation (E24) n'impacte pas le bloc REG U LAR_BLOCK.

Claims (13)

  1. REVENDICATIONS1. Procédé de personnalisation d'une carte à microcircuit, ce procédé comportant : - une étape d'installation, dans au moins un premier bloc mémoire (CODE_BLOCK), d'un code exécutable n'ayant plus d'utilité après une phase de pré-personnalisation de ladite carte; et 10 - après ladite phase de pré-personnalisation de ladite carte à microcircuit, une étape (E24) de réaffectation de la destination dudit au moins un premier bloc de mémoire (CODE_BLOCK) de sorte que d'autres données puissent être mémorisées dans ce bloc à la place dudit code exécutable. 15
  2. 2. Procédé de personnalisation selon la revendication 1 caractérisé en ce que: - ladite phase de pré-personnalisation comporte la création d'au moins un conteneur de fichier, ledit conteneur comportant un en-tête de fichier et une place mémoire réservée pour recevoir des données de 20 personnalisation, au moins un desdits conteneurs étant mémorisé dans un bloc d'une mémoire tampon (TEMP_BLOCK) destiné à être déplacé dans ledit premier bloc mémoire (CODE_BLOCK) après ladite phase de pré-personnalisation. 25
  3. 3. Procédé de personnalisation selon la revendication 2, caractérisé en ce qu'il comporte, après ladite étape de réaffectation : - une étape (E26) de déplacement des données contenues dans ledit bloc de mémoire tampon (TEMP_BLOCK) vers ledit au moins un premier bloc mémoire (CODE_BLOCK). 30
  4. 4. Procédé de personnalisation selon l'une quelconque des revendications 1 à 3 caractérisé en ce qu'il comporte une étape d'écriture de données de personnalisation dans la place mémoire réservée dudit conteneur de fichier. 35 302 3 9 4 1 8
  5. 5. Procédé selon l'une quelconque des revendications 2 à 4, caractérisé en ce que l'en-tête de fichier mémorisé dans ledit bloc de mémoire tampon (TEMP_BLOCK) comporte l'adresse à laquelle il devra être déplacé dans ledit au moins un premier bloc mémoire (CODE_BLOCK).
  6. 6. Procédé selon l'une quelconque des revendications 2 à 5, caractérisé en ce que lesdites données de personnalisation comportent des clefs secrètes ou des données biométriques.
  7. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ladite étape de réaffectation comporte une étape de suppression du code exécutable n'ayant plus d'utilité après ladite phase de personnalisation.
  8. 8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce qu'il comporte un moyen pour déclencher ladite étape de réaffectation.
  9. 9. Procédé selon la revendication 8, caractérisé en ce que ledit moyen est une commande APDU.
  10. 10. Procédé selon la revendication 8, caractérisé en ce que ledit moyen est un signal électrique ou électromagnétique. 25
  11. 11. Procédé selon l'une quelconque des revendications 2 à 10, caractérisé en ce que la carte à microcircuit comporte un bloc mémoire (REGULAR_BLOCK) de données utilisateurs, et en ce que, au cours de ladite phase de pré-personnalisation, on crée automatiquement dans ledit 30 bloc de mémoire tampon (TEMP_BLOCK), les conteneurs de fichier dont la place mémoire réservée excède la place mémoire disponible dans ledit bloc mémoire (REGULAR_BLOCK) de données utilisateurs.
  12. 12. Carte à microcircuit comportant : 35 - des moyens de gestion de mémoire aptes à réaffecter, après une phase de pré-personnalisation de ladite carte à microcircuit, au moins un premierbloc de mémoire (CODE_BLOCK) dans lequel était initialement mémorisé du code exécutable n'ayant plus d'utilité après ladite phase de pré-personnalisation de sorte que d'autres données puissent être mémorisées dans ce bloc à la place dudit code exécutable.
  13. 13. Carte à microcircuit selon la revendication 12, caractérisé en ce que lesdits moyens de gestion de mémoire sont mis en oeuvre par un système d'exploitation de ladite carte.
FR1457021A 2014-07-21 2014-07-21 Procede de personnalisation d'une carte a microcircuit Active FR3023941B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1457021A FR3023941B1 (fr) 2014-07-21 2014-07-21 Procede de personnalisation d'une carte a microcircuit

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1457021A FR3023941B1 (fr) 2014-07-21 2014-07-21 Procede de personnalisation d'une carte a microcircuit

Publications (2)

Publication Number Publication Date
FR3023941A1 true FR3023941A1 (fr) 2016-01-22
FR3023941B1 FR3023941B1 (fr) 2017-11-24

Family

ID=51519102

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1457021A Active FR3023941B1 (fr) 2014-07-21 2014-07-21 Procede de personnalisation d'une carte a microcircuit

Country Status (1)

Country Link
FR (1) FR3023941B1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3588308A1 (fr) * 2018-06-28 2020-01-01 IDEMIA France Configuration d'un dispositif électronique

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2687816A1 (fr) * 1992-02-24 1993-08-27 Gemplus Card Int Procede de personnalisation d'une carte a puce.
EP0957461A1 (fr) * 1998-05-14 1999-11-17 Sagem Sa Procédé de personnalisation d'une carte à puce
EP1376492A1 (fr) * 2002-06-24 2004-01-02 Canal + Technologies Personnalisation de logiciels protégés pour carte à puce
WO2007042533A1 (fr) * 2005-10-14 2007-04-19 Gemplus Personnalisation de carte a puce

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2687816A1 (fr) * 1992-02-24 1993-08-27 Gemplus Card Int Procede de personnalisation d'une carte a puce.
EP0957461A1 (fr) * 1998-05-14 1999-11-17 Sagem Sa Procédé de personnalisation d'une carte à puce
EP1376492A1 (fr) * 2002-06-24 2004-01-02 Canal + Technologies Personnalisation de logiciels protégés pour carte à puce
WO2007042533A1 (fr) * 2005-10-14 2007-04-19 Gemplus Personnalisation de carte a puce

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JOLIET C: "An integrated personalization workshop for smart cards", PROCEEDINGS OF THE ESCAT CONFERENCE, XX, XX, 4 September 1991 (1991-09-04), pages 99 - 108, XP002108140 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3588308A1 (fr) * 2018-06-28 2020-01-01 IDEMIA France Configuration d'un dispositif électronique
FR3083341A1 (fr) * 2018-06-28 2020-01-03 Idemia France Configuration d'un dispositif electronique

Also Published As

Publication number Publication date
FR3023941B1 (fr) 2017-11-24

Similar Documents

Publication Publication Date Title
EP2786317B1 (fr) Ecriture de données dans une mémoire non volatile de carte à puce
WO2003040917A3 (fr) Mise en oeuvre d'une programmation systeme de mise a jour de micrologiciel sur des cartes memoires
WO2001084320A3 (fr) Systeme et procede permettant a un terminal de communication de gerer la memoire et de tenir a jour une version d'application courante pour plusieurs applications
EP2447835B1 (fr) Procédé de configuration d'une entité électronique
WO2013045101A1 (fr) Procede d'effacement d'informations memorisees dans une memoire reinscriptible non volatile, support de memorisation et calculateur de vehicule automobile
FR3023941A1 (fr) Procede de personnalisation d'une carte a microcircuit
EP1046108A1 (fr) Protocole d'echange interne de donnees entre applications d'un objet portatif multi-applications et objet portatif multi-applications correspondant
CN109643239B (zh) Java卡应用存储器占用空间优化
FR2823330A1 (fr) Procede et systeme de gestion de donnees destinees a etre stockees dans une memoire, par exemple du code d'une application charge dans une carte a puce programmable
EP2530586B1 (fr) Procédé de génération d'un logiciel
FR3051061B1 (fr) Procede de sauvegarde et de restauration de donnees d'un element securise
CN111414339A (zh) 一种文件的处理方法、系统、装置、设备及介质
EP2901291B1 (fr) Procédé de gestion des ressources mémoire d'un dispositif de sécurité, tel qu'une carte à puce, et dispositif de sécurité mettant en oeuvre ledit procédé.
FR2835628A1 (fr) Gestion de la mise a jour d'informations encodees en memoire
CN106657092B (zh) 一种基于ssl/tls的业务处理方法及装置
WO2001059788A1 (fr) Ecriture en temps reel securisee pour memoire volatile
CN107704247B (zh) 一种减小多核固件大小的方法
FR2689662A1 (fr) Procédé de protection d'une carte à puce contre la perte d'information.
EP3588308B1 (fr) Configuration d'un dispositif électronique
US20190188689A1 (en) Loading a java card memory with a java card package through a card personalization specification flow
FR3041796A1 (fr) Stockage et lecture d'un code d'authentification de message dans une memoire externe
WO2009040204A1 (fr) Procede de generation de masques dans un objet communiquant et objet communiquant correspondant
FR3074317B1 (fr) Procede d'acces a une zone memoire non volatile de type flash d'un element securise, tel qu'une carte a puce
CN103942297A (zh) 基于图片对比结果以通过网络调用相关信息的方法
FR3028642A1 (fr) Procede de personnalisation d'un microcircuit avec ecriture d'une partie compressee d'entite logicielle, et procede d'utilisation et microcircuit correspondants

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20160122

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8

PLFP Fee payment

Year of fee payment: 9

CA Change of address

Effective date: 20230220

CD Change of name or company name

Owner name: IDEMIA FRANCE, FR

Effective date: 20230220

PLFP Fee payment

Year of fee payment: 10

PLFP Fee payment

Year of fee payment: 11