WO2000054155A1 - Procede de surveillance du deroulement d'un programme - Google Patents

Procede de surveillance du deroulement d'un programme Download PDF

Info

Publication number
WO2000054155A1
WO2000054155A1 PCT/FR2000/000150 FR0000150W WO0054155A1 WO 2000054155 A1 WO2000054155 A1 WO 2000054155A1 FR 0000150 W FR0000150 W FR 0000150W WO 0054155 A1 WO0054155 A1 WO 0054155A1
Authority
WO
WIPO (PCT)
Prior art keywords
instructions
inst
program
instruction
value
Prior art date
Application number
PCT/FR2000/000150
Other languages
English (en)
Inventor
Pierre Girard
David Naccache
Ludovic Rousseau
Original Assignee
Gemplus
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Gemplus filed Critical Gemplus
Priority to JP2000604312A priority Critical patent/JP4172745B2/ja
Priority to DE60001393T priority patent/DE60001393T2/de
Priority to MXPA01009056A priority patent/MXPA01009056A/es
Priority to US09/936,174 priority patent/US7168065B1/en
Priority to AT00900650T priority patent/ATE232616T1/de
Priority to AU30589/00A priority patent/AU3058900A/en
Priority to EP00900650A priority patent/EP1161725B1/fr
Publication of WO2000054155A1 publication Critical patent/WO2000054155A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/54—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by adding security routines or objects to programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/28—Error detection; Error correction; Monitoring by checking the correct order of processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/77—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in smart cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2153—Using hardware token as a secondary aspect

