WO2007082900A1 - Dispositif electronique portable apte a fournir un contenu dynamique - Google Patents

Dispositif electronique portable apte a fournir un contenu dynamique Download PDF

Info

Publication number
WO2007082900A1
WO2007082900A1 PCT/EP2007/050458 EP2007050458W WO2007082900A1 WO 2007082900 A1 WO2007082900 A1 WO 2007082900A1 EP 2007050458 W EP2007050458 W EP 2007050458W WO 2007082900 A1 WO2007082900 A1 WO 2007082900A1
Authority
WO
WIPO (PCT)
Prior art keywords
electronic device
portable electronic
application
block
microprocessor
Prior art date
Application number
PCT/EP2007/050458
Other languages
English (en)
Inventor
Frédéric Faure
Pascal Di Girolamo
Pierre Girard
Original Assignee
Gemplus
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 Gemplus filed Critical Gemplus
Publication of WO2007082900A1 publication Critical patent/WO2007082900A1/fr

Links

Classifications

    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11C—STATIC STORES
    • G11C7/00—Arrangements for writing information into, or reading information out from, a digital store
    • G11C7/10—Input/output [I/O] data interface arrangements, e.g. I/O data control circuits, I/O data buffers
    • G11C7/1006—Data managing, e.g. manipulating data before writing or reading out, data bus switches or control circuits therefor

