[go: up one dir, main page]

WO2004066127A1 - Procede et dispositif de securisation de l'execution d'un programme informatique - Google Patents

Procede et dispositif de securisation de l'execution d'un programme informatique Download PDF

Info

Publication number
WO2004066127A1
WO2004066127A1 PCT/FR2003/003658 FR0303658W WO2004066127A1 WO 2004066127 A1 WO2004066127 A1 WO 2004066127A1 FR 0303658 W FR0303658 W FR 0303658W WO 2004066127 A1 WO2004066127 A1 WO 2004066127A1
Authority
WO
WIPO (PCT)
Prior art keywords
instructions
instruction
execution
signature
sig1
Prior art date
Application number
PCT/FR2003/003658
Other languages
English (en)
Inventor
Jean-Bernard Fischer
Paul Dischamp
Original Assignee
Oberthur Card Systems S.A.
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 Oberthur Card Systems S.A. filed Critical Oberthur Card Systems S.A.
Priority to US10/540,219 priority Critical patent/US9092618B2/en
Priority to AU2003296805A priority patent/AU2003296805A1/en
Publication of WO2004066127A1 publication Critical patent/WO2004066127A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/073—Special arrangements for circuits, e.g. for protecting identification code in memory
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/073—Special arrangements for circuits, e.g. for protecting identification code in memory
    • G06K19/07309—Means for preventing undesired reading or writing from or onto record carriers
    • G06K19/07363—Means for preventing undesired reading or writing from or onto record carriers by preventing analysis of the circuit, e.g. dynamic or static power analysis or current analysis