Definitions

  • the present invention relates to the field of computer program security, and more particularly to a method and a device for detecting an unacceptable progress in the execution of a computer program, the latter being able to be in a low level language or high level.
  • a low-level language program the commands are formulated according to a structure very close to that of the instructions actually executed by the processor part of the computer.
  • the program only needs to be compiled before it can be run.
  • Low-level languages, known as machine code are used in particular for programming microprocessors or microcontrollers.
  • Microcontrollers are processors that can only execute a small number of specific instructions. They are used in particular to equip smart cards (bank cards, telephone cards, access to services, etc.) and to control industrial or domestic devices.
  • the commands In a high-level language program, the commands have a structure closer to natural language, but on the other hand more distant from that used by the processor.
  • the commands written in such languages must first be interpreted, that is to say converted into machine code commands, before they can then be put into the form of instructions in view of their execution by the processor.
  • any computer program gives rise to a series of instructions adapted to the processor, microprocessor or microcontroller for which it is intended.
  • the instructions of a program are executed by a processor according to a sequence governed by an instruction counter, as will be briefly described with reference to FIG. 1.
  • the compiled instructions of a program are loaded in blocks of 'successive instructions Inst. l, Inst. 2, Inst. 3,, Inst. (where n is an integer) in the form of codes or microcodes in an instruction register 2.
  • Each instruction is identified by a specific address in this register 2.
  • the addresses of the instructions Inst are designated. l, Inst. 2, Inst. 3,, Inst. not respectively Ad.l, Ad.2, Ad.3, ...., Ad.n.
  • the instructions are read from the instruction register 2 is successively loaded into the processor 4 to be executed there under the command of an instruction counter 6, itself controlled by the processor 4.
  • the instruction counter instructions 6 includes an address pointer 8 which designates the address Ad.1, .... Ad.n of register 2 from which the instruction to be loaded into processor 4 must be read during the execution of a sequence of instructions.
  • the position of the pointer 8 with respect to the addresses of the instruction register 2 therefore changes as the instructions are executed.
  • the instructions Inst. l, Inst. 2, Inst. 3,, Inst.n in register 2 must be executed successively from the first Inst instruction. 1 to the n th instruction Inst.n, that is to say linearly.
  • the pointer 8 of the instruction counter 6 initially designates the address Ad. L of the register 2, and the data 10-1 of the corresponding instruction Inst. l are loaded into the processor 4.
  • the processor 4 instructs the instruction counter 6 to supply the next instruction (in this case Inst. 2)
  • the latter increments the position of the pointer 8 by an evolution unit d address to designate the address Ad.2. This process is repeated and ends when the pointer 8 designates the address Ad.n in order to load the data 10-n of the last instruction Inst.n (dotted lines).
  • a series of instructions executed in a linear fashion does not include "jumps" which escape from the sequential progression of the pointer 8 with respect to the successive addresses. This is the case, for example, with a sequence of instructions in microcodes like:
  • this sequence will be executed in a linear fashion, the instruction counter 6 being incremented by an address evolution unit during the passage from one instruction to the other.
  • An instruction which causes a jump requires, at the level of the instruction counter 6, to determine the address in register 2 of the next instruction following this jump and to position the pointer 8 at this address so that the instruction or the data found there is loaded into processor 4.
  • the sequence: Ida txa bra label; jump mul bset 3, t sta n label rts will cause a new value to be loaded into the instruction counter 6 at the location of the code corresponding to the comment "jump".
  • sampling points allow the deposit of sampling points using specialized workbenches (also known by the Anglo-Saxon term of "probe stations") allowing the continuous reading of a bit (and the monitoring its evolution over time) or an external change in its value.
  • depositing contacts on the register of the instruction counter 6 allows the value of the register being executed to be loaded externally and to cause a connection not provided for by the program designer.
  • a jump can, of course, have harmful consequences on the security of the application and lead, for example, to the disclosure of secret data by performing incomplete calculations.
  • the invention proposes a method for monitoring the progress of the execution of a sequence of instructions of a computer program, consisting in analyzing the sequence of instructions transmitted to the processor intended for execute the monitored program and verify the result of this analysis with reference data recorded with said program.
  • the present invention makes it possible to verify that all the instructions included in the set of instructions considered have indeed been transmitted to the processor in view of their execution. It is assumed that if this is the case, the instructions read in this way will also have been executed.
  • the reference data can for example be a preset value so as to correspond to the result of the analysis carried out during the monitoring process only if all of the instructions in the sequence of instructions have actually been analyzed during the course of the program.
  • the analysis step comprises the sub-steps of extracting data from each instruction transmitted to the processor and of predetermined calculation on each data thus extracted, and the verification step comprises comparing the result of analysis with reference data.
  • the verification step is carried out by a wired comparison of a value contained in a register associated with the monitoring means with the reference value, the latter being able to be entered in the program in a fixed, wired manner (for example in a frozen ROM type memory) once and for all when hiding the code which constitutes the monitored program.
  • the verification is caused by an instruction placed at a predetermined location in the program, this instruction containing the aforementioned reference data.
  • the instructions of the set of instructions to be monitored are in the form of a value, hexadecimal or decimal, these instructions are treated as simple numerical values during the abovementioned analysis.
  • the overall method of monitoring the execution of a sequence of instructions of a computer program can thus comprise the following steps: - during the preparation of the program: incorporate, at at least one predetermined location in a sequence of program instructions, a reference value established according to a given rule applied to identifiable data in each instruction to be monitored, and - during the execution of the part of the program to monitor: obtain said identifiable data in each instruction executed,
  • This interruption can be accompanied by an invalidation action for future use of the device comprising the monitored computer program if the non-correspondence between the verification value and the reference value is detected a predetermined number of times.
  • the set of instructions to be monitored does not include jumps in its planned course, so that it is expected that all the instructions which it comprises are executed in all the cases envisaged.
  • the monitoring method can be implemented separately for a set of instructions devoid of jumps and which precedes the jump, and for at least one set of instructions without jumps which follows this jump.
  • the verification value obtained during a previous implementation of the method is erased at each new implementation of the method.
  • This arrangement makes it easy to manage the monitoring of different sets of instructions in a program, such as those separated by jumps. It makes it possible in particular to implement the method with the same initial conditions for calculating the verification value for the different sets separated by jumps.
  • the verification value can be erased by a simple reset. This value can also be replaced by another predetermined initial value. These reset or initialization operations can be activated by the protected software itself.
  • the verification value is obtained as the last value of a series of values which is made to evolve successively with the analysis of each of the instructions considered in the set of instructions.
  • the analysis mode allowing this change in the verification value consists in calculating, for each instruction considered following a previous instruction, the result of an operation on both a value extracted from the instruction considered and the result obtained by the same operation performed on this previous instruction.
  • an operation can be applied to both the data extracted from this first instruction and a predetermined value (which can then correspond to the aforementioned reset or reset value) , which acts as a "seed" value in the absence of the result of a previous operation.
  • the calculation operation can be chosen so that a correct verification value is obtained only if on the one hand the data of all the instructions were considered during the calculation, and on the other hand they were considered in the order provided.
  • the calculation operation can consist in applying a hash function, according to a technique known per se in the field of data encryption, such as the hash function SHA-1 established by federal hash standard.
  • the abovementioned internal evolution of the monitoring process can be carried out by cryptographically chopping all the operation codes (considered as numerical values) and addresses executed since the last initialization carried out.
  • the invention also relates to a device for monitoring the execution of a sequence of instructions of a computer program, characterized in that it includes means for analyzing the sequence of instructions transmitted to the processor intended to execute the monitored program and means for verifying the result of this analysis with reference data recorded with said program.
  • the monitoring device advantageously comprises a register making it possible to record intermediate results in the calculation of the verification value.
  • This register can be adapted to retain only the last intermediate result in progress. It can be provided to allow the recording of a predetermined value or a reset to zero under the control of the program being executed. In this way, the program can control an initial condition at the level of the content of the register each time the monitoring process is implemented again, this intervening for example after a jump in the program.
  • the monitoring device can be integrated into a program execution device to be monitored or into a programmed device which contains the program to be monitored.
  • the invention also relates to a program execution device, for example a computer, a microprocessor or microcontroller device such as a smart card reader or a program saved on a card in PCMCIA format, intended to execute a suite instructions of a computer program, characterized in that it comprises means for analyzing the sequence of instructions transmitted for execution and means for verifying that the result of this analysis corresponds with reference data recorded with the program.
  • the invention also relates to a programmed device intended to operate with the abovementioned program execution device and comprising a series of instructions, characterized in that it furthermore comprises pre-established reference data as a function of data contained in said instructions and intended to allow verification of the sequence of instructions analyzed by the aforementioned program execution device.
  • the programmed device for example a smart card or a mechanism control member, such as an ABS braking system, can integrate the program to be monitored in a fixed memory of the ROM type.
  • the reference data are advantageously recorded in the form of pre-wired value (s) fixed in the memory once and for all during the masking of the code.
  • the present invention also relates to a device for programming a device for executing a program intended to operate in association with the aforementioned programmed device, characterized in that it comprises means for registering, at at least one predetermined location in a sequence of program instructions, a reference value calculated according to a preset mode from data included in each instruction d 'a set of instructions whose execution we want to monitor.
  • the invention also relates to a virtual machine or interpreter interpreting a critical code, characterized in that it implements the aforementioned monitoring method for the execution of this critical code.
  • the aforementioned devices for monitoring, executing a program, or programming, or even devices equipped with such programs can be equipped with all the means necessary to carry out the various possible optional aspects of the aforementioned monitoring method.
  • the monitoring unit could be made up of registers whose content at all times constitutes the internal state of the monitoring unit.
  • a specific input from the monitoring unit allows its reset (RESET), typically by erasing the contents of the monitoring unit.
  • RESET reset
  • This function can be activated at any time by the software running and can, for example, be carried out by adding a new operation code in assembler (for example "clr us") or by manipulating a given bit in the memory of the protected component (for example: setb 3, service).
  • the monitoring unit compares its internal state with a given chain supplied by the protected software. This can for example be achieved by copying inside the monitoring unit (using a "lda-sta" loop) the value to which the software wishes to compare the internal state. Once the copying of the value is complete, the monitoring unit compares it to its internal state and adopts the following behavior: if the state of the monitoring unit is equal to the value presented by the protected software, resume the execution normally, otherwise program execution is stopped (forcing the user to reset the card to zero), possibly by first ratifying a false counter executions in a non-volatile memory of the EEPROM type having the effect of definitive blocking of the card if its value exceeds a reasonable limit (for example
  • the monitoring unit can permanently keep a cryptographic hash of the instruction codes and addresses executed since its last reset.
  • the monitoring mechanism can be adapted to the interpretation of code in a virtual machine (Java "byte code", for example).
  • the compiler can calculate the hash value of a portion of byte code, integrate it into an attribute of a structure known by the Anglo-Saxon term of "class file” produced and add to the generated byte code codes known as Anglo-Saxon term of additional "opcodes" corresponding to the reset of the monitoring unit and the call to the verification function
  • the virtual machine will act as the monitoring unit and when it encounters the opcode of check, will check the value of the current hash compared to the value of the theoretical hash contained in the class file.
  • FIG. 2 is a simplified block diagram of a program execution device aimed at explaining the operating principle of a monitoring unit in accordance with a first embodiment of the invention
  • FIG. 3 is a flowchart the monitoring method according to the invention
  • FIG. 4 is a flow diagram of a variant of the monitoring method according to the invention.
  • FIG. 5 is a simplified block diagram of a program execution device intended to explain the operating principle of a monitoring unit in accordance with a second embodiment of the invention
  • FIG. 6 is a flow diagram of the monitoring method according to the invention, adapted to the second embodiment, and - Figure 7 shows schematically sets of instructions of a program with branching further containing instructions specific to the monitoring process.
  • FIG. 2 represents the basic elements of a program execution device 20 in the broad sense II can be a computer intended to execute a program in a high level language, a microprocessor or a microcontroller, the latter operating from low-level language programs.
  • the execution device 20 can be a smart card reader intended to manage banking, telephone or other service transactions. The program to check is then physically contained in the smart card
  • the processor 4 executes a program portion stored in an instruction register 2 in the form of microcodes
  • the operational part of this program portion comprises a sequence of n instructions (where n is an integer greater than 1) designated respectively Inst 1, Inst 2, Inst 3,, Inst n
  • the microcodes that make up the instructions are in the form of numeric values, which can be decimal or hexadecimal
  • the first instruction Inst 1 is equal to 40
  • This figure is a code which corresponds to an instruction recognized by the processor, but it has the same binary structure as the numerical value 40 None of the instructions Inst 1, Inst 2, Inst 3,, Inst n orders a jump to another instruction outside the linear sequence of execution of the instructions
  • the normal and expected sequence of this portion of program necessarily requires the execution of each of the instructions in succession, in starting with the instruction Inst 1 and ending with the instruction Inst.n
  • the instruction counter 6 (already described) will position its pointer 8 successively at the address of each of the instructions Inst 1 to Inst n in the instruction register 2 as and when they must be loaded into the processor
  • the monitoring unit 22 is described as being integrated into the program execution device 20
  • the monitoring unit 22 can just as easily be integrated with the device which includes the program to be monitored, by being example incorporated in a smart card whose program it contains in memory is to be monitored, without this changing the principles which will be described below
  • the monitoring unit 22 includes a register 24 intended to temporarily store data included in an instruction Inst 1, Inst 2, Inst 3,, Inst n and a computer 26 intended to execute an operation on this data
  • the implementation of the monitoring unit requires the addition of two new instructions to the n instructions Inst 1, Inst 2, Inst 3,, Inst n of the program a first monitoring instruction Inst 0 placed before the first instruction Inst.l of the program and a second Inst n + 1 monitoring instruction placed after the last Inst n of the program
  • the instruction counter 6 is initially controlled to position its pointer 8 at the address of the first monitoring instruction Inst 0
  • This instruction commands the monitoring unit to initialize a hash value VH contained in its register 24
  • each instruction is subjected by the computer 26 to a hashing algorithm, such as the SHA-1 hashing specified by the federal hashing standard
  • a hashing algorithm such as the SHA-1 hashing specified by the federal hashing standard
  • This NHi value serves as the basis for the hash operation with the following instruction Inst i + 1
  • the hash result VHi + 1 thus obtained for the instruction Inst.i + 1 is then written in place of the hash result VHi previously obtained
  • the second monitoring instruction Inst n + 1 is loaded into the monitoring unit 22
  • This instruction comprises two components, a reference value Vref and a command, intended for the computer 26, for comparing this reference value Vref with the value of the last hash result entered in the register 24
  • This last value therefore corresponds to the result of the hash VHn obtained from the numerical value of the instruction Inst n (equal to 36 in the figure) and the VHn-1 hash result obtained for the previous Inst n-1 instruction
  • the computer 26 compares the value VHn in the register 22 with the reference value Vref specified in this monitoring instruction
  • the reference value Vref is determined during the preparation of the recorded program in order to correspond to the expected value VHn for the result of successive hashes of the values of the instructions Inst 1, Inst 2, Inst 3,, Inst n
  • This value Vref can be calculated in advance using the same procedure for successively hashing the instructions Inst 1, Inst 2, Inst 3,, Inst n as used by the monitoring unit 22
  • the value Vref is wired in a frozen memory so as not to cannot be altered by malicious act
  • the monitoring unit 22 finds, by executing the monitoring instruction Inst n + 1, that there is identity between the values Vref and NHn mentioned above, it is concluded that all Inst. l, Inst.2, Inst.3, ...., Inst.n. have indeed been transmitted to processor 4 in view of their execution.
  • the monitoring unit 22 finds that there is no identity between the values Vref and NHn, it is concluded that either all the instructions Inst. l, Inst.2, Inst.3, ...., Inst.n. have not been received and transmitted by the monitoring unit, or they have not been received in the expected sequential order. In this case, an action can be provided to alert the user or the owner of the program, or to prevent the program from continuing. In the example, such an action is transmitted from the monitoring unit 22 to the processor 4 in the form of a command to interrupt the Int program.
  • the monitoring method as carried out by the means of FIG. 2 will now be described with reference to the flow diagram represented in FIG. 3. It is assumed that the program or the part of the program to be monitored has been prepared correctly for the monitoring method. by incorporating the first and second monitoring instructions respectively at the beginning and at the end.
  • the monitoring unit 22 positions itself on a monitoring start routine 30, the first step 32 of which is waiting for the first monitoring instruction (Inst.O).
  • the monitoring unit 22 When the first monitoring instruction Inst.O is received, the monitoring unit 22 performs a step 34 of initialization (by resetting to zero) of an instruction counter and of the register 24.
  • the resetting of the register 24 is a way of placing a seed value in this register to start a sequence of hash operations, as will be explained later. These operations can be directly controlled by the first monitoring instruction or can be simply triggered by the latter from a routine associated with the monitoring unit 22.
  • the reset can be achieved by adding a new assembly code in assembler (for example "clr us”), or by manipulating a given bit in the memory of the program execution device 20 Such an order can be "setb 3, service”.
  • the numeric value of this first Inst instruction. l is then subjected to a hashing operation with the value contained in the register 24 (step 40).
  • this last value is the initialization value, that is to say 0.
  • the hashing operation well known in itself, here consists in acting on the value of l instruction n considered a mathematical operator f (VHn-l, Vinst.n), where NHn-1 is the result of a previous hash operation (or the initialization value in the case of the first instruction) recorded in the register 24 and Vinst.n is the numerical value of the instruction n considered.
  • the NHn result of this hashing operation is then recorded in register 24 in place of the previous VHn-1 result (step 42).
  • this procedure for updating the content of the register at each hash operation makes it possible to permanently keep a cryptographic hash of the instruction codes and addresses executed since the last initialization.
  • the instruction is transmitted to the processor 4 for execution (step 44).
  • the monitoring unit 22 determines whether the program or the part of the program to be monitored contains another instruction to be executed (step 46).
  • the procedure performs a loopback B1 towards step 36 of incrementation from n to n + 1.
  • the value of the next instruction (Inst.2) will then be read from the instruction register 2 and subjected to the hash operation in the same way as for the instruction Inst.1. Only, the hashing is carried out this time with on the one hand the numerical value of the instruction Inst.2 and the result obtained during the previous hashing operation, that is to say the value NHI (n being here equal to 2) which is then in register 24.
  • Steps 42 to 46 of the method are carried out in the same manner as for the first instruction. In this way, all of the steps 36 to 46 continue in a loop for each instruction Inst.l, Inst.2, Inst.3, ...., Inst.n. read from the instruction register 2, with the hashing taking place, for an Inst.i instruction (where i is an integer from 1 to n) with the value VHni-1 in the register 24 and the value Vinst.i.
  • Inst. l, Inst.2, Inst.3, ...., Inst.n. have thus been processed by the monitoring unit 22, which receives the second monitoring instruction Inst. n + 1, this following the last Inst.n instruction of the program or part of the monitored program.
  • This second monitoring instruction commands the monitoring unit 22 to extract the reference value Vref from the program (step 48) and to compare the content of the register 24 with this value Vref (step 50).
  • This command can be carried out using a "lda-sta" loop.
  • the value contained in the register 24 at this stage is the result VHn of the hash performed with the result NHn-1 of the previous hash and the numerical value of the instruction n (equal to 36 in the example in Figure 2).
  • the reference value Vref has been determined beforehand during the preparation of the program for knowledge of hash operations, in order to be equal to what the monitoring unit 22 should return as value NHn if all the instructions Inst. l, Inst.2, Inst.3, ...., Inst.n. have indeed been transferred to processor 4.
  • the result of the comparison makes it possible to control the proper execution of the instructions Inst.
  • VHn Vref (step 52)
  • the monitoring operation is then terminated with regard to the program or the part of the program containing the instructions Inst.1, Inst.2, Inst.3, ...., Inst.n.
  • the monitoring procedure then returns to the start phase 30 awaiting a new first monitoring instruction.
  • the comparison step 50 reveals that there is no identity between the compared values (NHn ⁇ Vref)
  • all the instructions Inst. l, Inst 2, Inst.3,. , Inst have not been transferred to processor 4, or have not been transferred in the correct order (step 54).
  • the monitoring unit 22 commands an action (step 56), such as interrupting the program and / or recording that the program has not run correctly.
  • the monitoring process takes place as in the previous case with regard to steps 30 to 38 (FIGS. 3 and 4).
  • step 38 of reading the value of the instruction Vinst.n from the instruction register 2 the monitoring unit 22 proceeds to record this value (step 39).
  • This recording can be carried out in an internal register of the computer 26, in a dedicated section of the register 24, in a specific memory (not shown) of the monitoring unit 22, or even in a memory external to the monitoring unit. 22, as soon as it is accessible by it. Then, the monitoring unit 22 proceeds to the steps 44 and 46 previously described.
  • step 39 of recording the Vinst.n values is in the loop Bl connecting the step 46 to the step 36 of incrementing n by a unit, so that each of the Vinst.n values is thus recorded until the detection of the second monitoring instruction in step 46.
  • the monitoring unit 22 reads the reference value Vref (step 48) and performs hashing in step 49 according to the same algorithm as in the previously described steps 40 and 42 of FIG. 3, based on the set of Vinst values. previously registered.
  • the final hash value VHn is then the same as in the case of the method of FIG. 3. It will be noted that it is possible to reverse the order of steps 48 and 49.
  • FIG. 5 is a simplified block diagram of the monitoring unit 22 in accordance with a second embodiment of the invention. Its integration into the program execution device 20 is the same as for the first embodiment described with reference to FIGS. 2 and 3 as regards its operation with the instruction counter 6, the instruction register 2 and processor 4, and will not be repeated for the sake of brevity.
  • the monitoring unit 22 differs from that of the first embodiment essentially by the fact that it further comprises a memory 60 which records the number of times that the execution of a series of instructions Inst. l-Inst.n did not run correctly according to the criteria explained with reference to Figure 3 or 4
  • the memory 60 is embodied in the form of a fixed memory (non-volatile) with electrically erasable content (commonly known by the English name EEPROM).
  • the memory 60 is functionally connected to the computer 26 so that it stores a count value VC incremented by one on each observation of an incorrect execution in the series of instructions monitored.
  • This counting value VC thus makes it possible to detect the number of incorrect sequences of the series of instructions and to act accordingly, for example by invalidating any future use of the device containing the program (for example a smart card) if this number crosses a threshold value.
  • the flow diagram of FIG. 6 gives an example of the use of the counting value VC to control the device of program execution. This example includes all of the steps 30 to 54 of the flow diagram of FIG. 3 or the similar steps of FIG. 4.
  • the calculation unit 26 increments the counting value VC in the memory 60, initially equal to 0, of one unit (step 62). Then, it checks whether the count value VC thus incremented has reached a predetermined threshold value VC threshold (step 64).
  • This threshold value VCseuil corresponds to the number of times that it is admitted that the unexpected execution of the instructions Inst. l-Inst.n can occur in the programmed device before taking definitive measures to deal with such a failure.
  • the monitoring unit 22 establishes the interrupt command Int. as previously described with a simple alert message intended for the user and / or the operating system (step 66) and transmits it to the processor 4 (step 68).
  • the monitoring unit 22 then establishes the interrupt command Int. as previously described with an order to prohibit any future use of the programmed device containing the instructions executed in an unexpected manner (step 70) and transmits it to the processor (step 68). In this case, it will not be possible to reuse this device only after having re-programmed the memory 60. In the case where this memory 60 is in the form of EEPROM or other non-volatile memory, such re-programming is very difficult to do it in a roundabout way.
  • the Int. of interrupting the program accompanied by a transmission of an alert message or of an invalidation command for future use can be executed either at the processor level or at the level of the monitoring unit 22. It will now be described by with reference to FIG. 7 how the monitoring unit 22 in accordance with the present invention can be implemented for monitoring a program which provides for jumps or connections.
  • the program execution device 20 comprises in the instruction register 2 a program or part of a program intended for the processor 4, consisting of three sets of instructions:
  • the three sets of instructions EU, EI2 and EI3 do not have jumps within their sequence of instructions. (In the case of the first set of instructions, the conditional jump to the EIl-j instruction is at the end of the sequence.)
  • the first monitoring instruction and the second monitoring instruction described above with reference to FIGS. 2 to 6 are added to the head and to the tail of each set of instructions EU, EI2 and EI3 respectively.
  • the monitoring of the program or of the program part composed by the EU, EI2 and EI3 sets then proceeds as follows.
  • the monitoring unit 22 first positions itself in the monitoring start phase (step 30, FIG. 3).
  • the process begins with the execution of the first set of EU instructions.
  • the first monitoring instruction placed at the header of this set will first be loaded into the monitoring unit 22.
  • the monitoring unit initializes its instruction counter and its value register 24 of hash VH (step 34, figure 3) and proceeds to the hash routine for each instruction Inst.EIl-1 to Inst. EIl-j of first set of instructions according to steps 36 to 46 of there figure 3.
  • the last instruction E11-j of the assembly which controls the connection is thus also subject to hashing by the monitoring unit 22 before being transmitted to the processor 4.
  • the following instruction is the second monitoring instruction (step 46, FIG. 3) at the end of the first set of instructions EU, which causes the phase of comparison between the last hash value recorded in register 24 with the reference value Vref associated with this second instruction.
  • the monitoring unit 22 proceeds to the steps of interrupting the program 54 and 56 ( Figures 3 or 4) or 54 to 70 ( Figure 6).
  • this interruption is expected to occur even before the program has performed conditional branching. This can be achieved, for example, by associating the jump instruction with a validation wait instruction from the monitoring unit, using known programming techniques.
  • step 50 If it is detected in step 50 (FIG. 2) of comparison that the last hash value thus recorded actually corresponds to the reference value Vref, the monitoring unit authorizes the execution of the conditional branch determined by the last instruction Is it all. The program then continues to one or the other of the second or third sets of instructions in accordance with the connection conditions laid down by this last instruction.
  • the instruction counter 6 passes the instruction pointer 8 directly from the second monitoring instruction at the tail of the first set of instructions EU to the first monitoring instruction at the head of the third set of instructions EI3.
  • the monitoring unit will execute this new first instruction by resetting the instruction counter and the register 24.
  • the monitoring procedure for this third set of instructions therefore continues in exactly the same way as for the first set of instructions.
  • the monitoring unit 22 will successively hash each of the instructions read from this set, starting the hash with the same "seed" value (which here corresponds to zero) as for the first set.
  • the second monitoring instruction this time makes it possible to detect a course not provided for in the localized execution at the level of this third set of instructions and to carry out the same type of action in step 56. It will be understood that the explanation given for a connection to the third assembly applies strictly analogously in the case of a connection to the second set of instructions following the execution of the instruction to connect the first set of instructions.
  • the monitoring unit 22 It is possible to allow the monitoring unit 22 to count not only the number of unplanned sequences in a program comprising jumps, but also the independently monitored instruction sets in which they occurred.
  • monitoring unit 22 can either be materialized separately from the processor 4 or functionally integrated therewith.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)
  • Communication Control (AREA)
  • Storage Device Security (AREA)
  • Flow Control (AREA)

Abstract

Une surveillance du déroulement de l'exécution d'une suite d'instructions (Inst.1-Inst.n) d'un programme informatique est obtenue en analysant la séquence des instructions transmises vers le processeur (4) destiné à exécuter le programme surveillé et en vérifiant le résultat de cette analyse par référence à des données de référence (Vréf) enregistrées avec ledit programme. Les données de référence peuvent comprendre une valeur (Vréf) préétablie de manière à correspondre au résultat de l'analyse réalisée lors de la surveillance seulement si toutes les instructions (Inst.1-Inst.n) de la séquence d'instructions ont été effectivement analysées lors du déroulement du programme. L'invention concerne également undispositif de surveillance d'exécution de programme, un dispositif d'exécution de programme et un dispositif de programmation fonctionnant sur les principes de surveillance précités.

Description

PROCEDE DE SURVEILLANCE DU DEROULEMENT D'UN PROGRAMME
La présente invention concerne le domaine de la sécurité des programmes informatiques, et plus particulièrement un procédé et un dispositif de détection d'un déroulement inadmissible dans l'exécution d'un programme informatique, celui-ci pouvant être dans un langage de bas niveau ou de haut niveau. Dans un programme en langage de bas niveau, les commandes sont formulées selon une structure très proche de celle des instructions effectivement exécutées par la partie processeur de l'ordinateur. Le programme nécessite seulement d'être compilé avant de pouvoir être exécuté. Les langages de bas niveau, connues sous l'appellation de code machine, sont utilisés notamment pour la programmation de microprocesseurs ou de microcontrôleurs. Les microcontrôleurs sont des processeurs qui ne peuvent exécuter qu'un nombre réduit d'instructions spécifiques. Ils sont utilisés notamment pour équiper des cartes à puce (cartes bancaires, téléphoniques, d'accès à des services, etc.) et pour piloter des appareils industriels ou domestiques.
Dans un programme en langage de haut niveau, les commandes ont une structure plus proche du langage naturel, mais en revanche plus éloignée de celle utilisée par le processeur. Les commandes écrites dans de tels langages doivent d'abord être interprétées, c'est-à-dire converties en commandes de code machine, avant de pouvoir être ensuite mises sous forme d'instructions en vu de leur exécution par le processeur. Ainsi, tout programme informatique donne lieu à une suite d'instructions adaptées au processeur, microprocesseur ou microcontrôleur auquel il est destiné.
De manière classique, les instructions d'un programme sont exécutées par un processeur selon une séquence régie par un compteur d'instructions, comme il sera brièvement décrit par référence à la figure 1. Les instructions compilées d'un programme sont chargées en blocs d'instructions successives Inst. l, Inst. 2, Inst. 3, , Inst. (où n est un entier) sous forme de codes ou de microcodes dans un registre d'instructions 2. Chaque instruction est identifiée par une adresse spécifique dans ce registre 2. Dans l'exemple, on désigne les adresses des instructions Inst. l, Inst. 2, Inst. 3, , Inst. n respectivement Ad.l, Ad.2, Ad.3, ...., Ad.n. Les instructions sont lues du registre d'instructions 2 est chargées successivement dans le processeur 4 pour y être exécutés sous la commande d'un compteur d'instructions 6, lui-même contrôlé par le processeur 4. A cette fin, le compteur d'instructions 6 comporte un pointeur d'adresses 8 qui désigne l'adresse Ad.1, ....Ad.n du registre 2 à partir de laquelle doit être lue l'instruction à charger dans le processeur 4 durant l'exécution d'une séquence d'instructions. La position du pointeur 8 vis-à-vis des adresses du registre d'instructions 2 évolue donc au fur et à mesure de l'exécution des instructions.
Dans l'exemple représenté à la figure 1, les instructions Inst. l, Inst. 2, Inst. 3, , Inst.n dans le registre 2 doivent être exécutées successivement de la première instruction Inst. 1 à la n'eme instruction Inst.n, c'est-à-dire de façon linéaire. Ainsi, le pointeur 8 du compteur d'instructions 6 désigne initialement l'adresse Ad. l du registre 2, et les données 10-1 de l'instruction correspondante Inst. l sont chargées dans le processeur 4. Lorsque le processeur 4 ordonne au compteur d'instructions 6 de fournir la prochaine instruction (dans ce cas Inst.2), celui-ci incrémente la position du pointeur 8 d'une unité d'évolution d'adresse afin de désigner l'adresse Ad.2. Ce processus se répète et se termine lorsque le pointeur 8 désigne l'adresse Ad.n afin de charger les données 10-n de la dernière instruction Inst.n (pointillées).
Une série d'instructions exécutées de façon linéaire ne comporte pas de "sauts" qui échappent de la progression séquentielle du pointeur 8 vis-à-vis des adresses successives. Ceci est le cas, par exemple, avec un séquence d'instructions en microcodes comme :
Ida t txa mul bset 3,t sta n
Autrement dit, cette séquence s'exécutera de façon linéaire, le compteur d'instructions 6 étant incrémente d'une unité d'évolution d'adresse lors du passage d'une instruction à l'autre.
Cependant, il est courant que l'exécution d'un programme nécessite des sauts vers des instructions en dehors de la séquence linéaire des instructions telle qu'elle se présente dans le registre 2. De tels sauts peuvent résulter d'une instruction de chargement de données situées dans une adresse en dehors de la séquence, ou d'une instruction, dite de branchement, d'exécution conditionnelle de la commande suivante.
Une instruction qui provoque un saut nécessite, au niveau du compteur d'instructions 6, de déterminer l'adresse dans le registre 2 de la prochaine instruction suivant ce saut et de positionner le pointeur 8 à cette adresse afin que l'instruction ou la donnée qui s'y trouve soit chargée dans le processeur 4. A titre d'exemple, la séquence : Ida txa bra label ; saut mul bset 3,t sta n label rts provoquera le chargement d'une nouvelle valeur dans le compteur d'instructions 6 à l'endroit du code correspondant au commentaire "saut".
Le fait pouvoir ainsi effectuer sous commande des sauts vers des adresses en dehors d'une suite séquentielle d'adresses peut malheureusement donner lieu à un déroulement inadmissible du programme Un tel déroulement inadmissible du programme peut résulter d'un dysfonctionnement accidentel du dispositif programmé. Mais il peut aussi provenir d'une action malveillante visant à détourner le fonctionnement du dispositif programmé de sa fonction voulue. Par exemple, dans le cas d'une carte à puce, des modifications de programmation du microcontrôleur par la création ou la modification de sauts et/ou de branchements peuvent permettre de charger des données erronées (augmentation de crédit autorisé avec une carte bancaire ou téléphonique, fausse autorisation d'accès à certains services, etc.) ou de récupérer des données confidentielles stockées en mémoire (code d'accès, informations personnelles concernant le titulaire de la carte, etc.). En effet, même lorsque les programmes sont enregistrés de manière figée sur une puce semiconductrice, il est possible avec les technique actuelles de sondage et de test de composants de créer des contacts de sondage sur la surface de la puce (ou même dans les couches basses de celle-ci) à l'aide de stations de travail à focalisation de faisceaux d'ions (aussi connues sous le terme anglo-saxon de "Focus Ion Beams", ou "FIBs").
Une fois créés, ces points de sondage permettent le dépôt de pointes de sondage à l'aide d'établis spécialisés (aussi connu sous le terme anglo-saxon de "probe stations") permettant la lecture en continue d'un bit (et le suivi de son évolution au cours du temps) ou une modification externe de sa valeur.
En particulier, le dépôt de contacts sur le registre du compteur d'instructions 6 permet de charger de façon externe la valeur du registre en cours d'exécution et de provoquer un branchement non-prévu par le concepteur du programme. Comme expliqué plus haut, un tel saut peut avoir, bien entendu, des conséquences néfastes sur la sécurité de l'applicatif et aboutir, par exemple, à la divulgation de données secrètes en effectuant des calculs incomplets.
Il existe également des manières plus rudimentaires, mais moins sûres, de provoquer de tels dysfonctionnements dans le déroulement du programme. Un exemple en est donné dans un article intitulé "Tamper-resistance, a cautionary note" par R.Anderson. Une autre technique consiste à exploiter des fautes de calcul provoquées délibérément afin d'extraire d'une carte à puce des données telles que les clés secrètes. Cette technique est décrite dans l'article intitulé "On the Importance of Checking Computations" de Boneh, DeMillo et Lipton; Bellcore Report, publié le 31 octobre 1996.
Bien entendu, le même phénomène peut également se produire lorsque le programme attaqué est interprété au lieu d'être compilé. Ainsi, une application en langage Java ou Basic peut être détourné de son usage légitime si l'attaquant arrive, par exemple, à provoquer un changement dans le pointeur de programme de l'interpréter indiquant l'instruction courante à interpréter.
Or, les systèmes informatiques actuels ne sont pas spécifiquement conçus afin d'interdire les branchements incontrôlés à l'intérieur d'un code. Bien au contraire, les langages d'assemblage ont été spécifiquement conçus afin de permettre au programmeur le maximum de liberté. A titre d'exemple, en langage C, il est possible de sauter à l'intérieur du code d'une fonction en utilisant l'exécution indexée par le pointeur
Au vu de ces problèmes de déroulement de programme de manière inadmissible, qu'ils aient pour cause un dysfonctionnement intempestif ou une volonté de détourner le programme de son utilisation prévue, l'invention propose un procédé de surveillance du déroulement de l'exécution d'une suite d'instructions d'un programme informatique, consistant à analyser la séquence des instructions transmises vers le processeur destiné à exécuter le programme surveillé et à vérifier le résultat de ce cette analyse avec des données de référence enregistrées avec ledit programme.
Ainsi, la présente invention permet de vérifier que toutes les instructions comprises dans l'ensemble d'instructions considéré ont bien été transmises vers le processeur en vu de leur exécution. Il est à supposer que si tel est le cas, les instructions lues ainsi auront aussi été exécutées.
Les données de référence peuvent être par exemple une valeur préétablie de manière à correspondre au résultat de l'analyse réalisée lors du procédé de surveillance seulement si toutes les instructions de la séquence d'instructions ont été effectivement analysées lors du déroulement du programme. De préférence, l'étape d'analyse comprend les sous-étapes d'extraction d'une donnée de chaque instruction transmise vers le processeur et de calcul prédéterminé sur chaque donnée ainsi extraite, et l'étape de vérification comporte la comparaison du résultat de l'analyse avec les données de référence.
Avantageusement, l'étape de vérification s'effectue par une comparaison câblée d'une valeur contenue dans un registre associé aux moyens de surveillance avec la valeur de référence, celle-ci pouvant être inscrite dans le programme de manière câblée, fixée (par exemple dans une mémoire figée type ROM) une fois pour toutes lors du masquage du code qui constitue le programme surveillé.
De préférence, la vérification est provoquée par une instruction placée à un emplacement prédéterminé dans le programme, cette instruction contenant les données de référence précitées.
Avantageusement, lorsque les instructions de l'ensemble d'instructions à surveiller se présentent sous la forme d'une valeur, hexadécimal ou décimal, on traite ces instructions en tant que simples valeur numériques lors de l'analyse précitée. Le procédé global de surveillance de l'exécution d'une séquence d'instructions d'un programme informatique peut ainsi comprendre les étapes suivantes : - lors de la préparation du programme: incorporer, à au moins un emplacement prédéterminé d'une séquence d'instructions du programme, une valeur de référence établie selon une règle donnée appliquée sur des données identifiables dans chaque instruction à surveiller, et - lors de l'exécution de la partie du programme à surveiller: obtenir lesdites données identifiables dans chaque instruction exécutée,
- appliquer ladite règle donnée sur lesdites données identifiables ainsi obtenues pour établir une valeur de vérification, et - vérifier que cette valeur de vérification correspond effectivement à la valeur de référence enregistrée avec le programme.
Dans un mode de réalisation préféré de l'invention, on prévoit d'interrompre le déroulement du programme lorsque qu'il est détecté que la valeur de vérification ne correspond à la valeur de référence. Cette interruption peut être assortie d'une action d'invalidation pour usage futur du dispositif comprenant le programme informatique surveillé si la non correspondance entre la valeur de vérification et la valeur de référence est détectée un nombre prédéterminé de fois.
Avantageusement, l'ensemble d'instructions à surveiller ne comporte pas de sauts dans son déroulement prévu, de sorte que l'on s'attend à ce que toutes les instructions qu'il comporte soient exécutées dans tous les cas de figure envisagés.
Lorsque le programme ou la portion de programme à surveiller prévoit au moins un saut, il est possible d'appliquer le procédé de surveillance séparément sur des ensembles d'instructions qui ne comportent pas de sauts.
Dans le cas d'une instruction donnant lieu à au moins un saut dépendant des données manipulées, c'est-à-dire un branchement conditionnel, on peut mettre en œuvre le procédé de surveillance séparément pour un ensemble d'instructions dépourvu de sauts et qui précède le saut, et pour au moins un ensemble d'instructions dépourvu de sauts qui succède à ce saut.
Dans ce cas, on peut envisager que pour un ensemble d'instructions précédant un saut, on intègre à cet ensemble l'instruction qui commande le saut (cette instruction étant normalement la dernière avant un branchement) aux fins de l'analyse visant à obtenir la valeur de vérification de cet ensemble d'instructions, et on vérifie ainsi le bon déroulement de cet ensemble d'instructions avant d'exécuter l'instruction de saut.
Avantageusement, on efface la valeur de vérification obtenue lors d'une précédente mise en œuvre du procédé à chaque nouvelle mise en œuvre du procédé. Cette disposition permet de gérer aisément le surveillance de différents ensembles d'instructions d'un programme, tels que ceux séparés par des sauts. Elle permet notamment de mettre en œuvre le procédé avec les mêmes conditions initiales de calcul de valeur de vérification pour les différents ensembles séparés par des sauts.
A chaque nouvelle mise en œuvre du procédé, la valeur de vérification peut être effacée par une simple remise à zéro Cette valeur peut également être remplacée par une autre valeur initiale prédéterminée. Ces opérations de remise à zéro ou d'initialisation peuvent être activées par le logiciel protégé lui-même.
Avantageusement, la valeur de vérification est obtenue en tant que dernière valeur d'une suite de valeurs que l'on fait évoluer successivement avec l'analyse de chacune des instructions considérées de l'ensemble d'instructions. Cette approche permet de contenir un état interne du déroulement du procédé de surveillance et de suivre son évolution.
De préférence, le mode d'analyse permettant cette évolution de la valeur de vérification consiste à calculer, pour chaque instruction considérée succédant à une instruction précédente, le résultat d'une opération sur à la fois une valeur extraite de l'instruction considérée et le résultat obtenu par la même opération effectuée sur cette instruction précédente. Pour le calcul lié à une première instruction à vérifier, on peut appliquer une opération sur à la fois la donnée extraite de cette première instruction et une valeur prédéterminée (qui peut correspondre alors à la valeur de ré- initialisation ou de remise à zéro précitée), celle-ci faisant office de valeur "graine" en l'absence résultat d'opération précédante.
De cette manière, il est possible d'obtenir la valeur de vérification correcte en utilisant un algorithme récursif applicable de la même manière pour les données extraites de chacune des instructions considérées. Qui plus est, l'opération de calcul peut être choisi isément de manière à ce qu'une valeur de vérification correcte soit obtenue seulement si d'une part les données de toutes les instructions ont été considérées lors du calcul, et d'autre part elles ont été considérées dans l'ordre prévu. L'opération de calcul peut consister à appliquer une fonction de hachage, selon une technique connue en elle-même dans le domaine du chiffrement de données, tel que la fonction de hachage SHA-1 établie par norme fédérale de hachage. On peut réaliser dans ce cas l'évolution interne précité du déroulement du procédé de surveillance en hachant cryptographiquement l'ensemble des codes d'opération (considérés en tant que valeurs numériques) et des adresses exécutés depuis la dernière initialisation effectuée.
En variante, il possible de faire évoluer la valeur de vérification en effectuant un calcul de redondance non nécessairement cryptographique sur l'ensemble des codes d'opération et des adresses exécutées depuis la dernière initialisation effectuée. A titre d'exemple, on peut utiliser des algorithmes du type CRC (cyclic redundancy check en anglais).
Il est possible avec l'invention d'obtenir le valeur de comparaison par calcul de valeurs intermédiaires au fur et à mesure que les données comprises dans les instructions respectives sont obtenues au cour de l'exécution de celles-ci. Avec cette approche, il n'est pas nécessaire de sauvegarder chaque valeur extraite des instructions de l'ensemble d'instructions considéré. En effet, à l'issu d'un calcul de valeur intermédiaire, seule compte cette valeur intermédiaire pour calculer la prochaine valeur intermédiaire (ou la valeur ultime qui correspond à la valeur de vérification), et la donnée qui a permis de l'engendrer n'est plus à prendre en considération. Cette disposition permet d'économiser de l'espace mémoire au niveau des moyens de mise en œuvre de l'invention.
En variante, il est possible de sauvegarder chaque donnée comprise dans les instructions de l'ensemble d'instructions considéré au fur et à mesure qu'elles sont exécutées et de n'effectuer le calcul de la valeur de vérification seulement au moment nécessaire, par exemple lors de l'étape de vérification.
L'invention concerne aussi un dispositif de surveillance du déroulement de l'exécution d'une suite d'instructions d'un programme informatique, caractérisé en ce qu'il comporte des moyens pour analyser la séquence des instructions transmises vers le processeur destiné à exécuter le programme surveillé et des moyens pour vérifier le résultat de ce cette analyse avec des données de référence enregistrées avec ledit programme. Le dispositif de surveillance conforme à la présente invention comporte avantageusement un registre permettant d'enregistrer des résultats intermédiaires dans le calcul de la valeur de vérification. Ce registre peut être adapté pour ne retenir seulement le dernier résultat intermédiaire en cours. II peut être prévu pour permettre l'enregistrement d'une valeur prédéterminée ou une remise à zéro sous la commande du programme en cours d'exécution. De cette manière, le programme peut commander une condition initiale au niveau du contenu du registre à chaque nouvelle mise en œuvre du procédé de surveillance, celle-ci intervenant par exemple après un saut dans le programme. Le dispositif de surveillance peut être intégré dans un dispositif d'exécution de programme à surveiller ou dans un dispositif programmé qui contient le programme à surveiller.
L'invention concerne également un dispositif d'exécution de programme, par exemple un ordinateur, un appareil à microprocesseur ou à microcontrôleur tel qu'un lecteur de carte à puce ou de programme enregistré sur une carte au format PCMCIA, destiné à exécuter une suite d'instructions d'un programme informatique, caractérisé en ce qu'il comporte des moyens pour analyser la séquence des instructions transmises pour exécution et des moyens pour vérifier que le résultat de cette analyse correspond avec des données de référence enregistrées avec le programme. L'invention concerne aussi un dispositif programmé destiné à fonctionner avec le dispositif d'exécution de programme précité et comportant une suite d'instructions, caractérisé en ce qu'il comporte en outre des données de référence préétablies en fonction de données contenues dans lesdites instructions et destinées à permettre une vérification de la séquence des instructions analysées par le dispositif d'exécution de programme précité.
Le dispositif programmé, par exemple une carte à puce ou un organe de contrôle de mécanisme, tel qu'un système de freinage ABS, peut intégrer le programme à surveiller dans une mémoire figée du type ROM.
Les données de référence sont avantageusement enregistrées sous la forme de valeur(s) pré-câblée(s) fixée(s) dans la mémoire une fois pour toutes lors du masquage du code.
La présente invention concerne aussi un dispositif de programmation d'un dispositif d'exécution d'un programme destiné à fonctionner en association avec le dispositif programmé précité, caractérisé en ce qu'il comprend des moyens pour inscrire, à au moins un emplacement prédéterminé d'une séquence d'instructions du programme, une valeur de référence calculée selon un mode préétabli à partir de données comprises dans chaque instruction d'un ensemble d'instructions dont on souhaite surveiller l'exécution.
Enfin, l'invention concerne aussi une machine virtuelle ou interpréteur interprétant un code critique, caractérisé en ce qu'il met en œuvre le procédé de surveillance précité pour l'exécution de ce code critique.
Les dispositifs précités de surveillance, d'exécution de programme, ou de programmation ou encore les dispositifs équipés de tels programmes peuvent être équipés de tous les moyens nécessaires pour réaliser les différents aspects optionnels possibles du procédé de surveillance précité.
A titre d'exemple, on peut envisager dans une application liée à une carte à puce, d'ajouter à un microprocesseur qui exécute un programme un composant matériel additionnel servant d'unité de surveillance. Le rôle de cette unité est de surveiller que des sauts non-prévus par le concepteur du logiciel ne puissent avoir lieu en cours d'exécution. Dans cet exemple, l'unité de surveillance pourra être composée de registres dont le contenu constitue à tout moment l'état interne de l'unité de surveillance. Une entrée spécifique de l'unité de surveillance permet sa remise à zéro (RAZ), typiquement en effaçant le contenu de l'unité de surveillance. Cette fonction peut être activée à tout moment par le logiciel exécuté et peut, par exemple, se réaliser par l'ajout d'un nouveau code opération en assembleur (par exemple "clr us") ou en manipulant un bit donnée dans la mémoire du composant protégé (par exemple : setb 3, service). Dans cet exemple d'application, l'unité de surveillance compare son état interne avec une chaîne donnée fournie par le logiciel protégé. Cela peut par exemple être réalisé en recopiant à l'intérieur de l'unité de surveillance (à l'aide d'une boucle "lda-sta") la valeur à laquelle le logiciel souhaite comparer l'état interne. Une fois la recopie de la valeur terminée, l'unité de surveillance la compare à son état interne et adopte le comportement suivant: si l'état de l'unité de surveillance est égal à la valeur présentée par le logiciel protégé, reprendre l'exécution normalement, sinon l'exécution du programme est arrêtée (forçant l'utilisateur à faire une remise à zéro de la carte), éventuellement en ratifiant au préalable un compteur de fausses exécutions dans une mémoire non volatile du type EEPROM ayant pour effet le blocage définitif de la carte si sa valeur dépasse une limite raisonnable (par exemple
4).
L'unité de surveillance peut garder de façon permanente un haché cryptographique des codes instructions et des adresses exécutés depuis sa dernière remise à zéro.
Le mécanisme de surveillance peut être adapté à l'interprétation de code dans une machine virtuelle (du "byte code" Java, par exemple). Le compilateur peut calculer la valeur du haché d'une portion de byte code, l'intégrer dans un attribut d'une structure connue sous le terme anglo-saxon de "class file" produit et ajouter au byte code généré des codes connus sous le terme anglo-saxon de "opcodes" supplémentaires correspondant à la remise à zéro de l'unité de surveillance et à l'appel de la fonction de vérification La machine virtuelle tiendra lieu d'unité de surveillance et lorsqu'elle rencontrera l'opcode de vérification, vérifiera la valeur du haché courant par rapport à la valeur du haché théorique contenu dans le class file.
L'invention sera mieux comprise et les avantages et caractéristiques ressortiront plus clairement à la lecture de la description suivante d'un mode de réalisation préféré, donnée purement à titre d'exemple, par référence aux dessins annexés, dans lesquels : - la figure 1, déjà présentée, est un schéma bloc simplifié visant à expliquer le rôle d'un compteur d'instructions dans le déroulement de l'exécution d'un programme,
- la figure 2 est un schéma bloc simplifié d'un dispositif d'exécution de programme visant à expliquer le principe de fonctionnement d'une unité de surveillance conformément à un premier mode de réalisation de l'invention, - la figure 3 est un organigramme du procédé de surveillance selon l'invention,
- la figure 4 est un organigramme d'une variante du procédé de surveillance selon l'invention,
- la figure 5 est un schéma bloc simplifié d'un dispositif d'exécution de programme visant à expliquer le principe de fonctionnement d'une unité de surveillance conformément à un deuxième mode de réalisation de l'invention,
- la figure 6 est un organigramme du procédé de surveillance selon l'invention, adapté au deuxième mode de réalisation, et - la figure 7 représente de manière schématisée des ensembles d'instructions d'un programme avec branchement contenant en outre des instructions spécifiques au procédé de surveillance.
Le principe de l'invention sera expliqué par référence au schéma bloc de la figure 2, dans lequel les blocs ayant un rôle analogue à ceux de la figure 1 portent les mêmes références et ne seront pas décrits à nouveau par souci de concision
La figure 2 représente les éléments de base d'un dispositif d'exécution de programme 20 au sens large II peut s'agir d'un ordinateur destiné à exécuter un programme dans un langage de haute niveau, d'un microprocesseur ou d'un microcontrôleur, ces derniers fonctionnant à partir de programmes en langage de bas niveau A titre d'exemple, le dispositif d'exécution 20 peut être un lecteur de carte à puce destinée à gérer des transactions bancaires, téléphoniques, ou d'autres services Le programme à vérifier est alors contenu matériellement dans la carte à puce
Afin de concrétiser la description qui suit, on supposera que le dispositif d'exécution de programme 20 est basé sur un processeur 4 de type microcontrôleur
Le processeur 4 exécute une portion de programme stockée dans un registre d'instructions 2 sous forme de microcodes La partie opérationnelle de cette portion de programme comprend une séquence de n instructions (où n est un entier supérieur à 1) désignées respectivement Inst 1, Inst 2, Inst 3, , Inst n Les microcodes qui constituent les instructions se présentent sous la forme de valeurs numériques, qui peuvent être décimales ou hexadécimales
Une telle valeur peut ainsi être considérée de deux façons distinctes, chacune porteuse d'une donnée premièrement en tant qu'instruction qu'elle représente pour le processeur (dans lequel cas elle sera désignée "valeur code"), et deuxièmement en tant que simple valeur numérique susceptible de traitement arithmétique (dans lequel cas elle sera désignée "valeur numérique" Vinst ) Par exemple, la première instruction Inst 1 est égale à 40 Ce chiffre est un code qui correspond à une instruction reconnue par le processeur, mais il possède la même structure binaire que la valeur numérique 40 Aucune des instructions Inst 1, Inst 2, Inst 3, , Inst n ordonne un saut vers une autre instruction en dehors de la séquence linéaire d'exécution des instructions Ainsi, le déroulement normal et prévu de cette portion de programme requiert obligatoirement l'exécution de chacune des instructions en succession, en commençant par l'instruction Inst 1 et en terminant par l'instruction Inst.n De la sorte, le compteur d'instructions 6 (déjà décrit) positionnera son pointeur 8 successivement à l'adresse de chacune des instructions Inst 1 à Inst n dans le registre d'instruction 2 au fur et à mesure qu'elles doivent être chargées dans le processeur 4 Conformément à la présente invention, le dispositif d'exécution de programme 20 comporte une unité de surveillance 22 qui permet de vérifier que chacune des instructions Inst. l à Inst n a bien été chargée vers le processeur 4 en vu de leur exécution Elle est fonctionnellement reliée entre le registre d'instructions 2 et le processeur 4 Ainsi, toutes les instructions lues du registre d'instructions 2 transitent à travers l'unité de surveillance 22 avant de parvenir au processeur 4
Dans cet exemple, l'unité de surveillance 22 est décrite comme étant intégrée au dispositif d'exécution de programme 20 Toutefois, l'unité de surveillance 22 peut tout aussi bien être intégrée avec le dispositif qui comporte le programme à surveiller, en étant par exemple incorporée dans une carte à puce dont le programme qu'elle contient en mémoire est à surveiller, sans que cela change les principes qui seront décrits ci-après
Comme il sera expliqué de manière plus détaillée ci-après, l'unité de surveillance 22 comporte un registre 24 destiné a stocker provisoirement une donnée comprise dans une instruction Inst 1, Inst 2, Inst 3, , Inst n et un calculateur 26 destiné à exécuter une opération sur cette donnée
La mise en œuvre de l'unité de surveillance demande l'adjonction de deux nouvelles instructions aux n instructions Inst 1, Inst 2, Inst 3, , Inst n du programme une première instruction de surveillance Inst 0 placée avant la première instruction Inst.l du programme et une seconde instruction de surveillance Inst n+1 placée à la suite de la dernière instruction Inst n du programme
Lors du déroulement de l'exécution des n instructions du programme, le compteur d'instructions 6 est initialement commandé pour positionner son pointeur 8 à l'adresse de la première instruction de surveillance Inst 0 Cette instruction commande à l'unité de surveillance d'initialiser une valeur de hachage VH contenue dans son registre 24 Dans l'exemple, l'instruction Inst 0 commande simplement au registre 24 mettre la valeur VH =0 Elle n'est pas transmise vers le processeur 4
Ensuite, le dispositif d'exécution de programme 20 passe en phase d'exécution des instructions Inst 1, Inst 2, Inst 3. , Inst n du programme proprement dit Chaque instruction lue à partir du registre d'instructions 2 est transmise en premier lieu à l'unité de surveillance 22 où elle est considérée comme valeur numérique
La valeur numérique de chaque instruction est soumise par le calculateur 26 a un algorithme de hachage, tel le hachage SHA-1 précisé par la norme fédérale de hachage Le résultat VHi de l'opération de hachage liée à une instruction Inst i (où i est un entier de 1 à n) est inscrite dans le registre 24
Cette valeur NHi sert de base pour l'opération de hachage avec l'instruction suivante Inst i+1 Le résultat de hachage VHi+1 ainsi obtenu pour l'instruction Inst.i+1 est alors inscrit en lieu et place du résultat de hachage VHi obtenu précédemment
Cette procédure est poursuivie pour chacune des instructions Inst 1, Inst 2, Inst.3, . , Inst n qui transitent par l'unité de surveillance 22
Lorsque la dernière instruction Inst n est exécutée, la seconde instruction de surveillance Inst n+1 est chargée dans l'unité de surveillance 22 Cette instruction comporte deux composantes une valeur de référence Vréf et une commande, destinée au calculateur 26, de comparaison de cette valeur de référence Vréf avec la valeur du dernier résultat de hachage inscrite dans le registre 24 Cette dernière valeur correspond donc au résultat du hachage VHn obtenu à partir de la valeur numérique de l'instruction Inst n (égale à 36 dans la figure) et du résultat de hachage VHn-1 obtenue pour l'instruction Inst n-1 précédente
Ainsi, en réponse à la seconde instruction de surveillance Inst n+1, le calculateur 26 compare la valeur VHn dans le registre 22 avec la valeur de référence Vréf spécifiée dans cette instruction de surveillance
La valeur de référence Vréf est déterminée lors de la préparation du programme enregistré afin de correspondre à la valeur attendue VHn pour le résultat des hachages successifs des valeurs des instructions Inst 1, Inst 2, Inst 3, , Inst n Cette valeur Vréf peut être calculée d'avance en utilisant la même procédure de hachage successif des instructions Inst 1, Inst 2, Inst 3, , Inst n qu'utilisée par l'unité de surveillance 22 De préférence, la valeur Vréf est câblée dans une mémoire figée afin de ne pas pouvoir être modifiée par un acte de malveillance
Si l'unité de surveillance 22 constate, en exécutant l'instruction du surveillance Inst n+1, qu'il y a identité entre les valeurs Vréf et NHn précitées, il est conclu que toutes les instructions Inst. l, Inst.2, Inst.3, ...., Inst.n. ont bien été transmises vers le processeur 4 en vu de leur exécution.
Si, au contraire, l'unité de surveillance 22 constate qu'il n'y a pas identité entre les valeurs Vréf et NHn, il est conclu que ou bien toutes les instructions Inst. l, Inst.2, Inst.3, ...., Inst.n. n'ont pas été reçues et transmises par l'unité de surveillance, ou bien elles ne l'ont pas été dans l'ordre séquentiel prévu. Dans ce cas, on peut prévoir une action visant alerter l'utilisateur ou le titulaire du programme, ou d'empêcher le programme de se poursuivre. Dans l'exemple, une telle action est transmise de l'unité de surveillance 22 vers le processeur 4 sous forme d'une commande d'interruption du programme Int..
Le procédé de surveillance tel que réalisé par les moyens de la figure 2 sera maintenant décrit par référence à l'organigramme représenté à la figure 3. On suppose que le programme ou la partie de programme à surveiller a été préparé correctement pour le procédé de surveillance par l'incorporation des première et seconde instructions de surveillance respectivement au début et à la fin.
Au stade initial, l'unité de surveillance 22 se positionne sur une routine de début de surveillance 30, dont la première étape 32 est l'attente de la première instruction de surveillance (Inst.O).
Lorsque la première instruction de surveillance Inst.O est reçue, l'unité de surveillance 22 effectue une étape 34 d'initialisation (par remise à zéro) d'un compteur d'instructions et du registre 24. La remise à zéro du registre 24 est une manière de placer une valeur "graine" dans ce registre pour démarrer une séquence d'opérations de hachage, comme il sera expliqué plus loin. Ces opérations peuvent être commandées directement par la première instruction de surveillance ou être simplement déclenchée par celle-ci à partir d'une routine associée à l'unité de surveillance 22.
Dans ce premier cas, la remise à zéro peut se réaliser par l'ajout d'un nouveau code opération en assembleur (par exemple "clr us"), ou en manipulant un bit donné dans la mémoire du dispositif d'exécution de programme 20. Une telle commande peut être "setb 3, service".
Après l'étape d'initialisation, l'unité de surveillance 22 incrémente le compteur d'instructions d'une unité (positionnant alors ce compteur à n=l) (étape 36). Ensuite, la première instruction Inst. l du programme ou de la partie de programme sous surveillance est lue du registre d'instructions 2 (étape 38). Comme expliqué plus haut, cette instruction est considérée par l'unité de surveillance 22 purement en tant que valeur numérique permettant des opérations arithmétiques. Dans l'exemple de la figure 2, cette valeur est 40.
La valeur numérique de cette première instruction Inst. l est alors soumise à une opération de hachage avec la valeur contenue dans le registre 24 (étape 40). Dans le cas de la première instruction, cette dernière valeur est la valeur d'initialisation, c'est-à-dire 0. L'opération de hachage, bien connue en elle-même, consiste ici à faire agir sur la valeur de l'instruction n considérée un opérateur mathématique f(VHn-l, Vinst.n), où NHn-1 est le résultat d'une opération de hachage précédente (ou la valeur d'initialisation dans le cas de la première instruction) enregistré dans le registre 24 et Vinst.n est la valeur numérique de l'instruction n considérée. Le résultat NHn de cette opération de hachage est ensuite enregistré dans le registre 24 à la place du résultat VHn-1 précédent (étape 42). On note que cette procédure de réactualisation du contenu du registre à chaque opération de hachage permet de garder de façon permanente un haché cryptographique des codes instructions et des adresses exécutés depuis la dernière initialisation. A la fin de cette opération de hachage, l'instruction est transmise vers le processeur 4 en vue de son exécution (étape 44).
Ensuite, l'unité de surveillance 22 détermine si le programme ou la partie de programme à surveiller contient une autre instruction à exécuter (étape 46).
Ceci étant le cas, la procédure effectue un rebouclage Bl vers l'étape 36 d'incrémentation de n à n+1. La valeur de la prochaine instruction (Inst.2) sera alors lue du registre d'instructions 2 et soumise à l'opération de hachage de la même manière que pour l'instruction Inst.1. Seulement, le hachage s'effectue cette fois avec d'une part la valeur numérique de l'instruction Inst.2 et le résultat obtenu lors de l'opération de hachage précédente, c'est-à-dire la valeur NHI (n étant ici égal à 2) qui est alors dans le registre 24.
Les étapes 42 à 46 du procédé s'effectuent de la même manière que pour la première instruction. De la sorte, l'ensemble des étapes 36 à 46 se poursuit en boucle pour chaque instruction Inst.l, Inst.2, Inst.3, ...., Inst.n. lue du registre d'instructions 2, avec le hachage s'opérant, pour une instruction Inst.i (où i est un entier de 1 à n) avec la valeur VHni-1 dans le registre 24 et la valeur Vinst.i.
Une fois que toutes les instructions Inst. l, Inst.2, Inst.3, ...., Inst.n. ont été ainsi traitées par l'unité de surveillance 22, celle-ci reçoit la seconde instruction de surveillance Inst. n+1, celle-ci suivant la dernière instruction Inst.n du programme ou de la partie de programme surveillé.
Cette seconde instruction de surveillance commande l'unité de surveillance 22 d'extraire la valeur de référence Vréf du programme (étape 48) et de comparer le contenu du registre 24 à cette valeur Vréf (étape 50). Cette commande peut être réalisée à l'aide d'une boucle "lda-sta".
On rappelle que, par exécution de boucles successives des étapes 36 à 46, la valeur contenue dans le registre 24 à ce stade est le résultat VHn du hachage réalisé avec le résultat NHn-1 du hachage précédent et de la valeur numérique de l'instruction n (égal à 36 dans l'exemple de la figure 2). La valeur de référence Vréf a été préalablement déterminée lors de la préparation du programme en connaissance des opérations de hachage, afin d'être égale à ce que l'unité de surveillance 22 devrait rendre en tant que valeur NHn si toutes les instructions Inst. l, Inst.2, Inst.3, ...., Inst.n. ont bien été transférées vers le processeur 4. Ainsi, le résultat de la comparaison permet de contrôler le bon déroulement des instructions Inst. l, Inst.2, Inst.3, ...., Inst.n si VHn = Vréf (étape 52), on suppose que toutes les instructions on été effectivement transférées vers le processeur 4. L'opération de surveillance est alors terminée en ce qui concerne le programme ou la portion de programme contenant les instructions Inst.1, Inst.2, Inst.3, ...., Inst.n. La procédure de surveillance retourne alors à la phase de début 30 en attente d'une nouvelle première instruction de surveillance.
Si, au contraire, l'étape de comparaison 50 fait apparaître qu'il n'y a pas identité entre les valeurs comparées (NHn≠Vréf), on suppose que toutes les instructions Inst. l, Inst 2, Inst.3, . , Inst n n'ont pas été transférées vers le processeur 4, ou n'ont pas été transférées dans le bon ordre (étape 54). En effet, le résultat d'une succession d'opérations de hachage dépend de l'ordre dans lequel elles ont été effectuées Dans ce cas, l'unité de surveillance 22 commande une action (étape 56), telle que l'interruption du programme et/ou l'enregistrement du fait que le programme ne s'est pas déroulé correctement.
Une variante du procédé de surveillance précité sera maintenant décrite par référence à l'organigramme de la figure 4. Selon cette variante, au lieu d'effectuer une opération de hachage lors de la réception de chaque nouvelle instruction par l'unité de surveillance 22, on réalise l'ensemble des opérations de hachage seulement après réception de la seconde instruction de surveillance. Dans l'organigramme de la figure 4, les étapes qui sont identiques à celles précédemment décrites par référence à la figure 3 portent les mêmes références et ne seront pas décrites à nouveau par souci de concision.
Le procédé de surveillance se déroule comme pour le cas précédent en ce qui concerne les étapes 30 à 38 (figures 3 et 4). Après l'étape 38 de lecture de la valeur de l'instruction Vinst.n du registre d'instructions 2, l'unité de surveillance 22 procède à l'enregistrement de cette valeur (étape 39). Cet enregistrement peut s'effectuer dans un registre interne du calculateur 26, dans une section dédiée du registre 24, dans une mémoire spécifique (non représentée) de l'unité de surveillance 22, ou encore dans une mémoire extérieure à l'unité de surveillance 22, dès lors qu'elle est accessible par celle-ci. Ensuite, l'unité de surveillance 22 procède aux étapes 44 et 46 précédemment décrites. On remarque que l'étape 39 d'enregistrement des valeurs Vinst.n est dans la boucle Bl reliant l'étape 46 à l'étape 36 d'incrémentation de n par une unité, de sorte que chacune des valeurs Vinst.n est ainsi enregistrée jusqu'à la détection de la seconde instruction de surveillance à l'étape 46. Lorsque cette seconde instruction apparaît, l'unité de surveillance 22 lit la valeur de référence Vréf (étape 48) et effectue à l'étape 49 le hachage selon le même algorithme qu'aux étapes précédemment décrites 40 et 42 de la figure 3, en se basant sur l'ensemble des valeurs Vinst. préalablement enregistrées. La valeur finale de hachage VHn est alors la même que dans le cas du procédé de la figure 3. On notera qu'il est possible d'intervertir l'ordre des étapes 48 et 49.
Les étapes de comparaison 50 et celles qui suivent sont identiques à celles de la figure 3. La figure 5 est un schéma bloc simplifié de l'unité de surveillance 22 conformément à un deuxième mode de réalisation de l'invention. Son intégration dans le dispositif d'exécution de programme 20 est la même que pour le premier mode de réalisation décrit par référence aux figures 2 et 3 en ce qui concerne son fonctionnement avec le compteur d'instructions 6, le registre d'instructions 2 et le processeur 4, et ne sera pas répété par souci de concision.
L'unité de surveillance 22 selon le deuxième mode de réalisation se distingue de celle du premier mode de réalisation essentiellement par le fait qu'il comporte en outre une mémoire 60 qui enregistre le nombre de fois que l'exécution d'une série d'instructions Inst. l-Inst.n ne s'est pas déroulée correctement selon les critères expliqués par référence à la figure 3 ou 4
Dans l'exemple, la mémoire 60 est matérialisée sous forme de mémoire figée (non volatile) à contenu effaçable électriquement (connu communément par l'appellation anglo-saxonne EEPROM). La mémoire 60 est reliée fonctionnellement au calculateur 26 de manière à ce qu'elle enregistre une valeur de comptage VC incrémentée d'une unité à chaque constat d'une exécution incorrecte dans la série d'instructions surveillée. Cette valeur de comptage VC permet ainsi de détecter le nombre de déroulements incorrects de la série d'instructions et d'agir en conséquence, par exemple en invalidant toute future utilisation du dispositif contenant le programme (par exemple une carte à puce) si ce nombre franchit une valeur seuil.
L'organigramme de la figure 6 donne un exemple d'utilisation de la valeur de comptage VC pour contrôler le dispositif de l'exécution de programme. Cet exemple comporte l'ensemble des étapes 30 à 54 de l'organigramme de la figure 3 ou les étapes analogues de la figure 4.
Lorsque l'unité de surveillance 22 détecte à l'étape 54 une exécution non- prévue des instructions Inst.1 - Inst.n, suite à l'étape de comparaison 52, l'unité de calcul 26 incrémente la valeur de comptage VC dans la mémoire 60, initialement égale à 0, d'une unité (étape 62). Ensuite, elle vérifie si la valeur de comptage VC ainsi incrémentée a atteint une valeur seuil VCseuil prédéterminée (étape 64). Cette valeur seuil VCseuil correspond au nombre de fois qu'il est admis que l'exécution non-prévue des instructions Inst. l-Inst.n puisse survenir dans le dispositif programmé avant de prendre des mesures définitives pour faire face à une telle défaillance. A titre d'exemple dans le contexte d'une carte à puce, on peut admettre un nombre modéré de telles défaillances (par exemple 3 ou 4) au bénéfice du doute qu'il pourrait s'agir d'une avarie momentanée liée au lecteur (dispositif d'exécution de programme 20), mais qu'au delà de ce nombre, on doit considérer que la carte a été altérée, soit accidentellement, soit par malveillance. Dans ce cas de mise en œuvre, on peut aussi prévoir d'inscrire la valeur VC dans le dispositif programmé (carte) afin de garder un historique de ces exécutions défaillantes lié physiquement au dispositif programme.
Si la valeur de comptage VC est inférieure au seuil VCseuil, l'unité de surveillance 22 établit la commande d'interruption Int. telle que précédemment décrite avec un simple message d'alerte destiné à l'utilisateur et/ou au système d'exploitation (étape 66) et la transmet au processeur 4 (étape 68).
Si, au contraire, la valeur de comptage VC atteint la valeur seuil VCseuil, l'unité de surveillance 22 établit alors la commande d'interruption Int. telle que précédemment décrite avec un ordre d'interdire toute future utilisation du dispositif programmé contenant les instructions exécutées de manière non-prévue (étape 70) et la transmet au processeur (étape 68). Dans ce cas, il ne sera possible de réutiliser ce dispositif seulement après avoir re-programmé la mémoire 60. Dans le cas où cette mémoire 60 est sous forme de EEPROM ou autre mémoire non-volatile, une telle re- programmation est très difficile à réaliser de manière détournée.
On notera que la commande Int. d'interruption du programme assortie d'une transmission de message d'alerte ou de commande d'invalidation d'usage futur peut être exécutée soit au niveau du processeur, soit au niveau de l'unité de surveillance 22. II sera maintenant décrit par référence à la figure 7 comment l'unité de surveillance 22 conformément à la présente invention peut être mise en œuvre pour la surveillance d'un programme qui prévoit des sauts ou des branchements.
Dans l'exemple de la figure 7, le dispositif d'exécution de programme 20 comporte dans le registre d'instructions 2 un programme ou une partie de programme destiné au processeur 4, constitué de trois ensembles d'instructions :
- un premier ensemble d'instructions Inst.EIl-1 à Inst.EIl-j (où j est un entier > 1), dont la dernière instruction EIl-j est un code qui commande le branchement conditionnel vers l'un ou l'autre des deux autres ensembles qui suivent; - un deuxième ensemble d'instructions Inst.EI2-l à Inst.EI2k (où k est un entier > 1) ; l'exécution de la première instruction Inst.EI2-l de cet ensemble succède à l'exécution de l'instruction de branchement conditionnel EIl-j si la première de deux conditions posées par celle-ci est satisfaite; et - un troisième ensemble d'instructions Inst.EI3-l à Inst.EDl (où 1 est un entier > 1); l'exécution de la première instruction Inst.EI3-l de cet ensemble succède à l'exécution de l'instruction de branchement conditionnel EIl-j si la seconde de deux conditions posées par celle-ci est satisfaite.
Les trois ensembles d'instructions EU, EI2 et EI3 ne comportent pas de sauts à l'intérieur de leur séquence d'instructions. (Dans le cas du premier ensemble d'instructions, le saut conditionnel à l'instruction EIl-j est à la fin de la séquence.)
Ainsi, pour chacun des trois ensembles d'instructions, toutes les instructions sont prévues pour être exécutées séquentiellement à partir de la première.
Lors de la préparation du programme, on ajoute en tête et en queue de chaque ensemble d'instructions EU, EI2 et EI3 respectivement la première instruction de surveillance et la seconde instruction de surveillance décrites plus haut par référence aux figures 2 à 6.
La surveillance du programme ou de la partie de programme composé par les ensembles EU, EI2 et EI3 procède alors comme suit. L'unité de surveillance 22 se positionne d'abord en phase de début de surveillance (étape 30, figure 3).
Le déroulement débute par l'exécution du premier ensemble d'instructions EU. La première instruction de surveillance placée en en-tête de cet ensemble sera d'abord chargée dans l'unité de surveillance 22. En réponse à cette instruction, l'unité de surveillance initialise son compteur d'instructions et son registre 24 de valeur de hachage VH (étape 34, figure 3) et procède à la routine de hachage pour chaque instruction Inst.EIl-1 à Inst. EIl-j de premier ensemble d'instructions selon les étapes 36 à 46 de là figure 3.
La dernière instruction EIl-j de l'ensemble qui commande le branchement est ainsi également soumise au hachage par l'unité de surveillance 22 avant d'être transmise vers le processeur 4.
L'instruction suivante est la seconde instruction de surveillance (étape 46, figure 3) en queue du premier ensemble d'instructions EU, qui provoque la phase de comparaison entre la dernière valeur de hachage enregistrée dans le registre 24 avec la valeur de référence Vréf associée à cette seconde instruction.
S'il est détecté à l'étape 50 de comparaison (figure 3) que la dernière valeur de hachage ainsi enregistrée ne correspond pas à la valeur de référence Vréf, l'unité de surveillance 22 procède aux étapes d'interruption du programme 54 et 56 (figures 3 ou 4) ou 54 à 70 (figure 6). De préférence, on prévoit que cette interruption se produit avant même que le programme ait exécuté le branchement conditionnel. Ceci peut être réalisé, par exemple, en associant à l'instruction de saut avec une instruction d'attente de validation venant de l'unité de surveillance, en employant des techniques de programmation connues.
S'il est détecté à l'étape 50 (figure 2) de comparaison que la dernière valeur de hachage ainsi enregistrée correspond effectivement à la valeur de référence Vréf, l'unité de surveillance autorise l'exécution du branchement conditionnel déterminé par la dernière instruction EIl-j de l'ensemble. Le programme se poursuit alors vers l'un ou l'autre des deuxième ou troisième ensembles d'instructions conformément aux conditions de branchement posées par cette dernière instruction.
On suppose dans l'exemple que le saut conditionnel provoque le branchement vers le troisième ensemble d'instructions à exécuter. Dans ce cas, le compteur d'instructions 6 fait passer le pointeur d'instructions 8 directement de la seconde instruction de surveillance en queue du premier ensemble d'instructions EU à la première instruction de surveillance en tête du troisième ensemble d'instructions EI3. L'unité de surveillance exécutera cette nouvelle première instruction en réinitialisant le compteur d'instructions et le registre 24. La procédure de surveillance pour ce troisième ensemble d'instructions se poursuit donc exactement de la même manière que pour le premier ensemble d'instructions. Ainsi, l'unité de surveillance 22 procédera au hachage successif de chacune des instructions lues de cet ensemble, en commençant le hachage avec la même valeur "graine" (qui correspond ici à zéro) que pour le premier ensemble. La seconde instruction de surveillance permet cette fois de déceler un déroulement non-prévu dans l'exécution localisée au niveau de ce troisième ensemble d'instructions et de procéder au même type d'action à l'étape 56. On comprendra que l'explication donnée pour le cas d'un branchement vers le troisième ensemble s'applique de manière rigoureusement analogue dans le cas d'un branchement vers le deuxième ensemble d'instructions suite à l'exécution de l'instruction de branchement du premier ensemble d'instructions.
Il est possible de permettre à l'unité de surveillance 22 de comptabiliser non seulement le nombre de déroulements non-prévus dans un programme comportant des sauts, mais également les ensembles d'instructions indépendamment surveillés dans lesquels ils se sont produits.
Ainsi, l'unité de surveillance 22 selon le deuxième mode de réalisation (figure
5) peut enregistrer dans sa mémoire 60 l'ensemble d'instructions concerné par chaque interruption constatée. Il est aussi possible d'établir des critères d'invalidation d'usage futur du programme en fonction des ensembles d'instructions dans lesquels se sont les interruptions.
Bien entendu, on comprendra que l'unité de surveillance 22 peut être soit matérialisée séparément du processeur 4 ou intégrée fonctionnel lement à ce dernier.
Enfin, il est clair que tous les aspects de l'invention décrits en termes de procédé peuvent être aisément compris en termes de moyens matériels de leur mise en œuvre, et inversement. De même, on comprendra que l'invention décrite couvre également toutes les transpositions évidentes d'un mode de réalisation ou sa variante à un autre.

Claims

REVENDICATIONS
1. Procédé de surveillance du déroulement de l'exécution d'une suite d'instructions (Inst. l-Inst.n) d'un programme informatique, consistant à analyser la séquence des instructions transmises vers le processeur (4) destiné à exécuter le programme surveillé et à vérifier le résultat de cette analyse par référence à des données de référence (Vréf) enregistrées avec ledit programme.
2. Procédé selon la revendication 1, caractérisé en ce que les données de référence comprennent une valeur (Vréf) préétablie de manière à correspondre au résultat de l'analyse réalisée lors du procédé de surveillance seulement si toutes les instructions (Inst.l-Inst.n) de la séquence d'instructions ont été effectivement analysées lors du déroulement du programme.
3. Procédé selon la revendication 1 ou 2, caractérisé en ce que ladite analyse de la séquence d'instructions (Inst. l-Inst.n) comprend l'extraction (38) d'une donnée de chaque instruction transmise vers le processeur (4) et un calcul prédéterminé (40, 42) sur chaque donnée ainsi extraite, et en ce que la vérification comprend une comparaison (50) du résultat de l'analyse avec les données de référence (Vréf).
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ladite vérification du résultat de l'analyse est provoquée par une instruction
(Inst.n+1) placée à un emplacement prédéterminé dans le programme à surveiller, cette instruction contenant les données de référence (Vréf) relatives à un ensemble d'instructions (Inst.l-Inst.n) dont l'exécution correcte est à surveiller.
5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que, lorsque les instructions (Inst. l-Inst.n) de l'ensemble d'instructions à surveiller se présentent sous la forme d'une valeur, par exemple des codes enregistrés sous forme hexadécimal ou décimal, on effectue ladite analyse des instructions en considérant celles-ci en tant que valeur numérique.
6. Procédé selon la revendication 1, comprenant les étapes consistant à :
- lors de la préparation du programme à surveiller :
- incorporer, à au moins un emplacement prédéterminé d'une séquence d'instructions (Inst.l-Inst.n) du programme, une valeur de référence (Vréf) établie selon une règle prédéterminée appliquée sur des données identifiables dans chaque instruction à surveiller, et
- lors de l'exécution du programme à surveiller:
- obtenir (38) lesdites données identifiables dans chaque instruction reçue en vu de son exécution,
- appliquer (40, 42) ladite règle prédéterminée sur lesdites données identifiables ainsi obtenues pour établir une valeur de vérification (VHn), et
- vérifier (50) que cette valeur de vérification correspond effectivement à la valeur de référence enregistrée avec le programme.
7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comprend en outre une étape (56) d'interruption du déroulement du programme surveillé si l'analyse révèle le programme surveillé ne s'est pas déroulé de manière prévue.
8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce qu'il comprend en outre une étape (70) d'invalidation pour usage futur du dispositif comprenant le programme surveillé si ladite analyse révèle un nombre prédéterminé de fois que le programme surveillé ne s'est pas déroulé de manière prévue.
9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce l'ensemble d'instructions à surveiller ne comporte pas de sauts dans son déroulement prévu.
10. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que, lorsque le programme (EU, EI2, EI3) ou la portion de programme à surveiller prévoit au moins un saut, on applique le procédé de surveillance séparément sur des ensembles d'instructions de ce programme qui ne comportent pas de sauts entre deux instructions successives.
11. Procédé selon la revendication 10, caractérisé en ce que lorsque le programme à surveiller comporte une instruction (EIl-j) donnant lieu à un saut dépendant des données manipulées, on met en œuvre le procédé de surveillance séparément pour un ensemble d'instructions (EU) qui précède le saut, et pour au moins un ensemble d'instructions (EI2, EI3) qui succède à ce saut.
12. Procédé selon la revendication 1 1, caractérisé en ce que, pour un ensemble d'instructions (EU) prévoyant un saut, on intègre à cet ensemble l'instruction (EIl-j) qui commande ce saut aux fins de l'analyse visant à obtenir la valeur de vérification (VH) de cet ensemble d'instructions, et on vérifie ainsi le bon déroulement de cet ensemble d'instructions avant d'exécuter l'instruction de saut.
13. Procédé selon l'une quelconque des revendications 1 à 12, caractérisé en ce que l'on ré-initialise l'analyse avant chaque nouvelle surveillance d'une séquence ou d'un ensemble (EU, EI2, EI3) d'instructions à surveiller.
14. Procédé selon la revendication 13, caractérisé en ce que la réinitialisation de l'analyse à chaque nouvelle surveillance consiste à effacer ou remplacer une valeur de vérification (VH) obtenue lors d'une précédente analyse.
15. Procédé selon la revendication 13 ou 14, caractérisé en ce que la ré- initialisation de l'analyse de surveillance est commandée par le logiciel protégé lui- même.
16. Procédé selon l'une quelconque des revendications 1 à 15, caractérisé en ce que l'analyse produit une valeur de vérification (VH) obtenue en tant que dernière valeur d'une suite de valeurs que l'on fait évoluer successivement avec l'analyse de chacune des instructions (Inst. l-Inst.n) analysées de l'ensemble d'instructions, permettant ainsi de contenir un état interne du déroulement du procédé de surveillance et de suivre son évolution.
17. Procédé selon l'une quelconque des revendications 1 à 16, caractérisé en ce que l'analyse consiste à calculer (40, 42), pour chaque instruction considérée (Inst.n) succédant à une instruction précédente (Inst.n-1), le résultat d'une opération sur à la fois une valeur (VHn) obtenue de l'instruction considérée et le résultat (VHn- 1) obtenu par la même opération effectuée sur l'instruction précédente.
18. Procédé selon l'une quelconque des revendications 1 à 17, caractérisé en ce que l'analyse consiste à appliquer de manière récursive une fonction de hachage f(VHn-l, Vinst.n) sur des valeurs obtenues de chaque instruction surveillée, en partant d'une dernière initialisation effectuée.
19. Procédé selon l'une quelconque des revendications 1 à 17, caractérisé en ce que l'analyse consiste à faire évoluer une valeur de vérification en effectuant un calcul de redondance non nécessairement cryptographique sur l'ensemble des codes d'opération et des adresses exécutées depuis la dernière initialisation effectuée.
20. Procédé selon l'une quelconque des revendications 1 à 19, caractérisé en ce que l'analyse consiste à obtenir une valeur de comparaison (NCn) par calcul de valeurs intermédiaires successives au fur et à mesure que l'on obtient les données des instructions respectives servant pour ce calcul durant l'exécution de ces instructions.
21. Procédé selon l'une quelconque des revendications 1 à 19, caractérisé en ce que l'analyse comprend une étape de sauvegarde de chaque donnée nécessaire pour la vérification, obtenue à partir des instructions de l'ensemble d'instructions à surveiller (Inst. l-Inst.n) au fur et à mesure qu'elles sont exécutées, et de n'effectuer un calcul de la valeur de vérification (VHn) à partir de ces données seulement au moment nécessaire, une fois que toutes les données nécessaires ont été obtenues.
22. Dispositif de surveillance du déroulement de l'exécution d'une suite d'instructions (Inst. l-Inst.n) d'un programme informatique, comportant des moyens (22-26) pour analyser la séquence des instructions transmises vers le processeur (4) destiné à exécuter le programme surveillé et des moyens (26) pour vérifier le résultat (VCn) de cette analyse par référence à des données de référence (Vréf) enregistrées avec ledit programme.
23. Dispositif selon la revendication 22, adapté pour mettre en œuvre le procédé de surveillance selon l'une quelconque des revendications 1 à 21, caractérisé en ce qu'il comporte un registre (24) permettant d'enregistrer des résultats intermédiaires (VH) dans un calcul en chaîne effectué par le moyen d'analyse (26) pour obtenir une valeur de vérification (VHn).
24. Dispositif selon la revendication 23, caractérisé en ce qu'il comprend des moyens pour permettre l'enregistrement d'une valeur prédéterminée ou une remise à zéro du registre (24) sous la commande d'une instruction (Inst.n+1) transmise lors de l'exécution d'un programme à surveiller, par exemple à l'occasion d'un saut dans le programme.
25. Dispositif selon l'une quelconque des revendications 22 à 24, caractérisé en ce qu'il comporte un moyen (60) de comptabilisation du nombre de déroulements non-prévus du programme surveillé, tel que déterminé par le moyen d'analyse (26), et des moyens pour invalider l'utilisation future du programme à surveiller si ce nombre atteint un seuil (VCseuil) prédéterminé.
26. Dispositif selon l'une quelconque des revendications 22 à 25, caractérisé en ce qu'il est intégré à un dispositif programmé, telle qu'une carte à puce, contenant ledit programme à surveiller.
27. Dispositif selon l'une quelconque des revendications 22 à 25, caractérisé en ce qu'il est intégré un dispositif d'exécution de programme (20).
28. Dispositif d'exécution de programme (20), destiné à exécuter une suite d'instructions (Inst. l-Inst.n) d'un programme informatique, caractérisé en ce qu'il comporte des moyens (22-26) pour analyser la séquence des instructions transmises pour exécution et des moyens pour vérifier le résultat de cette analyse par référence à des données de référence (Vréf) enregistrées avec le programme à surveiller.
29. Dispositif d'exécution de programme (20) selon la revendication 28, adapté pour mettre en œuvre le procédé selon l'une quelconque des revendications 1 à 21.
30. Dispositif programmé comportant une suite d'instructions enregistrées (Inst.l-Inst.n), caractérisé en ce qu'il comporte en outre des données de référence (Vréf) préétablies en fonction de données contenues dans lesdites instructions et destinées à permettre une vérification de la séquence des instructions analysées selon l'une quelconque des revendications 1 à 21.
31. Dispositif selon la revendication 30, caractérisé en ce qu'il se présente sous forme de carte à puce.
32. Dispositif selon la revendication 30 ou 31, caractérisé en ce que les données de référence (Vréf) sont enregistrées soUs la forme de valeur(s) pré-câblée(s) fixée(s) en mémoire.
33. Dispositif de programmation d'un dispositif destiné à être programmé selon l'une quelconque des revendications 30 à 32, caractérisé en ce qu'il comprend des moyens pour inscrire à au moins un emplacement prédéterminé d'une séquence d'instructions du programme (Inst. l-Inst.n) une valeur de référence (Vréf) calculée selon un mode préétabli à partir de données comprises dans chaque instruction d'un ensemble d'instructions dont on souhaite surveiller l'exécution.
34. Machine virtuelle ou interpréteur interprétant un code critique, caractérisé en ce qu'il met en œuvre le procédé selon l'une quelconque des revendications 1 à 21 pour l'exécution de ce code critique.
PCT/FR2000/000150 1999-03-09 2000-01-24 Procede de surveillance du deroulement d'un programme WO2000054155A1 (fr)

Priority Applications (7)

Application Number Priority Date Filing Date Title
JP2000604312A JP4172745B2 (ja) 1999-03-09 2000-01-24 プロセッサによる命令シーケンスの実行を監視する方法および監視装置
DE60001393T DE60001393T2 (de) 1999-03-09 2000-01-24 Verfahren zur überwachung des programmablaufs
MXPA01009056A MXPA01009056A (es) 1999-03-09 2000-01-24 Procedimiento de supervision del desarrollo de un programa.
US09/936,174 US7168065B1 (en) 1999-03-09 2000-01-24 Method for monitoring program flow to verify execution of proper instructions by a processor
AT00900650T ATE232616T1 (de) 1999-03-09 2000-01-24 Verfahren zur überwachung des programmablaufs
AU30589/00A AU3058900A (en) 1999-03-09 2000-01-24 Method for monitoring a programme flow
EP00900650A EP1161725B1 (fr) 1999-03-09 2000-01-24 Procede de surveillance du deroulement d'un programme

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR9902924A FR2790844B1 (fr) 1999-03-09 1999-03-09 Procede et dispositif de surveillance du deroulement d'un programme, dispositif programme permettant la surveillance de son programme
FR99/02924 1999-03-09

Publications (1)

Publication Number Publication Date
WO2000054155A1 true WO2000054155A1 (fr) 2000-09-14

Family

ID=9542995

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2000/000150 WO2000054155A1 (fr) 1999-03-09 2000-01-24 Procede de surveillance du deroulement d'un programme

Country Status (10)

Country Link
US (1) US7168065B1 (fr)
EP (1) EP1161725B1 (fr)
JP (1) JP4172745B2 (fr)
CN (1) CN1350675A (fr)
AT (1) ATE232616T1 (fr)
AU (1) AU3058900A (fr)
DE (1) DE60001393T2 (fr)
FR (1) FR2790844B1 (fr)
MX (1) MXPA01009056A (fr)
WO (1) WO2000054155A1 (fr)

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003029979A2 (fr) * 2001-09-28 2003-04-10 Infineon Technologies Ag Unite commandee par programme
WO2003042547A2 (fr) 2001-11-16 2003-05-22 Giesecke & Devrient Gmbh Execution controlee d'un programme par un support de donnees portable
EP1357459A1 (fr) * 2002-04-23 2003-10-29 STMicroelectronics S.A. Processeur securisé contre les deroutements
FR2841015A1 (fr) * 2002-06-18 2003-12-19 St Microelectronics Sa Controle d'execution d'un programme
FR2849226A1 (fr) * 2002-12-20 2004-06-25 Oberthur Card Syst Sa Procede et dispositif de securisation de l'execution d'un programme informatique.
EP1460546A1 (fr) * 2003-03-18 2004-09-22 SCHLUMBERGER Systèmes Procédé de sécurisation de l'exécution d'un programme dans un ensemble électronique contre les attaques par introduction d'erreurs
FR2864655A1 (fr) * 2003-12-31 2005-07-01 Trusted Logic Procede de controle d'integrite de programmes par verification d'empreintes de traces d'execution
WO2006024903A1 (fr) * 2004-08-30 2006-03-09 Axalto Sa Verification d'integrite d'un code d'application pendant l'execution d'une machine virtuelle
FR2886027A1 (fr) * 2005-05-20 2006-11-24 Proton World Internatinal Nv Detection d'erreur de sequencement dans l'execution d'un programme
EP1870829A1 (fr) 2006-06-23 2007-12-26 Microsoft Corporation Protéger les logiciels en imposant l'intégrité du flux des données
US8161293B2 (en) 2005-04-20 2012-04-17 Stmicroelectronics S.A. Protection of the execution of a program executed by an integrated circuit
US8843761B2 (en) 2007-08-16 2014-09-23 Siemens Aktiengesellschaft Method and apparatus for protection of a program against monitoring flow manipulation and against incorrect program running
CN107194258A (zh) * 2017-04-06 2017-09-22 珠海格力电器股份有限公司 监测代码漏洞的方法、装置及电子设备、存储介质
CN111427723A (zh) * 2020-03-19 2020-07-17 阳光电源股份有限公司 基于AutoSAR的程序流监控方法及应用装置

Families Citing this family (69)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030149887A1 (en) * 2002-02-01 2003-08-07 Satyendra Yadav Application-specific network intrusion detection
DE10340411B4 (de) 2003-09-02 2005-10-13 Infineon Technologies Ag Vorrichtung und Verfahren zur sicheren Ausführung eines Programms
US7424709B2 (en) * 2003-09-15 2008-09-09 Intel Corporation Use of multiple virtual machine monitors to handle privileged events
EP1538509A1 (fr) * 2003-12-04 2005-06-08 Axalto S.A. Procédé de sécurisation de l'éxécution d'un programme contre des attaques par rayonnement
JP4282472B2 (ja) * 2003-12-26 2009-06-24 株式会社東芝 マイクロプロセッサ
DE102004007614A1 (de) * 2004-02-17 2005-09-01 Giesecke & Devrient Gmbh Datenträger mit Ablaufdiagnosespeicher
US7584386B2 (en) 2004-04-21 2009-09-01 Stmicroelectronics Sa Microprocessor comprising error detection means protected against an attack by error injection
CN100465982C (zh) * 2004-07-16 2009-03-04 松下电器产业株式会社 应用执行装置及应用执行装置的应用执行方法
US8364792B2 (en) * 2005-03-09 2013-01-29 Vudu, Inc. Method and system for distributing restricted media to consumers
US7873947B1 (en) * 2005-03-17 2011-01-18 Arun Lakhotia Phylogeny generation
FR2883998A1 (fr) * 2005-04-05 2006-10-06 St Microelectronics Sa Coprocesseur securise comprenant un circuit de detection d'un evenement
FR2884000A1 (fr) 2005-04-05 2006-10-06 St Microelectronics Sa Coprocesseur securise comprenant des moyens pour empecher l'acces a un organe du coprocesseur
EP1894101A1 (fr) * 2005-06-23 2008-03-05 Bayerische Motorenwerke Aktiengesellschaft Procede et dispositif pour surveiller un acces non autorise a une memoire d'une unite de calcul, en particulier dans un vehicule automobile
FR2895814A1 (fr) * 2006-01-04 2007-07-06 Gemplus Sa Procede de securisation de l'execution d'un programme d'ordinateur
US7900060B2 (en) * 2006-02-17 2011-03-01 Vudu, Inc. Method and system for securing a disk key
US8239686B1 (en) * 2006-04-27 2012-08-07 Vudu, Inc. Method and system for protecting against the execution of unauthorized software
DE102006021494A1 (de) * 2006-05-09 2007-11-15 Giesecke & Devrient Gmbh Verfahren und Vorrichtung zur Erkennung nichteindeutiger Hashwerte
US7587663B2 (en) * 2006-05-22 2009-09-08 Intel Corporation Fault detection using redundant virtual machines
WO2007145366A1 (fr) * 2006-06-15 2007-12-21 Kabushiki Kaisha Toshiba Dispositif électronique portable et SA méthode de COMMANDE
DE102006037810A1 (de) 2006-08-11 2008-02-14 Giesecke & Devrient Gmbh Sichere Programmcodeausführung
EP1923789A1 (fr) 2006-11-16 2008-05-21 Nagracard S.A. Procédé de contrôle de l'exécution d'un programme par un microcontrôleur
US7644322B2 (en) * 2006-11-21 2010-01-05 Atmel Corporation Hardware flow control monitor
DE102006057297A1 (de) * 2006-12-05 2008-06-12 Giesecke & Devrient Gmbh Verfahren zur Überwachung des Ablaufs eines Programms
US8429623B2 (en) * 2007-01-16 2013-04-23 Oracle America Inc. Processing engine for enabling a set of code intended for a first platform to be executed on a second platform
EP2043017A1 (fr) * 2007-04-12 2009-04-01 Gemplus Procédé d'exécution sécurisée d'une application
FR2915007A1 (fr) * 2007-04-12 2008-10-17 St Microelectronics Sa Protection de l'execution d'un programme
CN101689233B (zh) * 2007-07-05 2013-01-02 Nxp股份有限公司 安全敏感系统中的微处理器
JP4661854B2 (ja) * 2007-11-09 2011-03-30 株式会社デンソー 検査システム及びプログラム
JP5060372B2 (ja) 2008-04-10 2012-10-31 ルネサスエレクトロニクス株式会社 データ処理装置
CN101299849B (zh) * 2008-04-25 2010-05-12 中兴通讯股份有限公司 一种WiMAX终端及其启动方法
WO2009144531A1 (fr) * 2008-05-27 2009-12-03 Freescale Semiconductor, Inc. Dispositif à semi-conducteurs et procédé de validation d’un état de ce dispositif
JP5200664B2 (ja) * 2008-05-28 2013-06-05 大日本印刷株式会社 メモリの内容を改竄する故障攻撃の検知方法、セキュリティデバイス及びコンピュータプログラム
JP5200686B2 (ja) * 2008-06-18 2013-06-05 大日本印刷株式会社 情報処理装置、正常処理判別方法、及び情報処理プログラム
EP2262259A1 (fr) 2009-06-08 2010-12-15 Nagravision S.A. Procédé pour le contrôle l'exécution d'instructions de programme de traitement de données dans un module sécurisé
FR2958764B1 (fr) * 2010-04-07 2013-01-25 Proton World Int Nv Compteur d'evenements dans un systeme adapte au langage javacard
CN102053927B (zh) * 2010-12-29 2013-11-27 北京握奇数据系统有限公司 攻击监控方法及具有攻击监控功能的装置
FR2970357B1 (fr) * 2011-01-07 2013-01-11 Oridao Dispositif et procede de tracage
US20120179898A1 (en) * 2011-01-10 2012-07-12 Apple Inc. System and method for enforcing software security through cpu statistics gathered using hardware features
US8725644B2 (en) * 2011-01-28 2014-05-13 The Active Network, Inc. Secure online transaction processing
DE102011005209B4 (de) 2011-03-07 2016-06-23 Infineon Technologies Ag Programmanweisungsgesteuerte Instruktionsflusskontrolle
DE102011006000B4 (de) * 2011-03-23 2015-01-15 Infineon Technologies Ag Signaturaktualisierung durch Codetransformation
FR2977342A1 (fr) * 2011-06-30 2013-01-04 Proton World Int Nv Verification d'integrite d'un programme execute par un circuit electronique
CN103718182B (zh) * 2011-08-09 2016-11-23 飞思卡尔半导体公司 电子器件和计算机程序产品
US8417609B2 (en) * 2011-08-19 2013-04-09 Bank Of America Corporation Methods and systems for modeling deposits' data
CN103455445A (zh) * 2012-05-31 2013-12-18 上海华虹集成电路有限责任公司 智能卡系统抵抗故障攻击的方法
US8745594B1 (en) * 2013-05-10 2014-06-03 Technobasics Software Inc. Program flow specification language and system
CN103383566B (zh) * 2013-06-24 2015-10-28 奇瑞汽车股份有限公司 一种程序流监控方法
US9323920B2 (en) * 2013-10-23 2016-04-26 Infineon Technologies Ag Data processing arrangement and method for ensuring the integrity of the execution of a computer program
TWI712915B (zh) 2014-06-12 2020-12-11 美商密碼研究公司 執行一密碼編譯操作之方法，以及電腦可讀非暫時性儲存媒體
JP6318976B2 (ja) * 2014-08-22 2018-05-09 富士通株式会社 デバッグ回路、デバッガ装置、半導体装置及びデバッグ方法
FR3035240B1 (fr) * 2015-04-15 2018-04-06 Rambus Inc. Procede de securisation de l'execution d'un programme
EP3091437A1 (fr) 2015-05-08 2016-11-09 Robert Bosch Gmbh Procédé et appareil permettant de surveiller un flux de commande d'un programme informatique
US10785259B2 (en) 2016-04-19 2020-09-22 Mitsubishi Electric Corporation Relay device
US10552413B2 (en) * 2016-05-09 2020-02-04 Sap Se Database workload capture and replay
CN105955115A (zh) * 2016-05-10 2016-09-21 重庆长安汽车股份有限公司 一种汽车整车控制器的程序流监控方法和装置
GB2550903B (en) * 2016-05-27 2019-06-12 Arm Ip Ltd Context data control
US10298702B2 (en) 2016-07-05 2019-05-21 Sap Se Parallelized replay of captured database workload
EP3279826A1 (fr) * 2016-08-04 2018-02-07 Nagravision SA Vérification de séquence
DE112017006528T5 (de) * 2017-01-25 2019-09-26 Mitsubishi Electric Corporation Angriff/abnormalität-detektionsvorrichtung, angriff/abnormalität-detektionsverfahren und angriff/abnormalität-detektionsprogramm
US10592528B2 (en) 2017-02-27 2020-03-17 Sap Se Workload capture and replay for replicated database systems
US10345801B2 (en) * 2017-08-21 2019-07-09 Honeywell International Inc. Ensuring a correct program sequence in a dual-processor architecture
US10698892B2 (en) 2018-04-10 2020-06-30 Sap Se Order-independent multi-record hash generation and data filtering
CN108646708B (zh) * 2018-05-02 2020-05-22 阳光电源股份有限公司 一种程序流监控方法及系统
WO2020027815A1 (fr) * 2018-07-31 2020-02-06 Hewlett-Packard Development Company, L.P. Exécution d'instructions
US11138085B2 (en) 2018-10-09 2021-10-05 Argo AI, LLC Execution sequence integrity monitoring system
US11144375B2 (en) 2018-10-09 2021-10-12 Argo AI, LLC Execution sequence integrity parameter monitoring system
US11709752B2 (en) 2020-04-02 2023-07-25 Sap Se Pause and resume in database system workload capture and replay
US11615012B2 (en) 2020-04-03 2023-03-28 Sap Se Preprocessing in database system workload capture and replay
KR20230144611A (ko) * 2021-04-06 2023-10-16 구글 엘엘씨 보안 암호화 코프로세서

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0012794A1 (fr) * 1978-12-22 1980-07-09 International Business Machines Corporation Procédé et dispositif pour vérifier les signaux de commande déduits de l'instruction d'une unité électronique de traitement de données
US4266272A (en) * 1978-10-12 1981-05-05 International Business Machines Corporation Transient microcode block check word generation control circuitry