Definitions

  • Portable electronic device capable of providing dynamic content.
  • the present invention relates to the general field of portable electronic devices accessible by data blocks intended to communicate with a host electronic device, in particular to the domains of USB keys, non-volatile memory cards, portable hard disks. etc.
  • these portable electronic devices do not have their own power supply.
  • an application microprocessor intended, at least, to perform the primary functions of the device, which may in particular be to carry out a data storage.
  • a microprocessor is generally a memory controller and / or an input / output controller.
  • This memory controller typically has the role of managing memory blocks and communications with the host device. These communications are performed according to a communication protocol with a non-volatile memory.
  • the controller or an intelligent chip such as a smart card chip integrated with the portable device executes an additional application whose execution result is intended to be exploited by the host device, it is necessary to provide the host device of specific software elements (driver in English) allowing it to manage the data exchange necessary for the execution of this application.
  • specific software elements driver in English
  • the addition of a software element can be difficult, complex or impossible depending on the context encountered.
  • the main purpose of the present invention is therefore to overcome such drawbacks by proposing a portable electronic device such that the application microprocessor with which it is equipped is capable of generating data dynamically, it includes processing means able to process the data generated as contents of a nonvolatile memory during communications with the host device.
  • the host device communicates with the application microprocessor without using any other specific protocol than that used for communication with a non-volatile memory, for example the MMC protocol. This eliminates the need to install additional protocol stacks in the host device.
  • the invention is particularly useful for security applications that are easily and simply implemented with the help of the invention. Indeed, given the host device, a simple request to access data stored in a memory allows for example to dynamically generate a key and simply return to the host device the value of the key generated as blocks of data.
  • said processing means consist of a memory controller able to manage memory blocks and presenting the data generated to the host device as block contents of a non-volatile memory.
  • the invention redirects a memory block read request to a programmable entity whose role is to generate a dynamic block content.
  • the host device sees a non-volatile memory whose content is made dynamic thanks to the invention.
  • the portable device comprises at least one non-volatile memory accessible in blocks and managed by said memory controller.
  • a request for access to a block of the non-volatile memory being sent by the host device the memory controller redirects the request to the application microprocessor when the block to access is a block corresponding to data generated by the application microprocessor.
  • all access requests to a memory block are redirected to the application microprocessor which indicates in return to the controller whether or not it manages the corresponding block.
  • the application microprocessor declares itself to the processing means for managing a set of blocks said to be redirected.
  • the declaration can indicate a number of blocks to redirect or a maximum size of data to be managed, the processing means then respond to the declaration by the allocation of a set of block identifiers, the identifier can in particular be an address Virtual.
  • the declaration can also indicate virtual addresses of blocks to redirect.
  • said application microprocessor is able to withdraw from the management of a set of blocks said to be redirected.
  • the processing means are able to process this request and to redirect it to the application microprocessor when the processing of the File data access request requires access to data generated by the application microprocessor.
  • the data generated by the application microprocessor being data from a file allocation table or requiring a modification of data in a file allocation table stored within the portable device
  • the processing means are capable of blocking the access of the host device to the memory blocks of the portable device, such blocking being activated at each modification of the file allocation table within the portable device and the portable electronic device includes means update to trigger, subsequent to the blocking, an update of a file allocation table within the host device.
  • the memory controller and the application microprocessor are implemented by the same component.
  • the application microprocessor is the processor of a smart card type chip.
  • FIG. 1 is a schematic illustration of a portable electronic device according to the invention and its registration with a host electronic device;
  • FIG. 2 is a schematic illustration of the operation of an electronic device according to the invention when receiving requests from a host device;
  • FIG. 3 is a schematic illustration of an update of an allocation table within a host electronic device connected to a portable device according to the invention.
  • FIG. 1 represents a portable electronic device 10 according to the invention in connection with a host electronic device 11.
  • portable electronic device means any electronic device comprising at least one application microprocessor 12 intended for implementing applications, for example security applications.
  • a device can be any storage component comprising a memory accessible in blocks, for example, a USB key, a portable hard disk, a smart card, a memory card etc.
  • Application microprocessor means the processor for the realization of the functional applications of the portable electronic device. This will be for example the processor of a smart card. According to the invention, besides the execution of the functional applications, the application microprocessor 12 is able to dynamically generate data. For this purpose it implements specific applications. For example, the application microprocessor 12 may generate security keys.
  • the term "host device” means any electronic device that can be connected to a portable electronic device according to the invention. It could be a mobile phone, a computer, an electronic personal assistant, a game console etc.
  • the portable electronic device further comprises processing means 13 able to communicate with the application microprocessor 12, for example via an internal bus. These processing means 13 are able to process the data generated by the application microprocessor 12 as contents of a non-volatile memory during communications with the host device 11.
  • the host device 11 communicates with the portable device 10 according to a communication protocol with a non-volatile memory, for example MMC, USB, SD, via a communication driver intended to work with a controller managing a non-volatile memory within of the portable device 10.
  • the processing means 13 are therefore a controller 13 capable of managing a non-volatile memory.
  • the portable electronic device 10 potentially comprises a non-volatile memory 14, for example a flash memory.
  • This non-volatile memory 14 is managed by a memory controller 13 which, in the illustrative example proposed, advantageously constitutes the processing means.
  • the role of such a controller 13 is conventionally to manage the reading and writing of data in or from blocks of the non-volatile memory 14.
  • the controller includes a block-oriented driver and any request for reading, writing or erasing data is transcribed into requests for reading, writing or erasing data blocks identified by their block identifier.
  • the application microprocessor 12 is previously declared to the processing means 13 for managing a set of blocks said to be redirected.
  • the reporting mechanism is illustrated in Figure 1.
  • the memory controller 13 sends an initialization request IR to Application microprocessor 12.
  • the IF information is taken into account in a dedicated table.
  • This dedicated table lists additional memory blocks reported as being managed by the application microprocessor 12.
  • the communicated information IF may be accompanied by a restriction on the type of access request to be managed by the application microprocessor 12 such as reading, writing or erasure.
  • the additional blocks are, for example, listed after the memory blocks corresponding to the blocks of the non-volatile memory 14.
  • blocks 00 to 3F are the blocks managed within the non-volatile memory 14
  • the following blocks 40 to 4B are additional blocks that will be managed according to the invention by the application microprocessor 12.
  • the controller 13 indicates identifiers, each associated with a block.
  • identifiers may be virtual addresses of blocks as known from the host device 11 or be identifiers specific to the communication between the controller 13 and the application microprocessor 12. In the latter case, the identifiers are correlated with the virtual addresses known by the host device listed in the dedicated table maintained by the controller. A specific correspondence table can be stored in the controller for this purpose.
  • the controller returns block identifiers as block addresses [40 ... 4B].
  • the IF information sent by the application microprocessor 12 directly includes the addresses of the blocks to be redirected.
  • the information communicated in return by the controller 13 may be an identifier associated with each of the addresses.
  • the register indicates to the application microprocessor 12 block identifiers associated with each application so that the application microprocessor 12 is able to route requests using the blocks corresponding to these identifiers to the application concerned.
  • the identifiers can be directly the virtual addresses as known by the host device or identifiers specific to the communication between the controller 13 and the application microprocessor 12.
  • a quantity of necessary blocks or virtual addresses may be indicated by each or some of the applications.
  • a particular application is responsible for routing access requests to the applications that have registered according to the identifiers that are indicated in the applications. queries.
  • All the applications executed by the application microprocessor 12 which are capable of managing additional blocks according to the invention are therefore also registered with this application routing application.
  • the identifier previously returned by the controller 13 during the registration of each application will allow the routing application to route a request in which this identifier is indicated to the application (s) concerned (s) concerned (s).
  • the controller 13 does not manage the dedicated table of the addresses and / or block identifiers managed by the application microprocessor 12.
  • Each request read, write or erase blocks received by the controller 13 is redirected to the application microprocessor 12 which indicates whether or not it manages the contents of this block. If it manages it, it will return the content itself after generation. Otherwise, the controller takes the request at his expense.
  • FIG. 2 illustrates the processing of requests for access to managed blocks according to the invention.
  • a request R [X] for access to an X block according to a communication protocol with a memory for example the MMC protocol
  • the controller 13 looks in the table dedicated if the current request is to be managed by the application microprocessor 12. If yes, the request is redirected to the application microprocessor 12 so that it returns a dynamically generated block content. Otherwise, the request is conventionally managed by the memory controller 13 for reading, erasing or writing the data of the block X in the nonvolatile memory 14.
  • the processing means 13 after having found that the block X is managed by the application microprocessor 12 in the dedicated table, then send a signal S [X] to the application microprocessor 12.
  • This signal S [X] may trigger an internal action of the application microprocessor 12, such as generating a data set of size equal to or larger than the size of a block.
  • the data generated is the content GD [X] of the block X communicated back to the processing means 13.
  • These generated data GD [X] may be also be stored in a buffer memory of the application microprocessor 12.
  • the processing means 13 then respond to the request R [X] of the host device 11 by sending it these data GD [X] according to said communication protocol with a memory, that is to say in this case in the form content of a memory block.
  • a portion of the data generated will correspond to the content GD [X] of the block X which will be sent to the processing means 13 so that they respond to the request.
  • host device 11 and the other data generated will be stored in a buffer of the application microprocessor 12 and correspond to the contents GD [Y ... Y + N] of other blocks managed by the application microprocessor 12.
  • the processing means 13 send a signal S [X] to the application microprocessor 12 so that it triggers the request. erasing the block X.
  • this request can easily be forbidden or not by the application microprocessor 12.
  • the application microprocessor 12 can indicate to the processing means 13 that it no longer manages the block X.
  • the processing means 13 send a signal S [X] to the application microprocessor 12 so that it triggers the modification of the block X.
  • This modification can cause an action of the application microprocessor 12 which can be a generation data GD [X] which will then be read during a read request of the X block.
  • requests for writing, reading or erasing data in a non-volatile memory are processed dynamically by a microprocessor, it is possible to protect the data generated by the application microprocessor against modification or deletion. from the host device. It is also possible to implement the invention in such a way that a request to read, write or delete a block triggers an additional processing action such as a login, a copy, a message sending, a signature of data, etc. in addition to dynamic data generation.
  • the request R [X] is performed as part of a file modification.
  • a file allocation table within the portable electronic device 10 lists the blocks necessary for the constitution of each of the files stored in the portable device 10. For example, there exists in this table a file "smartcard.txt" of a size of 512 bytes whose address of the first block is known. The blocks constituting the contents of the file can be managed according to the invention.
  • the controller 13 searches in the dedicated table if the different block write requests must be managed by the application microprocessor 12. When this is the case, the controller 13 sends the block write requests to the application microprocessor 12. Each received block write request is interpreted by the application routing application of the application microprocessor 12. This routing application triggers the application to which the access request is intended. In the aforementioned case where the command sent is an APDU command, this application will execute said command to the application microprocessor 12 and will store in an internal buffer memory of the application microprocessor 12 the result of the execution of this command.
  • the controller 13 When the application of the host device 11 requires a reading of this file, the controller 13 will redirect read requests from blocks to the application microprocessor 12.
  • the application routing application will route each request to the relevant registered application. In the above example, the application will return to each block read request the content of the APDU response previously stored in a buffer internal to the application microprocessor 12.
  • the block or file content is then communicated to the host device 11 as if it came from physical blocks of the non-volatile memory 14, the invention is therefore transparent from the point of view of the host device 11.
  • the data exchanged between the host device 11 and the application microprocessor 12, especially in the context of file modification can be encoded in various formats, for example in base64.
  • a file calculating a digital signature "digital-signature.txt” can also be advantageously managed using the invention: the data to be signed are written in this file by redirection to the application microprocessor which then generates the signature and the reading of the file returns the digital signature of the written data.
  • the application microprocessor which then generates the signature and the reading of the file returns the digital signature of the written data.
  • such an application can cause changes in the size of the file "digital-signature.txt" which requires changes in a file allocation table.
  • the file allocation table whose function is to describe the file system is copied from the portable device 10 to a dynamic memory of the host device 11 and is entirely managed by the host device 11. Therefore, only the applications of the host device 11 can interact with the file system.
  • the application microprocessor must have means for modifying the allocation table or the blocks associated with the allocation table within the portable device 10 must be managed according to the invention by the application microprocessor 12.
  • any command from the host device 11 must be blocked during the update of the allocation table within the portable device 10.
  • the portable device must have means for updating the allocation table of the host device 11.
  • the application microprocessor 12 manages at least a portion of the data of a file allocation table.
  • the name, the size and the content of certain files can be completely or partially managed by the application microprocessor 12, and therefore, if necessary, by the smart card on which it is implemented.
  • the portable electrical device shown in FIGS. 1 and 2 presents a three-component architecture, the memory 14, the memory controller 13 and a component including the application microprocessor 12, for example a smart chip such as a smart card chip. . Note that, in a variant, it is possible to merge the controller and the smart card into a single component to obtain a two-component architecture.
  • FIG. 3 presents a mechanism for updating a file allocation table 31 in the context of such a two-component architecture comprising a processor 30 combining the functions of the application microprocessor and those of the controller.
  • an application running on the processor dynamically manages the contents of the allocation table 31 and the contents of the associated file.
  • a prior blocking step LK of access to the memory blocks by the host device 11 is performed by the processor 30 to prevent any modification by the host device 11.
  • the blocking routines can be integrated into the operating software of the processor 30.
  • the blocking LK is raised, either after a predefined period of time or at the initiative of the processor 30.
  • an NTF notification step of the modifications to the host device 11 by the processor 30 takes place.
  • This NTF notification step can be done according to a polling mechanism implemented in the host device 11. It can use a specific bus or a generic communication bus between the processor 30 and the host device 11.
  • the host device 11 Upon receipt of this NTF notification, the host device 11 requires, by an RR request, a reading of the file allocation table 31 in the portable device 10.
  • the request RR may concretely take the form of a restart of the port on which the portable device is connected, for example a USB port.
  • the processor 30 unblocks access to the allocation table 31 and the memory blocks. The host device 11 then refreshes its file allocation table 31 '.
  • the processor 30 naturally has means for modifying a content of the non-volatile memory 14 since it has a role of controller of this memory 14.
  • the application microprocessor in a three-component architecture it will then be necessary for the application microprocessor to be able to send a modification command to the allocation table to the controller, itself able to change the content of the allocation table in the non-volatile memory that it controls. .

