EP1880282A2 - Method for verification of pseudo-code loaded in a portable system particularly a chipcard - Google Patents
Method for verification of pseudo-code loaded in a portable system particularly a chipcardInfo
- Publication number
- EP1880282A2 EP1880282A2 EP06725034A EP06725034A EP1880282A2 EP 1880282 A2 EP1880282 A2 EP 1880282A2 EP 06725034 A EP06725034 A EP 06725034A EP 06725034 A EP06725034 A EP 06725034A EP 1880282 A2 EP1880282 A2 EP 1880282A2
- Authority
- EP
- European Patent Office
- Prior art keywords
- verification
- code
- context
- dictionary
- application
- 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
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)
- Storage Device Security (AREA)
- Debugging And Monitoring (AREA)
Abstract
Description
Claims
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR0551036A FR2884994A1 (en) | 2005-04-22 | 2005-04-22 | METHOD FOR VERIFYING CHARGE PSEUDO-CODE IN AN INBOARD SYSTEM, IN PARTICULAR A CHIP CARD |
PCT/EP2006/060676 WO2006111441A2 (en) | 2005-04-22 | 2006-03-14 | Method for verification of pseudo-code loaded in a portable system particularly a chipcard |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1880282A2 true EP1880282A2 (en) | 2008-01-23 |
Family
ID=35229912
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP06725034A Withdrawn EP1880282A2 (en) | 2005-04-22 | 2006-03-14 | Method for verification of pseudo-code loaded in a portable system particularly a chipcard |
Country Status (5)
Country | Link |
---|---|
US (1) | US7991953B2 (en) |
EP (1) | EP1880282A2 (en) |
JP (1) | JP5225071B2 (en) |
FR (1) | FR2884994A1 (en) |
WO (1) | WO2006111441A2 (en) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2938091B1 (en) * | 2008-10-30 | 2010-12-31 | Caps Entpr | METHOD FOR REALIZING A CALL OF AN INSTANCE OF A FUNCTION, DEVICE, CORRESPONDING COMPUTER PROGRAM |
US8626919B1 (en) * | 2008-11-07 | 2014-01-07 | Google Inc. | Installer-free applications using native code modules and persistent local storage |
US20120159449A1 (en) * | 2010-12-15 | 2012-06-21 | International Business Machines Corporation | Call Stack Inspection For A Thread Of Execution |
EP2782006B1 (en) * | 2013-03-19 | 2018-06-13 | Nxp B.V. | Process and system for verifying computer program on a smart card |
KR101583133B1 (en) * | 2014-03-26 | 2016-01-07 | 단국대학교 산학협력단 | Method for evaluating software similarity using stack and apparatus therefor |
CN106845225A (en) * | 2016-12-20 | 2017-06-13 | 北京中电华大电子设计有限责任公司 | A kind of boundary detection method of JAVA card frame |
CN109144775A (en) * | 2018-06-30 | 2019-01-04 | 深圳市文鼎创数据科技有限公司 | Application data backup restoration method, electronic equipment and the storage medium of smart card |
RU2720254C1 (en) * | 2019-12-05 | 2020-04-28 | Акционерное общество "Актив-софт" (АО "Актив-софт") | Method of software recovery and updating on a smart card |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6092147A (en) * | 1997-04-15 | 2000-07-18 | Sun Microsystems, Inc. | Virtual machine with securely distributed bytecode verification |
FR2797963B1 (en) * | 1999-08-23 | 2002-11-29 | Trusted Logic | MANAGEMENT PROTOCOL, METHOD FOR VERIFICATION AND TRANSFORMATION OF A DOWNLOADED PROGRAM FRAGMENT AND CORRESPONDING SYSTEMS |
US7120572B1 (en) * | 2000-01-06 | 2006-10-10 | Sun Microsystems, Inc. | Memory efficient program pre-execution verifier and method |
FR2840084A1 (en) * | 2002-05-27 | 2003-11-28 | Gemplus Card Int | Code verification method for limited resource microcircuits used especially for high security applications e.g. bank cards, or telecommunications, involves modification of intermediary code and verifying the reallocated code |
US20040153709A1 (en) * | 2002-07-03 | 2004-08-05 | Burton-Krahn Noel Morgen | Method and apparatus for providing transparent fault tolerance within an application server environment |
US20050277432A1 (en) * | 2003-11-26 | 2005-12-15 | Viana Rodrigo B D | Dynamic display generation for mobile communication devices |
-
2005
- 2005-04-22 FR FR0551036A patent/FR2884994A1/en active Pending
-
2006
- 2006-03-14 US US11/918,973 patent/US7991953B2/en not_active Expired - Fee Related
- 2006-03-14 JP JP2008507033A patent/JP5225071B2/en not_active Expired - Fee Related
- 2006-03-14 WO PCT/EP2006/060676 patent/WO2006111441A2/en not_active Application Discontinuation
- 2006-03-14 EP EP06725034A patent/EP1880282A2/en not_active Withdrawn
Non-Patent Citations (1)
Title |
---|
See references of WO2006111441A3 * |
Also Published As
Publication number | Publication date |
---|---|
WO2006111441A2 (en) | 2006-10-26 |
US20090049258A1 (en) | 2009-02-19 |
WO2006111441A3 (en) | 2007-12-21 |
US7991953B2 (en) | 2011-08-02 |
JP2008537240A (en) | 2008-09-11 |
FR2884994A1 (en) | 2006-10-27 |
JP5225071B2 (en) | 2013-07-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1880282A2 (en) | Method for verification of pseudo-code loaded in a portable system particularly a chipcard | |
FR2801118A1 (en) | METHOD FOR LOADING APPLICATIONS IN A MULTI-APPLICATION ONBOARD SYSTEM, CORRESPONDING ONBOARD SYSTEM, AND METHOD FOR EXECUTING AN ONBOARD SYSTEM APPLICATION | |
WO2001014958A2 (en) | Management protocol, method for verifying and transforming a downloaded programme fragment and corresponding systems | |
FR2667171A1 (en) | Portable support with easily programmable microcircuit and method of programming this microcircuit | |
WO2004013800A2 (en) | Software for generating a computer application code and software description language | |
EP1960934B1 (en) | Method for making secure execution of an intermediate language software code in a portable appliance | |
WO2001088705A1 (en) | Method for making secure a typed data language in particular in an integrated system and integrated system therefor | |
EP2453356B1 (en) | Method, computer program and device for securing byte code to be run by a virtual machine | |
EP1649363B1 (en) | Method of managing software components that are integrated into an embedded system | |
EP1700218B1 (en) | Method for determining operational characteristics of a program | |
FR2642544A1 (en) | Data processing system with a security program | |
WO2005101725A1 (en) | Method for dynamically authenticating programmes with an electronic portable object | |
WO2001002955A1 (en) | Method for verifying code transformers for an incorporated system, in particular in a chip card | |
WO2002084610A1 (en) | Method and system for managing data designed to be stored in a programmable smart card | |
WO2008125479A1 (en) | Method of secure execution of an application | |
FR2864650A1 (en) | METHOD FOR UPDATING APPLICATIONS FOR A CHIP CARD | |
FR2936327A1 (en) | METHOD FOR DOWNLOADING A .NET PROGRAM AND DEVICE THEREFOR | |
EP2252978B1 (en) | Integrated circuit card having a modifiable operating program and corresponding method of modification | |
FR3010814A1 (en) | METHOD AND SYSTEM FOR SECURING A COMPUTER EXECUTING ENVIRONMENT AGAINST TYPE CONFUSION ATTACKS | |
FR2877454A1 (en) | METHOD FOR LOADING AN OBJECT-ORIENTED INTERMEDIATE LANGUAGE CODE IN A PORTABLE DEVICE | |
WO2001097013A2 (en) | Method for managing classes for an object-oriented programming language with dynamic resolution and tool for generating native structures from java binaries implementing said method | |
FR2815434A1 (en) | Verification of coherence of codes for an embedded system such as a smart card or portable device, uses two dimensional data structure to fetch codes that can be applied to coherence rules | |
FR2875656A1 (en) | Electronic unit e.g. chip card, customization performing method, involves storing master key in volatile memory unit of electronic unit, storing diversified key in non volatile memory unit and deleting volatile unit zone having master key | |
WO2006063911A1 (en) | Method for positioning elementary data of a data structure in a storage unit | |
FR2818767A1 (en) | Method for exploring electronic cards, comprises management program which contains a manager of object programs independent of smart cards and object programs which may contain code, data and a tree like structure |
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 |
|
AK | Designated contracting states |
Kind code of ref document: A2 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR |
|
AX | Request for extension of the european patent |
Extension state: AL BA HR MK YU |
|
R17D | Deferred search report published (corrected) |
Effective date: 20071221 |
|
DAX | Request for extension of the european patent (deleted) | ||
17P | Request for examination filed |
Effective date: 20080623 |
|
RBV | Designated contracting states (corrected) |
Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: 8566 |
|
17Q | First examination report despatched |
Effective date: 20090423 |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: GEMALTO SA |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
INTG | Intention to grant announced |
Effective date: 20160720 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: GRANT OF PATENT IS INTENDED |
|
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: 20161201 |
|
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 |