WO2001088705A1 - Procede de securisation d'un langage du type a donnees typees, notamment dans un systeme embarque et systeme embarque de mise en oeuvre du procede - Google Patents

Procede de securisation d'un langage du type a donnees typees, notamment dans un systeme embarque et systeme embarque de mise en oeuvre du procede Download PDF

Info

Publication number
WO2001088705A1
WO2001088705A1 PCT/FR2001/001506 FR0101506W WO0188705A1 WO 2001088705 A1 WO2001088705 A1 WO 2001088705A1 FR 0101506 W FR0101506 W FR 0101506W WO 0188705 A1 WO0188705 A1 WO 0188705A1
Authority
WO
WIPO (PCT)
Prior art keywords
memory
type
data
instructions
execution
Prior art date
Application number
PCT/FR2001/001506
Other languages
English (en)
Inventor
Nicolas Fougeroux
Olivier Landier
Patrice Hameau
Original Assignee
Bull Cp8
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull Cp8 filed Critical Bull Cp8
Priority to AU62437/01A priority Critical patent/AU6243701A/en
Priority to EP01936554A priority patent/EP1287432A1/fr
Priority to JP2001585035A priority patent/JP2003533820A/ja
Publication of WO2001088705A1 publication Critical patent/WO2001088705A1/fr

Links

Classifications

    • 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/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • 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/44589—Program code verification, e.g. Java bytecode verification, proof-carrying code