Definitions

  • the present invention relates to a method and a device for securing the execution of a computer program.
  • It also relates to a device for processing a computer program which can be secured with a method or a device in accordance with the present invention.
  • the method and the security device according to the invention can in particular, but not limited to, be used to secure the execution of a program on a microcircuit card.
  • the reliability of the progress of a computer program in particular that of a program running in a very disturbed environment, (such as a satellite) or that of a computer program with high reliability requirements such as for example a control program of 'a heart implant.
  • the present invention makes it possible in particular to detect an attack intended to modify the flow of the execution of a computer program executing in a microcircuit card.
  • document WO 00/65442 discloses a mechanism for protecting the core of a processor against external manipulation. This document describes a method for securing a computer program consisting, during the execution of a first instruction, in calculating a first value from the content of the processor registers, then a second value according to the same principle just before the execution of the immediately following instruction. By comparing these two values, this method makes it possible to detect a possible attack which would have been committed in the time interval elapsing between the end of the first instruction and the start of the following execution, that is to say during a moment of processor idle.
  • This security method nevertheless has two drawbacks: First of all, it does not allow the detection of an attack which would occur during the execution of an instruction or during the loading (FETCH) of the code of an instruction in a calculation register of the processor.
  • this method requires that the detection of a potential attack consecutive to an instruction be carried out even before the execution of the following instruction, because the execution of this next instruction would necessarily change the value of the processor registers and therefore the value.
  • the present invention relates to a method for securing the execution of a computer program comprising a set of at least one instruction.
  • signature any information representative of predetermined operations carried out by a processor during the execution of a set of computer instructions.
  • the security method according to the invention is characterized in that it comprises: a first step of calculation and storage, prior to the execution of the computer program, of a first signature representative of the expected execution of the set of instructions;
  • a step of detecting an anomaly in the execution of the set of instructions from the first and second signatures a step of detecting an anomaly in the execution of the set of instructions from the first and second signatures.
  • the first step of calculation and storage takes place during the generation of the instructions of the computer program.
  • this first step of calculation and storage can be carried out from the assembler code of the instructions of the computer program or from the compiled code or the executable code of this program.
  • the first signature is calculated and stored at the time of the generation of the computer program. The value of this first signature, representative of the normal execution of the program is therefore known.
  • a second signature is calculated representative of the actual execution of the instructions of the program. This second signature is also memorized.
  • the second signature would be different from the first.
  • the storage of the second signature is kept during the execution of at least one second instruction consecutive to the set of instructions.
  • the detection of the execution anomaly can be carried out later, including after the execution of several instructions consecutive to the set of instructions.
  • This embodiment also advantageously makes it possible to carry out the detection of an attack at any time during the execution of the program, which makes an attack on this detection proper very difficult.
  • the first and second signatures are obtained from the number of instructions in the instruction set.
  • the security method makes it possible to detect an unexpected jump in the execution of the computer program.
  • the first signature is the number of instructions in the instruction set
  • the second signature is the number of instructions in the instruction set having been executed at a given time.
  • the detection step detecting an execution anomaly when at the end of the execution of the set of instructions the first and the second signature differ.
  • the detection step detects an anomaly only when the second signature is strictly less than the first signature. This advantageously makes it possible to detect an anomaly only in the case where a minimum number of instructions has not been executed.
  • the first and second signatures are constituted by the number of instructions in the set of instructions and the arguments of these instructions.
  • the second signature is obtained from the number of instructions in the set of instructions that have not been executed.
  • This second signature can be obtained by subtracting from the first signature stored during the first calculation and storage step, the number of instructions having already been executed by the processor.
  • the detection step detects an anomaly when at the end of the execution of the set of instructions, the second signature is non-zero.
  • the first signature is equal to the number of instructions in the set of instructions increased by the number of arguments of these instructions, the second signature being equal to the number of instructions already executed increased by the number of arguments of these instructions.
  • an instruction of the computer program is triggered when the second signature is less than a predetermined threshold.
  • the first and the second signatures are kept in memory during the execution of the program, in the same register.
  • This embodiment is advantageous because it saves a memory register.
  • the first signature is obtained from the code of a critical instruction from the set of instructions;
  • the second signature is obtained from the code of the critical instruction, this code being stored simultaneously or following the execution of this critical instruction;
  • the detection step detects an execution anomaly when, at the end of the execution of the set of instructions, the first and second signatures are different.
  • this instruction code is, in practice, the machine code of the instruction recognized by the processor.
  • these signatures can for example be constituted by the instruction code and its arguments.
  • This second preferred embodiment makes it possible to verify that the critical instruction has actually been executed during the execution of the computer program.
  • the first signature is obtained from the address of a critical instruction of the set of instructions, this address being obtained during or after the generation of the executable code of the set of instructions;
  • the second signature is obtained from the address of this critical instruction, this address being stored simultaneously or following the execution of this critical instruction;
  • the detection step detects an execution anomaly when, at the end of the execution of the set of instructions, the first and second signatures are different.
  • the first and second signatures can for example consist of the address of the instruction itself, this address can be supplemented by the address of an argument of this instruction.
  • the critical instruction can be a jump instruction, such as for example the instructions JMP, JNZ, CJNE, JZ in assembly language.
  • the first and second signatures are error detector codes calculated from the code or the address of at least one instruction from the set of instructions.
  • the detection step detects an execution anomaly when, after the execution of the set of instructions, the first and second signatures are different.
  • This preferred embodiment is particularly advantageous when it is desired to verify that several instructions from the set of instructions have been executed, these instructions being able in particular not to be consecutive in this set.
  • the error detector codes are obtained by logical combination of the instruction codes, for example a logical exclusive OR (XOR).
  • XOR logical exclusive OR
  • the aforementioned error detector codes are cyclic redundancy codes (CRC), this embodiment being both particularly easy to implement and of rapid execution.
  • CRC cyclic redundancy codes
  • the first and second signatures are obtained, respectively during the generation and execution of said instructions, from at least two elements obtained from:
  • the detection step detects an execution anomaly when, at the end of the execution of the set of instructions, the first and the second signatures are different.
  • the first and second signatures of this fifth embodiment thus combine the advantages of the signatures described briefly above with reference to four first embodiments.
  • the security method further comprises a step of destroying at least part of the system on which the computer program is running, this destruction step being carried out when the detection step detects a execution anomaly.
  • the destruction step can for example destroy the operating system of the microcircuit card; the microcircuit card then becomes unusable after detection of an attack.
  • the first signature is generated automatically, for example by a software engineering tool. This characteristic advantageously makes it possible to simplify the work of the developer of the computer program to be secured.
  • the present invention relates to a device for processing a computer program comprising a set of at least one instruction and characterized in that it comprises: means of calculation and storage, prior to said execution, a first signature representative of the expected execution of said set of instructions.
  • This processing device allows the automatic generation of the first signature of the computer program.
  • this error detector code can be a cyclic redundancy code.
  • the present invention relates to a device for securing the execution of a computer program comprising a set of at least one instruction.
  • This security device comprises: - a first register for storing a first signature representative of the expected execution of the set of instructions;
  • the invention also relates to a smart card comprising a security device as briefly described above.
  • a smart card comprising a security device as briefly described above.
  • the advantages of the processing device, the security device and the smart card according to the invention being identical to those of the security method described above, they will not be repeated here.
  • FIG. 1 shows the main steps of a method for securing the execution of a computer program according to the invention in a particular embodiment
  • FIG. 2 shows schematically a device for processing a computer program in accordance with the present invention in a particular embodiment
  • FIG. 3 shows a device for securing a computer program according to the invention in a preferred embodiment.
  • Appendix A includes the assembler code for a computer program A. This assembler code includes 13 instructions marked A1 to A13.
  • the value 101 is stored in the register opcode_count.
  • This instruction is followed by an A2 instruction during which the opcode_start bit is initialized with the value 1, which triggers the automatic decrementing of the opcode_count register with each new instruction executed.
  • the instruction A2 is followed by three instructions A3, A4, A5 during which the messagel value is stored respectively in the register r0, the message2 value in the register r1 and the value 16 in the register r2.
  • Instruction A5 is then followed by a "loop_round_i" loop constituted by instructions A6 to A11.
  • the data pointed to by the address contained in the register r1 is stored in a register a.
  • the A6 instruction is followed by an A7 instruction during which the logical exclusive OR operation "XOR" between the content of the register a and the data pointed by the address contained in the register rO.
  • the instruction A7 is followed by an instruction A8 during which the data pointed to by the address contained in the register r0 is replaced by the content of the register a.
  • the instruction A8 is followed by two instructions A9 and A10 during which the content of the registers r0 and r1 is respectively incremented by one.
  • the instruction A10 is followed by an instruction A11 during which the content of the register r2 is decremented by one and it is tested whether the content of the register r2 thus decremented is zero.
  • the instruction A11 is followed by the instruction A6 described above.
  • A11 is followed by the instruction A12 during which the content of the opcode_start bit is modified with the value 0, which interrupts the automatic decrementation of the opcode_count counter.
  • the instruction A12 is followed by the instruction A13 during which the content of the register opcode_count is decremented, then the content of this register is tested.
  • the processor executing the computer program comprises means adapted to decrement this counter each time FETCH is loaded with the code of an operation. This counter is stopped by setting the opcode_start bit to zero at instruction A12.
  • this computer program A is secured in accordance with the invention.
  • a first signature of value 101 has been calculated and stored, this first signature being representative of the number of instructions that the computer program A must normally execute when the opcode_start bit is positioned at 1, that is to say between the instructions A3 and A12. If the program is running normally, the instructions executing between instructions A3 and A12 are:
  • the register opcode_start therefore contains if the program is executed normally, the value 1, (101 - 100).
  • the register opcode_count is decremented.
  • the opcode_count register should then normally contain the value 0. If this is not the case, this means that all the instructions of the program were not executed, or that unexpected instructions were executed.
  • the value 101 stored in the opcode_count register at the instruction A1 is a first signature representative of the execution of the set of instructions A2 to A13 calculated, for example, by the programmer or automatically at time of generation of this set of instructions.
  • the opcode_count register is decremented during the execution of each instruction. He thus memorizes a second signature equal to the number of instructions provided and which have not been executed, this second signature being calculated by difference from the first signature 101.
  • the instruction A13 constitutes a step for detecting an execution anomaly during which it is checked whether the content of the opcode_count register is zero, after decrementing this register. If the value of this register is non-zero, this means either that at least one of the planned instructions has not been executed, or that an unexpected instruction has been executed, which in any case constitutes an anomaly.
  • a software interrupt is triggered when the counter becomes strictly negative. This advantageously allows the detection of an attack which would have the effect of not executing the instruction A13 for detection and the instruction A12 for stopping the counter.
  • the instructions A12 for stopping the counter and A13 for detection can be combined into a single instruction added to the instruction set of the processor. It is then even more difficult to carry out an attack consisting in stopping the counter and bypassing the detection instruction.
  • Annex B contains the assembly code for another computer program B.
  • the processor which executes the program B comprises a register SFRJDPH which contains the operation code of the last instruction executed. During a first instruction B1, the XRL operation is carried out
  • Instruction B1 is followed by instruction B2 during which the program connects to the label "false_result" if the contents of registers A and R1 differ.
  • the instruction B2 is followed by an instruction B3 during which stores in the register R5 the content of the register SFR_OPH, ie the operation code of the last instruction executed (B2) before the instruction being executed (B3).
  • the register R5 contains the code of the instruction JNZ, that is to say 70h.
  • Instruction B3 is then followed by three instructions B4 to B6 during which, respectively, we store in register A the value of register R7, we perform a logical OR between the contents of register A and the hexadecimal value 55h and we store in the register R7 the new content of the value A.
  • the instruction B6 is followed by an instruction B7 during which the content of the register R5 is stored in the register A.
  • the register A contains the code 70h of the operation JNZ if the instruction B2 has been executed previously with the instruction B3.
  • the instruction B7 is followed by an instruction B8 during which a logical exclusive OR is carried out between the content of the register A and the value 70h of the code of the instruction JNZ.
  • the instruction B9 following the instruction B8 connects the program B to a routine "os_kill_card” for destroying the operating system of the microcircuit card.
  • the program makes it possible to verify, in accordance with the securing method according to the invention that the critical instruction B2 has actually been executed.
  • Step B9 constitutes a step for detecting an execution anomaly, an anomaly being detected if the first signature and the second signature differ.
  • Appendix C contains the assembly code for another computer program C.
  • each instruction of program C comprises in the first column the address of this instruction.
  • the address of the C1 instruction is 0x8500.
  • the processor which executes the program C includes a register SFR_JMP which stores the address of the last instruction which executed a jump (JMP, JNZ, CJNE, ).
  • the logic exclusive XRL is carried out between the content of register A and that of register R1.
  • the C1 instruction is followed by a C2 instruction during which a jump to the “continue” label is performed if the result of the previous C1 instruction differs from the value 0.
  • the computer program C connects to the label "continue” if the values of the registers A and R1 differ.
  • the processor automatically stores the address 0x8501 of the jump instruction JNZ (C2) in the predetermined register SFR_JMP, consisting of an upper part SFR__JMPH and a lower part SFR_JMPL.
  • the program connects to the label "continue” it first executes two instructions C4 and C5 respectively during which it stores in the content of the A register the value 25 and adds to the content of this A register the value 34.
  • Code_secret it firstly executes two instructions C7 and C8 during which the contents of the upper part SFR_JMPH and the lower part SFR_JMPL of the content of the register SFR_JMP are stored in the registers A and R5 respectively.
  • the contents of the registers A and R5 must respectively contain the values 85 and 03, corresponding to the upper and lower parts of the address 0x8503.
  • the instruction C8 is then followed by two instructions C9 and C10 during which it is checked whether the content of the registers A and R5 is respectively equal to 85H and 03H. If this is not the case, the computer program executes a routine "os_kill_card" to destroy the operating system of this computer program.
  • the C11 instruction is followed by a C12 instruction to end the execution of the program C.
  • the first signatures constituted by the values 85H and 03H constituting the address of the instruction C3 have been calculated and stored.
  • a second signature was stored by loading into the registers A and R5 the content of the register SFR_JMP, this register having to contain the value 0x8503 if the program C has executed normally.
  • the instructions C9 and C10 constitute the steps for detecting an execution anomaly, these steps consisting in comparing the content of the registers A and R5, namely the second signature, with the first signature stored at the time of the generation of the program, namely the address of the instruction C3.
  • the security method described here makes it possible to verify that when the program connects to the instruction C7 it previously executed the instruction C3, which means that the operation of the logical exclusive OR carried out at the instruction C1 has given a value null, and therefore that registers A and R1 contain an identical value.
  • the security program therefore makes it possible to verify that when entering the sub-part of the program identified by the label “code_secret”, these instructions are executed lawfully and not after an attack, in which case the value of the register SFR_JMP would be different from the value 0x8503, corresponding to the address of the C3 instruction.
  • the computer program C includes other instructions similar to the instructions C9 and C10, these instructions comprising, in place of the values 85H and 03H, the lower and upper parts of the addresses of other jump instructions, which makes it possible to secure, according to the principle described above, a program comprising several instruction jumps.
  • Appendix D contains the assembly code of another computer program D. For easier description, the instructions in lines D2 to D12 U i ⁇ "v";' compensated ⁇ - -
  • the instruction code "mov r0, # messagel" is the value 78 H.
  • the bit chk_opcode_ start is initialized with the value 1.
  • the instruction D1 is followed by three instructions D2, D3, D4 during which the messagel value is stored respectively in the register r0, the message2 value in the register M, and the value 16 in the register r2.
  • the instruction D4 is then followed by a loop “loop_round_i” constituted by the instructions D5 to D10.
  • the data pointed to by the address contained in the register r1 is stored in a register a.
  • the instruction D5 is followed by an instruction D6 during which the logical exclusive OR "XRL" is carried out between the content of the register a and the data pointed by the address contained in the register rO.
  • the instruction D6 is followed by an instruction D7 during which the data pointed to by the address contained in the register rO is replaced by the content of the register a.
  • the instruction D7 is followed by two instructions D8 and D9 during which the content of the registers rO and r1 is respectively incremented by one.
  • the instruction D9 is followed by an instruction D10 during which the content of the register r2 is decremented by one and it is tested whether the content of the register r2 thus decremented is zero.
  • the instruction D10 is followed by the instruction D5 described above.
  • this "checksum" register is an error detecting code calculated from the instruction code D2 to D11.
  • the processor after the initialization (during instruction D1) of the chk_opcode_start bit with the value 1, the processor performs the logical exclusive OR between the code of the following instructions and stores the result of this operation in the checksum register.
  • the content of the checksum register is equal to 78h.
  • the content of the checksum register is equal to the logical exclusive OR between the values 78h and 79h, ie 01.
  • the checksum register contains a signature representative of the instructions which have been executed after the execution of the instruction D1.
  • the content of the checksum register at the end of the last execution of the instruction D10 is equal to 7Bh.
  • the D11 instruction is followed by a D12 instruction during which the content of the register a is compared with the hexadecimal value OFh.
  • This value OFh constitutes, according to the terms of the present invention, a first signature calculated and stored in a memory register comprising the program D, this first signature being representative of the expected execution of the instructions D2 to D11.
  • the program D calls a routine for processing execution anomalies "kill_card”.
  • This instruction D12 thus constitutes a step of detecting an anomaly in the execution of the instructions D2 to D11 from the first signature OFh and the second signature stored in the checksum register. ⁇ v ui i ⁇ uo / "J 0 3
  • the "kill_card” processing routine is a routine making the use of the microcircuit card impossible.
  • FIG. 1 represents the main steps E10 to E80 of a security method in accordance with the present invention in a preferred embodiment.
  • the security method makes it possible to secure the execution of an EXE computer program whose SOURCE source code is written in assembly language.
  • This is for example a source code similar to those described above with reference to appendices A to D.
  • the security method according to the invention comprises two series of steps, namely a first series composed of steps E10 to E30 of generation of the executable code of the computer program from the SOURCE source code and a second series of steps consisting of steps E40 to E80 of executing the computer program EXE.
  • the source code SOURCE of the program to be secured is read.
  • This step of reading a source code is known to those skilled in the art. It can be implemented by an assembler or compiler.
  • step E10 of reading the source code is followed by a step E20 during which the executable code EXE of the computer program is generated.
  • This step is known to those skilled in the art. It can in particular be implemented by a compiler.
  • the step E20 of generation of the executable code EXE is followed by a step E30 of calculation and storage of a first signature SIG1 representative of the expected execution of a set of instructions of the computer program to be secured.
  • this first signature SIG1 representative of the expected execution of a set of instructions of the computer program to be secured.
  • SIG1 is stored in a register REG0 of the ROM ROM comprising the executable computer program EXE.
  • this step E30 of calculating and storing a first signature SIG1 is carried out during the reading of the source code E10.
  • this step E30 of calculating and storing a first signature SIG1 is carried out during the step of generating the executable code E20. This is particularly the case, when this first signature is obtained from the address of a critical instruction of the computer program.
  • This first step E30 of calculation and storage can be carried out in different ways.
  • the first signature SIG1 is the number of instructions whose execution is to be secured.
  • this step consists in counting the number of operation codes of the instructions of the set of instructions to secure.
  • this step consists first of all in generating an assembler program from the high level source code, then, counting the number d 'assembly instructions thus generated.
  • the first signature is the number 101 stored in a register REG0 of the memory comprising the executable code of the program A.
  • the first signature is the code of a critical instruction from the set of instructions.
  • the first signature is the code 70h of the JNZ instruction. This first signature is stored in a REGO register in the memory of the executable program B.
  • the first signature is the address of a critical instruction of the set of instructions, this address being obtained during or after the generation of the executable code of the instruction set.
  • this first signature is the value 0x8503 corresponding to the address of the instruction C3, this address being stored in registers of the memory comprising the executable code of the program C, these registers being associated with instructions C9 and C10.
  • the first signature is an error detecting code calculated from the code of at least one instruction from the set of instructions to be secured.
  • This signature can for example be a logical combination of the instruction codes to be secured.
  • This first signature can also be, in a preferred embodiment of this variant embodiment, a cyclic redundancy code obtained from these instruction codes, or by logical combination (XOR) of these instruction codes.
  • Step E30 is followed by a step E40 during which the execution of the computer program EXE begins.
  • this computer program EXE is stored in a ROM ROM, a REGO register of which includes the first signature SIG1 calculated in step E20.
  • step E40 of the start of execution of the computer program is followed by a step E45 during which the content SIG1 of the REGO register of ROM read-only memory in a REG1 register of RAM used by the EXE computer program.
  • the copy step E45 is followed by a step E50 during which a second signature SIG2 is calculated and stored in a register REG2 of the RAM, this second signature SIG2 being representative of the actual execution of the set of instructions to memorize.
  • This second signature is calculated during the execution of the set of instructions. It is for example the number of instructions having been executed at a given instant or the number of instructions remaining to be executed as described previously with reference to appendix A.
  • step E50 of calculation and storage of the second signature SIG2 is performed by calculating the error detecting code as and when the instructions in question are executed.
  • step E50 of calculation and storage of a second signature SIG2 makes it possible to store the second signature in a register REG2 of the RAM memory executing the computer program EXE.
  • this register REG2 is kept during the execution of at least one second instruction consecutive to the set of instructions to be secured.
  • the step E50 of calculating and storing a second signature SIG2 is followed by a test E60 for detecting an anomaly in the execution of the set of instructions from the first and second signatures, respectively SIG1 and SIG2.
  • any number of instructions can be executed between step E50 and the test E60.
  • This test E60 for detecting an anomaly consists in verifying whether the value of the second signature SIG2 is in agreement with the value of the first signature SIG1 calculated and stored during the generation of the computer program, which means that the instructions to secure were executed according to plan.
  • the test E60 for detecting an execution anomaly can notably consist in comparing the signatures SIG1 and SIG2 when these signatures are:
  • an error detecting code CRC1 for example a cyclic redundancy code calculated from the operating codes of a certain number of instructions and the error detecting code CRC2, for example a cyclic redundancy code calculated from of a set of instructions actually executed.
  • this step E60 of detecting an execution error consists in comparing the number of instructions remaining to be executed with the value zero.
  • this test is followed by a step E70 of processing this anomaly.
  • This step E70 may in particular consist of a step of destroying part of the computer system in which the computer program is executed, for example the destruction of the operating system, which makes the microcircuit card unusable in the event of detection of 'a malicious attack.
  • the processing step E70 is implemented only when several anomalies have been detected during the different uses of the card.
  • a register is then used in which the number of anomalies will be accumulated, possibly depending on their nature.
  • the processing step E70 consists in resetting the computer system in which the computer program is executed, for example by a reset command.
  • step E70 of processing an anomaly can consist in sending a simple information message intended for the user of the device.
  • This variant embodiment is particularly advantageous when the security method according to the invention is used to make the progress of a computer program more reliable (satellite, control of a cardiac implant).
  • This step E70 completes the security method according to the present invention described here.
  • FIG. 2 schematically represents a device for processing a computer program in accordance with the present invention in a preferred embodiment.
  • the processing device 10 comprises means 11 for editing the SOURCE computer program.
  • These editing means 11 comprise in particular selection means, for example a keyboard, a mouse and a word processor, making it possible to select, in the SOURCE computer program, the instructions to be secured. These editing means 11 also make it possible to introduce into the SOURCE computer program, automatically or manually, specific instructions for the calculation and storage of the second signature SIG2, this second signature SIG2 being calculated during execution. instructions to be secured. These editing means 11 also make it possible to introduce into the SOURCE computer program an instruction making it possible to implement the step of detecting an anomaly.
  • the device 10 for processing a computer program comprises means 12 for calculating and storing, during the generation of the instructions, of a first signature SIG1 representative of the expected execution of the set of instructions selected by the editing resources 11.
  • These means 12 of calculation and storage are, in known manner, adapted to read the computer program SOURCE. They are particularly suitable for reading a computer program such as those given in appendices A to D.
  • the processing device 10 comprises means 14 for generating an executable code from the source computer program.
  • These means 14 for generating an executable code are in particular adapted to obtain and store the addresses of the instructions. critical to secure in the executable code from the SOURCE computer program.
  • the calculation and storage means 12 are adapted, in a preferred embodiment, to count the number of instructions selected and the number of arguments of these instructions by the editing means 11, and to store this value in a register.
  • This value constitutes a first signature SIG1 in accordance with the present invention.
  • the calculation and storage means 12 are also adapted to store the operation code of a critical instruction selected by the editing means 11.
  • the means 12 of calculation and storage are adapted to calculate an error detector code, for example a cyclic redundancy code or a logical combination (XOR) from the code of the instructions selected by the means 11 editing.
  • the register REG1 for storing the first signature SIG1 can also be selected by the editing means 11.
  • the processing device generates a computer program EXE capable of being executed later and associated with a REGO register storing a signature SIG1 representative of the expected execution of the instructions selected by the editing means 11.
  • the device 100 for securing the microcircuit card C according to the invention described here comprises a register REG1 for storing a first signature SIG1 representative of the expected execution of a set instructions to be secured, this signature having been calculated and stored by a processing device 10 of the type described above with reference to FIG. 2.
  • the securing device 100 also comprises means 22 for calculating and storing during the execution of the set of instructions a second signature SIG2 representative of the actual execution of the instructions, this storing being carried out in a second storage register REG2.
  • the means 22 of calculation and storage are adapted to count the number of instructions of the set of instructions having been executed, or those not yet executed, by comparison with the signature SIG1.
  • the means 22 for calculating and storing comprise means for triggering an interruption of the computer program EXE when the second signature SIG2 is less than a predetermined threshold.
  • the instructions of the set of instructions to be secured are those executing while the opcode_start bit is set to 1, ie between the execution of instructions A2 and A12 inserted in the computer program SOURCE by the editing means 11 of the generation device 10 described with reference to FIG. 2.
  • the means 22 for calculating and storage decrement the counter opcode_count contained in the second register REG2.
  • this operation is carried out by the processor during the FETCH instruction.
  • the calculation and storage means 22 store in the register REG2 the code or the address of the last instruction executed. This can be done as described above, respectively with reference to instructions D7, C7 and C8 of appendices B and C.
  • the calculation and storage means 22 calculate an error detecting code from the code or from an address of at least one instruction from the set of instructions.
  • the calculation of the error detector code is carried out by the processor which executes the computer program to be secured at the time of loading into memory of the selected instructions using the means 11 for selecting the processing device according to the invention.
  • the error detector code is a cyclic redundancy code CRC2 or a logical combination (XOR) calculated from the codes or addresses of these instructions.
  • the securing device 100 also includes means 24 for detecting an execution anomaly of the set of instructions to be secured.
  • These detection means 24 consist for example of a comparator of registers REG1 and REG2.
  • This preferred embodiment makes it possible to detect in particular a difference between the signatures SIG1 generated and stored by the generation device 10 according to the invention and the signature SIG2 calculated and stored in the register REG2 by the means 22 for calculating and memorizing the security device 100.
  • the means 24 for detecting an anomaly are constituted by a comparator adapted to compare the content of the register REG2 for storing the second signature with the value 0.
  • This preferred embodiment is easy to implement; it makes it possible to detect that all the instructions to be secured have been executed, as previously described with reference to appendix A.
  • the means 22 of calculation and storage are adapted to keep the second signature in the second register REG2 during the execution of at least one instruction consecutive to the set of instructions to be secured.
  • the second register REG2 can for example be a dedicated register of a volatile memory RAM of the security device 100, this volatile memory register being overwritten by the means 24 for detecting an anomaly after comparison of the first and second signature.
  • the first SIG1 and second signatures SIG2 are stored in the same register REG1 of the RAM memory during the execution of the computer program EXE.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Storage Device Security (AREA)
  • Executing Machine-Instructions (AREA)

