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/445—Program loading or initiating
  • G06F9/44589—Program code verification, e.g. Java bytecode verification, proof-carrying code

Definitions

• the present invention relates to a method of checking code coherence for an embedded system.
• the invention relates more particularly, but not exclusively, to the field of applications in interpreted bytecode type (pseudo-code), loaded on a smart card.
• embedded system in the broad sense is considered, especially as a system for any portable electronic device, for example a smart card, whose processing and storage resources are relatively limited.
• an interpreted language is an uncompiled language whose execution of lines of code requires the presence of auxiliary means to interpret this code.
• An example of such a language is the Java language
• Java application (trademark) widely used in application solutions for smart cards.
• the Java application or “applet” is interpreted by an associated Java virtual machine.
• hardware solutions for example a dedicated chip, that implement the equivalent of the virtual machine.
• virtual machine will refer indifferently to auxiliary means of software or hardware type for interpreting an associated interpreted language.
• the pseudo-code (bytecode) verification for example and not exclusively Java (registered trademark), is an element key in the security of Java platforms (registered trademark).
• This check consists in particular of ensuring the integrity and the conformity of a bytecode program to properties, for example the typing of the variables of the code, this bytecode program being interpreted by a virtual machine, that is to say say a stack machine (access memory stacking and depilating) and registers (indexed access memory boxes).
• These verification operations are relatively complex and resource-intensive (RAM, processing time).
• Java registered trademark
• Java registered trademark
• new applications for example Java (registered trademark) applets
• Java registered trademark
• These applets can be corrupted or tampered with and can make calls to unauthorized memory areas creating malfunctions on the virtual machine.
• this verification has become extremely complicated in all embedded systems due to the limited resources available.
• FIG. 1 provides an example code presenting a subroutine (B7 to RET) with a call to this subroutine (line 4: JSR B7).
• a RET instruction is executed, the virtual machine executes the bytecode following the JSR having called the subroutine.
• the address of this latter is stored on the stack of the virtual machine, but without any typing instance of this information: it is a numerical value in the stack that depends on the flow of execution.
• the problem with this registration is that standard verifiers work on the basis of typing and do not have access to the numerical values themselves. It is therefore not possible to statically determine the parts of code calling the subroutine.
• the pseudo-code verification ensures that no illegal manipulation on the typing of the elements used by the bytecode is performed.
• Two properties are to be checked: - for each bytecode the height of the stack is always the same whatever the execution path,
• integrity checking requires the storage of a lot of information. It has been shown then that it is sufficient to perform this memorization only for the jump targets.
• the algorithm needs to store additional information like the instruction pointer or "program counter" (pointer on the line of code at the current verification point), the worklist (list of lines of codes to be checked later) and the current frame (set of typings of the registers and the stack at the point which is being examined, stored in the device's RAM).
• Verification with a Proof Carrying Code is also known.
• a proof component is calculated off map and then added to the program when it is transmitted on the map. This is to insert typing info into the code.
• the verification on the card is greatly facilitated and requires very little RAM (Random Access Memory).
• the disadvantage of this solution lies in the need for off-card pretreatment: the calculation of the proof; and in the larger size of the data
• the Trusted Logic (registered trademark) verifier protected by patent FR 2 815 434 is also known.
• the registers used by the virtual machine are exploded in a monomorphic manner, that is to say that each register has a unique variable typing. The RAM requirements are thus reduced.
• the disadvantage of this solution is that you need to perform an off-board calculation to modify the methods to verify the two additional properties required.
• the present invention intends to overcome the disadvantages of the prior art by proposing a code coherence verification method for an embedded system limiting the RAM consumed during processing.
• the invention also does not require any pretreatment outside the portable electronic device, for example the smart card, and without adding elements in the application code.
• the invention also aims at optimizing this management of the random access memory (RAM) during the verification phase.
• the invention realizes bytecode verification by context (polyvariant) with a particular management of the current frames in order to consume less RAM.
• context polyvariant
• One is made to find himself, during a verification in sub-program, in the situation of a check in method. To do this, we proceed to a context change, saving the state of the current data (including including the stack frame jump targets, the current frame and the worklist).
• the current frame of the routine subroutine is unified with the frame corresponding to the successor of the calling bytecode (JSR for example) of the preceding context, and then the previous context is restored.
• JSR calling bytecode
• the invention optimizes the memory consumption during the backup of the frames to the jump targets by establishing, over the water, a dictionary of stack frames (for example, the current frames to the jump targets that are stored when the context) to which these safeguards point.
• a dictionary of stack frames for example, the current frames to the jump targets that are stored when the context
• This mass of information is not compatible with the memory size available in the majority of portable electronic devices.
• the advantage of the dictionary is not to unnecessarily multiply the number of identical stack frames saved in the memory and thus provides a good compression rate because of the properties of bytecodes and compilers. interest of the dictionary is to hold the memory consumed in the portable electronic devices with limited resources, and in the case of objects with large RAM memory, to allow the use of a portable electronic object having a smaller RAM memory and thereby generating a cost saving.
• the invention easily integrates with existing solutions in order to improve performance by appropriate management of RAM.
• the invention relates in its most general sense to a method for verifying an application that can be interpreted by a virtual machine, said application being loaded into a portable electronic device comprising at least one processor and a random access memory, the method consisting in carrying out, after the loading of said application in the device and before its validation, checks on the code of said application by a processing implemented by the processor characterized in that it comprises: during a call to a subroutine, a step of saving the current verification context in the RAM, a step of creating and activating a new verification context dedicated to the subroutine, at the end of the subroutine, a step of restoring the verification context previously saved.
• the new verification context is initialized, for example only with the current frame.
• the method further comprises immediately executing the checks on the code of the called routine when the call to it has been detected. More particularly, the method does not include a preliminary step of code demarcation.
• the method does not involve recourse to resources external to said device with the exception of the power supply.
• the context includes a worklist for navigating the application code tree.
• the method further comprises, when checking a line of code of the application, a step of updating said working list with the possible successors of said line of code.
• the context includes an instruction pointer and a current frame.
• all or part of the identical frames are saved under a single address in a zone of the random access memory called a dictionary.
• the identical frames are saved under a single address and a dictionary containing the frames to be saved is created. More precisely, for each new frame to be saved in the RAM, it is checked whether all or part of the new frame is present in the dictionary, and if it is the case, we use the pointer
• the dictionary is decomposed into sections corresponding to homogeneous portions of the frames.
• one of the homogeneous parts of the dictionary corresponds to the registers.
• one of the homogeneous parts of the dictionary corresponds to the stack.
• one of the homogeneous parts of the dictionary corresponds to non-variable registers in bytecode type.
• the invention also relates to a smart card and a Java card comprising at least one Java virtual machine and an "applet" in Java interpretable language whose consistency must be verified, for the implementation of this verification method.
• FIG. 1 represents an example of bytecodes including a subroutine
• FIG. 2 represents an example of Java card architecture (registered trademark) for the implementation of the present invention
• FIG. 3 illustrates the verification method according to the present invention
• FIGS. 4 to 7 illustrate the evolution of the random access memory during the implementation of the verification method of the invention.
• FIG. 8 illustrates the use of a dictionary to optimize the management of RAM.
• the card module 1 comprises a microprocessor 2 driving a nonvolatile memory 3, for example of the flash type, a ROM 4 and a RAM RAM 5.
• the ROM 4 stores the computer programs verifiers 41 of bytecode and the virtual machine 42 allowing the execution of the bytecode.
• a virtual machine is understood to mean a machine which, when executing bytecodes, manages in RAM 5 a stack 51 and registers 52.
• the stack 51 is a top-access memory in which the data is stacked and unstacked. .
• the registers 52 are index access or free access memory boxes: one can access any information from the registers.
• a program or application 31 to be verified is stored as a file in the non-volatile memory 3.
• This program is in the form of pseudo-code or bytecodes whose invention proposes to check the integrity with respect to the virtual machine. 42.
• the file 31 is a CAP (Converted APplet) file which is the file loaded by the virtual machine 42.
• This file may contain several methods in the Java (registered trademark) sense, in which case the verification of the bytecode is method by method. If a method M2 is invoked in method M1, M1 being checked, the verifier considers M2 already checked or to check later, and proceeds to the next bytecode.
• FIG. 1 Illustrated in Figure 1, an example of a bytecode of a method M is provided.
• This bytecode includes a JSR subroutine jump in line 4 and an online RET return 11.
• the subroutine called by the JSR extends from B7 to RET.
• the bytecode verifier starts checking the method M.
• the first bytecode B1 is taken 102. Since it is a traditional bytecode to be checked 104, a verification of the integrity criteria (typing) is done 106 on the bytecode in comparison with the registers and the stack of the current frame and this current frame is updated according to the bytecode (change of typing, new variable, ).
• the current frame is the set of typings of the registers and stack of the virtual machine at the point that is being examined. Since it is the first bytecode, the current frame data 200 can be stored in memory as illustrated in FIG. 4. Additional data, for example the "worklist" 202 are also saved in memory; the working list
• worklist includes the list of the following bytecode (s) to be checked and this is set to "line 2" to indicate that the next bytecode to be processed is that of line 2.
• the worklist allows you to browse the code tree and cover all the scenarios of this journey by taking into account the multiple successors that can present each line of code.
• "Multiple successors" of a line of code means the other lines of code that can be reached from that line.
• the set of data of the current frame and complementary data (for example the worklist 202, the dictionary 203, the list 201 of the stack frames to the jump targets) constitute the current context.
• the memory pointer pi of the current frame is stored, among other things, in the memory 204, the pointers p2 to p4 complementary data (working list, ...) and the end of context pointer p5.
• the term "stack frame” or “frame” refers to the current frame at the jump target, that is at the moment when it is saved.
• the context saved consists of all the data and structure 204 RAM data useful for checking a method: worklist 202, stack frame 200, in particular.
• the verification algorithm can then resume, with the worklist set to "line 7" at the beginning of the subroutine.
• the verification algorithm then applies to bytecodes B7, B8 and B9, the context data in memory being updated.
• a unification is made with the successor of the corresponding JSR and the next item to be checked is searched for in the working list of the current context.
• the subroutine is then complete and the previous context is restored 114, as shown in FIG.
• a verification of the parameters of the method is carried out to ensure the integrity of the current typings with those of the called method.
• the verification of this method is carried out independently of the method M as previously specified.
• a dictionary of stack frames is used. Indeed, in many cases, the evolution of stack frames is slow and many of them have the same content.
• the code includes three calls to subprograms.
• the current frame can be saved in a part of the RAM 5 which is called the dictionary.
• saving the current context in the RAM 5 then uses the pointer ptrl referencing the current frame.
• the ptrl pointer associated with the stack frame of the dictionary identical to the current frame at the time of the jump is used for the backup of the current context.
• the dictionary of unused stack frames (that is, when the associated pointer is not used in any context backup) is refined as subprograms are taken out. .
• the dictionary can be built with partial stack-frame entries that are recurrent in order to optimally optimize the compression and the RAM memory gain.
• this dictionary is not limited to stack frames and can contain any type of entries that are used when saving contexts, to minimize the size of these backups.

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)
• Test And Diagnosis Of Digital Computers (AREA)
• Debugging And Monitoring (AREA)
• Storage Device Security (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=35229912

Family Applications (1)

Country Status (5)

Families Citing this family (8)

Family Cites Families (6)

• 2005
  • 2005-04-22 FR FR0551036A patent/FR2884994A1/fr active Pending
• 2006
  • 2006-03-14 JP JP2008507033A patent/JP5225071B2/ja not_active Expired - Fee Related
  • 2006-03-14 EP EP06725034A patent/EP1880282A2/fr not_active Withdrawn
  • 2006-03-14 US US11/918,973 patent/US7991953B2/en not_active Expired - Fee Related
  • 2006-03-14 WO PCT/EP2006/060676 patent/WO2006111441A2/fr not_active Application Discontinuation

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events