EP1287432A1 - 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 procedeInfo
- Publication number
- EP1287432A1 EP1287432A1 EP01936554A EP01936554A EP1287432A1 EP 1287432 A1 EP1287432 A1 EP 1287432A1 EP 01936554 A EP01936554 A EP 01936554A EP 01936554 A EP01936554 A EP 01936554A EP 1287432 A1 EP1287432 A1 EP 1287432A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- memory
- type
- data
- instructions
- execution
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
- 238000000034 method Methods 0.000 title claims abstract description 41
- 238000012795 verification Methods 0.000 claims abstract description 13
- 238000004883 computer application Methods 0.000 claims abstract description 4
- 238000012545 processing Methods 0.000 claims description 9
- 230000006870 function Effects 0.000 claims 1
- 230000008569 process Effects 0.000 description 4
- 244000035744 Hura crepitans Species 0.000 description 3
- 230000004075 alteration Effects 0.000 description 3
- 238000003491 array Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 101100126176 Escherichia coli (strain K12) intQ gene Proteins 0.000 description 1
- 230000006866 deterioration Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000004064 dysfunction Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000005865 ionizing radiation Effects 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 239000011800 void material Substances 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
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 :
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
Claims
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).
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
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 |
FR0006882 | 2000-05-17 | ||
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 |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1287432A1 true EP1287432A1 (fr) | 2003-03-05 |
Family
ID=8850757
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP01936554A Withdrawn 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 |
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) |
Families Citing this family (27)
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 |
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 |
GB2395241B (en) * | 2002-11-12 | 2004-12-29 | Knorr Bremse Systeme | Electronic control apparatus for a vehicle |
US7222331B2 (en) * | 2003-01-16 | 2007-05-22 | Sun Microsystems, Inc. | Linking of virtual methods |
US7272830B2 (en) * | 2003-01-16 | 2007-09-18 | Sun Microsystems, Inc. | Ordering program data for loading on a device |
US7165246B2 (en) * | 2003-01-16 | 2007-01-16 | Sun Microsystems, Inc. | Optimized representation of data type information in program verification |
US8121955B2 (en) * | 2003-01-16 | 2012-02-21 | Oracle America, Inc. | Signing program data payload sequence in program loading |
US7281244B2 (en) * | 2003-01-16 | 2007-10-09 | Sun Microsystems, Inc. | Using a digital fingerprint to commit loaded data in a device |
US20040143739A1 (en) * | 2003-01-16 | 2004-07-22 | Sun Mircosystems, Inc., A Delaware Corporation | Run time code integrity checks |
US7484095B2 (en) * | 2003-01-16 | 2009-01-27 | Sun Microsystems, Inc. | System for communicating program data between a first device and a second device |
US7827077B2 (en) | 2003-05-02 | 2010-11-02 | Visa U.S.A. Inc. | Method and apparatus for management of electronic receipts on portable devices |
US8554610B1 (en) | 2003-08-29 | 2013-10-08 | Visa U.S.A. Inc. | Method and system for providing reward status |
US7051923B2 (en) | 2003-09-12 | 2006-05-30 | Visa U.S.A., Inc. | Method and system for providing interactive cardholder rewards image replacement |
US8407083B2 (en) | 2003-09-30 | 2013-03-26 | Visa U.S.A., Inc. | Method and system for managing reward reversal after posting |
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 |
US7653602B2 (en) | 2003-11-06 | 2010-01-26 | Visa U.S.A. Inc. | Centralized electronic commerce card transactions |
CN100462890C (zh) * | 2005-06-16 | 2009-02-18 | 北京航空航天大学 | 智能卡安全环境的控制方法 |
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 |
US20080140979A1 (en) * | 2006-12-12 | 2008-06-12 | Kim Sang Cheol | Method of allocating stack in multi-threaded sensor operating system environment |
US20110145082A1 (en) | 2009-12-16 | 2011-06-16 | Ayman Hammad | Merchant alerts incorporating receipt data |
US8429048B2 (en) | 2009-12-28 | 2013-04-23 | Visa International Service Association | System and method for processing payment transaction receipts |
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 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5748964A (en) * | 1994-12-20 | 1998-05-05 | Sun Microsystems, Inc. | Bytecode program interpreter apparatus and method with pre-verification of data type restrictions |
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 |
-
2000
- 2000-05-17 FR FR0006882A patent/FR2809200B1/fr not_active Expired - Fee Related
-
2001
- 2001-05-17 CN CN01801757.6A patent/CN1269035C/zh not_active Expired - Fee Related
- 2001-05-17 EP EP01936554A patent/EP1287432A1/fr not_active Withdrawn
- 2001-05-17 JP JP2001585035A patent/JP2003533820A/ja active Pending
- 2001-05-17 US US10/031,226 patent/US20030028742A1/en not_active Abandoned
- 2001-05-17 AU AU62437/01A patent/AU6243701A/en not_active Abandoned
- 2001-05-17 WO PCT/FR2001/001506 patent/WO2001088705A1/fr not_active Application Discontinuation
Non-Patent Citations (1)
Title |
---|
See references of WO0188705A1 * |
Also Published As
Publication number | Publication date |
---|---|
CN1383505A (zh) | 2002-12-04 |
FR2809200A1 (fr) | 2001-11-23 |
JP2003533820A (ja) | 2003-11-11 |
US20030028742A1 (en) | 2003-02-06 |
WO2001088705A1 (fr) | 2001-11-22 |
FR2809200B1 (fr) | 2003-01-24 |
CN1269035C (zh) | 2006-08-09 |
AU6243701A (en) | 2001-11-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1287432A1 (fr) | 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 | |
EP1212678B1 (fr) | Protocole de gestion, procede de verification et de transformation d'un fragment de programme telecharge et systemes correspondants | |
EP1782191B1 (fr) | Procede de chargement d'un logiciel en langage intermediaire oriente objet dans un appareil portatif | |
EP0479655B1 (fr) | Circuit intégré pour une carte à microprocesseur conçue pour recevoir des programmes multiples en mémoire programmable | |
FR2977694A1 (fr) | Microprocesseur protege contre un debordement de pile | |
FR2938358A1 (fr) | Interface de memoire securisee | |
JP5225071B2 (ja) | 埋め込みシステム、特にスマートカードにロードされる疑似コードの検証方法 | |
EP1983436B1 (fr) | Contrôle d'intégrité d'une mémoire externe à un processeur | |
WO2007068706A1 (fr) | Procede pour securiser l'execution d'un code logiciel en langage intermediaire dans un appareil portatif | |
FR2841997A1 (fr) | Securisation d'application telechargee notamment dans une carte a puce | |
FR2967275A1 (fr) | Procede, programme d'ordinateur et dispositif de securisation de code intermediaire de programmation pour son execution par une machine virtuelle | |
WO2005101725A1 (fr) | Procede d'authentification dynamique de programmes par un objet portable electronique | |
FR2643475A1 (fr) | Procede de controle de l'utilisation d'un support d'informations, notamment magnetique ou magneto-optique et systemes pour sa mise en oeuvre | |
FR2795835A1 (fr) | Procede de verification de transformateurs de codes pour un systeme embarque, notamment sur une carte a puce | |
WO2008125479A1 (fr) | Procédé d'exécution sécurisée d'une application | |
EP1058917B1 (fr) | Chargement de programmes informatiques en blocs | |
FR2854261A1 (fr) | Procede d'execution d'une application logicielle par l'intermediaire d'un programme d'amorce logicielle et architecture informatique pour la mise en oeuvre du procede | |
EP1713023B1 (fr) | Protection de données contenues dans un circuit intégré | |
EP3422232B1 (fr) | Procédé de protection d'un dispositif électronique exécutant un programme contre des attaques par injection de faute | |
FR3010814A1 (fr) | Procede et systeme de securisation d'un environnement d'execution informatique contre les attaques par confusion de type | |
FR2864658A1 (fr) | Controle d'acces aux donnees par verification dynamique des references licites | |
WO2003009110A1 (fr) | Securisation de lecture d'instructions dans un systeme de traitement de donnees | |
FR2836569A1 (fr) | Espace memoire pour donnees d'application telechargees dans une carte a puce | |
FR3095054A1 (fr) | Gestion d’une mémoire dans un dispositif électronique | |
EP2449495A1 (fr) | Procédé de validation distante d'un code exécutable |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20021217 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR |
|
17Q | First examination report despatched |
Effective date: 20070917 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20080328 |