Abstract

Procédé de sécurisation de l'exécution d'un programme informatique comportant un ensemble d'au moins une instruction, caractérisé en ce qu'il comporte : une première étape de calcul et de mémorisation, préalable à l'exécution dudit programme informatique, d'une première signature représentative de l'exécution attendue dudit ensemble d'instructions; une deuxième étape de calcul et de mémorisation, au cours de l'exécution dudit ensemble d'instructions, d'une deuxième signature représentative de l'exécution dudit ensemble d'instructions ; et une étape de détection d'une anomalie d'exécution dudit ensemble d'instructions à partir desdites première et deuxième signatures.

Description

Procédé et dispositif de sécurisation de l'exécution d'un programme informatique
La présente invention se rapporte à un procédé et à un dispositif de sécurisation de l'exécution d'un programme informatique.
Elle se rapporte également à un dispositif de traitement d'un programme informatique pouvant être sécurisé avec un procédé ou un dispositif conforme à la présente invention.
Le procédé et le dispositif de sécurisation conformes à l'invention peuvent notamment, mais de façon non limitative être utilisés pour sécuriser l'exécution d'un programme sur une carte à microcircuit.
Dans la suite de ce document on entendra par « sécurisation » d'un programme informatique :
- la détection d'attaques mal intentionnées visant à modifier le comportement normal d'un programme informatique ; mais aussi
- la fiabilisation du déroulement d'un programme informatique notamment celle d'un programme s'exécutant dans un environnement très perturbé, (comme un satellite) ou celle d'un programme informatique à forte exigence de fiabilité comme par exemple un programme de contrôle d'un implant cardiaque.
La présente invention permet en particulier de détecter une attaque destinée à modifier le déroulement de l'exécution d'un progamme informatique s'exécutant dans une carte à microcircuit.
Elle permet en particulier de détecter des attaques par perturbation du fonctionnement de la carte à microcircuit, souvent appelées DFA (de l'anglais "Differential Fault Analysis").
Ces attaques visent à modifier illicitement le contenu d'un registre, d'une mémoire ou d'un bus, ou à obliger un processeur à ne pas exécuter certaines instructions du programme informatique. Dans ce cas, le programme informatique attaqué peut se dérouler d'une façon très différente de celle qui avait été prévue au moment de sa conception. Elles peuvent, entre autres et de façon connue, être effectuées :
- en générant un pic de tension à l'une des bornes d'alimentation du processeur ;
- en élevant brusquement sa température; - en changeant rapidement sa fréquence d'horloge ou sa tension d'alimentation ;
- en appliquant un flash de lumière ou un rayon laser sur une partie du silicium qui le compose.
Selon l'état actuel de la technique, l'homme du métier dispose de différents moyens pour lutter contre les attaques DFA.
Il existe en particulier dans la plupart des composants des cartes à microcircuit, des capteurs qui permettent de détecter de telles attaques. Leur efficacité est néanmoins restreinte car il est en pratique impossible de mettre des capteurs sur toute la surface de ce composant. Par ailleurs ces capteurs étant également composés de silicium, il est possible de les perturber ou de modifier les informations qu'ils transmettent. On connaît d'autre part, par le document WO 00/65442 un mécanisme de protection du cœur d'un processeur contre des manipulations externes. Ce document décrit un procédé de sécurisation d'un programme informatique consistant, au cours de l'exécution d'une première instruction, à calculer une première valeur à partir du contenu des registres du processeur, puis une deuxième valeur selon le même principe juste avant l'exécution de l'instruction immédiatement suivante. Par comparaison de ces deux valeurs, ce procédé permet de détecter une attaque éventuelle qui aurait été commise dans l'intervalle de temps s'écoulant entre la fin de la première instruction et le début de l'exécution suivante, soit pendant un moment d'inactivité du processeur.
Ce procédé de sécurisation présente néanmoins deux inconvénients : Tout d'abord, il ne permet pas la détection d'une attaque qui se produirait au cours de l'exécution d'une instruction ou pendant le chargement (FETCH) du code d'une instruction dans un registre de calcul du processeur.
En effet, si les registres du processeur restent inchangés entre deux instructions consécutives, ce procédé ne détectera pas d'anomalie, même si ces registres contiennent une valeur illicite, due par exemple à une attaque au cours de la première instruction, juste avant le calcul de la première valeur.
D'autre part, le résultat de calcul de la première valeur étant a priori inconnu, ce procédé impose que la détection d'une attaque potentielle consécutive à une instruction soit effectuée avant même l'exécution de l'instruction suivante, car l'exécution de cette instruction suivante modifierait nécessairement la valeur des registres du processeur et donc la valeur.
Ainsi, seule une attaque se produisant entre deux instructions peut être détectée, mais pas un déroulement inattendu du programme, comme par exemple un saut illicite.
En particulier, il ne permet pas de mémoriser l'historique des instructions ayant été exécutées avant une instruction sensible, c'est-à-dire une instruction dont l'attaque met en péril la sécurité, comme par exemple des instructions de comparaison de données secrètes lors de la vérification d'un code secret (PIN). Cet inconvénient est particulièrement gênant car il empêche de se prémunir contre une attaque par perturbation du processeur, par exemple de type DFA, qui forcerait le processeur à exécuter cette instruction sensible sans exécuter les instructions préalables prévues.
Plus précisément, et selon un premier aspect, la présente invention concerne un procédé de sécurisation de l'exécution d'un programme informatique comportant un ensemble d'au moins une instruction.
Dans la suite de ce document on conviendra d'appeler "signature", toute information représentative d'opérations prédéterminées effectuées par un processeur lors de l'exécution d'un ensemble d'instructions informatiques. Le procédé de sécurisation selon l'invention est caractérisé en ce qu'il comporte : - une première étape de calcul et de mémorisation, préalable à l'exécution du programme informatique, d'une première signature représentative de l'exécution attendue de l'ensemble d'instructions;
-une deuxième étape de calcul et de mémorisation, au cours de l'exécution de l'ensemble d'instructions, d'une deuxième signature représentative de l'exécution de l'ensemble d'instructions ; et
-une étape de détection d'une anomalie d'exécution de l'ensemble d'instructions à partir des première et deuxième signatures.
Préférentiellement, la première étape de calcul et de mémorisation a lieu au cours de la génération des instructions du programme informatique.
Par exemple, cette première étape de calcul et de mémorisation peut être effectuée à partir du code assembleur des instructions du programme informatique ou à partir du code compilé ou du code exécutable de ce programme. Ainsi, conformément à ce premier aspect de l'invention, la première signature est calculée et mémorisée au moment de la génération du programme informatique. La valeur de cette première signature, représentative de l'exécution normale du programme est donc connue.
Lors de l'exécution du programme, on calcule une deuxième signature représentative de l'exécution réelle des instructions du programme. Cette deuxième signature est également mémorisée.
Il est donc possible, grâce à l'invention, de détecter une attaque se produisant au cours de l'exécution d'une instruction du programme ou pendant le chargement (FETCH) du code de cette instruction dans un registre de calcul du processeur.
En effet, si tel était le cas, la deuxième signature serait différente de la première.
Dans une première variante préférée de réalisation du procédé de sécurisation selon l'invention, la mémorisation de la deuxième signature est conservée pendant l'exécution d'au moins une deuxième instruction consécutive à l'ensemble d'instructions. Ainsi, la détection de l'anomalie d'exécution peut être réalisée ultérieurement, y compris après l'exécution de plusieurs instructions consécutives à l'ensemble d'instructions.
Ceci permet de façon très avantageuse de mémoriser l'historique des instructions ayant été exécutées avant une instruction sensible, et donc de détecter les attaques visant à obliger le processeur à éviter l'exécution d'un ensemble d'instructions données.
Ce mode de réalisation permet aussi avantageusement d'effectuer la détection d'une attaque à un moment quelconque de l'exécution du programme ce qui rend très difficile une attaque sur cette détection proprement dite.
Dans un premier mode préféré de réalisation, la première et la deuxième signatures sont obtenues à partir du nombre d'instructions de l'ensemble d'instructions. Selon ce premier mode préféré de réalisation, le procédé de sécurisation permet de détecter un saut inattendu dans l'exécution du programme informatique.
Selon un premier exemple de ce premier mode préféré, la première signature est le nombre d'instructions de l'ensemble d'instructions, la deuxième signature est le nombre d'instructions de l'ensemble d'instructions ayant été exécutées à un moment donné, l'étape de détection détectant une anomalie d'exécution lorsque à l'issue de l'exécution de l'ensemble d'instructions la première et la deuxième signature diffèrent.
En variante de ce premier exemple de ce premier mode préféré, l'étape de détection détecte une anomalie uniquement lorsque la deuxième signature est strictement inférieure à la première signature. Ceci permet avantageusement de ne détecter une anomalie que dans le cas où un nombre minimum d'instructions n'a pas été exécuté.
Dans un deuxième exemple de ce premier mode préféré de réalisation, la première et la deuxième signatures sont constituées par le nombre d'instructions de l'ensemble d'instructions et des arguments de ces instructions. Selon un troisième exemple de ce premier mode préféré de réalisation, la deuxième signature est obtenue à partir du nombre d'instructions de l'ensemble d'instructions n'ayant pas été exécutées.
Cette deuxième signature peut être obtenue en soustrayant à la première signature mémorisée au cours de la première étape de calcul et de mémorisation, le nombre d'instructions ayant déjà été exécutées par le processeur. Dans cette variante, l'étape de détection détecte une anomalie lorsque à l'issue de l'exécution de l'ensemble d'instructions, la deuxième signature est non nulle. Selon un quatrième exemple de ce premier mode préféré de réalisation, la première signature est égale au nombre d'instructions de l'ensemble d'instructions augmenté du nombre d'arguments de ces instructions, la deuxième signature étant égale au nombre d'instructions déjà exécutées augmenté du nombre d'arguments de ces instructions. Avantageusement, dans ces troisième et quatrième exemples du premier mode préféré de réalisation on déclenche une instruction du programme informatique lorsque la deuxième signature est inférieure à un seuil prédéterminé.
On peut ainsi détecter une exécution inattendue du programme informatique même si l'étape de détection proprement dite est rendue inefficace du fait d'une attaque visant cette étape elle-même.
Dans un mode préféré de ces troisième et quatrième exemples du premier mode de réalisation, la première et la deuxième signatures sont conservées en mémoire pendant l'exécution du programme, dans le même registre.
Ce mode de réalisation est avantageux car il permet d'économiser un registre de mémoire.
Dans un deuxième mode préféré de réalisation : - la première signature est obtenue à partir du code d'une instruction critique de l'ensemble d'instructions ; -la deuxième signature est obtenue à partir du code de l'instruction critique, ce code étant mémorisé simultanément ou consécutivement à l'exécution de cette instruction critique ; et
- l'étape de détection détecte une anomalie d'exécution lorsque, à l'issue de l'exécution de l'ensemble d'instructions, ies première et deuxième signatures sont différentes.
Préférentiellement, ce code d'instruction est, en pratique, le code machine de l'instruction reconnu par le processeur.
En variante ces signatures peuvent par exemple être constituées par le code d'instruction et ses arguments.
Ce deuxième mode préféré de réalisation, permet de vérifier que l'instruction critique a effectivement été exécutée lors de l'exécution du programme informatique.
Selon un troisième mode préféré de réalisation : -la première signature est obtenue à partir de l'adresse d'une d'instruction critique de l'ensemble d'instructions, cette adresse étant obtenue pendant ou après la génération du code exécutable de l'ensemble d'instructions;
-la deuxième signature est obtenue à partir de l'adresse de cette instruction critique, cette adresse étant mémorisée simultanément ou consécutivement à l'exécution de cette instruction critique ; et
- l'étape de détection détecte une anomalie d'exécution lorsque, à l'issue de l'exécution de l'ensemble d'instructions, les première et deuxième signatures sont différentes. Dans ce troisième mode préféré de réalisation, la première et la deuxième signatures peuvent être par exemple constituées par l'adresse de l'instruction proprement dite, cette adresse pouvant être complétée par l'adresse d'un argument de cette instruction.
Ce troisième mode préféré de réalisation permet également de vérifier que l'instruction critique a été exécutée. Dans ce troisième mode de réalisation, l'instruction critique peut être une instruction de saut, comme par exemple les instructions JMP, JNZ, CJNE, JZ en langage assembleur .
Il est ainsi possible de vérifier que des instructions en cours d'exécution ne sont pas exécutées à la suite d'une attaque sur une instruction de saut.
Selon un quatrième mode de réalisation préféré :
-les première et deuxième signatures sont des codes détecteurs d'erreur calculés à partir du code ou de l'adresse d'au moins une instruction de l'ensemble d'instructions ; et
-l'étape de détection détecte une anomalie d'exécution lorsque, à l'issue de l'exécution de l'ensemble d'instructions, les première et deuxième signatures sont différentes.
Ce mode préféré de réalisation est particulièrement avantageux lorsque l'on veut vérifier que plusieurs instructions de l'ensemble d'instructions ont été exécutées, ces instructions pouvant notamment ne pas être consécutives dans cet ensemble.
Dans un autre mode de réalisation les codes détecteurs d'erreur sont obtenus par combinaison logique des codes d'instructions, par exemple un OU exclusif logique (XOR).
De façon préférée, les codes détecteurs d'erreur précités sont des codes de redondance cycliques (CRC), ce mode de réalisation étant à la fois particulièrement facile à mettre en œuvre, et d'exécution rapide.
Dans un cinquième mode préféré de réalisation, la première et la deuxième signatures sont obtenues, respectivement au cours de la génération et de l'exécution desdites instructions, à partir d'au moins deux éléments obtenus à partir :
-du nombre d'instructions de l'ensemble d'instructions; ou
-du code d'au moins une instruction de cet ensemble d'instructions; ou
-de l'adresse d'au moins une instruction de cet ensemble d'instructions; ou - d'un code détecteur d'erreur calculé à partir du code ou d'une adresse d'au moins une instruction critique de cet ensemble d'instructions, cette adresse étant obtenue pendant ou après la génération du code exécutable de l'ensemble d'instructions. Dans ce mode préféré de réalisation, l'étape de détection détecte une anomalie d'exécution lorsque, à l'issue de l'exécution de l'ensemble d'instructions, la première et la deuxième signatures sont différentes.
Les première et deuxième signatures de ce cinquième mode de réalisation combinent ainsi les avantages des signatures décrites brièvement ci dessus en référence avec quatre premiers modes de réalisation.
Dans un autre mode préféré de réalisation, le procédé de sécurisation comporte en outre une étape de destruction d'au moins une partie du système sur lequel s'exécute le programme informatique, cette étape de destruction étant effectuée lorsque l'étape de détection détecte une anomalie d'exécution.
Ce mode de réalisation est particulièrement avantageux pour protéger la carte contre des attaques par perturbation du microcircuit, qui de façon connue ne permettent pas facilement de cibler une instruction particulière, du moins à la première tentative. Dans cette variante de réalisation, l'étape de destruction peut par exemple détruire le système d'exploitation de la carte à microcircuit ; la carte à microcircuit devient alors inutilisable après détection d'une attaque.
Dans une variante préférée de réalisation, la première signature est générée automatiquement, par exemple par un outil de génie logiciel. Cette caractéristique permet avantageusement de simplifier le travail du développeur du programme informatique à sécuriser.
Selon un deuxième aspect, la présente invention vise un dispositif de traitement d'un programme informatique comportant un ensemble d'au moins une instruction et caractérisé en ce qu'il comporte : -des moyens de calcul et de mémorisation, préalablement à ladite exécution, d'une première signature représentative de l'exécution attendue dudit ensemble d'instructions. Ce dispositif de traitement permet la génération automatique de la première signature du programme informatique.
Il peut notamment être adapté à calculer et mémoriser une première signature constituée par un élément ou une combinaison d'éléments obtenus à partir :
-du nombre d'instructions de l'ensemble d'instructions ; ou -du code ou de l'adresse d'une instruction critique de l'ensemble d'instructions ; ou
-d'un code détecteur d'erreur calculé à partir du code ou d'une adresse d'au moins une instruction de l'ensemble d'instructions, ce code détecteur d'erreur pouvant être un code de redondance cyclique.
Selon un autre aspect, la présente invention concerne un dispositif de sécurisation de l'exécution d'un programme informatique comportant un ensemble d'au moins une instruction. Ce dispositif de sécurisation comporte : - un premier registre de mémorisation d'une première signature représentative de l'exécution attendue de l'ensemble d'instructions;
-des moyens de calcul et de mémorisation, au cours de l'exécution de l'ensemble d'instructions, d'une deuxième signature représentative de l'exécution de l'ensemble d'instructions, cette mémorisation étant effectuée dans un deuxième registre de mémorisation ; et
-des moyens de détection d'une anomalie d'exécution de l'ensemble d'instructions à partir des première et deuxième signatures.
L'invention vise aussi une carte à puce comportant un dispositif de sécurisation tel que décrit brièvement ci-dessus. Les avantages du dispositif de traitement, du dispositif de sécurisation et de la carte à puce selon l'invention étant identique à ceux du procédé de sécurisation décrit précédemment, ils ne seront pas rappelés ici.
L'invention sera mieux comprise et d'autres avantages apparaîtront plus clairement à la lumière de la description qui va suivre d'un procédé et d'un dispositif de sécurisation ainsi que d'un dispositif de traitement d'un programme informatique conformes à son principe, cette description étant donnée uniquement à titre d'exemple et faite en référence aux dessins annexés dans lesquels :
- la figure 1 représente les principales étapes d'un procédé de sécurisation de l'exécution d'un programme informatique conforme à l'invention dans un mode particulier de réalisation ;
- la figure 2 représente de façon schématique un dispositif de traitement d'un programme informatique conformément à la présente invention dans un mode particulier de réalisation ; et
- la figure 3 représente un dispositif de sécurisation d'un programme informatique conforme à l'invention dans un mode préféré de réalisation.
La description est par ailleurs accompagnée des annexes A à D qui comportent quatre exemples de programmes informatiques sécurisés conformément à l'invention en langage assembleur. L'annexe A comporte le code en assembleur d'un programme informatique A. Ce code assembleur comporte 13 instructions notées A1 à A13.
Au cours de l'instruction A1 , on mémorise dans le registre opcode_count la valeur 101.
Cette instruction est suivie par une instruction A2 au cours de laquelle on initialise le bit opcode_start avec la valeur 1 , ce qui déclenche la décrémentation automatique du registre opcode_count à chaque nouvelle instruction exécutée.
L'instruction A2 est suivie par trois instructions A3, A4, A5 au cours desquelles on mémorise respectivement la valeur messagel dans le registre rO, la valeur message2 dans le registre r1 et la valeur 16 dans le registre r2.
L'instruction A5 est ensuite suivie par une boucle « boucle_round_i » constituée par les instructions A6 à A11.
Plus précisément, au cours de l'instruction A6, on mémorise dans un registre a la donnée pointée par l'adresse contenue dans le registre r1.
L'instruction A6 est suivie par une instruction A7 au cours de laquelle on réalise l'opération OU exclusif logique « XOR » entre le contenu du registre a et la donnée pointée par l'adresse contenue dans le registre rO.
L'instruction A7 est suivie par une instruction A8 au cours de laquelle on remplace la donnée pointée par l'adresse contenue dans le registre rO par le contenu du registre a.
L'instruction A8 est suivie par deux instructions A9 et A10 au cours desquelles on incrémente respectivement d'une unité le contenu des registres rO et r1.
L'instruction A10 est suivie par une instruction A11 au cours de laquelle on décrémente d'une unité le contenu du registre r2 et on teste si le contenu du registre r2 ainsi décrémenté est nul. Lorsque ce n'est pas le cas, l'instruction A11 est suivie par l'instruction A6 décrite précédemment.
Le contenu du registre r2 ayant été initialise avec la valeur 16 à l'instruction A5, la boucle « boucle_round_i » est exécutée seize fois. En revanche, lorsque le contenu du registre r2 est nul, l'instruction
A11 est suivie par l'instruction A12 au cours de laquelle on modifie le contenu du bit opcode_start avec la valeur 0, ce qui interrompt la décrémentation automatique du compteur opcode_count.
L'instruction A12 est suivie par l'instruction A13 au cours de laquelle on décrémente le contenu du registre opcode_count, puis on teste le contenu de ce registre.
Lorsque le contenu de ce registre est non nul, le programme appelle une routine de traitement des anomalies d'exécution « error_on_opcode_count ». Le fait de positionner à 1 la valeur du bit opcode_start au cours de l'instruction A2 permet, automatiquement, de déclencher le compteur opcode_count qui se décrémente automatiquement d'une unité à l'exécution de chaque instruction.
En pratique, le processeur exécutant le programme informatique comporte des moyens adaptés à décrémenter ce compteur à chaque chargement FETCH du code d'une opération. Ce compteur est arrêté par la mise à zéro du bit opcode_start à l'instruction A12.
L'exécution de ce programme informatique A est sécurisée conformément à l'invention. En effet : Au cours de la génération de ce programme, non décrite ici, une première signature de valeur 101 a été calculée et mémorisée, cette première signature étant représentative du nombre d'instructions que le programme informatique A doit normalement exécuter lorsque le bit opcode_start est positionné à 1 , c'est-à-dire entre les instructions A3 et A12. Si le programme s'exécute normalement, les instructions s'exécutant entre les instructions A3 et A12 sont :
- les instructions A3, A4 et A5 qui s'exécutent une fois ; et
- les instructions A6, A7, A8, A9, A10, A11 qui s'exécutent seize fois ; et - l'instruction A12 qui s'exécute une fois.
Le nombre d'instructions total est donc (3 x 1) +(16 x 6)+(1 x 1) = 100.
A l'issue de l'instruction A12, le registre opcode_start contient donc si le programme est exécuté normalement, la valeur 1 , (101 - 100). Au cours de l'instruction A13, on décrémente le registre opcode_count. Le registre opcode_count doit alors normalement contenir la valeur 0. Si tel n'est pas le cas, cela signifie que toutes les instructions du programme n'ont pas été exécutées, ou que des instructions non prévues ont été exécutées. Conformément à la présente invention, la valeur 101 mémorisée dans le registre opcode_count à l'instruction A1 est une première signature représentative de l'exécution de l'ensemble des instructions A2 à A13 calculée, par exemple, par le programmeur ou de façon automatique au moment de la génération de cet ensemble d'instructions. De la même façon, toujours conformément à la présente invention, au cours de l'exécution du programme, le registre opcode_count est décrémenté au cours de l'exécution de chaque instruction. Il mémorise ainsi une deuxième signature égale au nombre d'instructions prévues et n'ayant pas été exécutées, cette deuxième signature étant calculée par différence à partir de la première signature 101.
L'instruction A13 constitue quant à elle une étape de détection d'une anomalie d'exécution au cours de laquelle on vérifie si le contenu du registre opcode_count est nul, après décrémentation de ce registre. Si la valeur de ce registre est non nul, cela signifie soit qu' au moins une des instructions prévues n'a pas été exécutée, soit qu'une instruction non prévue a été exécutée, ce qui dans tous les cas constitue une anomalie. Dans un mode préféré de réalisation, on déclenche une interruption logicielle lorsque le compteur devient strictement négatif. Ceci permet avantageusement la détection d'une attaque qui aurait pour effet de ne pas exécuter l'instruction A13 de détection et l'instruction A12 d'arrêt du compteur. Dans ce mode de réalisation, les instructions A12 d'arrêt du compteur et A13 de détection peuvent être combinées en une seule instruction ajoutée au jeu d'instructions du processeur. Il est alors encore plus difficile de mener une attaque consistant à arrêter le compteur et à sauter l'instruction de détection. L'annexe B comporte le code assembleur d'un autre programme informatique B.
Dans ce mode de réalisation, le processeur qui exécute le programme B comporte un registre SFRJDPH qui contient le code d'opération de la dernière instruction exécutée. Au cours d'une première instruction B1 , on réalise l'opération XRL
(OU exclusif logique) entre le contenu d'un registre A et celui d'un registre R1 du processeur.
L'instruction B1 est suivie par l'instruction B2 au cours de laquelle le programme se branche au label « résultat_faux » si le contenu des registres A et R1 diffèrent.
Lorsque les contenus des registres A et R1 sont égaux, l'instruction B2 est suivie par une instruction B3 au cours de laquelle on mémorise dans le registre R5 le contenu du registre SFR_OPH, soit le code d'opération de la dernière instruction exécutée (B2) avant l'instruction en cours d'exécution (B3).
Ainsi, à l'issue de l'instruction B3, le registre R5 contient le code de l'instruction JNZ, soit 70h.
L'instruction B3 est ensuite suivie par trois instructions B4 à B6 au cours desquelles, respectivement, on mémorise dans le registre A la valeur du registre R7, on réalise un OU logique entre le contenu du registre A et la valeur hexadécimale 55h et on mémorise dans le registre R7 le nouveau contenu de la valeur A.
L'instruction B6 est suivie par une instruction B7 au cours de laquelle on mémorise dans le registre A, le contenu du registre R5.
Conformément à ce qui a été décrit précédemment, le registre A contient le code 70h de l'opération JNZ si l'instruction B2 a été exécutée précédemment à l'instruction B3.
L'instruction B7 est suivie par une instruction B8 au cours de laquelle on réalise un OU exclusif logique entre le contenu du registre A et la valeur 70h du code de l'instruction JNZ.
Ainsi, si le test prévu à l'instruction B2 a été effectivement exécuté, le résultat du OU exclusif logique effectué à l'opération B8 est égal à 0.
Si tel n'est pas le cas, l'instruction B9 consécutive à l'instruction B8 branche le programme B sur une routine « os_kill_card » de destruction du système d'exploitation de la carte à microcircuit. Ainsi, le programme permet de vérifier, conformément au procédé de sécurisation selon l'invention que l'instruction critique B2 a effectivement été exécutée.
Pour cela, on a, au cours de la génération du programme informatique, calculé et mémorisé dans un registre de la mémoire ROM contenant le code exécutable du programme informatique B, ce registre étant associé à l'instruction B8, une première signature représentative de l'exécution de l'instruction B2, à savoir le code 70H de l'instruction JNZ. Au cours de l'exécution de l'instruction B3, on a mémorisé une deuxième signature en chargeant dans le registre R5 le code de l'instruction précédent l'instruction B3, soit normalement le code 70h si aucune attaque n'a été effectuée. L'étape B9 constitue quant à elle une étape de détection d'une anomalie d'exécution, une anomalie étant détectée si la première signature et la deuxième signature diffèrent.
Le procédé précédemment décrit en référence à l'annexe B permet ainsi de détecter que l'exécution de l'instruction B2 a effectivement eu lieu.
L'annexe C comporte le code assembleur d'un autre programme informatique C.
De façon connue, chaque instruction du programme C comporte en première colonne l'adresse de cette instruction. Par exemple, l'adresse de l'instruction C1 est 0x8500.
Dans ce mode de réalisation, le processeur qui exécute le programme C comporte un registre SFR_JMP qui mémorise l'adresse de la dernière instruction ayant exécuté un saut (JMP, JNZ, CJNE, ...).
Au cours de la première instruction C1 , on réalise le OU exclusif logique XRL entre le contenu du registre A et celui du registre R1.
L'instruction C1 est suivie par une instruction C2 au cours de laquelle on effectue un saut au label « continue » si le résultat de l'instruction C1 précédente diffère de la valeur 0.
Ainsi, le programme informatique C se branche au label « continue » si les valeurs des registres A et R1 diffèrent.
Au cours de cette même instruction C2, et conformément à la présente invention, le processeur mémorise automatiquement l'adresse 0x8501 de l'instruction de saut JNZ (C2) dans le registre prédéterminé SFR_JMP, constitué d'une partie haute SFR__JMPH et d'une partie basse SFR_JMPL. Lorsque le programme se branche au label « continue » il exécute tout d'abord deux instructions C4 et C5 respectivement au cours desquelles, il mémorise dans le contenu du registre A la valeur 25 et il ajoute au contenu de ce registre A la valeur 34.
Il exécute ensuite, consécutivement à l'instruction C5, une instruction C6 qui termine l'exécution de ce programme informatique C. En revanche, lorsque le résultat de l'opération OU exclusif logique exécutée à l'instruction C1 est nul, c'est à dire lorsque les contenus des registres A et R1 sont égaux, l'instruction de saut conditionnel C2 est sans effet. Cette instruction C2 est alors suivie par une instruction C3 de saut au label « code_secret ». Conformément à la présente invention, au cours de l'exécution de l'instruction C3, le processeur mémorise automatiquement dans le registre SFR_JMP la valeur de l'adresse de l'instruction C3 à savoir 0x8503.
Lorsque le programme informatique C se branche au label
« code_secret », il exécute tout d'abord deux instructions C7 et C8 au cours desquelles on mémorise respectivement dans les registres A et R5, le contenu de la partie haute SFR_JMPH et de la partie basse SFR_JMPL du contenu du registre SFR_JMP.
Normalement, si l'instruction C7 a été exécutée consécutivement à l'instruction C3, les contenus des registres A et R5 doivent respectivement contenir les valeurs 85 et 03, correspondant aux parties hautes et basses de l'adresse 0x8503.
L'instruction C8 est ensuite suivie par deux instructions C9 et C10 au cours desquelles on vérifie si le contenu des registres A et R5 est respectivement égal à 85H et 03H. Si tel n'est pas le cas, le programme informatique exécute une routine « os_kill_card » de destruction du système d'exploitation de ce programme informatique.
Lorsque les contenus des registres A et R5 sont respectivement égaux à 85H et 03H, l'instruction C10 est suivie par une instruction C11 au cours de laquelle on mémorise dans le registre A la valeur PIN.
L'instruction C11 est suivie par une instruction C12 de fin d'exécution du programme C. Ainsi, par exemple durant la génération du programme informatique, conformément à la présente invention, on a calculé et mémorisé les premières signatures constituées par les valeurs 85H et 03H constituant l'adresse de l'instruction C3. Puis, au cours de l'exécution des instructions C7 et C8 on a mémorisé une deuxième signature en chargeant dans les registres A et R5 le contenu du registre SFR_JMP, ce registre devant contenir la valeur 0x8503 si le programme C s' est exécuté normalement.
Conformément à la présente invention, les instructions C9 et C10 constituent les étapes de détection d'une anomalie d'exécution, ces étapes consistant à comparer le contenu des registres A et R5, à savoir la deuxième signature, avec la première signature mémorisée au moment de la génération du programme à savoir l'adresse de l'instruction C3.
Le procédé de sécurisation décrit ici permet de vérifier que lorsque le programme se branche à l'instruction C7 il a précédemment exécuté l'instruction C3, ce qui signifie que l'opération du OU exclusif logique réalisé à l'instruction C1 a donné une valeur nulle, et donc que les registres A et R1 contiennent une valeur identique.
Le programme de sécurisation permet donc de vérifier que lorsque l'on entre dans la sous-partie du programme repéré par le label « code_secret », on exécute ces instructions de façon licite et non pas après une attaque, auquel cas la valeur du registre SFR_JMP serait différente de la valeur 0x8503, correspondant à l'adresse de l'instruction C3.
Dans un autre mode de réalisation non décrit ici, le programme informatique C comporte d'autres instructions similaires aux instructions C9 et C10, ces instructions comportant, en lieu et place des valeurs 85H et 03H, les parties basses et hautes des adresses d'autres instructions de saut, ce qui permet de sécuriser, selon le principe décrit ci-dessus un programme comportant plusieurs sauts d'instructions. L'annexe D comporte le code assembleur d'un autre programme informatique D. Pour faciliter la description, les instructions des lignes D2 à D12 U i ι « v «; ' „ „ ^ — -
comportent, en première colonne, le code hexadécimal de l'instruction correspondante.
Par exemple, le code de l'instruction "mov r0,# messagel" est la valeur 78 H. Au cours de la première instruction D1 , on initialise le bit chk_opcode_ start avec la valeur 1.
L'instruction D1 est suivie par trois instructions D2, D3, D4 au cours desquelles on mémorise respectivement la valeur messagel dans le registre rO, la valeur message2 dans le registre M , et la valeur 16 dans le registre r2.
L'instruction D4 est ensuite suivie par une boucle « boucle_round_i » constituée par les instructions D5 à D10.
Plus précisément, au cours de l'instruction D5, on mémorise dans un registre a la donnée pointée par l'adresse contenue dans le registre r1. L'instruction D5 est suivie par une instruction D6 au cours de laquelle on réalise le OU exclusif logique « XRL » entre le contenu du registre a et la donnée pointée par l'adresse contenue dans le registre rO.
L'instruction D6 est suivie par une instruction D7 au cours de laquelle on remplace la donnée pointée par l'adresse contenue dans le registre rO par le contenu du registre a.
L'instruction D7 est suivie par deux instructions D8 et D9 au cours desquelles on incrémente respectivement d'une unité le contenu des registres rO et r1.
L'instruction D9 est suivie par une instruction D10 au cours de laquelle on décrémente d'une unité le contenu du registre r2 et on teste si le contenu du registre r2 ainsi décrémenté est nul. Lorsque ce n'est pas le cas, l'instruction D10 est suivie par l'instruction D5 décrite précédemment.
Le contenu du registre r2 ayant été initialise avec la valeur 16 à l'instruction D4, la boucle "boucle_round_i" est exécutée 16 fois. En revanche lorsque le contenu du registre r2 est nul, l'instruction
D10 est suivie par l'instruction D11 au cours de laquelle on mémorise dans le registre a le contenu d'un registre "checksum". Conformément à l'invention, ce registre "checksum" est un code détecteur d'erreur calculé à partir du code des instructions D2 à D11.
En effet, dans le mode de réalisation décrit ici, après l'initialisation (au cours de l'instruction D1) du bit chk_opcode_start avec la valeur 1 , le processeur réalise le OU exclusif logique entre le code des instructions suivantes et mémorise le résultat de cette opération dans le registre checksum.
Ainsi, à l'issue de l'exécution de l'instruction D2, le contenu du registre checksum est égal à 78h.
De même, à l'issue de l'exécution de l'instruction D3, le contenu du registre checksum est égal au OU exclusif logique entre les valeurs 78h et 79h soit 01.
Ainsi, à l'issue de la boucle constituée des opérations D5 à D10, le registre checksum contient une signature représentative des instructions qui ont été exécutées après l'exécution de l'instruction D1. En l'espèce, si les instructions D2, D3, D4 ont été exécutées une fois et si les instructions D5 à D10 ont été exécutées 16 fois, le contenu du registre checksum à l'issue de la dernière exécution de l'instruction D10 est égale à 7Bh.
L'instruction D11 est suivie par une instruction D12 au cours de laquelle on compare le contenu du registre a avec la valeur hexadécimale OFh.
Cette valeur OFh constitue, selon les termes de la présente invention, une première signature calculée et mémorisée dans un registre de la mémoire comportant le programme D, cette première signature étant représentative de l'exécution attendue des instructions D2 à D11. Au cours de l'instruction D12, si on constate que le contenu du registre a est différent de la valeur OFh, le programme D appelle une routine de traitement des anomalies d'exécution "kill_card".
Cette instruction D12 constitue ainsi une étape de détection d'une anomalie d'exécution des instructions D2 à D11 à partir de la première signature OFh et de la deuxième signature mémorisée dans le registre checksum. ι v ui iλ u o / « J 0 3
Dans le mode préféré de réalisation décrit ici, la routine de traitement "kill_card" est une routine rendant l'utilisation de la carte à microcircuit impossible.
La figure 1 représente les principales étapes E10 à E80 d'un procédé de sécurisation conforme à la présente invention dans un mode préféré de réalisation.
Dans l'exemple décrit ici, le procédé de sécurisation permet de sécuriser l'exécution d'un programme informatique EXE dont le code source SOURCE est écrit en langage assembleur. II s'agit par exemple d'un code source semblable à ceux décrits précédemment en référence aux annexes A à D.
Le procédé de sécurisation selon l'invention comporte deux séries d'étapes, à savoir une première série composée des étapes E10 à E30 de génération du code exécutable du programme informatique à partir du code source SOURCE et une seconde série d'étapes constituée par les étapes E40 à E80 d'exécution du programme informatique EXE.
Au cours de la première étape E10 du procédé de sécurisation selon l'invention, on lit le code source SOURCE du programme à sécuriser.
Cette étape de lecture d'un code source est connue de l'homme du métier. Elle peut être mise en œuvre par un assembleur ou compilateur.
L'étape E10 de lecture du code source est suivie par une étape E20 au cours de laquelle on génère le code exécutable EXE du programme informatique.
Cette étape est connue de l'homme du métier. Elle peut notamment être mise en œuvre par un compilateur.
L'étape E20 de génération du code exécutable EXE est suivie par une étape E30 de calcul et de mémorisation d'une première signature SIG1 représentative de l'exécution attendue d'un ensemble d'instructions du programme informatique à sécuriser. Dans le mode de réalisation décrit ici, cette première signature
SIG1 est mémorisée dans un registre REG0 de la mémoire morte ROM comportant le programme informatique exécutable EXE. Dans une autre variante de réalisation, cette étape E30 de calcul et de mémorisation d'une première signature SIG1 s'effectue au cours de la lecture du code source E10.
Dans une autre variante de réalisation, cette étape E30 de calcul et de mémorisation d'une première signature SIG1 s'effectue au cours de l'étape de génération du code exécutable E20. C'est particulièrement le cas, lorsque cette première signature est obtenue à partir de l'adresse d'une instruction critique du programme informatique.
Cette première étape E30 de calcul et de mémorisation peut être effectuée de différentes manières.
Dans une première variante de réalisation, la première signature SIG1 est le nombre d'instructions dont l'exécution est à sécuriser. Une telle variante de réalisation a précédemment été décrite en référence à l'annexe A. Plus précisément, lorsque le langage de programmation du programme informatique est le langage assembleur, cette étape consiste à compter le nombre des codes d'opérations des instructions de l'ensemble d'instructions à sécuriser.
Dans la variante de réalisation dans laquelle le langage de programmation est un langage de haut niveau tel le langage C, cette étape consiste tout d'abord à générer un programme assembleur à partir du code source de haut niveau, puis, à compter le nombre d'instructions en assembleur ainsi générées.
Les outils de génie logiciel, et en particulier l'interface graphique de ces outils, permettant à un programmeur d'introduire dans le programme informatique les instructions nécessaires à la mise en œuvre du procédé de sécurisation conforme à l'invention seront décrits ultérieurement en référence à la figure 2.
Dans l'exemple décrit précédemment en référence à l'annexe A, la première signature est le nombre 101 mémorisé dans un registre REG0 de la mémoire comportant le code exécutable du programme A. Dans une autre variante de réalisation, telle que décrite précédemment en référence à l'annexe B, la première signature est le code d'une instruction critique de l'ensemble d'instructions.
Ainsi, dans le programme B décrit précédemment, la première signature est le code 70h de l'instruction JNZ. Cette première signature est mémorisée dans un registre REGO de la mémoire du programme exécutable B.
Dans un autre mode de réalisation, tel que décrit en référence à l'annexe C, la première signature est l'adresse d'une instruction critique de l'ensemble d'instructions, cette adresse étant obtenue pendant ou après la génération du code exécutable de l'ensemble d'instructions.
Dans l'exemple décrit précédemment en référence à l'annexe C, cette première signature est la valeur 0x8503 correspondant à l'adresse de l'instruction C3, cette adresse étant mémorisée dans des registres de la mémoire comportant le code exécutable du programme C, ces registres étant associés aux instructions C9 et C10.
Dans un autre mode préféré de réalisation, tel que décrit en référence à l'annexe D, la première signature est un code détecteur d'erreurs calculé à partir du code d'au moins une instruction de l'ensemble d'instructions à sécuriser. Cette signature peut par exemple être une combinaison logique des codes d'instructions à sécuriser.
Cette première signature peut également être, dans un mode préféré de cette variante de réalisation, un code de redondance cyclique obtenu à partir de ces codes d'instructions, ou par combinaison logique (XOR) de ces codes d'instruction.
L'étape E30 est suivie par une étape E40 au cours de laquelle on débute l'exécution du programme informatique EXE.
Dans le mode de réalisation décrit ici, ce programme informatique EXE est mémorisé dans une mémoire morte ROM dont un registre REGO comporte la première signature SIG1 calculée à l'étape E20.
L'étape E40 de début d'exécution du programme informatique est suivie par une étape E45 au cours de laquelle on copie le contenu SIG1 du registre REGO de la mémoire morte ROM dans un registre REG1 de la mémoire vive RAM utilisée par le programme informatique EXE.
L'étape de copie E45 est suivie par une étape E50 au cours de laquelle on calcule et on mémorise une deuxième signature SIG2 dans un registre REG2 de la mémoire vive RAM, cette deuxième signature SIG2 étant représentative de l'exécution proprement dite de l'ensemble d'instructions à mémoriser.
Cette deuxième signature est calculée au cours de l'exécution de l'ensemble d'instructions. II s'agit par exemple du nombre d'instructions ayant été exécutées à un instant donné ou du nombre d'instructions restant à exécuter tel que décrit précédemment en référence à l'annexe A.
Il peut également s'agir, tel que décrit en référence à l'annexe B, du code d'une instruction venant d'être exécutée, ou, comme décrit en référence à l'annexe C, d'une adresse de cette instruction.
Dans le mode de réalisation dans lequel la première signature SIG1 est un code détecteur d'erreur calculé à partir du code d'au moins une instruction de l'ensemble d'instructions, l'étape E50 de calcul et de mémorisation de la deuxième signature SIG2 est effectuée en calculant le code détecteur d'erreur au fur et à mesure de l'exécution des instructions considérées.
Il peut notamment s'agir, comme précisé précédemment en référence à l'annexe D, d'un code de redondance cyclique ou d'une combinaison logique telle que XOR. Quoiqu'il en soit, l'étape E50 de calcul et mémorisation d'une deuxième signature SIG2 permet de mémoriser la deuxième signature dans un registre REG2 de la mémoire vive RAM d'exécution du programme informatique EXE.
Préférentiellement, le contenu de ce registre REG2 est conservé pendant l'exécution d'au moins une deuxième instruction consécutive à l'ensemble d'instructions à sécuriser. L'étape E50 de calcul et de mémorisation d'une deuxième signature SIG2 est suivie par un test E60 de détection d'une anomalie d'exécution de l'ensemble d'instructions à partir des première et deuxième signatures, respectivement SIG1 et SIG2. Conformément à l'invention, un nombre quelconque d'instructions peuvent être exécutées entre l'étape E50 et le test E60.
Ce test E60 de détection d'une anomalie consiste à vérifier si la valeur de la deuxième signature SIG2 est en accord avec la valeur de la première signature SIG1 calculée et mémorisée au cours de la génération du programme informatique, ce qui signifie que les instructions à sécuriser ont été exécutées conformément à ce qui était prévu.
Lorsque la deuxième signature SIG2 n'est pas en accord avec la première signature SIG1 , cela signifie que le programme informatique EXE n'a pas été exécuté tel que prévu, par exemple suite à une attaque DFA. Le test E60 de détection d'une anomalie d'exécution peut notamment consister à comparer les signatures SIG1 et SIG2 lorsque ces signatures sont :
- le nombre d'instructions prévues SIG1 et le nombre d'instructions réellement exécutées SIG2 ; - le code SIG1 d'une instruction critique prévue et le code SIG2 d'une instruction réellement exécutée ;
- l'adresse SIG1 d'une instruction critique prévue et l'adresse SIG2 d'une instruction réellement exécutée ; et
- un code détecteur d'erreurs CRC1 par exemple un code de redondance cyclique calculé à partir des codes d'opération d'un certain nombre d'instructions et le code détecteur d'erreurs CRC2, par exemple un code de redondance cyclique calculé à partir d'un ensemble d'instructions réellement exécutées.
Dans le mode préféré de réalisation décrit précédemment à l'annexe A, cette étape E60 de détection d'une erreur d'exécution consiste à comparer le nombre d'instructions restant à exécuter avec la valeur zéro. Quoiqu'il en soit, lorsqu'une anomalie d'exécution est détectée au cours du test E60 de la détection, ce test est suivi par une étape E70 de traitement de cette anomalie.
Cette étape E70 peut notamment consister en une étape de destruction d'une partie du système informatique dans lequel le programme informatique s'exécute, par exemple la destruction du système d'exploitation, ce qui rend la carte à microcircuit inutilisable en cas de détection d'une attaque mal intentionnée.
En variante, l'étape E70 de traitement est mise en œuvre uniquement lorsque plusieurs anomalies ont été détectées au cours des différentes utilisations de la carte. On utilise alors pour cela un registre dans lequel sera accumulé le nombre d'anomalies, éventuellement en fonction de leur nature.
En variante, l'étape de traitement E70 consiste à réinitialiser le système informatique dans lequel le programme informatique s'exécute, par exemple par une commande reset.
Dans une autre variante de réalisation, l'étape E70 de traitement d'une anomalie peut consister en l'envoi d'un simple message d'information destiné à l'utilisateur du dispositif. Cette variante de réalisation est particulièrement intéressante lorsque le procédé de sécurisation selon l'invention est utilisé pour fiabiliser le déroulement d'un programme informatique (satellite, contrôle d'un implant cardiaque).
Cette étape E70 termine le procédé de sécurisation conforme à la présente invention décrit ici.
Par ailleurs, lorsque aucune anomalie n'est détectée au cours de l'étape E60 de détection d'une anomalie d'exécution, le test E60 est suivi par une étape E80 où d'autres instructions, non sécurisées, sont éventuellement exécutées. A l'issue de l'étape E80, le procédé de sécurisation se termine. La figure 2 représente de façon schématique un dispositif de traitement d'un programme informatique conforme à la présente invention dans un mode préféré de réalisation.
Dans un mode préféré de réalisation, le dispositif 10 de traitement comporte des moyens 11 d'édition du programme informatique SOURCE.
Ces moyens 11 d'édition comportent en particulier des moyens de sélection, par exemple un clavier, une souris et un traitement de texte, permettant de sélectionner, dans le programme informatique SOURCE, les instructions à sécuriser. Ces moyens 11 d'édition permettent également d'introduire dans le programme informatique SOURCE, de façon automatique ou manuelle, des instructions particulières pour le calcul et la mémorisation de la deuxième signature SIG2, cette deuxième signature SIG2 étant calculée au cours de l'exécution des instructions devant être sécurisées. Ces moyens 11 d'édition permettent aussi d'introduire dans le programme informatique SOURCE une instruction permettant de mettre en œuvre l'étape de détection d'une anomalie.
Le dispositif 10 de traitement d'un programme informatique comporte des moyens 12 de calcul et de mémorisation, au cours de la génération des instructions, d'une première signature SIG1 représentative de l'exécution attendue de l'ensemble d'instructions sélectionnées par les moyens d'édition 11.
Ces moyens 12 de calcul et de mémorisation sont, de façon connue, adaptés à lire le programme informatique SOURCE. Ils sont en particulier adaptés à lire un programme informatique tels que ceux donnés aux annexes A à D.
Dans un mode préféré de réalisation, le dispositif 10 de traitement comporte des moyens 14 de génération d'un code exécutable à partir du programme informatique source. Ces moyens 14 de génération d'un code exécutable sont en particulier adaptés à obtenir et à mémoriser les adresses des instructions critiques à sécuriser dans le code exécutable à partir du programme informatique SOURCE.
Les moyens 12 de calcul et de mémorisation sont, adaptés, dans un mode de réalisation préféré, à compter le nombre d'instructions sélectionnées et le nombre d'arguments de ces instructions par les moyens 11 d'édition, et à mémoriser cette valeur dans un registre.
Cette valeur constitue une première signature SIG1 conformément à la présente invention.
Les moyens 12 de calcul et de mémorisation sont également adaptés à mémoriser le code d'opération d'une instruction critique sélectionnée par les moyens 11 d'édition.
Ils sont également adaptés à mémoriser l'adresse d'une instruction sélectionnée par les moyens 11 d'édition, cette adresse ayant été obtenue par les moyens 14 de génération d'un code exécutable pendant ou après la génération du code exécutable.
Dans une variante de réalisation, les moyens 12 de calcul et de mémorisation sont adaptés à calculer un code détecteur d'erreurs, par exemple un code de redondance cyclique ou une combinaison logique (XOR) à partir du code des instructions sélectionnées par les moyens 11 d'édition. Dans une variante de réalisation, le registre REG1 de mémorisation de la première signature SIG1 peut également être sélectionné par les moyens 11 d'édition.
Quoiqu'il en soit, le dispositif de traitement génère un programme informatique EXE susceptible d'être exécuté ultérieurement et associé à un registre REGO mémorisant une signature SIG1 représentative de l'exécution attendue des instructions sélectionnées par les moyens d'édition 11.
Nous allons maintenant décrire en référence à la figure 3 une carte à microcircuit C comportant un dispositif de sécurisation 100 conforme à la présente invention dans un mode préféré de réalisation. Le dispositif 100 de sécurisation de la carte à microcircuit C selon l'invention décrit ici comporte un registre REG1 de mémorisation d'une première signature SIG1 représentative de l'exécution attendue d'un ensemble d'instructions à sécuriser, cette signature ayant été calculée et mémorisée par un dispositif de traitement 10 du type de ceux décrits précédemment en référence à la figure 2.
Le dispositif 100 de sécurisation comporte en outre des moyens 22 de calcul et de mémorisation au cours de l'exécution de l'ensemble d'instructions d'une deuxième signature SIG2 représentative de l'exécution proprement dite des instructions, cette mémorisation étant effectuée dans un deuxième registre REG2 de mémorisation.
Dans un mode préféré de réalisation, les moyens 22 de calcul et de mémorisation sont adaptés à compter le nombre d'instructions de l'ensemble d'instructions ayant été exécutées, ou celles n'ayant pas encore été exécutées, par comparaison avec la signature SIG1.
Préférentiellement, les moyens 22 de calcul et de mémorisation comportent des moyens de déclenchement d'une interruption du programme informatique EXE lorsque la deuxième signature SIG2 est inférieure à un seuil prédéterminé.
Ces moyens de déclenchement d'une interruption sont connus de l'homme du métier et ne seront pas décrits ici.
Dans l'exemple décrit précédemment en référence à l'annexe A, les instructions de l'ensemble d'instructions à sécuriser sont celles s'exécutant alors que le bit opcode_start est positionné à 1 , c'est à dire entre l'exécution des instructions A2 et A12 insérées dans le programme informatique SOURCE par les moyens d'édition 11 du dispositif 10 de génération décrit en référence à la figure 2. Ainsi, lorsque le processeur du dispositif de sécurisation exécute ces instructions, les moyens 22 de calcul et de mémorisation décrémentent le compteur opcode_count contenu dans le deuxième registre REG2.
En pratique, cette opération est réalisée par le processeur au cours de l'instruction FETCH. Dans un deuxième mode de réalisation, les moyens 22 de calcul et de mémorisation mémorisent dans le registre REG2 le code ou l'adresse de la dernière instruction exécutée. Ceci peut se faire tel que décrit précédemment, respectivement en référence aux instructions D7, C7 et C8 des annexes B et C.
Dans un autre mode de réalisation, les moyens 22 de calcul et de mémorisation calculent un code détecteur d'erreur à partir du code ou d'une adresse d'au moins une instruction de l'ensemble d'instructions.
En pratique, le calcul du code de détecteur d'erreur est réalisé par le processeur qui exécute le programme informatique à sécuriser au moment du chargement en mémoire des instructions sélectionnées en utilisant les moyens 11 de sélection du dispositif de traitement selon l'invention. Dans le mode préféré de réalisation de cette variante, le code détecteur d'erreur est un code de redondance cyclique CRC2 ou une combinaison logique (XOR) calculés à partir des codes ou des adresses de ces instructions.
Le dispositif 100 de sécurisation selon l'invention comporte également des moyens 24 de détection d'une anomalie d'exécution de l'ensemble d'instructions à sécuriser.
Ces moyens 24 de détection sont par exemple constitués d'un comparateur des registres REG1 et REG2.
Ce mode préféré de réalisation permet de détecter en particulier une différence entre les signatures SIG1 générées et mémorisées par le dispositif 10 de génération selon l'invention et la signature SIG2 calculée et mémorisée dans le registre REG2 par les moyens 22 de calcul et de mémorisation du dispositif de sécurisation 100.
Ils permettent en particulier de détecter une erreur dans les modes de réalisation dans lesquels les signatures sont constituées :
- par le nombre d'instructions de l'ensemble d'instructions ;
- par l'adresse d'une instruction critique de cet ensemble d'instructions ;
- ou du code d'une instruction critique de cet ensemble. Dans un autre mode de réalisation préféré, les moyens 24 de détection d'une anomalie sont constitués par un comparateur adapté à comparer le contenu du registre REG2 de mémorisation de la deuxième signature avec la valeur 0.
Ce mode préféré de réalisation est facile à mettre en œuvre ; il permet de détecter que toutes les instructions à sécuriser ont été exécutées, tel que précédemment décrit en référence à l'annexe A.
Dans un mode préféré de réalisation, les moyens 22 de calcul et de mémorisation sont adaptés à conserver la deuxième signature dans le deuxième registre REG2 pendant l'exécution d'au moins une instruction consécutive à l'ensemble d'instructions à sécuriser. Dans cette variante préférée, le deuxième registre REG2 peut par exemple être un registre dédié d'une mémoire volatile RAM du dispositif de sécurisation 100, ce registre de mémoire volatile étant écrasé par les moyens 24 de détection d'une anomalie après comparaison des première et deuxième signature. Dans le mode préféré de réalisation décrit ici, les première SIG1 et deuxième signatures SIG2 sont mémorisées dans le même registre REG1 de la mémoire vive RAM au cours de l'exécution du programme informatique EXE.
ANNEXE A
A1 mov opcode_count, #101
A2 setb opcode_start
A3 mov rO, #message1
A4 mov r1 , #message2
A5 mov r2, 16 boucle_ _round_i :
A6 mov a,@r1
A7 xrl a, @r0
A8 mov @r0, a
A9 inc rO
A10 inc r1
A11 djnz r2, boucle_round_i
A12 clrb opcode_start
A13 djnz opcode_count, error
ANNEXE B
B1 XRL A, R1
B2 JNZ résultat_faux résultat bon :
B3 MOV R5, SFR_OPH
B4 MOV A, R7
B5 ORL A, #55h
B6 MOV R7, A
B7 MOV A,R5
B8 XRL A, #70h
B9 JNZ os card B10 RET
I "ésultat_faux
B11 MOV A, R6 B12 RET
ANNEXE C
C1 0x8500 XRL A, R1
C2 0x8501 JNZ continue
C3 0x8503 SJMP code_secret continue :
C4 0x8505 MOV A, #25
C5 0x8507 ADD A, #34
C6 0x8509 RET
code secret :
C7 0x850A MOV A, SFR_JMPH
C8 0x850C MOV R5, SFR_JMPL
C9 0x850E CJNE A, #85h, os_kill_card
C10 0x8511 CJNE R5, #03h, os_kill_card
C11 0x8514 MOV A, PIN
C12 0x8516 RET
ANNEXE D
D1 setb chk_opcode_start
D2 78 mov rO, #message1
D3 79 mov r1 , #message2
D4 7A mov r2, 16 boucle round i
D5 E7 mov a,@r1
D6 66 xrl a,@r0
D7 F6 mov @r0,a
D8 08 inc rO
D9 09 inc r1
D10 DA djnz r2, boucle_round_i
D11 74 mov a, checksum
D12 B4 cjne a, #OF,kill_card

Claims

REVENDICATIONS
1. Procédé de sécurisation de l'exécution d'un programme informatique (EXE) comportant un ensemble d'au moins une instruction, caractérisé en ce qu'il comporte :
- une première étape (E30) de calcul et de mémorisation, préalable à l'exécution dudit programme informatique, d'une première signature
(SIG1) représentative de l'exécution attendue dudit ensemble d'instructions;
- une deuxième étape (E50) de calcul et de mémorisation, au cours de l'exécution dudit ensemble d'instructions, d'une deuxième signature (SIG2) représentative de l'exécution dudit ensemble d'instructions ; et - une étape (E60) de détection d'une anomalie d'exécution dudit ensemble d'instructions à partir desdites première (SIG1) et deuxième (SIG2) signatures.
2. Procédé de sécurisation selon la revendication 1 , caractérisé en ce que ladite première étape (E30) de calcul et de mémorisation a lieu au cours de la génération des instructions (A1 , A13) dudit programme informatique.
3. Procédé de sécurisation selon la revendication 1 ou 2, caractérisé en ce que ladite deuxième signature (SIG2) mémorisée au cours de ladite deuxième étape de calcul et de mémorisation (E50) est conservée en mémoire pendant l'exécution d'au moins une deuxième instruction consécutive audit ensemble d'instructions.
4. Procédé de sécurisation selon l'une quelconque des revendications 1 à 3, caractérisé en ce que :
- la première signature (SIG1) est obtenue à partir du nombre d'instructions dudit ensemble d'instructions ;
- la deuxième signature (SIG2) est obtenue à partir du nombre d'instructions dudit ensemble d'instructions ayant été exécutées ; et en ce que -l'étape de détection (E60) détecte une anomalie d'exécution lorsque, à l'issue de l'exécution dudit ensemble d'instructions, la première (SIG1) et la deuxième (SIG2) signatures sont différentes.
5. Procédé de sécurisation selon l'une quelconque des revendications 1 à 3, caractérisé en ce que :
-la première signature (SIG1) est obtenue à partir du nombre d'instructions dudit ensemble d'instructions ;
-la deuxième signature (SIG2) est obtenue à partir du nombre d'instructions dudit ensemble d'instructions n'ayant pas été exécutées, cette deuxième signature (SIG2) étant calculée à partir de ladite première signature (SIG1) ; et en ce que
-l'étape de détection (E60) détecte une anomalie d'exécution lorsque, à l'issue de l'exécution dudit ensemble d'instructions, la deuxième signature (SIG2) est non nulle.
6. Procédé de sécurisation selon la revendication 5, caractérisé en ce que l'on déclenche une interruption dudit programme informatique lorsque ladite deuxième signature (SIG2) est inférieure à un seuil prédéterminé.
7. Procédé de sécurisation selon la revendication 5 ou la revendication 6, caractérisé en ce que la première (SIG1) et la deuxième (SIG2) signatures sont conservées en mémoire pendant l'exécution dudit programme dans le même registre (REG1).
8. Procédé de sécurisation selon l'une quelconque des revendications 1 à 3, caractérisé en ce que :
- la première signature (SIG1) est obtenue à partir du code d'une d'instruction critique dudit ensemble d'instructions ; -la deuxième signature est obtenue à partir du code de ladite instruction critique, ce code étant mémorisé simultanément ou consécutivement à l'exécution de ladite instruction critique ; et en ce que -l'étape de détection (E60) détecte une anomalie d'exécution lorsque, à l'issue de l'exécution dudit ensemble d'instructions, la première (SIG1) et la deuxième (SIG2) signatures sont différentes.
9. Procédé de sécurisation selon l'une quelconque des revendications 1 à 3, caractérisé en ce que :
- la première signature (SIG1) est obtenue à partir de l'adresse d'une d'instruction critique dudit ensemble d'instructions, ladite adresse étant obtenue pendant ou après la génération du code exécutable de l'ensemble d'instruction ;
-la deuxième signature (SIG2) est obtenue à partir de l'adresse de ladite instruction critique, cette adresse étant mémorisée (E30) simultanément ou consécutivement à l'exécution (E30) de ladite instruction critique ;
-l'étape de détection (E60) détecte une anomalie d'exécution lorsque, à l'issue de l'exécution dudit ensemble d'instructions, la première (SIG1) et la deuxième (SIG2) signatures sont différentes.
10 Procédé selon la revendication 8 ou 9 caractérisé en ce que ladite instruction critique est une instruction de saut (JMP, JNZ, CJNE, JZ).
11. Procédé de sécurisation selon l'une quelconque des revendications 1 à 3, caractérisé en ce que :
-la première (SIG1) et la deuxième (SIG2) signatures sont des codes (CRC1 , CRC2) détecteurs d'erreur calculés à partir du code ou d'une adresse d'au moins une instruction dudit ensemble d'instructions ; et en ce que
-l'étape de détection (E60) détecte une anomalie d'exécution lorsque, à l'issue de l'exécution dudit ensemble d'instructions, la première (SIG1) et la deuxième (SIG2) signatures sont différentes.
12. Procédé de sécurisation selon la revendication 11 , caractérisé en ce que lesdits codes détecteurs d'erreur (CRC1 , CRC2) sont des codes de redondance cyclique.
13 Procédé de sécurisation selon la revendication 11 , caractérisé en ce que lesdits codes détecteurs d'erreur sont obtenus par combinaison logique (XOR) à partir du code ou d'une adresse d'au moins une instruction dudit ensemble d'instructions.
14. Procédé de sécurisation selon l'une quelconque des revendications 1 à 3, caractérisé en ce que :
-la première signature (SIG1) et la deuxième signature (SIG2) sont obtenues, respectivement au cours de la génération et de l'exécution desdites instructions, à partir d'au moins deux éléments choisis parmi : -le nombre d'instructions dudit ensemble d'instructions; - le code d'au moins une instruction dudit ensemble d'instructions; - l'adresse d'au moins une instruction dudit ensemble d'instructions; et
- un code détecteur d'erreur calculé à partir du code ou d'une adresse d'au moins une instruction critique dudit ensemble d'instructions, ladite adresse étant obtenue pendant ou après la génération du code exécutable de l'ensemble d'instruction ; et en ce que -l'étape de détection (E60) détecte une anomalie d'exécution lorsque, à l'issue de l'exécution dudit ensemble d'instructions, la première (SIG1) et la deuxième (SIG2) signatures sont différentes.
15. Procédé de sécurisation selon l'une quelconque des revendications 1 à 14, caractérisé en ce qu'il comporte une étape (E70) de destruction d'au moins une partie du système sur lequel s'exécute ledit programme informatique, cette étape de destruction étant effectuée lorsque ladite étape de détection détecte ladite anomalie d'exécution.
16. Procédé de sécurisation selon l'une quelconque des revendications 1 à 15, caractérisé en ce que ladite première signature (SIG1) est générée automatiquement (E30).
17. Dispositif de traitement d'un programme informatique comportant un ensemble d'au moins une instruction, caractérisé en ce qu'il comporte -des moyens (12) de calcul et de mémorisation, préalablement à ladite exécution, d'une première signature (SIG1) représentative de l'exécution attendue dudit ensemble d'instructions.
18. Dispositif de traitement selon la revendication 17, caractérisé en ce que lesdits moyens (12) de calcul et de mémorisation de ladite première signature (SIG1) sont adaptés à calculer et mémoriser une information obtenue à partir du nombre d'instructions dudit ensemble d'instructions.
19. Dispositif de traitement selon la revendication 17, caractérisé en ce que par lesdits moyens (12) de calcul et de mémorisation de ladite première signature (SIG1) sont adaptés à obtenir et mémoriser une information obtenue à partir du code d'une d'instruction critique dudit ensemble d'instructions.
20. Dispositif de traitement selon l'une des revendications 17 à
19, caractérisé en ce qu'il comporte en outre des moyens (14) de génération d'un code exécutable à partir dudit programme informatique (SOURCE).
21. Dispositif de traitement selon la revendication 20, caractérisé en ce lesdits moyens de calcul et de mémorisation de ladite première signature (SIG1) sont adaptés à obtenir et mémoriser une information obtenue à partir de l'adresse d'une instruction critique dudit ensemble d'instructions, ladite information étant obtenue par lesdits moyens (14) de génération d'un code exécutable.
22. Dispositif de traitement selon la revendication 19 ou 21 , caractérisé en ce que ladite instruction critique est une instruction de saut (JMP, JNZ, CJNE, JZ).
23. Dispositif de traitement selon la revendication 17, caractérisé en ce que lesdits moyens (12) de calcul et de mémorisation de ladite première signature (SIG1) sont adaptés à calculer et mémoriser une information obtenue à partir d'un code détecteur d'erreur (CRC1 ) calculé à partir du code ou d'une adresse d'au moins une instruction dudit ensemble d'instructions.
24. Dispositif de traitement selon la revendication 23, caractérisé en ce que ledit code détecteur d'erreur (CRC1) est un code de redondance cyclique.
25. Dispositif de traitement selon la revendication 23, caractérisé en ce que ledit code détecteur d'erreur est obtenu par combinaison logique
(XOR) à partir du code ou d'une adresse d'au moins une instruction dudit ensemble d'instructions.
26. Dispositif de sécurisation de l'exécution d'un programme informatique comportant un ensemble d'au moins une instruction, caractérisé en ce qu'il comporte :
- un premier registre (REG1) de mémorisation d'une première signature (SIG1) représentative de l'exécution attendue dudit ensemble d'instructions; -des moyens (22) de calcul et de mémorisation, lors de l'exécution dudit ensemble d'instructions, d'une deuxième signature (SIG2) représentative de l'exécution dudit ensemble d'instructions, ladite mémorisation étant effectuée dans un deuxième registre (REG2) de mémorisation ;
-des moyens (24) de détection d'une anomalie d'exécution dudit ensemble d'instructions à partir desdites première (SIG1 ) et deuxième (SIG2) signatures.
27. Dispositif de sécurisation selon la revendication 26, caractérisé en ce que les moyens de calcul et de mémorisation sont adaptés à conserver ladite deuxième signature (SIG2) dans le deuxième registre (REG2) lors de l'exécution d'au moins une deuxième instruction consécutive audit ensemble d'instructions.
28. Dispositif de sécurisation selon la revendication 26 ou la revendication 27, caractérisé en ce que, ladite première signature (SIG1 ) étant obtenue à partir du nombre d'instructions dudit ensemble d'instructions, ladite deuxième signature (SIG2) calculée et mémorisée par lesdits moyens (22) de calcul et de mémorisation est obtenue à partir du nombre d'instructions dudit ensemble d'instructions ayant été exécutées, et en ce que lesdits moyens (24) de détection détectent une anomalie d'exécution lorsque, à l'issue de l'exécution dudit ensemble d'instructions, les première (SIG1) et deuxième signatures (SIG2) sont différentes.
29. Dispositif de sécurisation selon la revendication 26 ou la revendication 27, caractérisé en ce que, ladite première signature (SIG1) étant obtenue à partir du nombre d'instructions dudit ensemble d'instructions, ladite deuxième signature (SIG2) calculée et mémorisée par lesdits moyens (22) de calcul et de mémorisation est obtenue à partir du nombre d'instructions dudit ensemble d'instructions n'ayant pas été exécutées, cette deuxième signature (SIG2) étant calculée à partir de ladite première signature (SIG1), et en ce que lesdits moyens (24) de détection détectent une anomalie d'exécution lorsque, à l'issue de l'exécution dudit ensemble d'instructions, la deuxième signature (SIG2) est non nulle.
30. Dispositif de sécurisation selon la revendication 29, caractérisé en ce qu'il comporte en outre des moyens de déclenchement d'une interruption dudit programme informatique lorsque ladite deuxième signature (SIG2) est inférieure à un seuil prédéterminé.
31. Dispositif de sécurisation selon la revendication 29 ou la revendication 30, caractérisé en ce que les première (SIG1) et deuxième (SIG2) signatures sont mémorisées pendant l'exécution dudit programme dans ledit premier registre (REG1).
32. Dispositif de sécurisation selon la revendication 26 ou la revendication 27, caractérisé en ce que, ladite première signature (SIG1) étant obtenue à partir du code d'une d'instruction critique dudit ensemble d'instructions, ladite deuxième signature (SIG2) calculée et mémorisée par lesdits moyens (22) de calcul et de mémorisation est obtenue à partir du code de ladite instruction critique, ce code étant mémorisé simultanément ou consécutivement à l'exécution de ladite instruction critique, et en ce que lesdits moyens de détection (24) détectent une anomalie d'exécution lorsque, à l'issue de l'exécution dudit ensemble d'instructions, la première (SIG1) et la deuxième (SIG2) signatures sont différentes.
33. Dispositif de sécurisation selon la revendication 26 ou la revendication 27, caractérisé en ce que, ladite première signature (SIG1) étant obtenue à partir de l'adresse d'une d'instruction critique dudit ensemble d'instructions, ladite deuxième signature (SIG2) calculée et mémorisée par lesdits moyens (22) de calcul et de mémorisation étant obtenue à partir de l'adresse de ladite instruction critique, cette adresse étant mémorisée simultanément ou consécutivement à l'exécution de ladite instruction critique, et en ce que lesdits moyens de détection détectent une anomalie d'exécution lorsque, à l'issue de l'exécution dudit ensemble d'instructions, les première et deuxième signatures sont différentes.
34. Dispositif de sécurisation selon la revendication 32 ou la revendication 33, caractérisé en ce que ladite instruction critique est une instruction de saut (JMP, JNZ, CJNE, JZ).
35. Dispositif de sécurisation selon la revendication 26 ou la revendication 27, caractérisé en ce que, lesdites première (SIG1) et deuxième (SIG2) signatures étant des codes détecteurs d'erreur (CRC1 , CRC2) calculés à partir du code d'au moins une instruction dudit ensemble d'instructions, lesdits moyens de détection (24) détectent une anomalie d'exécution lorsque, à l'issue de l'exécution dudit ensemble d'instructions, la première (SIG1) et la deuxième (SIG2) signatures sont différentes.
36. Dispositif de sécurisation selon la revendication 35, caractérisé en ce que lesdits codes détecteurs d'erreur (CRC1 , CRC2) sont des codes de redondance cyclique.
37. Dispositif de sécurisation selon la revendication 35 caractérisé en ce que lesdits codes détecteurs d'erreur sont obtenus par combinaison logique (XOR) à partir du code ou d'une adresse d'au moins une instruction dudit ensemble d'instruction.
38. Dispositif de sécurisation selon la revendication 26 ou la revendication 27 caractérisé en ce que caractérisé en ce que ladite première signature (SIG1) étant obtenue à partir d'au moins deux éléments choisis parmi :
-le nombre d'instructions dudit ensemble d'instructions; -le code d'au moins une instruction dudit ensemble d'instructions; -l'adresse d'au moins une instruction dudit ensemble d'instructions; et
- et un code détecteur d'erreur calculé à partir du code ou de l'adresse d'au moins une instruction dudit ensemble d'instructions, ladite deuxième signature (SIG2) calculée et mémorisée par lesdits moyens (22) de calcul et de mémorisation est obtenue, de façon similaire, à partir desdits au moins deux éléments au cours de l'exécution desdites instructions et en ce que lesdits moyens (24) de détection détectent une anomalie d'exécution lorsque, à l'issue de l'exécution dudit ensemble d'instructions, la première (SIG1) et la deuxième signatures (SIG2) sont différentes.
39. Dispositif de sécurisation selon l'une quelconque des revendications 26 à 38 caractérisé en ce qu'il comporte en outre des moyens de destruction d'au moins une partie dudit programme informatique.
40. Carte à microcircuit caractérisé en ce qu'il comporte un dispositif de sécurisation (100) selon l'une quelconque des revendications 26 à 39.
PCT/FR2003/003658 2002-12-20 2003-12-10 Procede et dispositif de securisation de l'execution d'un programme informatique WO2004066127A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US10/540,219 US9092618B2 (en) 2002-12-20 2003-12-10 Method and device for making secure execution of a computer programme
AU2003296805A AU2003296805A1 (en) 2002-12-20 2003-12-10 Method and device for making secure execution of a computer programme

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR02/16376 2002-12-20
FR0216376A FR2849226B1 (fr) 2002-12-20 2002-12-20 Procede et dispositif de securisation de l'execution d'un programme informatique.

Publications (1)

Publication Number Publication Date
WO2004066127A1 true WO2004066127A1 (fr) 2004-08-05

Family

ID=32406299

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2003/003658 WO2004066127A1 (fr) 2002-12-20 2003-12-10 Procede et dispositif de securisation de l'execution d'un programme informatique

Country Status (4)

Country Link
US (1) US9092618B2 (fr)
AU (1) AU2003296805A1 (fr)
FR (1) FR2849226B1 (fr)
WO (1) WO2004066127A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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é

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2869486B1 (fr) * 2004-04-21 2007-08-31 Oberthur Card Syst Sa Procede de traitement de donnees securise et dispositif associe
US7890762B2 (en) * 2004-12-30 2011-02-15 Sap Ag Differentiated proxy digital signatures
EP1717704A3 (fr) 2005-04-20 2011-07-20 St Microelectronics S.A. Protection du déroulement d'un programme exécuté par un circuit intégré
FR2885709A1 (fr) * 2005-05-10 2006-11-17 St Microelectronics Sa Controle d'integrite d'une memoire externe a un processeur
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
EP1783648A1 (fr) * 2005-10-10 2007-05-09 Nagracard S.A. Microprocesseur sécurisé avec vérification des instructions
FR2895814A1 (fr) * 2006-01-04 2007-07-06 Gemplus Sa Procede de securisation de l'execution d'un programme d'ordinateur
FR2898704B1 (fr) * 2006-03-14 2008-06-06 Proton World Internatinal Nv Protection d'un programme contre un deroutement
DE102006037810A1 (de) * 2006-08-11 2008-02-14 Giesecke & Devrient Gmbh Sichere Programmcodeausführung
DE102007015369A1 (de) * 2006-12-29 2008-07-03 Endress + Hauser Gmbh + Co. Kg Verfahren zur Überwachung des logischen Programmablaufs von kritischen Funktionen in Programmen eines Feldgeräts der Prozess- und Automatisierungstechnik
US20080209559A1 (en) * 2007-02-22 2008-08-28 Aladdin Knowledge Systems Method for detecting that a protected software program is cracked
US8099718B2 (en) * 2007-11-13 2012-01-17 Intel Corporation Method and system for whitelisting software components
DE102011005209B4 (de) 2011-03-07 2016-06-23 Infineon Technologies Ag Programmanweisungsgesteuerte Instruktionsflusskontrolle
US20120324446A1 (en) * 2011-06-17 2012-12-20 Microsoft Corporation Virtual machine image composition and signing
FR2977342A1 (fr) * 2011-06-30 2013-01-04 Proton World Int Nv Verification d'integrite d'un programme execute par un circuit electronique
EP2831738A4 (fr) * 2012-03-29 2015-11-18 Intel Corp Système et procédé de détermination d'une exécution correcte d'un logiciel
DE102012010102A1 (de) * 2012-05-22 2013-11-28 Infineon Technologies Ag Verfahren und Vorrichtung zur Datenverarbeitung
US9003236B2 (en) * 2012-09-28 2015-04-07 Intel Corporation System and method for correct execution of software based on baseline and real time information
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
FR3035240B1 (fr) * 2015-04-15 2018-04-06 Rambus Inc. Procede de securisation de l'execution d'un programme
DE102015112143B4 (de) 2015-07-24 2017-04-06 Infineon Technologies Ag Ein Verfahren zum Bestimmen einer Integrität einer Ausführung eines Codefragments und ein Verfahren zum Bereitstellen einer abstrahierten Repräsentation eines Programmcodes
US10169251B1 (en) * 2015-12-10 2019-01-01 Massachusetts Institute Of Technology Limted execution of software on a processor
FR3098319A1 (fr) * 2019-07-05 2021-01-08 Commissariat à l'énergie atomique et aux énergies alternatives Procédé d'exécution d'un code binaire d'une fonction sécurisée par un microprocesseur

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5974529A (en) * 1998-05-12 1999-10-26 Mcdonnell Douglas Corp. Systems and methods for control flow error detection in reduced instruction set computer processors
WO2000054155A1 (fr) * 1999-03-09 2000-09-14 Gemplus Procede de surveillance du deroulement d'un programme
EP1056012A2 (fr) * 1999-05-27 2000-11-29 Harness System Technologies Research, Ltd. Appareil pour détecter l'exécution anormale d'un programme
WO2001097010A2 (fr) * 2000-06-12 2001-12-20 Koninklijke Philips Electronics N.V. Procede et dispositif de traitement de donnees servant a proteger l'execution d'instructions

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5574871A (en) * 1994-01-04 1996-11-12 Intel Corporation Method and apparatus for implementing a set-associative branch target buffer
GB9504743D0 (en) * 1995-03-09 1995-04-26 Int Computers Ltd Jump prediction
US6282675B1 (en) * 1997-08-06 2001-08-28 Macronix International Co., Ltd. Fault-tolerant architecture for in-circuit programming
US20010010331A1 (en) * 1996-12-31 2001-08-02 Michel Hazard Process for protecting a security module, and associated security module
US5983348A (en) * 1997-09-10 1999-11-09 Trend Micro Incorporated Computer network malicious code scanner
US6256753B1 (en) * 1998-06-30 2001-07-03 Sun Microsystems, Inc. Bus error handling in a computer system
FR2787900B1 (fr) * 1998-12-28 2001-02-09 Bull Cp8 Circuit integre intelligent
US6651171B1 (en) * 1999-04-06 2003-11-18 Microsoft Corporation Secure execution of program code
US7330978B1 (en) * 1999-04-08 2008-02-12 Microsoft Corporation Encrypted software installer
US7406603B1 (en) * 1999-08-31 2008-07-29 Intertrust Technologies Corp. Data protection systems and methods
US6829710B1 (en) * 2000-03-14 2004-12-07 Microsoft Corporation Technique for producing, through watermarking, highly tamper-resistant executable code and resulting “watermarked” code so formed
US6954747B1 (en) * 2000-11-14 2005-10-11 Microsoft Corporation Methods for comparing versions of a program
US7036111B2 (en) * 2001-06-01 2006-04-25 Hewlett-Packard Development Company, L.P. Code verification system and method
US7581103B2 (en) * 2001-06-13 2009-08-25 Intertrust Technologies Corporation Software self-checking systems and methods
US20030126454A1 (en) * 2001-12-28 2003-07-03 Glew Andrew F. Authenticated code method and apparatus
US7228426B2 (en) * 2002-04-03 2007-06-05 Microsoft Corporation Integrity ordainment and ascertainment of computer-executable instructions with consideration for execution context
US7086088B2 (en) * 2002-05-15 2006-08-01 Nokia, Inc. Preventing stack buffer overflow attacks
US6907522B2 (en) * 2002-06-07 2005-06-14 Microsoft Corporation Use of hashing in a secure boot loader
EP1429224A1 (fr) * 2002-12-10 2004-06-16 Texas Instruments Incorporated Autentification du firmware en temps d'exécution
US7594111B2 (en) * 2002-12-19 2009-09-22 Massachusetts Institute Of Technology Secure execution of a computer program
US7603704B2 (en) * 2002-12-19 2009-10-13 Massachusetts Institute Of Technology Secure execution of a computer program using a code cache
US7565551B2 (en) * 2003-02-19 2009-07-21 Microsoft Corporation Enhancing software integrity through installation and verification
US7325165B2 (en) * 2003-05-30 2008-01-29 Broadcom Corporation Instruction sequence verification to protect secured data
WO2006131921A2 (fr) * 2005-06-08 2006-12-14 Discretix Technologies Ltd. Procede, dispositif et systeme de conservation de contexte d'un environnement d'execution securise
JP4795812B2 (ja) * 2006-02-22 2011-10-19 富士通セミコンダクター株式会社 セキュアプロセッサ

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5974529A (en) * 1998-05-12 1999-10-26 Mcdonnell Douglas Corp. Systems and methods for control flow error detection in reduced instruction set computer processors
WO2000054155A1 (fr) * 1999-03-09 2000-09-14 Gemplus Procede de surveillance du deroulement d'un programme
EP1056012A2 (fr) * 1999-05-27 2000-11-29 Harness System Technologies Research, Ltd. Appareil pour détecter l'exécution anormale d'un programme
WO2001097010A2 (fr) * 2000-06-12 2001-12-20 Koninklijke Philips Electronics N.V. Procede et dispositif de traitement de donnees servant a proteger l'execution d'instructions

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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é
US8315382B2 (en) 2009-06-08 2012-11-20 Nagravision S.A. Method for monitoring execution of data processing program instructions in a security module

Also Published As

Publication number Publication date
AU2003296805A1 (en) 2004-08-13
FR2849226A1 (fr) 2004-06-25
US9092618B2 (en) 2015-07-28
US20060156005A1 (en) 2006-07-13
FR2849226B1 (fr) 2005-12-02

Similar Documents

Publication Publication Date Title
WO2004066127A1 (fr) Procede et dispositif de securisation de l'execution d'un programme informatique
EP1161725B1 (fr) Procede de surveillance du deroulement d'un programme
FR3000249A3 (fr) Systeme et procede de detection d'un code malveillant execute par une machine virtuelle
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
EP1538509A1 (fr) Procédé de sécurisation de l'éxécution d'un programme contre des attaques par rayonnement
FR2877118A1 (fr) Protection contre les attaques par generation de fautes sur les instructions de saut
WO2007068706A1 (fr) Procede pour securiser l'execution d'un code logiciel en langage intermediaire dans un appareil portatif
EP1644797B1 (fr) Procede de securisation de l'execution d'un programme informatique, notamment dans une carte a microcircuit
FR2765363A1 (fr) Procede et systeme de controle de l'utilisation d'un logiciel
WO2007077142A2 (fr) Procede de securisation de l'execution d'un programme d'ordinateur
FR2888960A1 (fr) Detection d'une faute par perturbation longue
EP2652664A1 (fr) Procede dynamique de controle de l'integrite de l'execution d'un code executable
WO2008125479A1 (fr) Procédé d'exécution sécurisée d'une application
EP4131041B1 (fr) Procédé de vérification d'une exécution d'un programme logiciel
EP1357459B1 (fr) Processeur securisé contre les deroutements
EP2860669B1 (fr) Procédé mis en oeuvre dans un microcircuit et dispositif associé
FR2879781A1 (fr) Procede et dispositif de remplissage de securisation d'une memoire et memoire associee
EP3203405B1 (fr) Procede d'execution d'instructions d'applications orientees objet par un interpreteur
FR3147397A1 (fr) Système informatique configuré pour exécuter un programme d’ordinateur
EP4430503A1 (fr) Procédé de détection d'une tentative d'extraction linéaire du contenu d'une mémoire
EP4177780A1 (fr) Procede de detection d'une tentative d'extraction lineaire du contenu d'une memoire
FR3140186A1 (fr) Procédé de détection d’une tentative d’extraction linéaire du contenu d’une mémoire
FR3116356A1 (fr) Procédé de compilation d’un code source
FR3011650A1 (fr) Procede et dispositif de realisation de fonction par un microcircuit
FR2980600A1 (fr) Procede et systeme de securisation d'une application logicielle comprenant une instruction conditionnelle basee sur une variable booleenne

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG 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 MZ NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

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

121 Ep: the epo has been informed by wipo that ep was designated in this application
ENP Entry into the national phase

Ref document number: 2006156005

Country of ref document: US

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 10540219

Country of ref document: US

122 Ep: pct application non-entry in european phase
WWP Wipo information: published in national office

Ref document number: 10540219

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP