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)

Applications Claiming Priority (3)

Publications (1)

Family

ID=8850757

Family Applications (1)

Country Status (7)

Families Citing this family (27)

Family Cites Families (4)

• 2000
  • 2000-05-17 FR FR0006882A patent/FR2809200B1/fr not_active Expired - Fee Related
• 2001
  • 2001-05-17 EP EP01936554A patent/EP1287432A1/de 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 WO PCT/FR2001/001506 patent/WO2001088705A1/fr not_active Application Discontinuation
  • 2001-05-17 CN CN01801757.6A patent/CN1269035C/zh not_active Expired - Fee Related
  • 2001-05-17 AU AU62437/01A patent/AU6243701A/en not_active Abandoned

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events