Landscapes

  • Stored Programmes (AREA)

Abstract

L'invention concerne un dispositif électronique portable [10] destiné à communiquer avec un dispositif électronique hôte [11], ledit dispositif électronique portable [10] comprenant au moins un microprocesseur dit applicatif [12]. Selon l'invention, le microprocesseur applicatif [12] étant apte à générer des données [GD[X]] dynamiquement, le dispositif électronique portable [10] inclut des moyens de traitement [13] aptes à traiter les données générées [GD[X]] comme des contenus d'une mémoire non volatile lors de communications avec le dispositif hôte [11].

Description

Titre de l'invention
Dispositif électronique portable apte à fournir un contenu dynamique.
Arrière-plan de l'invention La présente invention se rapporte au domaine général des dispositifs électroniques portables accessible par blocs de données destinés à communiquer avec un dispositif électronique hôte, notamment aux domaines des clés USB, des cartes mémoire non volatile, des disques durs portatifs etc.
Généralement, ces dispositifs électroniques portables ne possèdent pas leur propre alimentation. Ils sont en revanche munis d'un microprocesseur applicatif destiné à, au moins, réaliser les fonctions premières du dispositif qui peut notamment être de réaliser un stockage de données. Dans ce cas un tel microprocesseur est généralement un contrôleur de mémoire et/ou un contrôleur d'entrée / sortie. Ce contrôleur de mémoire a classiquement pour rôle la gestion de blocs mémoire et les communications avec le dispositif hôte. Ces communications sont réalisées selon un protocole de communication avec une mémoire non volatile.
Ainsi, si on souhaite que le contrôleur ou une puce intelligente telle qu'une puce de carte à puce intégrée au dispositif portable exécute une application additionnelle dont le résultat d'exécution est destiné à être exploité par le dispositif hôte, il est nécessaire de munir le dispositif hôte d'éléments logiciels spécifiques (driver en anglais) lui permettant de gérer les échanges de données nécessaires à l'exécution de cette application. Or, l'ajout d'un élément logiciel peut s'avérer difficile, complexe ou impossible selon le contexte rencontré.
En effet, en l'absence de droit d'administrateur, l'utilisateur d'un ordinateur ne pourra pas installer un tel élément logiciel et la nécessité de redémarrer le dispositif hôte pour installer de nouveaux éléments logiciels peut s'avérer préjudiciable dans certaines circonstances. On sait aussi que l'ajout d'éléments logiciels est délicat dans le cas de certains dispositifs hôte comme les consoles de jeux voire impossible dans le cas de dispositif hôte basique, comme un téléphone mobile.
En outre, on sait que les ressources en mémoire des dispositifs électroniques portables sont souvent limitées, notamment pour des raisons de coûts. Cela limite d'autant les capacités de développement de ces dispositifs portables en terme de mise en oeuvre d'applications exécutables. Objet et résumé de l'invention
La présente invention a donc pour but principal de pallier de tels inconvénients en proposant un dispositif électronique portable tel que, le microprocesseur applicatif dont il est muni étant apte à générer des données dynamiquement, il inclut des moyens de traitement aptes à traiter les données générées comme des contenus d'une mémoire non volatile lors de communications avec le dispositif hôte.
Il est alors possible pour le dispositif hôte de dialoguer avec le microprocesseur applicatif sans utiliser d'autre protocole spécifique que celui utilisé pour la communication avec une mémoire non volatile, par exemple le protocole MMC. Cela évite d'avoir à installer d'autres piles de protocole dans le dispositif hôte.
Le déploiement d'applications diverses est ainsi rendu possible sans modification logicielle ou matérielle du dispositif hôte puisque les interventions du microprocesseur applicatif sont transparentes du point de vue du dispositif hôte.
L'invention est particulièrement utile pour les applications de sécurité qui sont aisément et simplement mises en œuvre avec l'aide de l'invention. En effet, vu du dispositif hôte, une simple requête pour accéder à des données stockées dans une mémoire permet par exemple de générer dynamiquement une clé et de simplement retourner au dispositif hôte la valeur de la clé générée sous forme de blocs de données.
Dans un mode de réalisation, lesdits moyens de traitement sont constitués par un contrôleur de mémoire apte à gérer des blocs mémoire et présentant les données générées au dispositif hôte comme des contenus de blocs d'une mémoire non volatile.
Ainsi, par exemple, l'invention redirige une requête de lecture de bloc mémoire vers une entité programmable dont le rôle est de générer un contenu de bloc dynamique. Le dispositif hôte voit une mémoire non volatile dont le contenu est rendu dynamique grâce à l'invention.
Avantageusement, le dispositif portable comprend au moins une mémoire non volatile accessible par blocs et gérée par ledit contrôleur de mémoire.
Dans une mise en oeuvre de l'invention, une requête d'accès à un bloc de la mémoire non volatile étant envoyée par le dispositif hôte, le contrôleur de mémoire redirige la requête vers le microprocesseur applicatif lorsque le bloc à accéder est un bloc correspondant à des données générées par le microprocesseur applicatif.
Dans une autre mise en œuvre de l'invention, toutes les requêtes d'accès à un bloc mémoire sont redirigées vers le microprocesseur applicatif qui indique en retour au contrôleur s'il gère ou non le bloc correspondant
Dans un mode de réalisation, le microprocesseur applicatif se déclare auprès des moyens de traitement pour la gestion d'un ensemble de blocs dits à rediriger.
Il s'agit pour le microprocesseur applicatif de s'enregistrer auprès des moyens de traitement.
La déclaration peut indiquer un nombre de blocs à rediriger ou une taille maximum de données à gérer, les moyens de traitement répondent alors à la déclaration par l'attribution d'un ensemble d'identifiants de blocs, l'identifiant pouvant notamment être une adresse virtuelle. La déclaration peut aussi indiquer des adresses virtuelles de blocs à rediriger.
Avantageusement, ledit microprocesseur applicatif est apte à se retirer de la gestion d'un ensemble de blocs dits à rediriger.
Dans une application avantageuse de l'invention, une requête d'accès aux données d'un fichier étant envoyée par le dispositif hôte, les moyens de traitement sont aptes à traiter cette requête et à la rediriger vers le microprocesseur applicatif lorsque le traitement de la requête d'accès aux données du fichier requiert l'accès à des données générées par le microprocesseur applicatif. Dans une mise en œuvre de l'invention, les données générées par le microprocesseur applicatif étant des données d'une table d'allocation de fichier ou nécessitant une modification de données dans une table d'allocation de fichier stockée au sein du dispositif portable, les moyens de traitement sont aptes à bloquer l'accès du dispositif hôte aux blocs mémoire du dispositif portable, un tel blocage étant activé à chaque modification de la table d'allocation de fichier au sein du dispositif portable et le dispositif électronique portable inclut des moyens de mise à jour pour déclencher, de manière subséquente au blocage, une mise à jour d'une table d'allocation de fichier au sein du dispositif hôte.
Dans une variante de l'invention, le contrôleur de mémoire et le microprocesseur applicatif sont mis en œuvre par le même composant. Dans une réalisation, le microprocesseur applicatif est le processeur d'une puce du type carte à puce.
Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
- la figure 1 est une illustration schématique d'un dispositif électronique portable selon l'invention et de son enregistrement auprès d'un dispositif électronique hôte ;
- la figure 2 est une illustration schématique du fonctionnement d'un dispositif électronique selon l'invention lors de la réception de requêtes en provenance d'un dispositif hôte ; - la figure 3 est une illustration schématique d'une mise à jour d'une table d'allocation au sein d'un dispositif électronique hôte relié à un dispositif portable selon l'invention.
Description détaillée d'un mode de réalisation La figure 1 représente un dispositif électronique portable 10 selon l'invention en relation avec un dispositif électronique hôte 11.
On entend par dispositif électronique portable tout dispositif électronique comprenant au moins un microprocesseur applicatif 12 destiné à la mise en œuvre d'applications, par exemple de sécurité. En particulier, un tel dispositif peut être tout composant de stockage comprenant une mémoire accessible par blocs, par exemple, une clé USB, un disque dur portatif, une carte à puce, une carte mémoire etc.
On entend par microprocesseur applicatif, le processeur destiné à la réalisation des applications fonctionnelles du dispositif électronique portable. Il s'agira par exemple du processeur d'une carte à puce. Selon l'invention, outre l'exécution des applications fonctionnelles, le microprocesseur applicatif 12 est apte à générer dynamiquement des données. A cet effet il met en œuvre des applications spécifiques. Par exemple, le microprocesseur applicatif 12 peut générer des clés de sécurité. On entend par dispositif hôte tout dispositif électronique susceptible d'être relié à un dispositif électronique portable selon l'invention. Il peut s'agir d'un téléphone mobile, d'un ordinateur, d'un assistant personnel électronique, une console de jeux etc.
Le dispositif électronique portable comprend en outre des moyens de traitement 13 en mesure de communiquer avec le microprocesseur applicatif 12 par exemple par l'intermédiaire d'un bus interne. Ces moyens de traitement 13 sont aptes à traiter les données générées par le microprocesseur applicatif 12 comme des contenus d'une mémoire non volatile lors de communications avec le dispositif hôte 11.
En effet, le dispositif hôte 11 communique avec le dispositif portable 10 selon un protocole de communication avec une mémoire non volatile, par exemple MMC, USB, SD, via un pilote de communication prévu pour fonctionner avec un contrôleur gérant une mémoire non volatile au sein du dispositif portable 10. Avantageusement, les moyens de traitement 13 sont donc un contrôleur 13 susceptible de gérer une mémoire non volatile. On note à ce sujet que, dans le mode de réalisation de l'invention proposée sur la figure 1, le dispositif électronique portable 10 comprend potentiellement une mémoire non volatile 14, par exemple une mémoire flash. Cette mémoire non volatile 14 est gérée par un contrôleur de mémoire 13 qui, dans l'exemple illustratif proposé, constitue avantageusement les moyens de traitement. Le rôle d'un tel contrôleur 13 est classiquement de gérer la lecture et l'écriture de données dans ou en provenance de blocs de la mémoire non volatile 14.
Il s'agit ainsi d'implémenter l'invention en modifiant le fonctionnement du contrôleur de mémoire 13 afin qu'il aiguille les requêtes du dispositif hôte 11 entre le microprocesseur applicatif 12 qui générera des données et la mémoire non volatile 14.
Par exemple, le contrôleur inclut un pilote orienté bloc et toute requête de lecture, d'écriture ou d'effacement de données est transcrite en des requêtes de lecture, d'écriture ou d'effacement de blocs de données identifiés par leur identifiant de blocs. Selon l'invention, le microprocesseur applicatif 12 se déclare préalablement auprès des moyens de traitement 13 pour la gestion d'un ensemble de blocs dits à rediriger. Le mécanisme de déclaration est illustré sur la figure 1.
A l'insertion du dispositif électronique portable 10 dans le dispositif hôte 11 ou, plus généralement, quand les deux dispositifs sont mis en relation, le contrôleur de mémoire 13 envoie une requête d'initialisation IR au microprocesseur applicatif 12. La réponse du microprocesseur applicatif 12 comprend une information IF sur les blocs mémoire que le microprocesseur 12 sera en charge de gérer. Dans l'exemple présenté, il s'agit d'une taille maximale de données IF=N octets. Dans une variante de l'invention, l'information IF communiquée peut être une quantité de blocs.
Au sein du contrôleur de mémoire 13, l'information IF est prise en compte dans une table dédiée. Cette table dédiée liste des blocs mémoire additionnels signalés comme étant gérés par le microprocesseur applicatif 12. Dans une variante de l'invention, l'information IF communiquée pourra être accompagnée d'une restriction sur le type de requête d'accès devant être gérée par le microprocesseur applicatif 12 tel que lecture, écriture ou effacement.
Ainsi, dans un contrôleur de mémoire 13 gérant une mémoire non volatile 14, les blocs additionnels sont, par exemple, listés à la suite des blocs mémoire correspondant aux blocs de la mémoire non volatile 14. Ainsi, comme illustré sur la figure 1, les blocs 00 à 3F sont les blocs gérés au sein de la mémoire non volatile 14, les blocs suivants 40 à 4B sont des blocs additionnels qui seront gérés selon l'invention par le microprocesseur applicatif 12. En retour, le contrôleur 13 indique des identifiants, chacun associé à un bloc. De tels identifiants peuvent être des adresses virtuelles de blocs telles que connues du dispositif hôte 11 ou être des identifiants propre à la communication entre le contrôleur 13 et le microprocesseur applicatif 12. Dans ce dernier cas, les identifiants sont corrélés aux adresses virtuelles connues par le dispositif hôte listées dans la table dédiée tenue par le contrôleur. Une table de correspondance spécifique peut être stockée dans le contrôleur à cet effet.
Par exemple, comme illustré, le contrôleur retourne des identifiants de blocs sous la forme d'adresses des blocs [40...4B].
Dans une autre variante de l'invention, l'information IF envoyée par le microprocesseur applicatif 12 inclut directement les adresses des blocs à rediriger. Dans ce cas, l'information communiquée en retour par le contrôleur 13 peut être un identifiant associé à chacune des adresses.
Lorsque plusieurs applications exécutées par le microprocesseur applicatif 12 sont susceptibles de gérer des blocs mémoire additionnels gérés selon l'invention, une telle information IF pourra être envoyée pour chacune de ces applications exécutées par le microprocesseur applicatif 12. Elles sont pour cela enregistrées auprès d'un registre de gestion dynamique du contrôleur 13. Par exemple, lors de cette phase d'enregistrement, chaque application indique la taille maximale IF=N du contenu qu'elle gérera.
En retour, le registre indique au microprocesseur applicatif 12 des identifiants de blocs associés à chaque application afin que le microprocesseur applicatif 12 soit en mesure de router des requêtes faisant appel aux blocs correspondant à ces identifiants vers l'application concernée.
Ici aussi, les identifiants peuvent être directement les adresses virtuelles telles que connues par le dispositif hôte ou des identifiants propres à la communication entre le contrôleur 13 et le microprocesseur applicatif 12.
Ici encore, dans des variantes, une quantité de blocs nécessaires ou des adresses virtuelles peuvent être indiquées par chacune ou certaines des applications.
Au sujet du routage des requêtes, du côté du microprocesseur applicatif 12, une application particulière, dite application de routage applicatif, est en charge du routage des requêtes d'accès vers les applications qui se sont enregistrées en fonction des identifiants qui sont indiquées dans les requêtes.
Toutes les applications exécutées par le microprocesseur applicatif 12 qui sont susceptibles de gérer des blocs additionnels selon l'invention sont donc également enregistrées auprès de cette application de routage applicatif. L'identifiant préalablement retourné par le contrôleur 13 lors de l'enregistrement de chaque application permettra à l'application de routage de router une requête dans laquelle est indiqué cet identifiant vers la ou les application(s) concernée(s).
Dans une variante de l'invention, le contrôleur 13 ne gère pas la table dédiée des adresses et/ou identifiants de blocs gérés par le microprocesseur applicatif 12. Chaque requête de lecture, d'écriture ou d'effacement de blocs reçue par le contrôleur 13 est redirigée vers le microprocesseur applicatif 12 qui lui indique s'il gère ou non le contenu de ce bloc. S'il le gère, il indiquera en retour le contenu proprement dit après génération. Sinon, le contrôleur prend la requête à sa charge.
Avantageusement, il est prévu qu'après la phase d'initialisation, le microprocesseur applicatif 12 soit encore en mesure d'alimenter le contrôleur 13 avec de nouveaux blocs que le microprocesseur applicatif 12 sera en charge de gérer. En parallèle, il est avantageux que le microprocesseur applicatif 12 puisse indiquer au contrôleur 13 des identifiants de blocs qui ne doivent plus être gérés par le microprocesseur applicatif 12. De tels retraits du microprocesseur 12 sont par exemple provoqués par un code d'erreur spécifique retourné par le microprocesseur applicatif 12 au contrôleur 13 lors d'une requête d'accès au bloc concerné ou par une réponse spécifique. La figure 2 illustre le traitement des requêtes d'accès à des blocs gérés selon l'invention. Lorsqu'une requête R[X] d'accès à un bloc X selon un protocole de communication avec une mémoire, par exemple le protocole MMC, est envoyée par le dispositif hôte 11 vers le dispositif portable 10, le contrôleur 13 cherche dans la table dédiée si la requête en cours doit être gérée par le microprocesseur applicatif 12. Si oui, la requête est redirigée vers le microprocesseur applicatif 12 afin qu'il retourne un contenu de bloc généré dynamiquement. Sinon, la requête est classiquement gérée par le contrôleur de mémoire 13 pour lecture, effacement ou écriture des données du bloc X dans la mémoire non volatile 14. Plus particulièrement, dans le cas d'une requête en lecture d'un bloc d'adresse X géré par le microprocesseur applicatif 12, les moyens de traitement 13, après avoir trouvé que le bloc X est géré par le microprocesseur applicatif 12 dans la table dédiée, envoient alors un signal S[X] vers le microprocesseur applicatif 12. Ce signal S[X] peut déclencher une action interne au microprocesseur applicatif 12, comme la génération d'un ensemble de données de taille égale ou supérieure à la taille d'un bloc.
Dans le cas où la taille des données générées est égale à la taille d'un bloc, les données générées sont le contenu GD[X] du bloc X communiqué en retour aux moyens de traitement 13. Ces données générées GD[X] peuvent éventuellement être aussi stockées dans une mémoire tampon du microprocesseur applicatif 12.
Les moyens de traitement 13 répondent alors à la requête R[X] du dispositif hôte 11 en lui envoyant ces données GD[X] selon ledit protocole de communication avec une mémoire, c'est-à-dire en l'occurrence sous la forme de contenu d'un bloc mémoire.
Dans le cas où la taille des données générées est supérieure à la taille d'un bloc, une partie des données générées correspondra au contenu GD[X] du bloc X qui sera envoyé vers les moyens de traitement 13 pour que ceux-ci répondent au dispositif hôte 11 et les autres données générées seront stockées dans une mémoire tampon du microprocesseur applicatif 12 et correspondent aux contenus GD[Y...Y+N] d'autres blocs gérés par le microprocesseur applicatif 12.
On remarque alors qu'une requête en lecture d'un bloc appartenant au groupe Y...Y+N ne déclenchera a priori pas de génération de données de la part du microprocesseur applicatif 12, les données à lire dans le bloc demandé en lecture seront directement lues dans la mémoire tampon du microprocesseur applicatif 12.
Dans le cas d'une requête R[X] en effacement du bloc d'adresse X géré par le microprocesseur applicatif 12, les moyens de traitement 13 envoient un signal S[X] vers le microprocesseur applicatif 12 pour qu'il déclenche l'effacement du bloc X. Un des avantages de l'invention est que cette requête peut être aisément interdite ou pas par le microprocesseur applicatif 12. Dans le cas où elle est autorisée, le microprocesseur applicatif 12 peut indiquer aux moyens de traitement 13 qu'il ne gère plus le bloc X. Dans le cas d'une requête R[X] en écriture modificatrice du bloc d'adresse
X géré par le microprocesseur applicatif 12, les moyens de traitement 13 envoient un signal S[X] vers le microprocesseur applicatif 12 pour qu'il déclenche la modification du bloc X. Cette modification pourra engendrer une action du microprocesseur applicatif 12 pouvant être une génération de données GD[X] qui sera ensuite donnée en lecture lors d'une requête en lecture subséquente du bloc X.
Comme, selon l'invention, des requêtes en écriture, lecture ou effacement de données dans une mémoire non volatile sont traitées de manière dynamique par un microprocesseur, il est possible de protéger les données générées par le microprocesseur applicatif contre la modification ou l'effacement en provenance du dispositif hôte. Il est aussi possible d'implémenter l'invention de telle manière qu'une requête en lecture, en écriture ou en effacement de bloc déclenche une action de traitement supplémentaire comme une ouverture de session, une copie, un envoi de message, une signature des données, etc. en plus de la génération dynamique des données.
Souvent, la requête R[X] est réalisée dans le cadre d'une modification de fichier. Classiquement, une table d'allocation de fichier au sein du dispositif électronique portable 10 liste les blocs nécessaires à la constitution de chacun des fichiers stockés dans le dispositif portable 10. Par exemple, il existe dans cette table un fichier « smartcard.txt » d'une taille de 512 octets dont l'adresse du premier bloc est connue. Les blocs constituant le contenu du fichier peuvent être gérés selon l'invention.
Lorsqu'une application du dispositif hôte 11 envoie une requête en écriture au format APDU dans ce fichier, par exemple la suite de caractères « A0A40000023F00 », qui correspond à une commande APDU compréhensible par une carte à puce, complétée de caractères de contrôle, par exemple des espaces, jusqu'à la fin du fichier, ces données sont envoyées au contrôleur de mémoire 13 sous la forme d'une mise à jour du fichier « smartcard.txt », sans modification de sa description dans la table d'allocation de fichier.
Le contrôleur 13 cherche alors dans la table dédiée si les différentes requêtes d'écriture de blocs doivent être gérées par le microprocesseur applicatif 12. Lorsque c'est le cas, le contrôleur 13 envoie les requêtes d'écriture de blocs au microprocesseur applicatif 12. Chaque requête d'écriture de blocs reçue est interprétée par l'application de routage applicatif du microprocesseur applicatif 12. Cette application de routage déclenche l'application à laquelle la requête d'accès est destinée. Dans le cas précité où la commande envoyée est une commande APDU, cette application va faire exécuter la dite commande au microprocesseur applicatif 12 et va stocker dans une mémoire tampon interne du microprocesseur applicatif 12 le résultat de l'exécution de cette commande.
Lorsque l'application du dispositif hôte 11 requiert une lecture de ce fichier, le contrôleur 13 va rediriger les requêtes de lecture de blocs vers le microprocesseur applicatif 12. L'application de routage applicatif va router chaque requête vers l'application enregistrée concernée. Dans l'exemple précité, l'application va retourner à chaque requête de lecture de bloc le contenu de la réponse APDU préalablement stockée dans une mémoire tampon interne au microprocesseur applicatif 12.
Ainsi qu'il a été précédemment décrit, des requêtes de lecture subséquentes vont lire dans la mémoire tampon interne du microprocesseur applicatif sans que la réponse APDU ne soit recalculée.
Selon l'invention, le contenu de bloc ou de fichier est ensuite communiqué au dispositif hôte 11 comme s'il venait de blocs physiques de la mémoire non volatile 14, l'invention est donc transparente du point de vue du dispositif hôte 11. On note que les données échangées entre le dispositif hôte 11 et le microprocesseur applicatif 12, notamment dans le cadre de modification de fichier, peuvent être codées selon des formats divers, par exemple en base64. On note aussi que le contrôleur 13 peut aussi gérer des fichiers spécifiques aux protocoles utilisés dans les cartes à puce, par exemple les octets de procédures du protocole T=O et les commandes et réponses associées.
On note enfin qu'il est possible de gérer très simplement, avec l'aide de l'invention des fichiers destinés à des services ou à des applications dont les contenus doivent être générés au besoin. Par exemple, le contenu des blocs d'un fichier « otp.txt » (OTP pour One Time Password en anglais), dans lequel est stocké au moins un mot de passe à utilisation unique, est ainsi avantageusement géré par le microprocesseur applicatif 12 de l'invention. Le fichier « otp.txt », dont les blocs sont gérés par le microprocesseur applicatif 12, répondra, à chaque fois qu'il sera lu, une valeur de mot de passe à utilisation unique différente, donnée par une application OTP exécutée par le microprocesseur applicatif 12.
Un fichier calculant une signature digitale « digital-signature.txt » peut aussi être avantageusement géré à l'aide de l'invention : les données à signer sont écrites dans ce fichier par redirection vers le microprocesseur applicatif qui génère alors la signature et la lecture du fichier retourne la signature digitale des données écrites. Cependant, on note qu'une telle application peut engendrer des modifications de la taille du fichier « digital-signature.txt » ce qui nécessite des modifications dans une table d'allocation de fichier.
Actuellement, la table d'allocation de fichier dont la fonction est de décrire le système de fichier est copiée du dispositif portable 10 vers une mémoire dynamique du dispositif hôte 11 et est entièrement gérée par le dispositif hôte 11. Par conséquent, seules les applications du dispositif hôte 11 peuvent interagir avec le système de fichier.
Désormais, selon l'invention, il est envisageable que des applications exécutées par le microprocesseur applicatif 12 puissent interagir avec le contenu de la mémoire non volatile 14 telle que vu par le dispositif hôte 11. La table d'allocation de fichier présente dans le dispositif portable 10 peut alors être modifiée entraînant l'obsolescence de la table d'allocation de fichier telle que connue par le dispositif hôte 11. On constate aussi qu'avec l'invention, si le dispositif hôte 11 peut modifier la table d'allocation de fichier au sein du dispositif portable 10 afin que la taille du fichier corresponde à une quantité donnée d'octets écrits et si la quantité de données écrites par le dispositif hôte 11 dépasse la taille du fichier, le dispositif hôte 11 peut avoir besoin de blocs mémoire supplémentaires et on ne peut garantir que les blocs qu'il ajoutera dans la table d'allocation seront ou non gérés selon l'invention.
Aussi, dans le cas où le dispositif hôte 11 modifie un fichier dont les blocs sont gérés selon l'invention et dont la taille peut varier ou dans le cas où le microprocesseur applicatif peut modifier la taille d'un fichier, le microprocesseur applicatif doit disposer de moyens pour modifier la table d'allocation ou les blocs associés à la table d'allocation au sein du dispositif portable 10 doivent être gérés selon l'invention par le microprocesseur applicatif 12.
De plus, dans le cas où le microprocesseur applicatif 12 peut modifier la taille d'un fichier, toute commande en provenance du dispositif hôte 11 doit être bloquée pendant la mise à jour de la table d'allocation au sein du dispositif portable 10. En outre, le dispositif portable doit présenter des moyens de mise à jour de la table d'allocation du dispositif hôte 11.
Ainsi, dans une application avantageuse de l'invention, le microprocesseur applicatif 12 gère au moins une partie des données d'une table d'allocation de fichier. Ainsi, le nom, la taille et le contenu de certains fichiers peuvent être complètement ou partiellement gérés par le microprocesseur applicatif 12, et donc, le cas échéant, par la carte à puce sur laquelle il est implémenté.
Le dispositif électrique portable présenté sur les figures 1 et 2 présente une architecture à trois composants, la mémoire 14, le contrôleur de mémoire 13 et un composant incluant le microprocesseur applicatif 12, par exemple une puce intelligente telle qu'une puce de carte à puce. On note que, dans une variante, il est envisageable de fusionner le contrôleur et la carte à puce en un unique composant pour obtenir une architecture à deux composants.
La figure 3 présente un mécanisme de remise à jour d'une table d'allocation de fichier 31 dans le cadre d'une telle architecture à deux composants comprenant un processeur 30 réunissant les fonctions du microprocesseur applicatif et celles du contrôleur. Dans la configuration présentée, une application exécutée sur le processeur 30 gère dynamiquement le contenu de la table d'allocation 31 et le contenu du fichier associé.
Lors d'une étape de modification MOD de la table d'allocation 31 par le processeur 30, une étape préalable de blocage LK des accès aux blocs mémoire par le dispositif hôte 11 est réalisée par le processeur 30 pour empêcher toute modification par le dispositif hôte 11. Avantageusement, les routines de blocage peuvent être intégrées au logiciel d'exploitation du processeur 30.
Après la modification MOD, le blocage LK est levé, soit après un laps de temps prédéfini, soit à l'initiative du processeur 30. De manière subséquente au déblocage, une étape de notification NTF des modifications vers le dispositif hôte 11 par le processeur 30 a lieu. Cette étape de notification NTF peut se faire selon un mécanisme de polling implémenté dans le dispositif hôte 11. Elle peut utiliser un bus spécifique ou un bus générique de communication entre le processeur 30 et le dispositif hôte 11. A la réception de cette notification NTF, le dispositif hôte 11 requiert, par une requête RR, une lecture de la table d'allocation de fichier 31 dans le dispositif portable 10. Par exemple, la requête RR peut concrètement prendre la forme d'un redémarrage du port sur lequel le dispositif portable est connecté, par exemple un port USB. Lors de la requête RR, le processeur 30 débloque l'accès à la table d'allocation 31 et aux blocs mémoire. Le dispositif hôte 11 rafraîchit alors sa table d'allocation de fichier 31'.
On note qu'il est également possible qu'une table d'allocation, entièrement gérée au sein de la mémoire non volatile 14, subisse des modifications subséquentes à des modifications de blocs mémoire gérés par le processeur 30.
Dans le cas d'une architecture à deux composants, le processeur 30 dispose naturellement de moyens pour modifier un contenu de la mémoire non volatile 14 puisqu'il a un rôle de contrôleur de cette mémoire 14. En revanche, dans une architecture à trois composants, il sera alors nécessaire que le microprocesseur applicatif soit apte à envoyer un ordre de modification de la table d'allocation vers le contrôleur, lui-même apte à changer le contenu de la table d'allocation dans la mémoire non volatile qu'il contrôle.
Dans ce dernier cas de figure, il est toujours utile de bloquer l'accès du dispositif hôte au contenu du dispositif portable pendant les modifications des blocs concernés.
Outre les modes de réalisation illustratifs présentés, on remarque enfin que des mises en œuvre diverses peuvent être réalisées selon les principes de l'invention définis dans les revendications suivantes.

