Title of Invention

"A METHOD FOR SECURING COMPUTER SYSTEMS"

Abstract

The invention relates to a method of securing computer systems comprising at least one code interpretation module and memory capacity for storing the code to be interpreted. For said purpose, the invention consists in making more difficult attacks involving physical measures and/or requiring a synchronisation with the interpreted code, by introducing variants into the interpreted code runtimes and the measurable physical prints.

Full Text

The present invention relates to a method for securing computer systems. The present invention relates to securing computer systems comprising at least one code interpretation module and storage memory capacities for the code to be interpreted. More specifically, its object is to solve problems for securing computer systems comprising at least one code interpretation module (a code being defined as a structured set of instructions) which will simply be called "interpreter" in the following (hardware interpreter: microcontroller, microprocessor or software: virtual machine) and storage memory capacities for the code to be interpreted (or interpreted code). Said code may be directly written by a programmer, may be obtained automatically (which will be called code generation) from a source code in a language which is generally of a higher level or it may even result from a combination of automatic production and manual interventions. Generally, it is known that most of the inventorized attacks against such computer systems are based on physical measurements (electromagnetic emission, etc.) during execution and require synchronization with the interpreted code. In other words, the intruder must determine at what time the interpreter is found executing certain functionalities of the code. Among the most known techniques, those developed in order to find a key in cryptographic algorithms by passively spying the physical emission of a circuit may be cited: in particular the attacks of the simple power analysis (SPA) and differential power analysis (DPA) type have been successfully used for discovering DBS ("Data Encryption Standard") keys. As an example, on an embedded Java platform ("Java Card", "JEFF", "J2ME" ...) these attacks may be used in order to try to obtain information on secrets handled by the virtual Java machine. These secrets may concern both the confidential data and the Java code itself. More specifically, the object of the invention is therefore to suppress these drawbacks. For this purpose, it proposes making attacks based on physical measurements and/or requiring synchronization with the interpreted code, more difficult, by introducing alternatives in the execution times of the interpreted code and the measurable physical imprints (for example, and not exclusively, electromagnetic emission, etc.). According to the invention, this method essentially involves two types of alternatives in the execution times of the interpreted codes, in the following way: by causing at certain places of an interpreted code bypasses towards new portions of code (which do not belong to the original code) in order to complicate the synchronization and the physical imprint of the execution, or by proposing a plurality of implementations of certain instructions, each requiring a different execution time and/or having a different physical imprint and providing an identical result, so that two executions of this instruction within a same code may be performed by two different implementations. Hence, by introducing distortions in the execution times and by modifying the physical effect of the execution, both types of the above alternatives will make any correlation attempt more difficult between the observed physical expressions of an interpreted code and its functionalities. Advantageously, this method will be able to make the apparently executed code, different at each execution, and will therefore make the discovery of the actual code of the application, more difficult. This method may involve: • for the first alternative: two modes for introducing "bypass codes", four modes for realizing "bypass codes", • for the second alternative: two modes for introducing "multiple implementations" of certain instructions, three modes for realizing "alternative codes" with a variable physical imprint and duration. As regards the first alternative, the first mode for introducing "bypass codes" consists of introducing one or more specific so-called "bypass" instructions in certain particular locations of the code. This introduction may be made either manually or automatically upon generating the code. In the latter case, the code generator may be guided in order to produce these instructions by annotations inserted by the programmer in the source code and allowing the designation of portions of sensitive code (for example, and in a non-limiting way, encryption or access rights checking procedures). Execution of a bypass instruction by the interpreter causes branching towards an associated bypass code. This first method may also be improved by attaching different levels of security to bypass instructions and by associating them with all the more complex (or defensive with regards to security attacks as described above) bypass codes since their security level is high. Concerning the first alternative, the second mode for introducing "bypass codes" consists of introducing the bypass code in the implementation of the interpreter itself: between the executions of two consecutive instructions of the code, the interpreter executes the bypass code, either systematically or selectively or randomly. For example, it may execute this code only when certain sensitive methods arc called (typically from so-called API (application program interface) libraries). The advantage of the first mode is to allow selective introduction of the executions of bypass code which leads to less penalty in terms of execution times if the number of such bypasses is small. It also allows implementation of so-called "discretionary" security policies, i.e., at the discretion of the applications. On the other hand, the second mode will be more advantageous when the number of desired bypasses is large because the implementation of the method in the interpreter itself may then be optimized. Moreover, it allows implementation of so-called "proxy" security policies where checks are uniformly imposed on all the applications. Both previous aforesaid introduction modes require the introduction of a bypass code. The invention proposes four modes to reali/e these bypass codes so that they introduce alternatives in the execution times and the measurable physical imprints. Concerning the first alternative, the first mode for realizing "bypass codes" with physical imprint and variable duration consists of performing n so-called "superfluous" calculation depending on data known at execution (which may therefore differ at each execution). The superfluous calculation should be without any effect on the final result of the execution of the interpreter. A simple example of such a calculation is a parity test for a dynamic datum (known at execution) which may either lead to a void action, or to the adding of an item to a slack followed by its immediate removal. It should be noted that the number of possible actions is not necessarily limited to two. A large possible number of actions will lead to significant variability in the execution time and the physical imprint of the bypass code. "1 he second mode for realizing "bypass codes" improves ihe first mode by providing it with a random draw of an extra datum during the execution of the superfluous calculation, said extra datum being used in the calculation performed by the bypass code (for example in a test of said code). This random draw has a new variable item and makes the execution time and the physical imprint of the bypass code, even less predictable. The third mode for realizing "bypass codes" improves the efficiency of the two preceding ones by replacing the test for deciding on the next action with a branching in a so-called indirection table, i.e., containing the addresses of possible actions, at an index calculated from variable items (dynamic datum and/or result from a random draw). The fourth mode for realizing "bypass codes" improves the first embodiment (and therefore the three other ones) by considering a superfluous calculation which, while remaining without any effect on the final result, has external characteristics (physical imprint) of a particular sensitive calculation (for example encryption or decryption) without any relationship with the actual code of the application. Such a superfluous calculation enables an attacker to be fooled, who would attempt to infer secrets by measuring the physical effect of the execution of the application. Such a method may be described as a "software decoy" since its goal is to induce in error the attackers by making them believe in the presence of said sensitive calculation in the actual code of the application. This mode may simply be achieved by implementing the relevant sensitive calculation without retaining its result. Concerning the second alternative, the first mode for "introducing multiple implementations" of certain instructions, consists of enriching the set of instructions recognized by the interpreter with a plurality of implementations for a given instruction. These implementations will be achieved so as to have different physical imprints and different execution times while producing an identical result. Any of these implementations may be used in the code indiscriminately. This use may be performed either manually by programming or automatically during code generation. In the latter case, the code generator may be guided, in order to produce these instructions, by annotations inserted by the programmer into the source code and allowing designation of sensitive code portions (for example, and in a non-limiting way, encryption or access rights checking procedures). This first mode may also be improved by attaching different security levels to the implementations of instructions and associating them with all the more complex (or defensive with regard to security attacks) implementations since their security level is high. Concerning the second alternative, the second mode for introducing "multiple implementations" of certain instructions, consists of comprising in the actual implementation of the instruction, a branching to an alternative code portion which will dynamically determine the implementation to be executed. The advantage of the first mode is to minimize additional costs in terms of execution times as the selection of the instruction implementation to be applied is determined before execution. It also allows implementation of so-called "discretionary" security policies, i.e., at the discretion of the applications. The advantage of the second mode is to further complicate the attacks requiring synchronization with the code since two consecutive executions of the same instruction (at the same location in the code) will be able to take different execution times and to provide different physical imprints. Moreover, this second mode allows implementation of so-called "proxy" security policies where the checks are uniformly imposed to all the applications. Both modes do not mutually exclude each other: a realization may comprise a multiplicity of implementations for a given instruction, certain of them (or all of them) being implemented by branching to an alternative code portion dynamically determining the implementation to be executed. The aforesaid second mode of the second alternative requires the introduction of an alternative code associated with an instruction. The invention proposes three modes for realizing this alternative code so that it introduces different implementations in the execution times and the measured physical imprint. Concerning the second alternative, the first mode for realizing "alternative codes" with a physical imprint and variable duration consists of proposing a plurality of different implementations of the instruction and to condition the choice of the executed version to a dynamical test, i.e., depending on data known at execution. A simple example of such a calculation is a parity test of a dynamical datum (known at execution). A large number of implementations will lead to significant variability in execution time and in the physical imprint of the alternative code. The second mode for realizing "alternative codes" improves the first mode by providing it with a random draw of a datum which is then used for achieving the test leading to the dynamical choice of the executed version. This random draw adds a new variable item and makes the execution time and the physical imprint of the alternative code, even less predictable. The third mode for realizing "alternative codes" improves the efficiency of the two preceding ones by replacing the test for deciding on the selected version with a branching in a indirection table (containing the addresses of the available versions) at an index calculated from variable items (dynamical datum and/or result from a random draw). Thus, by introducing alternatives in the execution times of the interpreted codes and therefore in the physical imprints, it is possible to make the attacks based on said physical imprints, more difficult so that an action coded in the implementation of the application may have different electronic signatures and occurring at variable execution times. The implementation of the aforesaid interpreted codes will be performed on modules for interpreting software code such as virtual machines of the JAVA family and on modules for interpreting physical code of the microcontroller or microprocessor type. We claim: 1. A method for securing computer systems comprising at least one interpreter and memory means for storing an interpreted code having measurable physical imprints on said interpreter, characterized in that, with the purpose of making attacks based on physical measurements of said imprints or requiring synchronization with the aforesaid interpreted code, more difficult, it consists of introducing alternatives for executing the interpreted code, said alternatives having an effect on the execution times of the interpreted code or on its measurable physical imprint and being introduced according to at least one of the following steps: a first step comprising bypasses towards new code portions, so-called bypass codes, which do not belong to the original code, and a second step comprising a plurality of implementations of certain instructions, each requiring a different execution time or having a different physical imprint on said interpreter while providing an identical result. 2. The method as claimed in claim 1, wherein it comprises a second mode for introducing bypass codes consisting of introducing the bypass code in the implementation of the interpreter itself. 3. The method as claimed in claim 2, wherein the bypass code introduced into the implementation of the interpreter is executed either systematically by the interpreter or selectively or randomly. 4. The method as claimed in claim 1, wherein it comprises a third mode for realizing bypass codes consisting of replacing in the aforesaid first and second modes the test for deciding on the next action by a branching in an indirection table containing the addresses of possible actions at an index calculated from variable items (dynamical datum and/or result from a random draw). 5. The method as claimed in claim 1, wherein it comprises a fourth mode for realizing bypass codes consisting of performing a superfluous calculation having the external effect of a particular sensitive calculation. 6. The method as claimed in claim 1, wherein it comprises a first mode for introducing a plurality of implementations of certain instructions consisting of enriching the set of instructions recognized by the interpreter with a plurality of implementations for a given instruction; the aforesaid instructions are performed either manually by programming or automatically upon code generation. 7. The method as claimed in claim 1, wherein it comprises a second mode for introducing the aforesaid plurality of implementations of certain instructions consisting of comprising in the actual implementation of the instruction, a jump to a portion of at least one alternative code with a variable physical effect or duration, which dynamically determines the implementation to be executed. 8. The method as claimed in claim 7, wherein it comprises a first mode for realizing the aforesaid alternative code consisting of proposing a plurality of different implementations of the instruction and by conditioning the choice of the executed version to a dynamic test, i.e., a test depending on data known at execution time. 9. The method as claimed in claim 7, wherein it comprises a second mode for realizing the aforesaid alternative code consisting of improving the aforesaid first mode for realizing alternative codes by adding to it a random draw for achieving the test leading to the dynamic choice of the executed version. 10. The method as claimed in claim 7, wherein it comprises a third mode for realizing the aforesaid alternative code consisting of improving the aforesaid first and second modes for realizing "alternative codes" by replacing the test for deciding on the selected version with a branching in an indirection table containing the addresses of the available versions at an index calculated from variable items. 1 1 . The method as claimed in claim 1 , wherein it is implemented on a module for interpreting software code, a so-called virtual machine. 12. The method as claimed in claim 11, wherein said virtual machine is a Java platform. 13. The method as claimed in claim 1, wherein it is implemented on a module for interpreting physical code. 14. The method as claimed in claim 1, wherein it is implemented on an embedded system and on an interpretation module of the microcontroller or microprocessor type.

Documents:

2823-DELNP-2005-Abstract-07-05-2008.pdf

2823-delnp-2005-abstract.pdf

2823-DELNP-2005-Claims-07-05-2008.pdf

2823-delnp-2005-claims.pdf

2823-DELNP-2005-Correspondence-Others-13-05-2008.pdf

2823-delnp-2005-correspondence-others.pdf

2823-delnp-2005-description (complete)-07-05-2008.pdf

2823-delnp-2005-description (complete).pdf

2823-DELNP-2005-Form-1-07-05-2008.pdf

2823-delnp-2005-form-1.pdf

2823-delnp-2005-form-18.pdf

2823-DELNP-2005-Form-2-07-05-2008.pdf

2823-delnp-2005-form-2.pdf

2823-delnp-2005-form-3.pdf

2823-delnp-2005-form-5.pdf

2823-DELNP-2005-GPA-07-05-2008.pdf

2823-delnp-2005-gpa.pdf