Family Cites Families (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
PL168163B1 (pl) * 1991-01-18 1996-01-31 Thomson Multimedia Sa Sposób kontroli dostepu i/lub identyfikacji PL PL
US5347581A (en) * 1993-09-15 1994-09-13 Gemplus Developpement Verification process for a communication system
AU1690597A (en) * 1996-01-11 1997-08-01 Mitre Corporation, The System for controlling access and distribution of digital property
US6026485A (en) * 1996-01-24 2000-02-15 Sun Microsystems, Inc. Instruction folding for a stack-based machine
JP2000501217A (ja) * 1996-01-24 2000-02-02 サン・マイクロシステムズ・インコーポレイテッド 配列アクセス境界チェックを加速したプロセッサ
US6065108A (en) * 1996-01-24 2000-05-16 Sun Microsystems Inc Non-quick instruction accelerator including instruction identifier and data set storage and method of implementing same
US5974549A (en) * 1997-03-27 1999-10-26 Soliton Ltd. Security monitor
WO1999001815A1 (fr) * 1997-06-09 1999-01-14 Intertrust, Incorporated Techniques d'obscurcissement pour augmenter la securite de logiciels
US6275938B1 (en) * 1997-08-28 2001-08-14 Microsoft Corporation Security enhancement for untrusted executable code
US6199181B1 (en) * 1997-09-09 2001-03-06 Perfecto Technologies Ltd. Method and system for maintaining restricted operating environments for application programs or operating systems
US5983348A (en) * 1997-09-10 1999-11-09 Trend Micro Incorporated Computer network malicious code scanner
US5991414A (en) * 1997-09-12 1999-11-23 International Business Machines Corporation Method and apparatus for the secure distributed storage and retrieval of information
US6279123B1 (en) * 1997-09-15 2001-08-21 Lucent Technologies, Inc. System for viewing and monitoring embedded processor operation
US6023764A (en) * 1997-10-20 2000-02-08 International Business Machines Corporation Method and apparatus for providing security certificate management for Java Applets
FR2776410B1 (fr) * 1998-03-20 2002-11-15 Gemplus Card Int Dispositifs pour masquer les operations effectuees dans une carte a microprocesseur
US6092120A (en) * 1998-06-26 2000-07-18 Sun Microsystems, Inc. Method and apparatus for timely delivery of a byte code and serialized objects stream
US6418420B1 (en) * 1998-06-30 2002-07-09 Sun Microsystems, Inc. Distributed budgeting and accounting system with secure token device access
US6581206B2 (en) * 1999-11-12 2003-06-17 Sun Microsystems, Inc. Computer program language subset validation
US6859533B1 (en) * 1999-04-06 2005-02-22 Contentguard Holdings, Inc. System and method for transferring the right to decode messages in a symmetric encoding scheme
US6402028B1 (en) * 1999-04-06 2002-06-11 Visa International Service Association Integrated production of smart cards
US6615264B1 (en) * 1999-04-09 2003-09-02 Sun Microsystems, Inc. Method and apparatus for remotely administered authentication and access control
US6546546B1 (en) * 1999-05-19 2003-04-08 International Business Machines Corporation Integrating operating systems and run-time systems
US6327700B1 (en) * 1999-06-08 2001-12-04 Appliant Corporation Method and system for identifying instrumentation targets in computer programs related to logical transactions
US6510352B1 (en) * 1999-07-29 2003-01-21 The Foxboro Company Methods and apparatus for object-based process control
FR2804234B1 (fr) * 2000-01-24 2003-05-09 Gemplus Card Int Procede de protection contre le vol de la valeur d'authentification pour cartes a puce(s) multi-applications, cartes a puce(s) mettant en oeuvre le procede et terminaux susceptibles de recevoir lesdites cartes
US6557168B1 (en) * 2000-02-25 2003-04-29 Sun Microsystems, Inc. System and method for minimizing inter-application interference among static synchronized methods
US6507904B1 (en) * 2000-03-31 2003-01-14 Intel Corporation Executing isolated mode instructions in a secure system running in privilege rings
CA2305249A1 (fr) * 2000-04-14 2001-10-14 Branko Sarcanin Coffre-fort virtuel
US6951018B2 (en) * 2000-05-30 2005-09-27 Sun Microsystems, Inc. Method and apparatus for efficiently tracking monitors
FR2809892B1 (fr) * 2000-05-31 2002-09-06 Gemplus Card Int Procede de protection contre la modification frauduleuse de donnees envoyees a un support electronique securise
FR2810481B1 (fr) * 2000-06-20 2003-04-04 Gemplus Card Int Controle d'acces a un moyen de traitement de donnees
US6862684B1 (en) * 2000-07-28 2005-03-01 Sun Microsystems, Inc. Method and apparatus for securely providing billable multicast data
CA2315449A1 (fr) * 2000-08-10 2002-02-10 Ibm Canada Limited-Ibm Canada Limitee Generation de traces d'execution d'applications et determination de problemes connexes
FR2814557B1 (fr) * 2000-09-27 2002-12-27 Gemplus Card Int Protection contre l'exploitation abusive d'une instruction dans une memoire

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4266272A (en) * 1978-10-12 1981-05-05 International Business Machines Corporation Transient microcode block check word generation control circuitry
EP0012794A1 (fr) * 1978-12-22 1980-07-09 International Business Machines Corporation Procédé et dispositif pour vérifier les signaux de commande déduits de l'instruction d'une unité électronique de traitement de données

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8145953B2 (en) 2001-09-28 2012-03-27 Infineon Technologies Ag Programmable unit
WO2003029979A3 (fr) * 2001-09-28 2004-07-01 Infineon Technologies Ag Unite commandee par programme
WO2003029979A2 (fr) * 2001-09-28 2003-04-10 Infineon Technologies Ag Unite commandee par programme
CN1296819C (zh) * 2001-11-16 2007-01-24 德国捷德有限公司 便携式数据载体的控制程序执行
WO2003042547A2 (fr) 2001-11-16 2003-05-22 Giesecke & Devrient Gmbh Execution controlee d'un programme par un support de donnees portable
WO2003042547A3 (fr) * 2001-11-16 2004-05-27 Giesecke & Devrient Gmbh Execution controlee d'un programme par un support de donnees portable
US7441111B2 (en) 2001-11-16 2008-10-21 Giesecke & Devrient Gmbh Controlled program execution by a portable data carrier
EP1357459A1 (fr) * 2002-04-23 2003-10-29 STMicroelectronics S.A. Processeur securisé contre les deroutements
US7533412B2 (en) 2002-04-23 2009-05-12 Stmicroelectronics S.A. Processor secured against traps
FR2841015A1 (fr) * 2002-06-18 2003-12-19 St Microelectronics Sa Controle d'execution d'un programme
FR2849226A1 (fr) * 2002-12-20 2004-06-25 Oberthur Card Syst Sa Procede et dispositif de securisation de l'execution d'un programme informatique.
US9092618B2 (en) 2002-12-20 2015-07-28 Oberthur Technologies Method and device for making secure execution of a computer programme
WO2004066127A1 (fr) * 2002-12-20 2004-08-05 Oberthur Card Systems S.A. Procede et dispositif de securisation de l'execution d'un programme informatique
WO2004084073A1 (fr) * 2003-03-18 2004-09-30 Axalto Sa Procede pour proteger un assemblage electronique qui execute un algorithme quelconque contre des attaques par introduction d'erreurs
EP1460546A1 (fr) * 2003-03-18 2004-09-22 SCHLUMBERGER Systèmes Procédé de sécurisation de l'exécution d'un programme dans un ensemble électronique contre les attaques par introduction d'erreurs
WO2005073859A2 (fr) * 2003-12-31 2005-08-11 Trusted Logic Procede de controle d'integrite d'execution de programmes par verification d'empreintes de traces d'execution
WO2005073859A3 (fr) * 2003-12-31 2006-04-20 Trusted Logic Procede de controle d'integrite d'execution de programmes par verification d'empreintes de traces d'execution
FR2864655A1 (fr) * 2003-12-31 2005-07-01 Trusted Logic Procede de controle d'integrite de programmes par verification d'empreintes de traces d'execution
US7882396B2 (en) 2003-12-31 2011-02-01 Trusted Logic Method for controlling program execution integrity by verifying execution trace prints
WO2006024903A1 (fr) * 2004-08-30 2006-03-09 Axalto Sa Verification d'integrite d'un code d'application pendant l'execution d'une machine virtuelle
US8161293B2 (en) 2005-04-20 2012-04-17 Stmicroelectronics S.A. Protection of the execution of a program executed by an integrated circuit
FR2886027A1 (fr) * 2005-05-20 2006-11-24 Proton World Internatinal Nv Detection d'erreur de sequencement dans l'execution d'un programme
EP1870829A1 (fr) 2006-06-23 2007-12-26 Microsoft Corporation Protéger les logiciels en imposant l'intégrité du flux des données
US9390261B2 (en) 2006-06-23 2016-07-12 Microsoft Technology Licensing, Llc Securing software by enforcing data flow integrity
US8843761B2 (en) 2007-08-16 2014-09-23 Siemens Aktiengesellschaft Method and apparatus for protection of a program against monitoring flow manipulation and against incorrect program running
CN107194258A (zh) * 2017-04-06 2017-09-22 珠海格力电器股份有限公司 监测代码漏洞的方法、装置及电子设备、存储介质
CN111427723A (zh) * 2020-03-19 2020-07-17 阳光电源股份有限公司 基于AutoSAR的程序流监控方法及应用装置
CN111427723B (zh) * 2020-03-19 2023-05-30 阳光电源股份有限公司 基于AutoSAR的程序流监控方法及应用装置

Also Published As

Publication number Publication date
ATE232616T1 (de) 2003-02-15
CN1350675A (zh) 2002-05-22
EP1161725B1 (fr) 2003-02-12
EP1161725A1 (fr) 2001-12-12
US7168065B1 (en) 2007-01-23
FR2790844B1 (fr) 2001-05-25
DE60001393T2 (de) 2003-12-11
AU3058900A (en) 2000-09-28
JP4172745B2 (ja) 2008-10-29
JP2002539523A (ja) 2002-11-19
DE60001393D1 (de) 2003-03-20
FR2790844A1 (fr) 2000-09-15
MXPA01009056A (es) 2002-04-24

Similar Documents

Publication Publication Date Title
EP1161725B1 (fr) Procede de surveillance du deroulement d'un programme
EP1702268B1 (fr) Procede de controle d'integrite d'execution de programmes par verification d'empreintes de traces d'execution
FR2704341A1 (fr) Dispositif de protection des clés d'une carte à puce.
FR2612316A1 (fr) Carte a circuits integres ayant une capacite de verification d'erreur interne
EP1904946B1 (fr) Detection d'une faute par perturbation longue
EP1605333A1 (fr) Contrôle de l'exécution d'un programme
FR2849226A1 (fr) Procede et dispositif de securisation de l'execution d'un programme informatique.
EP2453356B1 (fr) Procédé, programme d'ordinateur et dispositif de sécurisation de code intermédiaire de programmation pour son exécution par une machine virtuelle
FR2879320A1 (fr) Carte a puce a circuit integre et procede pour detecter si des donnees en memoire dans une telle carte ont ete compromises
EP1960934A1 (fr) Procede pour securiser l'execution d'un code logiciel en langage intermediaire dans un appareil portatif
FR2864654A1 (fr) Procede de determination de caracteristiques operationnelles d'un programme
WO2007010009A2 (fr) Integrite materielle permanente des donnees
FR2765363A1 (fr) Procede et systeme de controle de l'utilisation d'un logiciel
EP1507185A1 (fr) Méthode et dispositif de protection contre l'accès non-autorisé à une routine sensible
EP2375358A1 (fr) Compteur d'événements dans un système adapté au langage JavaCard
EP3284206B1 (fr) Procédé de sécurisation de l' exécution d'un programme
WO2006067319A1 (fr) Procede et dispositif de remplissage de securisation d'une memoire et memoire associee
FR2808360A1 (fr) Procede de contre mesure dans un microcircuit mettant en oeuvre le procede et carte a puce comportant ledit microcircuit
EP3295297B1 (fr) Procede de securisation d'une comparaison de donnees lors de l'execution d'un programme
EP1770524A2 (fr) Détection d'erreur de séquencement dans l'exécution d'un programme
EP4086801B1 (fr) Procédé d'exécution d'une fonction, sécurisé par désynchronisation temporelle
EP3514749B1 (fr) Procede de controle de regles de dependances d'objets mis a jour dans un microcircuit, et dispositif correspondant
WO2007006887A1 (fr) Protection contre les attaques par generation de fautes sur les instructions de saut
WO2012172245A1 (fr) Transfert securise entre memoire non-volatile et memoire volatile
FR3147397A1 (fr) Système informatique configuré pour exécuter un programme d’ordinateur

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 00807379.1

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2000900650

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2000 604312

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: PA/a/2001/009056

Country of ref document: MX

WWE Wipo information: entry into national phase

Ref document number: 09936174

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2000900650

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWG Wipo information: grant in national office

Ref document number: 2000900650

Country of ref document: EP