Claims

REVENDICATIONS
1. Dispositif électronique portable [10] destiné à communiquer avec un dispositif électronique hôte [11] selon au moins un protocole de communication avec une mémoire non volatile, ledit dispositif électronique portable [10] comprenant au moins un microprocesseur dit applicatif [12] destiné à la réalisation d'applications fonctionnelles du dispositif électronique portable, caractérisé en ce que le microprocesseur applicatif [12] étant apte à générer des données dynamiquement par mise en œuvre d'au moins une application spécifique, le dispositif électronique portable [10] inclut des moyens de traitement [13] aptes à traiter les données générées par le microprocesseur applicatif, directement comme des contenus d'une mémoire non volatile, selon le protocole de communication avec une mémoire non volatile, lors de communications avec le dispositif hôte [H].
2. Dispositif électronique portable [10] selon la revendication 1, caractérisé en ce que lesdits moyens de traitement sont constitués par un contrôleur de mémoire [13] apte à gérer des blocs mémoire et présentant les données générées au dispositif hôte [11] comme des contenus de blocs d'une mémoire non volatile.
3. Dispositif électronique portable [10] selon la revendication 2, caractérisé en ce qu'il comprend au moins une mémoire non volatile [14] accessible par blocs et gérée par ledit contrôleur de mémoire [13].
4. Dispositif électronique portable [10] selon l'une des revendications 2 et 3, caractérisé en ce qu'une requête d'accès [R[X]] à un bloc mémoire [X] étant envoyée par le dispositif hôte [11], le contrôleur de mémoire [13] redirige la requête vers le microprocesseur applicatif [12] lorsque le bloc [X] à accéder est un bloc correspondant à des données générées [GD[X]] par le microprocesseur applicatif [12].
5. Dispositif électronique portable [10] selon l'une des revendications 2 et 3, caractérisé en ce que toutes les requêtes d'accès [GD[X]] à un bloc mémoire [X] sont redirigées vers le microprocesseur applicatif [12] qui indique en retour au contrôleur [13] s'il gère ou non le bloc [X] correspondant.
6. Dispositif électronique portable [10] selon l'une des revendications 2 à 5, caractérisé en ce que ledit microprocesseur applicatif [12] se déclare auprès des moyens de traitement [13] pour la gestion d'un ensemble de blocs dits à rediriger.
7. Dispositif électronique portable [10] selon la revendication 6, caractérisé en ce que la déclaration [IF] indique un nombre de blocs à rediriger.
8. Dispositif électronique portable [10] selon la revendication 6, caractérisé en ce que la déclaration [IF] indique une taille maximum [N] de données à gérer.
9. Dispositif électronique portable [10] selon la revendication 7 ou 8, caractérisé en ce que les moyens de traitement [13] répondent à la déclaration
[IF] par l'attribution d'un ensemble d'identifiants de blocs [[40...4B]].
10. Dispositif électronique portable [10] selon la revendication 9, caractérisé en ce que l'identifiant de bloc est l'adresse virtuelle du bloc.
11. Dispositif électronique portable [10] selon la revendication 6, caractérisé en ce que la déclaration [IF] indique des adresses virtuelles de blocs à rediriger.
12. Dispositif électronique portable [10] selon la revendication 6, caractérisé en ce que ledit microprocesseur applicatif [12] est apte à se retirer de la gestion d'un ensemble de blocs dits à rediriger.
13. Dispositif électronique portable [10] selon l'une des revendications précédentes, caractérisé en ce qu'une requête d'accès aux données d'un fichier étant envoyée par le dispositif hôte [11], les moyens de traitement [13] sont aptes à traiter cette requête et à la rediriger vers le microprocesseur applicatif [12] lorsque le traitement de la requête d'accès aux données du fichier requiert l'accès à des données générées par le microprocesseur applicatif [12].
14. Dispositif électronique portable [10] selon l'une des revendications précédentes, caractérisé en ce que les données générées par le microprocesseur applicatif [12] étant des données d'une table d'allocation de fichier [31], le dispositif électronique portable [10] inclut des moyens de mise à jour [ NTF, RR] pour déclencher, de manière subséquente à une modification [MOD] de la table d'allocation [31], une mise à jour d'une table d'allocation de fichier [31'] au sein du dispositif hôte [H].
15. Dispositif électronique portable [10] selon l'une des revendications 1 à 13, caractérisé en ce que les données générées par le microprocesseur applicatif
[12] nécessitant une modification de données dans une table d'allocation de fichier [31] stockée au sein du dispositif portable [10], le dispositif électronique portable [10] inclut des moyens de mise à jour pour déclencher, de manière subséquente à une modification [MOD] de la table d'allocation [31], une mise à jour d'une table d'allocation de fichier [31'] au sein du dispositif hôte [H].
16. Dispositif électronique portable [10] selon l'une des revendications 14 et 15, caractérisé en ce que les moyens de traitement [13] sont aptes à bloquer l'accès du dispositif hôte [11] aux contenus de mémoire non volatile du dispositif portable [10], un tel blocage [LK] étant activé lors des modifications [MOD] de la table d'allocation de fichier [31] au sein du dispositif portable [10].
17. Dispositif électronique portable [10] selon l'une des revendications précédentes, caractérisé en ce que le contrôleur de mémoire [13] et le microprocesseur applicatif [12] sont mis en œuvre par le même composant.
18. Dispositif électronique portable [10] selon l'une des revendications précédentes, caractérisé en ce que le microprocesseur applicatif [12] est le processeur d'une puce du type carte à puce.
PCT/EP2007/050458 2006-01-19 2007-01-17 Dispositif electronique portable apte a fournir un contenu dynamique WO2007082900A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0600494 2006-01-19
FR0600494 2006-01-19

Publications (1)

Publication Number Publication Date
WO2007082900A1 true WO2007082900A1 (fr) 2007-07-26

Family

ID=36972757

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/050458 WO2007082900A1 (fr) 2006-01-19 2007-01-17 Dispositif electronique portable apte a fournir un contenu dynamique

Country Status (1)

Country Link
WO (1) WO2007082900A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0596276A2 (fr) * 1992-10-14 1994-05-11 Bull HN Information Systems Inc. Carte à mémoire sécurisée
US5491827A (en) * 1994-01-14 1996-02-13 Bull Hn Information Systems Inc. Secure application card for sharing application data and procedures among a plurality of microprocessors
EP1396815A1 (fr) * 2001-06-04 2004-03-10 Renesas Technology Corp. Carte memoire
US20050006484A1 (en) * 2000-01-05 2005-01-13 Kabushiki Kaisha Toshiba IC card with radio interface function, antenna module and data processing apparatus using the IC card

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0596276A2 (fr) * 1992-10-14 1994-05-11 Bull HN Information Systems Inc. Carte à mémoire sécurisée
US5491827A (en) * 1994-01-14 1996-02-13 Bull Hn Information Systems Inc. Secure application card for sharing application data and procedures among a plurality of microprocessors
US20050006484A1 (en) * 2000-01-05 2005-01-13 Kabushiki Kaisha Toshiba IC card with radio interface function, antenna module and data processing apparatus using the IC card
EP1396815A1 (fr) * 2001-06-04 2004-03-10 Renesas Technology Corp. Carte memoire

Similar Documents

Publication Publication Date Title
EP2110742B1 (fr) Dispositif portable et procédé de démarrage externe d'une installation informatique
US20080091878A1 (en) Virtual memory card controller
WO2006053958A9 (fr) Support personnel de mémoire de masse portatif et système informatique d'accès sécurisé a un espace utilisateur via un réseau
EP1849054A1 (fr) Dispositif de stockage de donnees
FR2806505A1 (fr) Procede de communication entre une carte a puce et une station hote
WO2012089983A1 (fr) Procédé et dispositif de contrôle d'accès à un système informatique
FR2686171A1 (fr) Carte a memoire de masse pour microordinateur avec facilites d'execution de programmes internes.
EP2466470B1 (fr) Module matériel de sécurité et procédé de traitement dans un tel module
EP2024798B1 (fr) Procédé et dispositif de configuration sécurisée d'un terminal au moyen d'un dispositif de stockage de données de démarrage
WO2001084512A1 (fr) Carte a puce multi-applicatives
FR2807532A1 (fr) Dispositif et procede de memorisation de donnees de journalisation dans un reseau de communication
EP2124153A1 (fr) Procédés et dispositif de mise en oeuvre de périphériques multifonction avec un gestionnaire de périphérique standard unique
WO2007082900A1 (fr) Dispositif electronique portable apte a fournir un contenu dynamique
EP2048576B2 (fr) Procédé de mise à jour sécurisée d'un programme à lancement automatique et entité électronique portable le mettant en oeuvre
EP2304559B1 (fr) Procédé de basculement entre deux versions d'une même application au sein d'un dispositif de traitement de l'information et ledit dispositif
EP2053532A1 (fr) Procédé d'ouverture sécurisée à des tiers d'une carte à microcircuit
WO2024188822A1 (fr) Procédé et dispositif de paiement confidentiel sur chaîne de blocs
WO2003009110A1 (fr) Securisation de lecture d'instructions dans un systeme de traitement de donnees
WO2022269207A1 (fr) Procede et dispositif de controle d'acces a un support de stockage
EP2131287A1 (fr) Dispositif électronique de mise à disposition de services autoadaptatifs en fonction de la plateforme de l'équipement hôte avec lequel il est en liaison
WO2002008897A1 (fr) Protocole d'echange de messages entre applications implantees sur un systeme embarque, et systeme embarque correspondant
FR2901386A1 (fr) Support personnel de memoire de masse portatif et systeme informatique d'acces securise a un reseau par des utilisateurs.
WO2011000722A1 (fr) Procédé de validation distante d'un code exécutable
FR3147397A1 (fr) Système informatique configuré pour exécuter un programme d’ordinateur
FR2901380A1 (fr) Support personnel de memoire de masse portatif et systeme informatique d'acces securise a un espace utilisateur via un reseau

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07703955

Country of ref document: EP

Kind code of ref document: A1