Definitions

  • the invention relates to a method for dynamically securing a language of the typed data type, in particular for an on-board system with an electronic chip.
  • the invention also relates to an on-board electronic chip system for implementing the method.
  • the term "on-board system” must be understood in its most general sense. It relates in particular to all kinds of light terminals provided with an electronic chip, and more particularly to the smart cards themselves.
  • the electronic chip is provided with means for recording and processing digital data, for example a microprocessor for these latter means.
  • security must also be understood in a general sense. In particular, it concerns both the concept of confidentiality of the data handled and the concept of integrity, hardware and / or software, of the components present in the on-board system. Before describing the invention further, it is first of all useful to briefly recall the main characteristics of the "JAVA" language, in particular in an environment of the smart card type.
  • This latter language has in particular the advantage of being multiplatform: it suffices that the machine in which the application written in "JAVA” language is executed be provided with a minimum of specific IT resources, in particular a piece of software called “JAVA virtual machine” for the interpretation of a sequence of sequences of "opcodes” of 8 bit instructions, called “bytecode” or “p-code” (for "program code” or program code).
  • the "p-code” is recorded in memory positions of the aforementioned data recording means. More precisely, in the case of the "JAVA” language, the area occupied by the memory positions, from a logical point of view, has a configuration known as a stack. In the case of a smart card, this integrates the "virtual machine
  • JAVA "(saved in its memory) and works by interpreting a language based on the above opcode sequence.
  • the executable code or" p-code "results from a prior compilation.
  • the compiler is arranged so that the transformed language obeys a determined format and respects a certain number of rules fixed a priori.
  • the "opcodes” can receive values of the following elements in a sequence of the "p-code", these elements are then called parameters. Opcodes can also receive values from the stack. These elements then constitute operands.
  • elements known under the names of "classes” and “methods” are used.
  • the virtual machine finds the corresponding "p-code”. This "p-code” identifies specific operations to be performed by the virtual machine. A particular stack is necessary for the processing of so-called local variables, for arithmetic operations or for the invocation of other methods. This stack serves as the work area for the virtual machine. To optimize the performance of the virtual machine, the stack width is generally fixed for a given primitive type.
  • Reference objects can be seen as pointers to memory areas of the smart card (physical or logical references).
  • the "JAVA” language whose main characteristics have just been briefly mentioned, lends itself particularly well to applications involving interconnections with the Internet network and its great success is moreover linked to the strong development of applications
  • the executable code or "p-code" results from a prior compilation.
  • the compiler can therefore be arranged, as indicated, so that the transformed language obeys a determined format and respects a certain number of rules fixed a priori.
  • One of these rules is that a given application is confined within what is called a "sand box" (or “black box”).
  • the instructions and / or data associated with a specific application are stored in memory positions of the data recording means.
  • the configuration of these data recording means takes the form of a stack. Confinement in a "sand box” in practice means that the aforementioned instructions cannot address memory positions outside those assigned to the said application, without being expressly authorized to do so.
  • This verification can be carried out in so-called “off-line” mode, that is to say offline, which does not penalize the processing of the application, in particular from a communication cost point of view.
  • the aforementioned verifier alone requires a relatively large amount of memory, of the order of several MB. This high value does not present any particular problems if the verifier is stored in a microcomputer or a similar terminal having high memory resources.
  • a data processing terminal having more limited computer resources, a fortiori a smart card, it is not conceivable, from a practical point of view, given the technologies currently available. available, to implement the verifier in this type of terminal.
  • the verification is of a type that can be described as "static", because carried out once and for all, before the execution of the "p-code".
  • the "p-code" even if checked, is then loaded into the data recording means of the smart card, it can undergo alterations a posteriori.
  • the chip card this by nature, is not intended to remain permanently in the terminal from which the application has been loaded.
  • the smart card can be subjected to ionizing radiation which physically alters memory positions. It is also possible to alter the "p-code" when it is downloaded to the smart card from the terminal.
  • the invention aims to overcome the drawbacks of the methods and devices of the known art, some of which have just been mentioned.
  • the object of the invention is to provide a method for dynamic securing of applications in language of the type with typed data in an embedded system.
  • a binary information element comprising one or more bits, which will be called hereinafter "type information element"
  • type information element is associated with each object manipulated by the virtual machine, in the case of the aforementioned "JAVA" language. More generally, a type of information element is associated with each typed data item handled in a given language, of the type with objects or typed data.
  • the type of information elements are physically stored in specific memory areas of the storage means of the on-board system with electronic chip.
  • the virtual machine still in the case of the "JAVA” language, checks said type information elements during certain operations of execution of the "p-code", such as the manipulation of objects in the stack, etc., operations which will be specified below. More generally also, for another language, the process is similar and there is a step of checking the type of information elements. It can therefore be seen that, advantageously, said verification is of a type which can be called dynamic, since it is carried out in real time during the interpretation or execution of the code.
  • the virtual machine or what takes its place for a language other than the "JAVA” language, checks, continuously and before said execution of an instruction or an operation, that the type of information element corresponds well the expected type of the typed object or data to handle. When an incorrect type is detected, security measures are taken in order to protect the virtual machine and / or prevent any operations not compliant and / or dangerous for the integrity of the embedded electronic chip system.
  • said type information elements are also advantageously used to allow the management of stacks of variable widths, which makes it possible to optimize the memory space of the embedded chip system electronic, whose resources of this type are, by nature, limited, as has been pointed out.
  • type information elements are also used, by adding one or more additional information bit (s), used as “flags” ("flags"). "according to Anglo-Saxon terminology), to mark objects or typed data. This marking is then used to indicate whether these latter elements are used or not, and in the latter case, if they can be erased from the memory, which also makes it possible to save memory space.
  • the main object of the invention is therefore a method for the secure execution of a sequence of instructions of a computer application in the form of typed data recorded in a first series of determined locations of a memory of a computer system, in particular an on-board electronic chip system, characterized in that additional data called type information elements are associated with each of said typed data, so as to specify the type of this data, in that said elements type information is recorded in a second series of determined memory locations of said computer system memory, and in that, before the execution of instructions of a predetermined type, there is a continuous verification, prior to the execution of predetermined instructions, the agreement between a type indicated by these instructions and a type att ndu indicated by said type information items recorded in said second series of locations from memory, so as to authorize said execution only if there is agreement between said types.
  • FIGS. 1A to 1 G illustrate the main steps of correct execution of an example of "p-code" in a memory with stack associated with specific memory areas storing data called type information elements according to the invention
  • FIGS. 2A and 2B schematically illustrate stages of execution of this same code, but containing an alteration leading to an incorrect execution and detection of this alteration by the method of the invention
  • - Figure 3 schematically illustrates a system comprising a smart card for implementing the method according to the invention.
  • the virtual machine finds the corresponding "p-code".
  • This "p-code” identifies specific operations to be performed by the virtual machine.
  • a particular stack is necessary for the processing of so-called local variables, for arithmetic operations or for the invocation of other methods.
  • the stack serves as the work area for the virtual machine.
  • the stack width is generally fixed for a given primitive type.
  • objects of the type called “primitive” those known under the names “int” (for long integer: 4 bytes), “short” (for short integer: 2 bytes), “byte” (byte), “boolean” (boolean object); and so-called “reference” type objects (arrays of primitive type objects, class instances).
  • opcodes There are several types of "opcodes”, including; the creation of an object of primitive type (for example opcodes called “bip ⁇ sh” or “iconst”); - the execution of arithmetic operations on primitive objects
  • opcodes called “iadd” or “sadd”
  • the creation of a reference object for example the “opcodes” called “new”, “newarray” or “anewarray”
  • management of local variables for example “opcodes” called “aload”, “iload” or “/ store”
  • class variables for example “opcodes” called “getstatic a” or “putfieldj”
  • Each "opcode” that uses objects placed in a stack is typed to ensure that its execution can be controlled.
  • the first letter (s) of the "opcodes” indicates (s) the type used.
  • type information elements are stored in a memory area in the form, each, of one or more bits.
  • Each of these type information elements characterizes an object handled by the JVM.
  • the JVM checks the typing in the following cases: when an "opcode" manipulates an object stored in the stack; retrieves an object in the "heap” area or in that of local variables to place it in a stack; - modifies an object in the "heap” area or in that of local variables; and when a new method is invoked, when the operands are compared to the signature of the method.
  • the JVM verifies, before the execution of the above operations, that their types correspond well to that expected (that is to say those given by the
  • JVM is associated with a 32-bit stack comprising at most 32 levels and supporting primitive types (for example "int”, “short”, “byte”, “boolean” and “object reference”)
  • the typing of the stack can then be carried out using length type information elements
  • the source code "JAVA” which will be considered below as a specific example is as follows:
  • iconst_2 // Push int constant 2 newarray TJNT astore_1 int [] buffer aload_1 int [] buffer iconst_1 // Push int constant 1 iconst_5 // Push int constant 5 iastore return
  • the first three lines correspond to the creation of the above table (see source code (1)).
  • the last five lines correspond to the initialization of this table
  • FIG. 1A schematically illustrates the step of execution of this "p-code".
  • the memory of the on-board electronic chip system (not shown) has been shown under the reference 1. More precisely, this memory 1 is divided into four main parts, two being common to the known art: the so-called “data zone” (data) 2a and the so-called “local variable zone” 3a. These zones, 2a and 3a, constitute the actual stack of the "JAVA” virtual machine (JVM) which will be called hereinafter for simplicity "JVM stack". These areas are associated with memory areas, 4a and 5a, respectively, specific to the invention, which will be called areas of "Typing".
  • JVM virtual machine
  • the memory areas, 4a and 5a are intended to store type information elements (of length 3 bits in the example described) associated with the data stored in areas 2a and 3a , respectively, in memory locations in one-to-one relationship with the memory locations of these areas.
  • type information elements of length 3 bits in the example described
  • the logical organization of these memory areas is of the so-called "stack" type as mentioned. Also, they have been represented in the form of tables of dimensions cxl, with c number of columns and / number of rows, that is to say the "height" of the stack or level (which may vary at each step of execution of a "p-code").
  • the number of lines represented or level number: 1 to 32 maximum in the example described) is equal to 2 for all the memory areas. Each of the memory areas, 2a to 5a, therefore constitutes an elementary stack.
  • FIG. 1A only constitutes a schematic representation of the logical organization in stacks of the memory 1.
  • the "opcode" to execute during this first step has no parameters or operands.
  • the integer value 2 ie "0002" is placed in the stack: at level 1 (lower line in the example) in zone 2a.
  • the corresponding "Typing" area 4a is updated.
  • FIG. 1A The elements common to FIG. 1A bear the same numerical references and will only be re-described as necessary. Only the literal value associated with the numerical values is modified. It is identical to that of the corresponding figure, that is b in the case of FIG. 1 B, so as to characterize the successive modifications of the contents of the memory areas. It will be the same for the following figures 1 C to 1 G.
  • the "opcode" to be executed during this second step has for parameter the type of array to create (ie type "int").
  • This "opcode” has as operand a value which must be of type "int”, corresponding to the size of the array to be created (ie 2).
  • the verification of the "Typing" area (in state 4a) indicates a correct type. Execution is therefore possible.
  • a reference object is created in the "JVM stack”: for example the (arbitrary) value of four bytes “1234" is placed in the memory positions of the "local variable zone” (level 1). Since this is a reference type object, the value "100" (in bits) is placed in the corresponding "Typing" area 5b (level 1). No value is placed in the memory area 3b, nor in the "Typing" area 5b.
  • Step 3 astore_1 int [] buffer
  • the "opcode” has for operand a value which must be of type "Reference object”. Checking the "Typing" area (in state 4b) indicates a correct type. Execution is therefore possible.
  • the reference object is moved to the "local variable area” 3c: location 1 (level 1).
  • this "opcode” is to stack the reference object "1234", stored in the "local variable area” 3d, at level 1 of the "data area” 2d, that is to say in the positions of memory of the bottom line of this area.
  • the reference object "1234" is placed in the "data area” 2d.
  • the "Typing" areas 4d and 5d are updated and both store, in the corresponding memory locations, the value "100" (in bits), representative of a "Reference object” type.
  • Step 5 iconst_1 // Push int constant 1
  • the "opcode" to execute during this step has no parameters or operands.
  • the integer value 1 ie "0001" is placed in the stack: location 2 (level 2) of the "data area” 2e.
  • the corresponding "Typing" zone 4th is updated, also at level 2 (level 1 remains unchanged: value "1000").
  • the value "int” (integer) "000” (in bits) is placed in the "Typing" zone 4 e (level 2).
  • the 3rd and 5th zones remain unchanged.
  • Step 6 iconst_5 // Push int constant 5 This step is illustrated in Figure 1 F.
  • the "opcode” to execute during this step has no parameters or operands.
  • the integer value 1 ie "0001" is placed in the stack: level 3 of the "data area” 2f.
  • the corresponding "Typing" area 4f is updated, also at level 3 (levels 1 and 2 remain unchanged: values "1000" and "000” respectively).
  • the value "int” (integer) "000” (in bits) is placed in the "Typing" area 4f. Zones 3f and 5f remain unchanged.
  • Step 7 iastore This step is illustrated in Figure 1 G.
  • This "opcode” has for operand a value of type "int", an index of type "int” and a reference object of type array.
  • this "opcode" of type of reference object, stored at level 1 of the "local variable zone” 3a ', has the purpose of stacking an integer of value "5678" in the stack, in the "data area" 2'a.
  • the "Typing" area 4a ' will be updated. It follows that levels 1 of the “Typing" areas, 4a 'and 5a', will both contain the value "100" (in bits), that is to say a value associated with a "Reference object ". This particular configuration is illustrated in FIG. 2A.
  • Step 5 iconst_1 // Push int constant 1
  • Step 6 iconst_5 // Push int constant 5
  • This "opcode” has for operand a value of type "int", an index of type "int” and a reference object of type array.
  • the JVM therefore detects the presence of an illegal "opcode” threatening the security of the system.
  • the normal execution of the current sequence of instructions is interrupted and replaced by the execution of instructions corresponding to pre-programmed safety measures: alert signal, etc.
  • the type of information elements also make it possible to determine the instantaneous width required, in memory positions, of the zones of the "JVM stack".
  • the codes recorded in the "Typing" areas of the memory are associated, in whole or in part, with information characterizing the width of the aforementioned stack.
  • they may be additional bits, added to the typing codes, or an unused bit combination of these codes.
  • the width of the stack can vary, still by way of example, between 1 and 4 bytes, just 2 additional bits are enough to characterize the following widths:
  • the type information elements it is also possible to use the type information elements to indicate whether an object is still used (that is to say must be kept) or can be deleted from the "local variable area". Indeed, after a certain number of operations, a given object registered in this area is no longer used. Leaving it permanently therefore constitutes an unnecessary waste of memory space.
  • the following arbitrary agreements may be adopted:
  • This arrangement which can be described as a “garbage collector” (or “garbage collector”) type mechanism, also saves memory space.
  • FIG. 3 schematically illustrates an exemplary architecture of a computer system based on smart card applications for implementing the method according to the invention which has just been described.
  • This system comprises a terminal 7, which may or may not be connected to external networks, in particular to the Internet network RI, by a modem or any equivalent means 71.
  • the terminal 7, for example a microcomputer, notably comprises a compiler 9.
  • the code can be compiled outside the terminal to give a file called "Class"("JAVA” to "Class” compiler), it is this file which is downloaded by an Internet browser, the microcomputer includes a converterr which gives a file called "Cap”("Class” to “Cap”). This converter notably reduces the size of the "Class” file to allow it to be loaded onto a smart card.
  • Any application for example downloaded via the Internet RI and written in "JAVA” language is compiled by the compiler 9 and loaded, via a chip card reader 70 into the memory circuits 1 of the chip card 8. That -this integrates, as mentioned, a "JAVA (JVM) 6 virtual machine capable of interpreting the" p-code "from the compilation and loaded into memory 1.
  • JAVA JVM
  • Various memory stacks have also been shown: the “data zone” 2 and “local variable zone” 3 zones, as well as the typing zones, 4 and 5, the latter specific to the invention.
  • the smart card 8 also comprises conventional means for processing data connected to the memory 1, for example a microprocessor 80.
  • This arrangement also allows, at the cost of a minimal increase in processing time, to do without a verifier requiring significant memory resources.
  • This type of verifier cannot moreover be suitable, in practice, for the preferred applications of the invention.
  • the invention is not limited only to the examples of embodiments explicitly described, in particular in relation to FIGS. 1A to 1 G, 2A to 2B and 3.
  • the invention applies more particularly to an object type language, and more particularly to the "p-code" of the "JAVA” language, obtained after compilation, it applies to a large number of languages implementing typed data, such as the "ADA" languages. "or” KAMEL “mentioned in the preamble to this description.
  • the invention is particularly advantageous for embedded electronic chip systems, the resources of which IT, both data processing and storage of this data, are limited, in particular for smart cards, it is perfectly suited, a fortiori, for more powerful systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

L'invention concerne un procédé et un système embarqué à puce électronique (8) pour l'exécution sécurisée d'une séquence d'instructions d'une application informatique se présentant sous la forme d'objects ou de données typées, notamment écrite en langage 'JAVA'. La mémoire (1) est organisée en une première série de piles élémentaires (2, 3) pour l'enregistrement des instructions. On associe à chaque donnée ou objet typé un ou plusieurs bits dits de typage spécifiant le type. Ces bits sont enregistrés dans une deuxième série de piles élémentaires (4, 5), en relation biunivoque avec les piles (2, 3) de la première série. Avant l'exécution d'instructions de types prédéterminés, il est procédé à une vérification en continu, préalable à l'exécution de ces instructions, de la concordance entre un type indiqué par celles-ci et un type attendu, indiqué par les bits de typage. En cas de non-concordance l'exécution et stoppée.

Description

PROCEDE DE SECURISATION D'UN LANGAGE DU TYPE A DONNEES
TYPEES, NOTAMMENT DANS UN SYSTEME EMBARQUE ET SYSTEME
EMBARQUE DE MISE EN ŒUVRE DU PROCEDE
L'invention concerne un procédé de sécurisation dynamique d'un langage du type à données typées, notamment pour un système embarqué à puce électronique.
L'invention concerne encore un système embarqué à puce électronique pour la mise en œuvre du procédé.
Dans le cadre de l'invention, le terme "système embarqué" doit être compris dans son sens le plus général. Il concerne notamment toutes sortes de terminaux légers munis d'une puce électronique, et plus particulièrement les cartes à puce proprement dites. La puce électronique est munie de moyens d'enregistrement et de traitement de données numériques, par exemple un microprocesseur pour ces derniers moyens.
Pour fixer les idées, et sans que cela limite en quoi que ce soit sa portée, on se placera ci-après dans le cas de l'application préférée de l'invention, à savoir les applications à base de cartes à puce, sauf mention contraire.
De même, bien que divers langages informatiques, tels les langages "AD A" ou "KAMEL" (tous deux étant des marques déposées), sont du type dit à données ou objets typés, un des langages les plus utilisés dans le domaine préféré de l'invention étant le langage de type objet "JAVA" (marque déposée), ce langage sera pris comme exemple ci-après, pour décrire en détail le procédé de l'invention.
Enfin, le terme "sécurisation" doit lui aussi être compris dans un sens général. Notamment, il concerne aussi bien ce qui a trait au concept de confidentialité des données manipulées qu'au concept d'intégrité, matérielle et/ou logicielle, des composants présents dans le système embarqué. Avant de décrire plus avant l'invention, il est tout d'abord utile de rappeler brièvement les principales caractéristiques du langage "JAVA", notamment dans un environnement du type carte à puce.
Ce dernier langage présente en particulier l'avantage d'être multiplateformes : il suffit que la machine dans laquelle s'exécute l'application écrite en langage "JAVA" soit munie d'un minimum de ressources informatiques spécifiques, notamment d'une pièce de logiciel appelé "machine virtuelle JAVA" pour l'interprétation d'une suite de séquences d' "opcodes" d'instructions de 8 bits, appelées "bytecode" ou "p- code" (pour "program code" ou code programme). Le "p-code" est enregistré dans des positions de mémoire des moyens d'enregistrement de données précités. Plus précisément, dans le cas du langage "JAVA", la zone occupée par les positions de mémoire, d'un point de vue logique, se présente sous une configuration connue sous le nom de pile. Dans le cas d'une carte à puce, celle-ci intègre la "machine virtuelle
JAVA" (enregistrée dans ses moyens de mémoire) et fonctionne en interprétant un langage basé sur la séquence d'opcodes précitée. Le code exécutable ou "p-code" résulte d'une compilation préalable. Le compilateur est agencé pour que le langage transformé obéisse à un format déterminé et respecte un certain nombre de règles fixées a priori.
Les "opcodes" peuvent recevoir des valeurs d'éléments les suivants dans une séquence du "p-code", ces éléments sont alors appelés paramètres. Les opcodes peuvent aussi recevoir des valeurs en provenance de la pile. Ces éléments constituent alors des opérandes. Selon une autre caractéristique du langage "JAVA", il est mis en œuvre des éléments connus sous les noms de "classes" et de "méthodes". Lors de l'exécution d'une méthode donnée, la machine virtuelle retrouve le "p-code" correspondant. Ce "p-code" identifie des opérations spécifiques à effectuer par la machine virtuelle. Une pile particulière est nécessaire pour le traitement de variables dites locales, d'opérations arithmétiques ou pour l'invocation d'autres méthodes. Cette pile sert de zone de travail pour la machine virtuelle. Pour optimiser les performances de la machine virtuelle, la largeur de la pile est généralement fixée pour un type primitif donné.
Dans cette pile deux grands types d'objets peuvent être manipulés : - des objets de type dit "primitif", ceux connus sous les dénominations "int" (pour entier long : 4 octets), "short" (pour entier court : 2 octets), "byte" (octet), "boolean" (objet booléen) ; et des objets de type dit "référence" (tableaux d'objets de type primitif, instances de classes). La différence fondamentale entre ces deux types d'objets est que seule la machine virtuelle attribue une valeur à des objets de type référence et les manipule.
Les objets références peuvent être vus comme des pointeurs vers des zones mémoires de la carte à puce (références physiques ou logiques). Le langage "JAVA", dont les principales caractéristiques viennent d'être succinctement rappelées, se prête particulièrement bien aux applications mettant en jeu des interconnexions avec le réseau Internet et son grand succès est d'ailleurs lié au fort développement des applications
Internet. D'un point de vue sécurité, il présente aussi un certain nombre d'avantages. Tout d'abord, le code exécutable ou "p-code" résulte d'une compilation préalable. Le compilateur peut donc être agencé, comme il a été indiqué, pour que le langage transformé obéisse à un format déterminé et respecte un certain nombre de règles fixées a priori. Une de ces règles est qu'une application donnée soit confinée à l'intérieur de ce qui est appelé une "sand box" (ou "boite noire"). Les instructions et/ou données associées à une application déterminée sont mémorisées dans des positions de mémoire des moyens d'enregistrement de données. Dans le cas du langage "JAVA", d'un point de vue logique, la configuration de ces moyens d'enregistrement de données prend la forme d'une pile. Le confinement dans une "sand box" signifie en pratique que les instructions précitées ne peuvent pas adresser des positions mémoires en dehors de celles affectées à ladite application, sans y être autorisées expressément.
Cependant, une fois chargé en mémoire, des problèmes de sécurité peuvent se poser si le "p-code" a été altéré ou si son format n'a pas respecté les spécifications de la machine virtuelle. Aussi, dans l'art connu, notamment lorsqu'il s'agit d'applications, par exemple des "applets" (appliquettes), téléchargées via le réseau Internet, le code compilé, c'est-à- dire le "p-code" est vérifié par la machine virtuelle. Cette dernière est habituellement associée à un navigateur de type "WEB" dont est muni le terminal connecté au réseau Internet. Pour ce faire, la machine virtuelle est elle-même associée à une pièce de logiciel particulière ou vérificateur.
Cette vérification peut s'effectuer en mode dit "off-line", c'est-à-dire hors connexion, ce qui ne pénalise pas le traitement de l'application, notamment d'un point de vue coût de communication.
On est ainsi sûr, après que la vérification soit effectuée, que le "p- code" n'est pas endommagé et est conforme au format et aux règles préétablis. On est aussi sûr, dans ces conditions, que lors de l'exécution du "p-code", il n'y aura pas de détérioration du terminal dans lequel il s'exécute. Cependant, ce procédé n'est pas sans inconvénients, en particulier dans le cadre des applications visées préférentiellement par l'invention.
Tout d'abord, le vérificateur précité nécessite à lui seul une quantité de mémoire relativement importante, de l'ordre de plusieurs MO. Cette valeur élevée ne présente pas de problèmes particuliers si le vérificateur est enregistré dans un micro-ordinateur ou un terminal similaire disposant de ressources mémoires élevées. Cependant, lorsque l'on envisage d'utiliser un terminal de traitement de données possédant des ressources informatiques plus limitées, a fortiori une carte à puce, il n'est pas envisageable, d'un point de vue pratique, compte tenu des technologies actuellement disponibles, d'implémenter le vérificateur dans ce type de terminal. On doit également noter que la vérification est d'un type que l'on peut qualifier de "statique", car effectuée une fois pour toute, avant l'exécution du "p-code". Lorsqu'il s'agit d'un terminal du type microordinateur, notamment lorsque ce dernier est maintenu déconnecté lors de l'exécution du "p-code" vérifié au préalable, cette dernière caractéristique ne pose pas de problèmes particuliers. En effet, il n'existe pas de risques importants, d'un point de vue sécurité, car le terminal reste habituellement sous le contrôle de son opérateur.
Tel n'est pas le cas pour un système embarqué mobile, notamment pour une carte à puce. En effet, si le "p-code", même vérifié, est ensuite chargé dans les moyens d'enregistrement de données de la carte à puce, il peut subir a posteriori des altérations. En général, la carte à puce, ce par nature, n'est pas destinée à demeurer en permanence dans le terminal à partir duquel l'application a été chargée. A titre d'exemple non limitatif, la carte à puce peut être soumise à un rayonnement ionisant qui altère physiquement des positions de mémoire. Il est possible également d'altérer le "p-code" au moment de son téléchargement dans la carte à puce, à partir du terminal.
Il s'ensuit que, si le "p-code" est altéré, notamment dans un but malveillant, il est possible d'effectuer une opération dite de "dump" (duplication) de zones de mémoires et/ou de mettre en péril le bon fonctionnement de la carte à puce. Il devient ainsi possible, par exemple, et malgré la disposition dite de "sand box" précitée, d'avoir accès à des données confidentielles, ou pour le moins non autorisées, ou d'attaquer l'intégrité d'une ou plusieurs applications présentes sur la carte à puce. Enfin, si la carte à puce est connectée au monde extérieur, les dysfonctionnements provoqués peuvent se propager à l'extérieur de la carte à puce.
L'invention vise à pallier les inconvénients des procédés et dispositifs de l'art connu, et dont certains viennent d'être rappelés. L'invention se fixe pour but un procédé de sécurisation dynamique d'applications en langage du type à données typées dans un système embarqué.
Elle se fixe également pour but un système pour la mise en œuvre de ce procédé.
Pour ce faire, selon une première caractéristique, un élément d'information binaire comprenant un ou plusieurs bits, que l'on appellera ci- après "élément d'information de type", est associé à chaque objet manipulé par la machine virtuelle, dans le cas du langage "JAVA" précité. De façon plus générale, un élément d'information de type est associé à chaque donnée typée manipulée dans un langage donné, du type à objets ou données typés.
Selon une autre caractéristique, les éléments d'information de type sont stockés physiquement dans des zones de mémoire particulières des moyens de mémorisation du système embarqué à puce électronique.
Selon une autre caractéristique encore la machine virtuelle, toujours dans le cas du langage "JAVA" vérifie lesdits éléments d'information de type lors de certaines opérations d'exécution du "p-code", telles la manipulation d'objet dans la pile, etc., opérations qui seront précisées ci-après. De façon plus générale également, pour un autre langage, le processus est similaire et il est procédé à une étape de vérification des éléments d'information de type. On constate donc que, de façon avantageuse, ladite vérification est d'un type que l'on peut appeler dynamique, puisqu'effectuée en temps réel lors de l'interprétation ou de l'exécution du code. La machine virtuelle, ou ce qui en tient lieu pour un langage autre que le langage "JAVA", vérifie, en continu et avant ladite exécution d'une instruction ou d'une opération, que l'élément d'information de type correspond bien au type attendu de l'objet ou de la donnée typé à manipuler. Lorsqu'un type incorrect est détecté, des mesures sécuritaires sont prises afin de protéger la machine virtuelle et/ou d'empêcher toutes opérations non conformes et/ou dangereuses pour l'intégrité du système embarqué à puce électronique.
Selon une première variante de réalisation supplémentaire du procédé selon l'invention, lesdits éléments d'information de type sont également utilisés avantageusement pour permettent la gestion de piles de largeurs variables, ce qui permet d'optimiser l'espace mémoire du système embarqué à puce électronique, dont les ressources de ce type sont, par nature, limitées, comme il a été rappelé.
Selon une deuxième variante de réalisation supplémentaire, cumulable avec la première, les éléments d'information de type sont également utilisés, en y adjoignant un ou plusieurs bit(s) d'information supplémentaire(s), utilisés comme "drapeau" ("flags" selon la terminologie anglo-saxonne), pour marquer les objets ou les données typées. Ce marquage est alors utilisé pour indiquer si ces derniers éléments sont utilisés ou non, et dans ce dernier cas, s'ils peuvent être effacés de la mémoire, ce qui permet également de gagner de la place mémoire.
L'invention a donc pour objet principal un procédé pour l'exécution sécurisée d'une séquence d'instructions d'une application informatique se présentant sous la forme de données typées enregistrées dans une première série d'emplacements déterminés d'une mémoire d'un système informatique, notamment un système embarqué à puce électronique, caractérisé en ce que des données supplémentaires dites éléments d'information de type sont associés à chacune desdites données typées, de manière à spécifier le type de ces données, en ce que lesdits éléments d'information de type sont enregistrés dans une deuxième série d'emplacements de mémoire déterminés de ladite mémoire de système informatique, et en ce que, avant l'exécution d'instructions d'un type prédéterminé, il est procédé à une vérification en continu, préalable à l'exécution d'instructions prédéterminées, de la concordance entre un type indiqué par ces instructions et un type attendu indiqué par lesdits éléments d'information de type enregistrés dans ladite deuxième série d'emplacement de mémoire, de manière n'autoriser ladite exécution qu'en cas de concordance entre lesdits types.
L'invention a encore pour objet un système embarqué à puce électronique pour la mise en œuvre de ce procédé. L'invention va maintenant être décrite de façon plus détaillée en se référant aux dessins annexés, parmi lesquels : les figures 1A à 1 G illustrent les principales étapes d'une exécution correcte d'un exemple de "p-code" dans une mémoire à pile associée à des zones de mémoire spécifiques stockant des données dites éléments d'information de type selon l'invention ; les figures 2A et 2B illustrent schématiquement des étapes d'exécution de ce même code, mais contenant une altération menant à une exécution incorrecte et une détection de cette altération par le procédé de l'invention ; et - la figure 3 illustre schématiquement un système comprenant une carte à puce pour la mise en œuvre du procédé selon l'invention.
Dans ce qui suit, sans en limiter en quoi que ce soit la portée, on se placera ci-après dans le cadre de l'application préférée de l'invention, sauf mention contraire, c'est-à-dire dans le cas d'un système embarqué à puce électronique intégrant une machine virtuelle "JAVA" pour l'interprétation de
"p-code".
Comme il a été rappelé dans le préambule de la présente description, lors de l'exécution d'une méthode donnée, la machine virtuelle retrouve le "p-code" correspondant. Ce "p-code" identifie des opérations spécifiques à effectuer par la machine virtuelle. Une pile particulière est nécessaire pour le traitement de variables dites locales, d'opérations arithmétiques ou pour l'invocation d'autres méthodes.
La pile sert de zone de travail pour la machine virtuelle. Pour optimiser les performances de la machine virtuelle, la largeur de la pile est généralement fixée pour un type primitif donné. Comme il a été également rappelé, dans cette pile deux grands types d'objets peuvent être manipulés : des objets de type dit "primitif", ceux connus sous les dénominations "int" (pour entier long : 4 octets), "short" (pour entier court : 2 octets), "byte" (octet), "boolean" (objet booléen) ; et des objets de type dit "référence" (tableaux d'objets de type primitif, instances de classes).
C'est ce dernier type d'objets qui pose le plus de problème, d'un point de vue sécurité, puisqu'il existe des possibilités, comme indiqué précédemment, de les manipuler de façon artificielle et de créer ainsi des dysfonctionnements de natures diverses.
Ils existent plusieurs types d' "opcodes", et notamment ; la création d'un objet de type primitif (par exemple les opcodes dénommés "bipυsh" ou "iconst") ; - l'exécution d'opérations arithmétiques sur des objets de type primitif
(par exemple les "opcodes" dénommés "iadd" ou "sadd") ; la création d'un objet référence (par exemple les "opcodes" dénommés "new", "newarray" ou "anewarray"). la gestion de variables locales (par exemple les "opcodes" dénommés "aload", "iload" ou "/store") ; et la gestion de variables de classes (par exemple les "opcodes" dénommés "getstatic a" ou "putfieldj").
Chaque "opcode" qui utilise des objets placés en pile est typé afin de s'assurer que son exécution puisse être contrôlée. Généralement la(les) première(s) lettre(s) des "opcodes" indique(nt) le type utilisé. A titre d'exemple, et pour fixer les idées, (la ou les première(s) lettre(s) étant graissée pour mettre en évidence cette disposition), on peut citer les
"opcodes" suivants :
"aload" pour les objets références ; - "iload" pour les entiers ; et
"iaload" pour les tableaux d'entiers. Dans ce qui suit, par mesure de simplification la "machine virtuelle JAVA" sera appelée JVM.
Selon une première caractéristique du procédé selon l'invention, des éléments d'information de type sont stockés dans une zone mémoire sous la forme, chacun, d'un ou de plusieurs bits. Chacun de ces éléments d'information de type caractérise un objet manipulé par la JVM. On associe notamment un élément d'information de type à : chaque objet empilé dans la zone de donnée de la pile ; chaque variable locale (variable dont la portée ne dépasse pas le cadre d'une méthode) ; et à chaque objet de ce qui est appelé le "heap", c'est-à-dire une zone de mémoire stockant les objets dits "référence", chaque tableau et chaque variable globale.
Cette opération peut être appelée "typage" des objets. Selon une deuxième caractéristique du procédé de l'invention, la JVM vérifie le typage dans les cas suivants : lorsqu'un "opcode" manipule un objet stocké dans la pile ; récupère un objet dans la zone du "heap" ou dans celle des variables locales pour le placer en pile ; - modifie un objet dans la zone du "heap" ou dans celle des variables locales ; et lors de l'invocation d'une nouvelle méthode, lorsque les opérandes sont comparés à la signature de la méthode.
Selon une autre caractéristique du procédé de l'invention, la JVM vérifie, avant l'exécution des opérations ci-dessus, que leurs types correspondent bien à celui attendu (c'est-à-dire ceux donnés par les
"opcode" à effectuer).
Dans le cas de la détection d'un type incorrect, des mesures sécuritaires sont prises afin de protéger la JVM et/ou d'empêcher toutes opérations illégales ou dangereuses pour l'intégrité du système, tant d'un point de vue logique que matériel. Pour mieux expliciter le procédé selon l'invention, on va maintenant le détailler en considérant un exemple particulier de code source en langage "JAVA".
On suppose également que la JVM est associée à une pile de 32 bits comportant au plus 32 niveaux et supportant les types primitifs (par exemple "int", "short", "byte", "boolean" et "object référence")
Le typage de la pile, selon l'une des caractéristiques de l'invention, peut alors être réalisé à l'aide d'éléments d'information de type de longueur
3 bits, conformément à la TABLE I placée en fin de la présente description. Les valeurs portées dans la TABLE I sont naturellement arbitraires. D'autres conventions pourraient être prises sans sortir du cadre de l'invention.
Le code source "JAVA" qui va être considéré ci-après à titre d'exemple particulier est le suivant :
Source "JAVA" (1) :
Public void method(){ int[] buffer; //Déclaration buffer=new int[2] ; // création d'un tableau d'entiers de 2 éléments buffer[1]=5 ; // initialisation du tableau avec la valeur 5
}
Après un passage dans un compilateur approprié, un fichier "classe" contenant le "p-code" (2) correspondant au code source ci-dessus (1) est obtenu. Il se présente comme suit :
"p-code" (2) :
iconst_2 // Push int constant 2 newarray TJNT astore_1 int[] buffer aload_1 int[] buffer iconst_1 // Push int constant 1 iconst_5 // Push int constant 5 iastore return
Comme il est bien connu de l'homme de métier, les trois premières lignes correspondent à la création du tableau précité (voir code source (1)). Les cinq dernières lignes correspondent à l'initialisation de ce tableau
On va maintenant illustrer en détail les étapes d'une exécution correcte du "p-code" ci-dessus. Puisque le "p-code" est un langage de type interprété, les lignes successives sont lues les unes après les autres et les étapes précitées correspondent à l'exécution de ces lignes, avec éventuellement l'exécution d'itérations et/ou de branchements. Dans ce qui suit, les différentes lignes de code sont graissées pour les mettre en évidence.
Exécution correcte
Etape 1 : "iconst_2"
La figure 1 A illustre de façon schématique l'étape d'exécution de ce "p-code". On a représenté, sous la référence 1 , la mémoire du système embarqué à puce électronique (non représenté). De façon plus précise, cette mémoire 1 est divisée en quatre parties principales, deux étant communes à l'art connu : la zone dite "zone data" (données) 2a et la zone dite "zone variable locale" 3a. Ces zones, 2a et 3a, constituent la pile proprement dite de la machine virtuelle "JAVA" (JVM) que l'on appellera ci- après par simplification "pile de la JVM". A ces zones sont associées des zones de mémoire, 4a et 5a, respectivement, spécifiques à l'invention, que l'on appellera zones de "Typage". Selon un des aspects de l'invention, les zones de mémoire, 4a et 5a, sont destinées à stocker des éléments d'information de type (de longueur 3 bits dans l'exemple décrit) associés aux données stockées dans les zones 2a et 3a, respectivement, dans des emplacements de mémoire en relation biunivoque avec les emplacements de mémoire de ces zones. L'organisation logique de ces zones de mémoire est du type dit "pile" comme rappelé. Aussi, elles ont été représentées sous la forme de tableaux de dimensions cxl, avec c nombre de colonnes et / nombre de lignes, c'est-à- dire la "hauteur" de la pile ou niveau (qui peut varier à chaque étape de l'exécution d'un "p-code"). Dans l'exemple, c=4 pour les zones "zone data" 2a et "zone variable locale" 3a (chaque colonne correspondant à une position de mémoire de 4 octets, soit au total 32 bits), et c=3 pour les zones de "typage", 4a et 5a, (chaque colonne correspondant à une position de mémoire de 1 bit). Sur la figure 1A, le nombre de lignes représenté (ou numéro de niveau : 1 à 32 maximum dans l'exemple décrit) est égal à 2 pour toutes les zones de mémoire. Chacune des zones de mémoire, 2a à 5a, constitue donc une pile élémentaire.
On doit bien comprendre cependant que, physiquement, les positions de mémoires précitées peuvent être réalisées à base de divers circuits électroniques : cellules de mémoire vive, registres, etc. De même, elles ne sont pas forcément contiguës dans l'espace mémoire 1. La figure 1 A ne constitue qu'une représentation schématique de l'organisation logique en piles de la mémoire 1.
L' "opcode" à exécuter pendant cette première étape n'a ni paramètre, ni opérande. La valeur entière 2 (soit "0002") est placée dans la pile : au niveau 1 (ligne inférieure dans l'exemple) de la zone 2a. La zone de "Typage" correspondante 4a est mise à jour.
D'après les conventions de la TABLE I, la valeur "int" (entier) "000" (en bits) est placée dans la zone de "Typage" 4a, également au niveau 1 (ligne inférieure). Aucune valeur n'est placée dans la "zone variable locale" 3a. Il en est de même de la zone de "Typage" correspondante 5a. Etape 2 : ne array T_INT
L'étape correspondante est illustrée par la figure 1 B.
Les éléments communs à la figure 1A portent les mêmes références numériques et ne seront re-décrits qu'en tant que de besoin. Seule la valeur littérale associée aux valeurs numériques est modifiée. Elle est identique à celle de la figure correspondante, soit b dans le cas de la figure 1 B, de manière à caractériser les modifications successives des contenus des zones de mémoire. Il en sera de même pour les figures suivantes 1 C à 1 G.
L' "opcode" à exécuter pendant cette deuxième étape a pour paramètre le type de tableau à créer (soit type "int").
Cet "opcode" a pour opérande une valeur qui doit être de type "int", correspondant à la taille du tableau à créer (soit 2).
La vérification de la zone de "Typage" (à l'état 4a) indique un type correct. L'exécution est donc possible. Un objet référence est créé dans la "Pile JVM" : par exemple la valeur (arbitraire) de quatre octets "1234" est placée dans les positions de mémoire de la "zone variable locale" (niveau 1). Puisqu'il s'agit d'un objet de type référence, la valeur "100" (en bits) est placée dans la zone de "Typage" correspondante 5b (niveau 1 ). Aucune valeur n'est placée dans la zone de mémoire 3b, ni dans la zone de "Typage" 5b.
Etape 3 : astore_1 int[] buffer
Cette étape est illustrée par la figure 1 C.
L' "opcode" a pour opérande une valeur qui doit être de type "Objet référence". La vérification de la zone de "Typage" (à l'état 4b) indique un type correct. L'exécution est donc possible.
L'objet référence est déplacé vers la "zone variable locale" 3c : emplacement 1 (niveau 1 ).
Les zones de "Typage", 4c et 5c sont mise à jour : la valeur "100" (en bits) est déplacée du niveau 1 de la zone 4c vers le niveau 1 de la zone 5c. Etape 4 : aloacM intQ buffer
Cette étape est illustrée par la figure 1 D.
Cet "opcode" a pour objet d'empiler l'objet référence "1234", stocké dans la "zone variable locale" 3d, au niveau 1 de la "zone data" 2d, c'est-à- dire dans les positions de mémoire de la ligne inférieure de cette zone.
La vérification de la zone de "Typage" (à l'état 5c) indique un type correct. L'exécution est donc possible.
L'objet référence "1234" est placé dans la "zone data" 2d. Les zones de "Typage" 4d et 5d sont mises à jour et stockent toutes deux, dans les emplacements de mémoire correspondants, la valeur "100" (en bits), représentative d'un type "Objet référence".
Etape 5 : iconst_1 // Push int constant 1
Cette étape est illustrée par la figure 1 E.
L' "opcode" à exécuter pendant cette étape n'a ni paramètre ni opérande. La valeur entière 1 (soit "0001 ") est placée dans la pile : emplacement 2 (niveau 2) de la "zone data" 2e. La zone de "Typage" correspondante 4e est mise à jour, également au niveau 2 (le niveau 1 reste inchangé : valeur "1000"). La valeur "int" (entier) "000" (en bits) est placée dans la zone de "Typage" 4e (niveau 2). Les zones 3e et 5e restent inchangées.
Etape 6 : iconst_5 // Push int constant 5 Cette étape est illustrée par la figure 1 F.
L' "opcode" à exécuter pendant cette étape n'a ni paramètre ni opérande. La valeur entière 1 (soit "0001 ") est placée dans la pile : niveau 3 de la "zone data" 2f. La zone de "Typage" correspondante 4f est mise à jour, également au niveau 3 (les niveaux 1 et 2 restent inchangés : valeurs "1000" et "000" respectivement). La valeur "int" (entier) "000" (en bits) est placée dans la zone de "Typage" 4f. Les zones 3f et 5f restent inchangées. Etape 7 : iastore Cette étape est illustrée par la figure 1 G. Cet "opcode" a pour opérande une valeur de type "int", un index de type "int" et un objet référence de type tableau.
La vérification de la zone de "Typage" (à l'état 4f : niveau 3) indique un type correct. L'exécution est donc possible. La valeur est stockée dans l'objet référence à l'index donné.
Etape 7 : return
Cet "opcode" indique la fin de la méthode, la pile doit alors être vide.
En considérant de nouveau le même "p-code" (voir (2), obtenu après compilation du code source (1)), on va maintenant détailler un exemple d'exécution incorrecte.
Exécution incorrecte :
A l'étape que l'on nommera 4' (correspondant à l'étape 4 : figure 1 D). Il est supposé que le "p-code" a été altéré et que I' "opcode" :
"aload int Q buffer" , a été remplacé, par exemple, par I' "opcode" suivant :
"iipush 0x5678", instruction dans laquelle " Ox" indique une valeur hexadécimale.
Comme illustré par la figure 2A, cet "opcode", de type objet de référence, stocké au niveau 1 de la "zone variable locale" 3a', a pour objet d'empiler un entier de valeur "5678" dans la pile, dans la "zone data" 2'a.
La zone de "Typage" 4a' va être mise à jour. Il s'ensuit que les niveaux 1 des zones de "Typage", 4a' et 5a', vont tous deux contenir la valeur "100" (en bits), c'est-à-dire une valeur associée à un "Objet référence". Cette configuration particulière est illustrée par la figure 2A.
L'exécution se poursuit normalement comme dans le cas précédemment illustré par référence aux figures 1 E et 1 F. Etape 5' : iconst_1 // Push int constant 1 Etape 6' : iconst_5 // Push int constant 5
L'état des zones de la "pile de la JVM", "zone variable locale" 3b' et "zone data" 2b', est illustré par la figure 2B. de façon plus précise la "zone data" 2b' enregistre, au niveau 1 , la valeur entière "5678", au niveau 2, la valeur entière "0001 " et au niveau 3, la valeur entière "0005". La "zone variable locale" 3a' est restée inchangée. Il en est de même de la zone de "Typage" correspondante 5a'. Par contre, la zone de "Typage" 4b' est mise à jour et les valeurs suivantes sont enregistrées aux niveaux respectifs 1 à 3 : "100", "000" et "000" (en bits). Etape 7' : ia store
Cet "opcode" a pour opérande une valeur de type "int", un index de type "int" et un objet référence de type tableau.
La vérification de la zone de "Typage" (niveau 1 de la zone, à l'état 4b') indique que le code détecté est incorrect. En effet, un entier ("int" ; code "000") est attendu à la place d'un "Objet référence" (code "100").
La JVM détecte donc la présence d'un "opcode" illégal menaçant la sécurité du système. L'exécution normale de la séquence d'instructions en cours est interrompue et remplacée par l'exécution d'instructions correspondant à des mesures sécuritaires pré-programmées : signal d'alerte, etc.
On a supposé jusqu'à présent que la largeur (ou taille) de la "pile de la JVM" ; que ce soit celle de la "zone data" ou la "zone variable locale", était fixe, ce qui est généralement le cas dans l'art connu. Dans l'exemple décrit, on a supposé que chaque emplacement de mémoire compte quatre octets (soit 32 bits). Cependant, une telle disposition s'avère pénalisante en terme de capacité de mémoire. En effet, d'une application logicielle à l'autre, voire à l'intérieur d'une même application, le nombre d'octets nécessaire pour chaque instruction est variable. Comme il a été indiqué, l'agencement les piles élémentaires des "zone data" et "zone variable locale" telles qu'illustrées par les figures 1A à 1 G, ou 2A à 2B, ne représentent qu'une vue logique de l'espace mémoire 1. Il est donc tout à fait possible de conserver une architecture logique du type pile, même si les emplacements de mémoire, successifs ou non, sont de longueurs variables, voire même si les différentes positions (cellules) de mémoire sont physiquement dispersées.
Aussi, selon une première variante supplémentaire du procédé selon l'invention, les éléments d'information de type permettent aussi de déterminer la largeur instantanée nécessaire, en positions de mémoire, des zones de la "pile de la JVM". Il suffit, pour ce faire, que les codes enregistrés dans les zones de "Typage" de la mémoire soient associés, en tout ou partie, à une information caractérisant la largeur de la pile précitée. A titre d'exemple non limitatif, il peut s'agir de bits supplémentaires, ajoutés aux codes de typage, ou d'une combinaison de bits non utilisée de ces codes. Dans le premier cas, si la largeur de la pile peut varier, toujours à titre d'exemple, entre 1 et 4 octets, il suffit de 2 bits supplémentaires pour caractériser les largeurs suivantes :
Figure imgf000020_0001
Cette disposition, qui permet d'optimiser l'espace mémoire en fonction des applications à exécuter, conduit à un gain de place de mémoire substantiel, ce qui constitue un avantage appréciable lorsqu'il s'agit de dispositifs, telle notamment une carte à puce, dont les ressources de stockage sont limitées par nature.
Selon une deuxième variante de réalisation du procédé selon l'invention, il est également possible d'utiliser les éléments d'information de type pour indiquer si un objet est encore utilisé (c'est-à-dire doit être conservé) ou peut être effacé de la "zone variable locale". En effet, au bout d'un certain nombre d'opérations, un objet donné enregistré dans cette zone n'est plus utilisé. Le laisser en permanence constitue donc une perte inutile d'espace mémoire. A titre d'exemple non limitatif, on peut ajouter un bit d'information aux codes enregistrés dans les zones de "Typage", faisant fonction de drapeau, ou "flag" selon la terminologie anglo-saxonne. L'état de ce bit indique alors si l'objet doit être conservé (car encore utilisé) ou peut être effacé, et le marque comme tel. Les conventions arbitraires suivantes peuvent être adoptes :
- état logique "0" = objet utilisé
- état logique "1 " = objet pouvant être effacé
Cette disposition, que l'on peut qualifier de mécanisme de type "garbage collector" (ou "ramasse-miettes") permet aussi un gain en espace mémoire.
Naturellement, les dispositions propres aux deux variantes de réalisation supplémentaires qui viennent d'être décrites peuvent être cumulées. La figure 3 illustre schématiquement un exemple d'architecture de système informatique à base d'applications de carte à puce pour la mise en œuvre du procédé selon l'invention qui vient d'être décrit.
Ce système comprend un terminal 7, qui peut être relié ou non à des réseaux extérieurs, notamment au réseau Internet RI, par un modem ou tous moyens équivalents 71. Le terminal 7, par exemple un micro-ordinateur, comprend notamment un compilateur 9. Le code peut être compilé à l'extérieur du terminal pour donner un fichier dit " Class" (compilateur "JAVA" vers "Class"), c'est ce fichier qui est téléchargé par un navigateur Internet, le micro-ordinateur comprend lui un convertisseurr qui donne un fichier dit "Cap" ("Class" vers "Cap"). Ce convertisseur réduit notamment la taille du fichier "Class" pour permettre de le charger sur une carte à puce. Une application quelconque, par exemple téléchargée via le réseau Internet RI et écrite en langage "JAVA" est compilée par le compilateur 9 et chargée, via un lecteur de carte à puce 70 dans les circuits de mémoire 1 de la carte à puce 8. Celle-ci intègre, comme il a été rappelé, une machine virtuelle "JAVA (JVM) 6 capable d'interpréter le "p-code" issu de la compilation et chargés dans la mémoire 1. On a également représenté différentes piles de mémoire : les zones "zone data" 2 et "zone variable locale" 3, ainsi que les zones de typage, 4 et 5, ces dernières spécifiques à l'invention. La carte à puce 8 comprend également des moyens classiques de traitement de données reliés à la mémoire 1 , par exemple un microprocesseur 80.
Les communications entre la carte à puce 8 et le terminal 7, via le lecteur 70, d'une part, et entre le terminal 7 et le monde extérieur, par exemple le réseau Internet RI, via le modem 71 , d'autre part, s'effectuent de façon également classique en soi, et il n'y pas lieu de les décrire plus avant. A la lecture de ce qui précède, on constate aisément que l'invention atteint bien les buts qu'elle s'est fixés.
Elle permet une exécution sécurisée d'une suite d'instructions d'une application écrite langage du type à données typées se déroulant dans une mémoire à architecture de type pile. Le degré de sécurisation élevé est obtenu notamment du fait que la vérification du code est effectuée de façon dynamique, selon un des aspects de l'invention.
Cette disposition permet en outre, au prix d'une augmentation minime du temps de traitement, de se passer d'un vérificateur nécessitant des ressources de mémoire importantes. Ce type de vérificateur ne peut d'ailleurs convenir, dans la pratique, aux applications préférées de l'invention.
Il doit être clair cependant que l'invention n'est pas limitée aux seuls exemples de réalisations explicitement décrits, notamment en relation avec les figures 1A à 1 G, 2A à 2B et 3. De même, bien que l'invention s'applique plus particulièrement à un langage de type objet, et plus particulièrement au "p-code" du langage "JAVA", obtenu après compilation, elle s'applique à un grand nombre de langage mettant en œuvre des données typées, tels les langages "ADA" ou "KAMEL" rappelés dans le préambule de la présente description. Enfin, bien que l'invention soit particulièrement avantageuse pour des systèmes embarqués à puce électronique, dont les ressources informatiques, tant de traitement de données que de stockage de ces données, sont limitées, notamment pour des cartes à puce, elle convient parfaitement, a fortiori, pour des systèmes plus puissants.
TABLE I
Figure imgf000023_0001

Claims

REVENDICATIONS
1. Procédé pour l'exécution sécurisée d'une séquence d'instructions d'une application informatique se présentant sous la forme de données typées enregistrées dans une première série d'emplacements déterminés d'une mémoire d'un système informatique, notamment un système embarqué à puce électronique, caractérisé en ce que des données supplémentaires dites éléments d'information de type sont associées à chacune desdites données typées, de manière à spécifier le type de ces données, en ce que lesdits éléments d'information de type sont enregistrés dans une deuxième série d'emplacements de mémoire déterminés (4, 5) de ladite mémoire (1) de système informatique (8), et en ce que, avant l'exécution d'instructions d'un type prédéterminé, il est procédé à une vérification en continu, préalable à l'exécution d'instructions prédéterminées, de la concordance entre un type indiqué par ces instructions et un type attendu indiqué par lesdits éléments d'information de type enregistrés dans ladite deuxième série d'emplacement de mémoire (4, 5), de manière n'autoriser ladite exécution qu'en cas de concordance entre lesdits types.
2. Procédé selon la revendication 1 , caractérisé en ce que chacun desdits éléments d'information de type est constitué par une suite de bits enregistrés dans des emplacements de mémoire de ladite deuxième série (4, 5), en correspondance biunivoque avec des emplacements de mémoire de ladite première série (2, 3) dans lesquels sont enregistrées desdites données typées associées, et dont la configuration est représentative d'un desdits types de données typées.
3. Procédé selon la revendication 1 , caractérisé en ce que lesdites instructions étant celles d'une application écrite en langage "JAVA" (marque déposée), lesdites données typées sont constituées par des objets typés, en ce que ledit système informatique intègre une pièce de logicielle dite machine virtuelle "JAVA" (5) manipulant lesdits objets typés, en ce que, lesdits emplacements de mémoire (2-5) de ladite mémoire (1) du système informatique (8) étant organisés en piles comportant un 5 nombre maximum de niveaux déterminé, chaque niveau constituant un desdits emplacements de mémoire, lesdits objets typés sont enregistrés dans au moins une première pile élémentaire dite zone de données (2) et un deuxième pile élémentaire dite zone de variables locales (3), et en ce que lesdits éléments d'information de type sont répartis dans deux piles w élémentaires supplémentaires (4, 5) en relation biunivoque avec lesdites première (2) et deuxième (3) piles élémentaires, de manière à spécifier le type desdits objets associés enregistrés dans lesdites zones de données (2) et de variables locales (3).
4. Procédé selon la revendication 1 , caractérisé en ce que lorsque ladite 15 concordance n'est pas réalisée, l'exécution de ladite séquence d'instructions est interrompue et remplacée par l'exécution d'instructions correspondant à des mesures sécuritaires pré-programmées
5. Procédé selon la revendication 3, caractérisé en ce que lesdits éléments d'information de type sont associés à des éléments 0 d'information supplémentaires déterminant la taille desdits emplacements de mémoires desdites piles (2, 3) enregistrant lesdits objets typés, de manière à rendre variable la taille desdites piles, en fonction desdits objets à manipuler.
6. Procédé selon la revendication 3, caractérisé en ce que lesdits 5 éléments d'information de type sont associés à des éléments d'information supplémentaires, dits drapeaux, de manière à marquer lesdits objets qui leur sont associés et à indiquer s'ils doivent être conservés dans lesdites piles (2, 3) ou peuvent être effacés.
7. Système embarqué à carte à puce électronique comprenant des moyens de traitement informatique de données et des moyens de mémoire pour l'exécution sécurisée d'une séquence d'instructions d'une application informatique se présentant sous la forme de données typées enregistrées dans une première série d'emplacements déterminés d'une mémoire d'un système informatique, caractérisé en ce que lesdits moyens de mémoire (1) comprennent une deuxième série d'emplacements déterminés (4, 5) pour l'enregistrement de données supplémentaires dites éléments d'information de type, associés à chacune desdites données typées, de manière à spécifier le type de ces données, et des moyens de vérification (6) permettant une vérification en continu, préalable à l'exécution d'instructions prédéterminées, de la concordance entre un type indiqué par ces instructions et un type indiqué par lesdits éléments d'information de type, de manière n'autoriser ladite exécution qu'en cas de concordance entre lesdits types.
8. Système selon la revendication 7, caractérisé en ce que, ladite première série d'emplacements déterminés de ladite mémoire (1) du système embarqué à puce électronique (8) étant organisée en piles comportant un nombre maximum de niveaux déterminé, chaque niveau constituant un desdits emplacements de mémoire, lesdites données typées sont enregistrées dans au moins une première pile élémentaire dite zone de données (2) et une deuxième pile élémentaire dite zone de variables locales (3), et en ce que ladite deuxième série d'emplacements de mémoire est aussi organisée en piles élémentaires (4, 5), en relation biunivoque avec lesdites première (2) et deuxième (3) piles élémentaires.
9. Système selon la revendication 8, caractérisé en ce que lesdits éléments d'information de type enregistrés dans ladite deuxième série d'emplacements de mémoire (4, 5) sont associés à des éléments d'information supplémentaires déterminant la taille desdits emplacements de mémoires desdites piles (2, 3) enregistrant lesdites données typées. Système selon la revendication 7, caractérisé en ce que ledit système embarqué est une carte à puce (8).
PCT/FR2001/001506 2000-05-17 2001-05-17 Procede de securisation d'un langage du type a donnees typees, notamment dans un systeme embarque et systeme embarque de mise en oeuvre du procede WO2001088705A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
AU62437/01A AU6243701A (en) 2000-05-17 2001-05-17 Method for making secure a typed data language in particular in an integrated system and integrated system therefor
EP01936554A EP1287432A1 (fr) 2000-05-17 2001-05-17 Procede de securisation d'un langage du type a donnees typees, notamment dans un systeme embarque et systeme embarque de mise en oeuvre du procede
JP2001585035A JP2003533820A (ja) 2000-05-17 2001-05-17 特に組込システムにおける型付きデータ用型付き言語の安全化方法とその方法を利用する組込システム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR00/06882 2000-05-17
FR0006882A FR2809200B1 (fr) 2000-05-17 2000-05-17 Procede de securisation d'un langage du type a donnees typees, notamment dans un systeme embarque et systeme embarque de mise en oeuvre du procede

Publications (1)

Publication Number Publication Date
WO2001088705A1 true WO2001088705A1 (fr) 2001-11-22

Family

ID=8850757

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2001/001506 WO2001088705A1 (fr) 2000-05-17 2001-05-17 Procede de securisation d'un langage du type a donnees typees, notamment dans un systeme embarque et systeme embarque de mise en oeuvre du procede

Country Status (7)

Country Link
US (1) US20030028742A1 (fr)
EP (1) EP1287432A1 (fr)
JP (1) JP2003533820A (fr)
CN (1) CN1269035C (fr)
AU (1) AU6243701A (fr)
FR (1) FR2809200B1 (fr)
WO (1) WO2001088705A1 (fr)

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006508845A (ja) * 2002-11-12 2006-03-16 ノールブレムス・システムズ・フォー・コマーシャル・ヴィークルス・エルティーディー 車両用電子制御装置
EP1881404A1 (fr) * 2006-07-20 2008-01-23 Gemplus Procédé de protection dynamique des données lors de l'exécution d'un code logiciel en langage intermédiaire dans un appareil numérique
US7653602B2 (en) 2003-11-06 2010-01-26 Visa U.S.A. Inc. Centralized electronic commerce card transactions
US7725369B2 (en) 2003-05-02 2010-05-25 Visa U.S.A. Inc. Method and server for management of electronic receipts
US7857216B2 (en) 2003-09-12 2010-12-28 Visa U.S.A. Inc. Method and system for providing interactive cardholder rewards image replacement
US8005763B2 (en) 2003-09-30 2011-08-23 Visa U.S.A. Inc. Method and system for providing a distributed adaptive rules based dynamic pricing system
US8010405B1 (en) 2002-07-26 2011-08-30 Visa Usa Inc. Multi-application smart card device software solution for smart cardholder reward selection and redemption
US8015060B2 (en) 2002-09-13 2011-09-06 Visa Usa, Inc. Method and system for managing limited use coupon and coupon prioritization
US8407083B2 (en) 2003-09-30 2013-03-26 Visa U.S.A., Inc. Method and system for managing reward reversal after posting
US8429048B2 (en) 2009-12-28 2013-04-23 Visa International Service Association System and method for processing payment transaction receipts
US8554610B1 (en) 2003-08-29 2013-10-08 Visa U.S.A. Inc. Method and system for providing reward status
US8626577B2 (en) 2002-09-13 2014-01-07 Visa U.S.A Network centric loyalty system
US9852437B2 (en) 2002-09-13 2017-12-26 Visa U.S.A. Inc. Opt-in/opt-out in loyalty system
US11132691B2 (en) 2009-12-16 2021-09-28 Visa International Service Association Merchant alerts incorporating receipt data

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100174717A1 (en) * 2002-02-28 2010-07-08 Olivier Fambon Interative serialisation procedure for structured software objects
US20040143739A1 (en) * 2003-01-16 2004-07-22 Sun Mircosystems, Inc., A Delaware Corporation Run time code integrity checks
US7281244B2 (en) * 2003-01-16 2007-10-09 Sun Microsystems, Inc. Using a digital fingerprint to commit loaded data in a device
US7165246B2 (en) * 2003-01-16 2007-01-16 Sun Microsystems, Inc. Optimized representation of data type information in program verification
US7484095B2 (en) * 2003-01-16 2009-01-27 Sun Microsystems, Inc. System for communicating program data between a first device and a second device
US7222331B2 (en) * 2003-01-16 2007-05-22 Sun Microsystems, Inc. Linking of virtual methods
US8121955B2 (en) 2003-01-16 2012-02-21 Oracle America, Inc. Signing program data payload sequence in program loading
US7272830B2 (en) * 2003-01-16 2007-09-18 Sun Microsystems, Inc. Ordering program data for loading on a device
CN100462890C (zh) * 2005-06-16 2009-02-18 北京航空航天大学 智能卡安全环境的控制方法
US20080140979A1 (en) * 2006-12-12 2008-06-12 Kim Sang Cheol Method of allocating stack in multi-threaded sensor operating system environment
FR3006471A1 (fr) * 2013-05-29 2014-12-05 Morpho Systeme et procede d'execution d'applications d'une carte a puce
FR3010814B1 (fr) * 2013-09-17 2016-12-30 Oberthur Technologies Procede et systeme de securisation d'un environnement d'execution informatique contre les attaques par confusion de type
US9384034B2 (en) * 2014-03-28 2016-07-05 International Business Machines Corporation Detecting operation of a virtual machine

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0718764A2 (fr) * 1994-12-20 1996-06-26 Sun Microsystems, Inc. Appareil et méthode interprétateur de programme en code octet avec prévérification de restrictions de type de données

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5748963A (en) * 1995-05-12 1998-05-05 Design Intelligence, Inc. Adaptive binding
US6021273A (en) * 1997-06-30 2000-02-01 Sun Microsystems, Inc. Interpreter generation and implementation utilizing interpreter states and register caching
US6651186B1 (en) * 2000-04-28 2003-11-18 Sun Microsystems, Inc. Remote incremental program verification using API definitions

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0718764A2 (fr) * 1994-12-20 1996-06-26 Sun Microsystems, Inc. Appareil et méthode interprétateur de programme en code octet avec prévérification de restrictions de type de données

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
COHEN, RICHARD: "Defensive Java Virtual Machine", VERSION 0.5 ALPHA RELEASE, 13 May 1997 (1997-05-13), Austin, Texas (USA), pages 1-14 23-38 61-62 93-94 131-133, XP002161893, Retrieved from the Internet <URL:http://www.cli.com/software/djvm/index.html> [retrieved on 20010302] *
GRIMAUD G ET AL: "FACADE: a typed intermediate language dedicated to smart cards", ESEC/FSE'99. 7TH EUROPEAN SOFTWARE ENGINEERING CONFERENCE. HELD JOINTLY WITH 7TH ACM SIGSOFT SYMPOSIUM ON THE FOUNDATIONS OF SOFTWARE ENGINEERING, TOULOUSE, FRANCE, 6-10 SEPT. 1999, vol. 24, no. 6, Software Engineering Notes, Nov. 1999, ACM, USA, pages 476 - 493, XP002161892, ISSN: 0163-5948 *
HEONSHIK SHIN ET AL: "Concurrent garbage collection with associative tag", SECOND INTERNATIONAL CONFERENCE ON COMPUTERS AND APPLICATIONS (CAT. NO.87CH2433-1), BEIJING, CHINA, 23-27 JUNE 1987, 1987, Washington, DC, USA, IEEE Comput. Soc. Press, USA, pages 230 - 236, XP002161891, ISBN: 0-8186-0780-7 *
MCGRAW G ET AL: "JAVA SECURITY AND TYPE SAFETY", BYTE,US,MCGRAW-HILL INC. ST PETERBOROUGH, vol. 22, no. 1, 1997, pages 63 - 64, XP000679974, ISSN: 0360-5280 *
STEENKISTE P ET AL: "TAGS AND TYPE CHECKING IN LISP: HARDWARE AND SOFTWARE APPROACHES", OPERATING SYSTEMS REVIEW (SIGOPS),US,ACM HEADQUARTER. NEW YORK, vol. 21, no. 4, 1 October 1987 (1987-10-01), pages 50 - 59, XP000001708 *

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8010405B1 (en) 2002-07-26 2011-08-30 Visa Usa Inc. Multi-application smart card device software solution for smart cardholder reward selection and redemption
US8626577B2 (en) 2002-09-13 2014-01-07 Visa U.S.A Network centric loyalty system
US9852437B2 (en) 2002-09-13 2017-12-26 Visa U.S.A. Inc. Opt-in/opt-out in loyalty system
US8015060B2 (en) 2002-09-13 2011-09-06 Visa Usa, Inc. Method and system for managing limited use coupon and coupon prioritization
US8239261B2 (en) 2002-09-13 2012-08-07 Liane Redford Method and system for managing limited use coupon and coupon prioritization
US10460338B2 (en) 2002-09-13 2019-10-29 Visa U.S.A. Inc. Network centric loyalty system
JP2006508845A (ja) * 2002-11-12 2006-03-16 ノールブレムス・システムズ・フォー・コマーシャル・ヴィークルス・エルティーディー 車両用電子制御装置
US8386343B2 (en) 2003-05-02 2013-02-26 Visa U.S.A. Inc. Method and user device for management of electronic receipts
US7827077B2 (en) 2003-05-02 2010-11-02 Visa U.S.A. Inc. Method and apparatus for management of electronic receipts on portable devices
US7987120B2 (en) 2003-05-02 2011-07-26 Visa U.S.A. Inc. Method and portable device for management of electronic receipts
US9087426B2 (en) 2003-05-02 2015-07-21 Visa U.S.A. Inc. Method and administration system for management of electronic receipts
US7725369B2 (en) 2003-05-02 2010-05-25 Visa U.S.A. Inc. Method and server for management of electronic receipts
US8793156B2 (en) 2003-08-29 2014-07-29 Visa U.S.A. Inc. Method and system for providing reward status
US8554610B1 (en) 2003-08-29 2013-10-08 Visa U.S.A. Inc. Method and system for providing reward status
US7857216B2 (en) 2003-09-12 2010-12-28 Visa U.S.A. Inc. Method and system for providing interactive cardholder rewards image replacement
US7857215B2 (en) 2003-09-12 2010-12-28 Visa U.S.A. Inc. Method and system including phone with rewards image
US8244648B2 (en) 2003-09-30 2012-08-14 Visa U.S.A. Inc. Method and system for providing a distributed adaptive rules based dynamic pricing system
US8005763B2 (en) 2003-09-30 2011-08-23 Visa U.S.A. Inc. Method and system for providing a distributed adaptive rules based dynamic pricing system
US8407083B2 (en) 2003-09-30 2013-03-26 Visa U.S.A., Inc. Method and system for managing reward reversal after posting
US7653602B2 (en) 2003-11-06 2010-01-26 Visa U.S.A. Inc. Centralized electronic commerce card transactions
US9710811B2 (en) 2003-11-06 2017-07-18 Visa U.S.A. Inc. Centralized electronic commerce card transactions
US8646092B2 (en) 2006-07-20 2014-02-04 Gemalto Sa Method of dynamic protection of data during the execution of a software code in intermediate language in a digital apparatus
WO2008009697A1 (fr) * 2006-07-20 2008-01-24 Gemalto Sa Procédé de protection dynamique de données pendant l'exécution d'un code logiciel dans un langage intermédiaire dans un appareil numérique
EP1881404A1 (fr) * 2006-07-20 2008-01-23 Gemplus Procédé de protection dynamique des données lors de l'exécution d'un code logiciel en langage intermédiaire dans un appareil numérique
US11132691B2 (en) 2009-12-16 2021-09-28 Visa International Service Association Merchant alerts incorporating receipt data
US8650124B2 (en) 2009-12-28 2014-02-11 Visa International Service Association System and method for processing payment transaction receipts
US8429048B2 (en) 2009-12-28 2013-04-23 Visa International Service Association System and method for processing payment transaction receipts

Also Published As

Publication number Publication date
JP2003533820A (ja) 2003-11-11
FR2809200A1 (fr) 2001-11-23
CN1383505A (zh) 2002-12-04
CN1269035C (zh) 2006-08-09
AU6243701A (en) 2001-11-26
FR2809200B1 (fr) 2003-01-24
EP1287432A1 (fr) 2003-03-05
US20030028742A1 (en) 2003-02-06

Similar Documents

Publication Publication Date Title
WO2001088705A1 (fr) Procede de securisation d&#39;un langage du type a donnees typees, notamment dans un systeme embarque et systeme embarque de mise en oeuvre du procede
EP1212678B1 (fr) Protocole de gestion, procede de verification et de transformation d&#39;un fragment de programme telecharge et systemes correspondants
EP1782191B1 (fr) Procede de chargement d&#39;un logiciel en langage intermediaire oriente objet dans un appareil portatif
FR2977694A1 (fr) Microprocesseur protege contre un debordement de pile
FR2801118A1 (fr) Procede de chargement d&#39;applications dans un systeme embarque multi-application, systeme embarque correspondant, et procede d&#39;execution d&#39;une application du systeme embarque
JP5225071B2 (ja) 埋め込みシステム、特にスマートカードにロードされる疑似コードの検証方法
EP1983436B1 (fr) Contrôle d&#39;intégrité d&#39;une mémoire externe à un processeur
WO2007068706A1 (fr) Procede pour securiser l&#39;execution d&#39;un code logiciel en langage intermediaire dans un appareil portatif
FR2841997A1 (fr) Securisation d&#39;application telechargee notamment dans une carte a puce
WO2005101725A1 (fr) Procede d&#39;authentification dynamique de programmes par un objet portable electronique
FR2643475A1 (fr) Procede de controle de l&#39;utilisation d&#39;un support d&#39;informations, notamment magnetique ou magneto-optique et systemes pour sa mise en oeuvre
WO2001002955A1 (fr) Procede de verification de transformateurs de codes pour un systeme embarque, notamment sur une carte a puce
WO2008125479A1 (fr) Procédé d&#39;exécution sécurisée d&#39;une application
EP1058917B1 (fr) Chargement de programmes informatiques en blocs
EP1713023B1 (fr) Protection de données contenues dans un circuit intégré
EP3422232B1 (fr) Procédé de protection d&#39;un dispositif électronique exécutant un programme contre des attaques par injection de faute
FR2854261A1 (fr) Procede d&#39;execution d&#39;une application logicielle par l&#39;intermediaire d&#39;un programme d&#39;amorce logicielle et architecture informatique pour la mise en oeuvre du procede
EP2252978B1 (fr) Carte a circuit integre ayant un programme d&#39;exploitation modifiable et procede de modification correspondant
FR3010814A1 (fr) Procede et systeme de securisation d&#39;un environnement d&#39;execution informatique contre les attaques par confusion de type
FR2836569A1 (fr) Espace memoire pour donnees d&#39;application telechargees dans une carte a puce
WO2011000722A1 (fr) Procédé de validation distante d&#39;un code exécutable
CA2283158A1 (fr) Procede de controle de l&#39;etancheite d&#39;applications chargees dans un terminal multi-applicatif et terminal pour la mise en oeuvre
FR2538927A1 (fr) Systeme de protection des logiciels et notamment des logiciels standards
WO2012127138A1 (fr) Procede de masquage de passage en fin de vie d&#39;un dispositif electronique et dispositif comportant un module de controle correspondant

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU CN JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

WWE Wipo information: entry into national phase

Ref document number: 2001936554

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 10031226

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 018017576

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2001936554

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2001936554

Country of ref document: EP