WO2005101725A1 - Procede d'authentification dynamique de programmes par un objet portable electronique - Google Patents

Procede d'authentification dynamique de programmes par un objet portable electronique Download PDF

Info

Publication number
WO2005101725A1
WO2005101725A1 PCT/EP2005/050828 EP2005050828W WO2005101725A1 WO 2005101725 A1 WO2005101725 A1 WO 2005101725A1 EP 2005050828 W EP2005050828 W EP 2005050828W WO 2005101725 A1 WO2005101725 A1 WO 2005101725A1
Authority
WO
WIPO (PCT)
Prior art keywords
instruction
xμp
phase
instructions
execution
Prior art date
Application number
PCT/EP2005/050828
Other languages
English (en)
Inventor
Benoit Chevallier-Mames
David Naccache
Pascal Paillier
Original Assignee
Gemplus
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gemplus filed Critical Gemplus
Priority to EP05716818A priority Critical patent/EP1728354A1/fr
Priority to US10/593,411 priority patent/US20080232582A1/en
Publication of WO2005101725A1 publication Critical patent/WO2005101725A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/30—Compression, e.g. Merkle-Damgard construction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • This patent describes a method for dynamically authenticating the contents of an executable program, that is to say the sequence of instructions that it defines. More specifically, the authentication of a program is performed repeatedly during the actual execution of said program.
  • the operating principle of the invention allows to design a new type of secure element called "Externalized Microprocessor" where X ⁇ P which, unlike other computing devices such as smart card ⁇ object of many patents such as for example .2 266 222) does not contain a program memory (conventionally called ROM, of the English “Read Only Memory”).
  • ROM of the English "Read Only Memory”
  • a smart card is a miniature computer.
  • a small random memory RAM on the "Random Access Memory" embedded with the microprocessor is used to store the temporary results of a calculation and the microprocessor of the chip executes a program written in a non-modifiable way in the ROM: one skilled in the art uses the term etching, this etching having been carried out in the so-called masking step. This program can not be modified in any way.
  • the chips For the storage of user-specific data, the chips contain a non-volatile memory EEPROM (for "Electrically Erasable and Programmable ROM”) or Flash, both types of memory can authorize both reads and writes by hundreds of thousands.
  • EEPROM Electrically Erasable and Programmable ROM
  • Flash Flash
  • Java cards special smart cards, even allow the import of executable programs (called “applets”, acronym for English) in their non-volatile memory according to the needs of the cardholder.
  • the latest generation of Java cards include a linker, a loader, a Java virtual machine, remote method invocation modules. " in English) , an applet checker ("bytecode check”), a firewall for resident Java applications (“applet firewall”), a garbage collector, cryptographic libraries, complex stack managers, and so on.
  • a smart card includes a communication port for exchanging data and control information with the outside world.
  • a typical communication rate is 9,600 bits per second, but much faster rates compatible with the International Organization for Standardization (ISO) standard are generally used (from 19,200 up to 115,200 bits per second).
  • ISO International Organization for Standardization
  • the advent of the USB protocol in the smart card world opens up new horizons and makes it possible to easily reach speeds of the order of megabit per second. In this context, it becomes worthwhile to extract the ROM memory operating model of the smart card, and rely on an ultra-fast communication protocol to transmit when necessary the programs it previously contained.
  • having a mobile device execute an executable program transmitted by a potentially unsafe and malicious terminal poses significant security problems.
  • HASH hash functions
  • HASHi HASH 2 and HASH 3 in the patent.
  • these functions are defined by a so-called compression function.
  • HASH is said to be a hash function defined by an H compression function and an IV (initialization vector) constant, when the following definition applies: H (HASH (ai, ..., a k _ ⁇ ), a k ) with the following special case: the integers ai, a 2 , ..., a k denoting here the arguments of the hash function.
  • FIG. 1 describes the dynamic semantics of an example of a set of instructions called XJVML that allows to illustrate in a nonlimiting manner the various embodiments of the invention.
  • FIG. 1 describes the dynamic semantics of an example of a set of instructions called XJVML that allows to illustrate in a nonlimiting manner the various embodiments of the invention.
  • FIG. 2 describes the naive method of the state of the art that makes it possible, unsurprisingly, to execute a program P supplied by the outside world to the X ⁇ P.
  • Figure 3 describes a security policy in XJVML according to the invention, allowing the reading and writing of so-called public data.
  • Figure 4 describes a security policy in XJVML according to the invention, allowing only the reading of so-called public data.
  • Figure 5 explains the management of the security policy during the execution of the program P.
  • INSi 2 INS 2 3
  • F INS F
  • XJVML a set of instruction which will serve to illustrate the embodiments of the invention.
  • XJVML describes a simplistic architecture based on the JVMLO virtual processor defined in the document R. Stata and M. Abadi entitled in English "A type System for Java Bytecode Subroutines" published in the referenced document SRC Research Report 158 on 11/06/1998 available at the following e-mail address: ttp: // www. researc. digital. com / SRC /.
  • the architecture on which XJVML operates is similar to the computational model known to those skilled in the art as von Neumann's, except that it does not contain program memory.
  • the architecture of XJVML includes: a volatile memory called RAM, a nonvolatile memory called NVM, - a random number generator called RNG, an operand stack called ST, a communication port (also called input / output) called 10.
  • the instruction set of XJVML is defined by the following instructions, where x denotes an immediate data, L is the address of an instruction with 1 ⁇ L ⁇ F and F is the instruction number of the program considered. :
  • the * load 10 'instruction captures the data presented on the communication port and the stack while the instruction x store 10 'staple the upper data of the stack and copy it on the port 10.
  • the load RNG' instruction produces a random number and stacks it.
  • the xor 'instruction unpacks the top two stack data, calculates the XOR (OR EXCLUSIVE) of that data, and stacks the result.
  • the effect of the instruction ⁇ dec ' is the exact opposite of that of the instruction ⁇ inc', that is to say that the superior data is decremented by 1.
  • the instruction ⁇ mul 'depiles the two superior data multiply them and stack the two data representing the result in the form of two words, one of high weight, the other of low weight.
  • the goto instruction L ' is a simple jump to the program address L.
  • the instruction ⁇ div' unpacks the two upper data, divides the lower of these two data (the numerator) by the highest data in the stack (the denominator), and stack the data resulting from the quotient evaluation. It should be noted that if, for the instruction ⁇ div ', the denominator is null, an exception is executed, and the program counter is reset to the start address of the exception, called AdExcDiv later. This exception is called the "division by zero" exception.
  • Terminal " ie the terminal which communicates with the
  • each terminal XT (which is said to be insecure and possibly malicious) is in the form of a sequence of instructions:
  • INSi 2 INS 2 3
  • F INS F
  • the principle of the exchange between the X ⁇ P and the XT is very simple: when the execution starts, the X ⁇ P initializes to 1 its counter of program, referenced below by the variable i, and requests the instruction of address i at XT. The X ⁇ P executes INSi, thereby updating its internal state and thereby determining the new value of the program counter. The program counter i and the INSi address merge during program execution. Thus, when executing the program, i will designate the address equally as the program counter. This process is repeated until the end of program instruction is reached.
  • the invention relates to a method of securing an electronic portable object X ⁇ P executing a program P provided by another insecure electronic object XT, characterized in that it uses: a secret key protocol; - an ephemeral secret key K; a MAC ⁇ ⁇ function ; a hash function HASHi defined by a compression function Hi and a constant IVi; a hash function HASH 2 defined by a compression function H 2 and a constant IV 2 ; an identifier of program ID stored in the electronic object X ⁇ P and worth a hash of P.
  • this method of securing an electronic portable object is characterized in that the program P is provided under the form of a sequence of F instructions, F denoting the number of instructions of this program P.
  • the value of ID which corresponds to the hash of the program P, is calculated by hashing, one by one, the instructions, in ascending order of addresses.
  • the first part of the invention is characterized in that said protocol comprises the following phases: a) an initialization phase during which the X ⁇ P generates an ephemeral key K, then receives the entire program P from the XT, the number of instructions F and its identifier ID, calculates the hash h of this program P with the function HASH X , using the compression function Hi and the constant IVi, and finally generates signatures ⁇ t using the function ⁇ ⁇ and the key K, signatures ⁇ (which it transmits to the XT; an execution phase during which the X ⁇ P checks the equality between the values of h and of ID, also verifies that ID is stored in its non-volatile memory, then requests, one after the other, the instructions of P for execute them, and for some of them, performs a verification sub-phase which consists in asking for a signature ⁇ , constructed from the signatures ⁇ .
  • the method for securing an electronic portable object is characterized in that the verification sub-phase in the execution phase is a verification of the signature ⁇ taking place before the execution of each instruction. .
  • this first embodiment is characterized in that the execution phase comprises the following sub-phases: b-1) the X ⁇ P requests an instruction to the XT; b-2) the X ⁇ P requires a signature ⁇ constructed from the signatures ⁇ ,. generated during the initialization phase and using the HASH 2 function, and, in case of non-validity of this signature ⁇ , executes the reaction phase; b-3) the X ⁇ P executes the instruction and returns to the sub-phase b-1.
  • the first mode of securing an electronic portable object according to the invention is characterized in that it uses a secret key protocol comprising the following steps: -2.
  • the X ⁇ P generates a session random key K, asks the XT for the identifier ID of the program, the number of instructions F that it contains and initialises hi-IV ⁇ -1. For i ⁇ - 1 to F (a) The X ⁇ P asks the XT for instruction number i (b) The XT sends the INS instruction. X ⁇ P (c) The X ⁇ P calculates the signature ⁇ ,. ⁇ - ⁇ ⁇ ID.IN.INS.) and updates h ⁇ r- _Q r 1 (A, ZMS , J. ) (D) The X ⁇ P sends G t to the XT (no copy of 0 " ( .
  • the XT records O t 0.
  • the X ⁇ P initializes V ⁇ - IV 2 2.
  • the XT initializes O " A IV 2 3.
  • the X ⁇ P asks the XT the instruction number i 4.
  • the XT (a) updates ⁇ ⁇ - H 2 ( ⁇ , ⁇ .) (B) sends INS ,. to X ⁇ P 5.
  • the X ⁇ P updates VAH 2 (V, ⁇ ⁇ (ID, i, INS i )) 6.
  • the X ⁇ P knows that the program provided is a non-authentic program, and therefore takes all the necessary protective defensive measures.
  • IV X and IV 2 denote the initial vectors of the hash functions ⁇ AS ⁇ i and ⁇ AS ⁇ 2 ; i is always the value representing the program counter; o * designates the signature of the INSi instruction. It is recalled that the execution of INSi modifies the value of i.
  • the letters h, V and ⁇ denote variables of the protocol whose use is explained in what follows. The protocol above includes different steps. We denoted by (-2) and (-1) the so-called negative steps which take place before the execution of the program P and by (0) to (7) the so-called positive stages which take place during the execution of the program P In step (-2), the X ⁇ P randomly generates an ephemeral key K.
  • Step (-1) is a loop on the program addresses i. It consists of sub-steps. • In the sub-step (-la), the X ⁇ P asks XT for the address instruction i • In the sub-step (-lb), the XT sends the requested instruction to X ⁇ P • In the sub-step (-lc) , the X ⁇ P calculates the symmetric signature (also called signature or MAC) ⁇ of the instruction. In addition, the X ⁇ P accumulates the hash of the program in the value h by means of the compression function Hi.
  • a random number generator random number generator
  • the MAC ⁇ i is sent by X ⁇ P to XT.
  • the MAC G ⁇ received from the X ⁇ P is stored by the XT.
  • the steps taking place during the execution of the program P proceed subsequently.
  • the X ⁇ P verifies that the final value of h (calculated during the loop of the step (-1)) is equal to to the ID value, stored in its non-volatile memory. Thanks to the non-collision property of the hash function, the
  • step (0) the program counter i is initialized to 1. If the value of h differs from that of ID, the program sent is not authentic, and section (7) is executed: the X ⁇ P then takes the appropriate measures against the supposed aggression (for example, the X ⁇ P erases its memory). Steps (1), (2), (3), (4), (5), (6) are then repeated a number of times, until the final instruction is executed. This loop method is explained in the following.
  • step (1) the X ⁇ P initializes the variable V to IV 2 .
  • step (2) the XT initializes the variable ⁇ to IV 2 .
  • step (3) the X ⁇ P requests the XT address instruction i.
  • step (4) the XT updates the variable ⁇ and sends the requested instruction to the X ⁇ P.
  • step (5) the X ⁇ P updates the variable V.
  • Step (6) is the critical step for security.
  • Substeps (6.a), (6.b) and (6.c) are performed.
  • the substep (6.a) is a substep during which the X ⁇ P asks the XT to send it the collective signature ⁇ .
  • X ⁇ P then compares with the value V that it has calculated before. If these values differ, the received program P is not authentic and step (7) is then executed: the X ⁇ P then takes the appropriate measures against this aggression. If these values are equal, the X ⁇ P continues executing the protocol by executing the received instruction and returning to step (1).
  • the X ⁇ P itself signs the program sent to it with the help of an ephemeral key K, while checking that it is correct by comparing the hash of the program sent to it. identifier that it contains in its memory (ID).
  • ID identifier that it contains in its memory
  • step (- 1) a program other than that of identifier ID without being detected in step (0), the makes the property of non-collision of the hash function. Consequently, during the execution of the positive steps, the XT can only send instructions signed by the X ⁇ P during the execution of the negative steps, that is to say the instructions corresponding to the program; otherwise, if the XT tries to send different instructions, it will not be able to send the correct signature during the verification because it can not calculate by itself the signatures of other instructions because it does not know the signature key K.
  • This solution is safe, but may be subject to improvement.
  • the first mode is the subject of an improvement which is a second embodiment of dynamic verification of the program P which is sent to the X ⁇ P.
  • this second embodiment only certain instructions trigger a verification of the collective signature ⁇ .
  • the execution of the xor 'instruction does not reveal information on the two elements of the top of the stack that could be observed from outside the X ⁇ P. Since traceable instruction execution can reveal information about internal program values, these instructions are by definition critical to security, so we include them in S.
  • S For example, in our illustrative XJVML instruction set, only the instructions x if L 'and iv' are traceable and the set S is thus defined as below:
  • the instruction x store 10 ' is in S because it could trigger the emission of an electrical signal to the outside (through the input-output port).
  • the putstatic instruction x ' is also in S because it can perform a modification of the non-volatile memory.
  • the classification of the instructions for defining S thus leads to the second embodiment of the invention as described in the following section.
  • the method of securing an electronic portable object is characterized in that the verification sub-phase in the execution phase is a verification of the signature ⁇ taking place before the execution of the instruction, if it is a safety critical instruction.
  • the method of securing an electronic portable object is characterized in that the execution phase comprises the following sub-phases: b-1) the X ⁇ P requests an instruction to the XT; b-2) if this instruction is critical for security, then the X ⁇ P requires a signature ⁇ constructed from the signatures ⁇ ,. generated during the initialization phase and using the HASH 2 function, and, in case of non-validity of this signature ⁇ , executes the reaction phase; b-3) the X ⁇ P executes the instruction and returns to the sub-phase b-1.
  • the method of securing an electronic portable object is characterized in that it uses a set of critical instructions for the security S and in that the protocol comprises the following steps: -2.
  • the X ⁇ P generates a session random key K, asks the XT for the identifier ID of the program, the number of instructions F that it contains and initializes h * - IV 1 -1.
  • the X ⁇ P asks the XT for instruction number i
  • the XT sends the INS statement.
  • X ⁇ P (c) The X ⁇ P calculates the signature ⁇ ,.
  • the X ⁇ P initializes VA IV 2
  • IVi and IV 2 denote the initial vectors of the hash functions HASHi and
  • HASH 2 HASH 2 ; i always denotes the value representing the program counter; G ⁇ designates the signature of the INSi instruction. It is recalled that the execution of INSi modifies the value of i.
  • the letters h, v and ⁇ denote variables of the protocol whose use is explained in what follows.
  • the protocol consists of different stages. We denoted by (-2) and (-1) the so-called negative steps which take place before the execution of the program P and by (0) to (8) the so-called positive stages which take place during the execution of the program P
  • step (-2) the X ⁇ P randomly generates an ephemeral key K. This random generation can be done using a random number generator ("random number generator" in English) hardware or using some other means.
  • Step (-1) is a loop on the program addresses i. It consists of sub-steps. • In the sub-step (-la), the X ⁇ P asks XT for the address instruction i • In the sub-step (-lb), the XT sends the requested instruction to X ⁇ P • In the sub-step (-lc) , the X ⁇ P calculates the symmetric signature (also called signature or MAC) G ⁇ of the instruction. In addition, the X ⁇ P accumulates the hash of the program in the value h by means of the compression function H x . • In the sub-step (-ld), the MAC G ⁇ is sent by X ⁇ P to XT.
  • the MAC G ⁇ is sent by X ⁇ P to XT.
  • the MAC G ⁇ received from the X ⁇ P is stored by the XT.
  • the steps that take place during the execution of the program P proceed subsequently.
  • the X ⁇ P verifies that the final value of h calculated during the loop of the step (-1) is equal to the the identifier ID, stored in its non-volatile memory.
  • the X ⁇ P is thus certain that the program for which it has calculated the sequence of G ⁇ MACs during the negative steps is actually allowed to run.
  • the program counter i is initialized to 1. If the value of h differs from that of ID, the program sent is not authentic, and the section (8) is executed: the X ⁇ P then takes the appropriate measures against the supposed aggression (for example, the X ⁇ P erases its memory). Steps (1), (2), (3), (4), (5), (6), (7) are then repeated a number of times, until the final instruction is executed. This loop method is explained in the following.
  • the X ⁇ P initializes the variable V to IV 2 .
  • step (2) the XT initializes the variable ⁇ to IV 2 .
  • step (3) the X ⁇ P requests the XT address instruction i.
  • step (4) the XT updates the variable ⁇ and sends the requested instruction to the X ⁇ P.
  • step (5) the X ⁇ P updates the variable V.
  • Step (6) is the critical step for security. This one starts with a test first. • If the received instruction INSi is in the set of instructions critical for security S, sub-steps (6.a), (6.b) and ⁇ 6.c) are performed. The substep (6.a) is a substep during which the X ⁇ P asks the XT to send it the collective signature ⁇ .
  • step (8) the X ⁇ P then takes the appropriate measures against this attack (for example, the X ⁇ P re-initializes its memory). If these values are equal, the X ⁇ P continues executing the protocol by executing the received instruction and returning to step (1).
  • step (7) the X ⁇ P simply executes INSi and continues to execute the process returning to step (3).
  • the X ⁇ P itself signs the program that is sent to it (again with an ephemeral key), while checking that it is authentic by comparing the hash of the program sent to it. program identifier it contains in its memory (ID).
  • the process allows to collectively verify, at the appropriate times (ie for all safety critical instructions, listed in the S set), that the signatures provided by the XT are identical to those that the X ⁇ P had calculated in the steps negative.
  • step (- 1) a program different from that of identifier ID not detected in step (0) because of the hash function's non-collision property. Consequently, during the execution of the positive steps, the XT can only send instructions signed by the X ⁇ P during the execution of the negative steps, that is to say the instructions corresponding to the program; otherwise, if the XT tries to send different instructions, it will not be able to send the correct signature during the verification because it can not calculate by itself the signatures of other instructions because it does not know
  • step (- 1) a program different from that of identifier ID not detected in step (0) because of the hash function's non-collision property.
  • a security level is associated with each of the data manipulated by the X ⁇ P. It makes it possible to distinguish a secret datum (for example a cryptographic key stored in non-volatile memory) from a public datum (known or that can be recalculated from known data).
  • a secret datum for example a cryptographic key stored in non-volatile memory
  • public datum known or that can be recalculated from known data.
  • the security level is implemented in the form of an information bit ⁇ according to the convention that its value is zero when the data concerned is public and one when it is secret. More specifically, the implementation of the method relates to volatile memory cells (RAM), non-volatile (NVM) and stack cells (ST).
  • RAM volatile memory cells
  • NVM non-volatile
  • ST stack cells
  • the security bits of the NVM cells are nonvolatile and set to 0 or 1 by the X ⁇ P manufacturer at the production or customization stage, depending on the nature of the corresponding nonvolatile data.
  • Those of the RAM memory are initialized to 0 when the device is reset.
  • ⁇ (IO) is left constant at 0
  • ⁇ (RNG) is left constant at 1.
  • the security bits of the disused stack elements are automatically reset to 0.
  • the second rule is applied to arithmetic and logical instructions. It defines each security bit of the output variables of the instruction concerned as the logical OR of the security bits of all the input variables of the instruction. In other words, as soon as a secret data enters the calculation, all the resulting data is listed as secret.
  • This rule can notably but not only be easily wired in hardware like a simple boolean OR ("OR", denoted V in Figure 5) for the binary instructions (that is to say with two input arguments). For the sake of clarity, in Figure 5 we provide the dynamic semantics of XJVML statements on ⁇ .
  • any set of instructions, and the rules allowing to define over time all the security levels ⁇ of the data used by the execution of a program we associate with it the process of the invention such as as described by its second embodiment.
  • the principle of the third embodiment is based on the fact that the collective verification of the instructions issued by the XT, hitherto triggered by the detection of a safety-critical instruction, can be avoided if this instruction does not use example that data listed as public.
  • a MAC verification is not necessarily invoked in this case since the danger inherent in the execution of an instruction Critical is canceled by the fact that it can provide information only on previously known data or modify such data.
  • Alert denotes the Boolean function (that is, returning TRUE or FALSE) which determines whether or not the execution of the INS critical instruction causes a check when the security level is reached.
  • input data that this instruction manipulates is given by ⁇ .
  • the Alert function can be defined in several different ways as illustrated in Figures 3 and.
  • the verification sub-phase in the execution phase is a verification of the signature ⁇ taking place before the execution of the instruction if it This is a critical instruction for security, and if at least one of the data used by this instruction is a secret data.
  • this method of securing an electronic portable object uses a variable ⁇ defining the set of security levels defined at a given instant by the execution of a given program P and in that the execution phase comprises the following sub-phases: b-1) the X ⁇ P requests an instruction to the XT; b-2) if this instruction is critical for security and if at least one of the data used by the instruction is secret, then the X ⁇ P asks a signature ⁇ constructed from the signatures ⁇ ,.
  • the X ⁇ P executes the instruction, updates the security level (secret data or non-secret data) of each of the data resulting from the execution, and returns to the sub-phase b-1.
  • this third embodiment is characterized in that it uses a variable ⁇ defining the set of security levels defined at a given instant by the execution of a given program P , and in that the execution phase comprises the following sub-phases: b-1) the X ⁇ P requests an instruction to the XT; b-2) if this instruction is critical for security and if the Alert boolean function determined from the data security level used by the instruction and the nature of the statement itself evaluates to TRUE, then the X ⁇ P requires a signature ⁇ constructed from the signatures ⁇ ; generated during the initialization phase and using the HASH 2 function, and, in case of non-validity of this signature ⁇ , executes the reaction phase; b-3) the X ⁇ P executes the instruction, updates the security level (secret data or non-secret data) of each of the data resulting from the execution, and returns to the sub-phase b-1.
  • the execution phase comprises the following sub-phases: b-1) the X ⁇ P requests an instruction to the XT; b
  • this third embodiment is characterized in that it uses a set of instructions critical for the security S and in that the protocol comprises the following steps: -2.
  • the X ⁇ P generates a session random key K, asks the XT for the identifier ID of the program, the number of instructions F that it contains and initializes h A IV -1.
  • the X ⁇ P asks the XT for instruction number i
  • the XT sends the INS statement.
  • X ⁇ P (c) The X ⁇ P calculates the signature ⁇ ,.
  • a ⁇ ⁇ (ID, z, INS.) And (d) The X ⁇ P sends G t to the XT (no copy of O ", is kept in the X ⁇ P) (e) The XT records G t 0. The X ⁇ P checks that h ID, that ID is present in memory non-volatile (in case of failure go to step 8) and initializes z " A 1 1. The X ⁇ P initializes VA IV 2 2. The XT initializes GA IV 2 3. The X ⁇ P asks the XT instruction number i 4 The XT (a) updates ⁇ ⁇ - H 2 ( ⁇ , ⁇ ,) (b) sends INS ,. to X ⁇ P 5.
  • the X ⁇ P knows that the program provided is a non-authentic program, and therefore takes all necessary protective defensive measures.
  • a verification of the collective signature in step 6 is performed only when the Alert function evaluates to TRUE just before the instruction critical is executed.
  • the architect of the architecture thus obtains a way to check the program according to the context, that is to say by avoiding in the protocol the triggering of a check considered as unnecessary in view of the level of security of the data involved.
  • the program is authenticated by group of instructions, and no longer by simple instructions.
  • the instructions can indeed be grouped together in the form of small blocks called sections which make it possible to limit the number of signatures generated and verified by the X ⁇ P. Following the classic definition of the "Advanced Compiler Design and Implementation" documents, by S.
  • the second part of the invention is a fourth, fifth and sixth embodiments of the invention that we describe now. In these modes, the symmetric signatures generated by the X ⁇ P authenticate sections rather than individual program instructions.
  • these fourth, fifth, and sixth embodiments of the invention are methods of securing an electronic portable object characterized in that the program P is provided in the form of a sequence of sections or blocks of instructions, G denoting the number of sections of this program P, and in that it uses a third function hash, named HASH 3 , defined by a compression function H 3 and a constant IV 3 .
  • HASH 3 third function hash
  • the value of ID which corresponds to the hash of the program P, is calculated by hashing, one by one, the sections, in the ascending order of the addresses of these sections, and finally by hashing the chopped sections in ascending order of section start addresses.
  • the second part of the invention is characterized in that said protocol comprises the following phases: a) an initialization phase during which the X ⁇ P generates an ephemeral key K, then receives from the XT the entire program P, its number of sections G and its identifier ID, calculates the hash h of this program P using the function HASHi, using the compression function Hi and the constant IV lf and using the function HASH 3 , using the compression function H 3 and the constant IV 3 , and finally generates signatures ⁇ , using the function ⁇ ⁇ and the key K, signatures G j that it transmits to the XT; b) an execution phase during which the X ⁇ P checks the equality between the values of h and ID, also verifies that ID is stored in its non-volatile memory, then requests, one after the other, the sections of P to execute them, then carries out a sub-phase of verification of conformity of these sections, then finally, for the final instruction of certain sections, performs a verification sub-phase which
  • the compliance verification sub-phase of a given section consists of verifying that no statement in this section, except possibly the last one, is a security-critical instruction.
  • This second part of the invention then comes in several modes, called fourth, fifth and sixth embodiments of the invention.
  • the fourth embodiment is characterized in that the verification sub-phase in the execution phase is a verification of the signature ⁇ taking place before the execution of the final instruction of each section.
  • this fourth embodiment is characterized in that the execution phase comprises the following sub-phases: b-1) the X ⁇ P requires a section at XT; b-2) for each non-final instruction of the requested section, the X ⁇ P checks whether this instruction is critical, performing in this case the reaction phase, and otherwise executes this instruction and proceeds to the next instruction; b-3) for the final instruction of the requested section: b-31) the X ⁇ P requires a signature ⁇ constructed from the signatures ⁇ y .
  • the fourth embodiment of the invention is characterized in that it uses a secret key protocol comprising the following steps: -2.
  • the X ⁇ P generates a session random key K, asks the XT for the identifier ID of the program, the number of sections G that it contains and initializes h ⁇ r- IV l -1.
  • the X ⁇ P asks the XT the section number j, the number t of instructions in this section and initialises g ⁇ - IV 3 (b) For i ⁇ -1 to t, the XT sends the INS instruction, to X ⁇ P which updates g AH 3 (g, INS ⁇ ) (c) The X ⁇ P calculates the signature G j ⁇ - i ⁇ (ID, j, g) of the section and updates h ⁇ r- (d) The X ⁇ P sends G, to the XT (no copy of G • is kept in the X ⁇ P) (e) The XT records O " • 0.
  • the X ⁇ P initializes VA IV 2 2.
  • the XT initializes ⁇ ⁇ r- IV 2 3.
  • the X ⁇ P asks the XT section number, the number of instructions that compose it and initialize g ⁇ - IV 3 and! -l 4.
  • the XT updates G ⁇ r- H 2 (G, G j ) and initializes z ' ⁇ - 1 5.
  • the XT sends INS, to X ⁇ P and increments z " ⁇ - z ' + l 6.
  • the X ⁇ P updates g ⁇ - H 3 (g, INS.) 7.
  • the X ⁇ P knows that the program provided is a non-authentic program, and therefore takes all necessary protective defensive measures.
  • HASH 3 being here a hash function defined by a compression function H 3 and an initialization vector IV 3 according to the state of the art.
  • the fourth embodiment is also composed of negative and positive steps. We explain briefly how it works, this one being very close to the first embodiments.
  • step (-2) a random key K is generated, the identifier ID and the number of sections G are requested. Then h is initialized to IVi.
  • step (- 1) the program P is signed using the key K and the function of MAC ⁇ K.
  • the signatures are signatures by section.
  • the signatures Oj are generated by the X ⁇ P and then sent to the XT, which stores them.
  • step (0) the X ⁇ P verifies that the program is correct, verifying that the calculated hash is identical to ID, and that ID is present in its nonvolatile memory.
  • Steps (1) and (2) are initialization steps for X ⁇ P and XT.
  • step (3) the X ⁇ P asks the XT for the number of instructions t of the current section, and initialises g to IV 3 .
  • the XT updates the variable ⁇ in step (4) and initializes i to 1.
  • step (5) the current instruction of the current section is sent to the X ⁇ P and i is incremented.
  • the X ⁇ P then updates g, a variable used to accumulate the hash of the current section.
  • Step (6) is that of the conformity check of the section: the X ⁇ P verifies that all the non-final instructions are non-critical. It also executes these instructions.
  • Step (7) is the one that takes place for the final instruction of the section: the X ⁇ P then requests a signature and verifies its authenticity. If successful, the instruction is executed, and the process starts again from step 1.
  • step (9) which is that of the reaction step, is executed: the X ⁇ P then takes the necessary protective measures.
  • each section can cause at most a MAC check. It will be remembered that a critical instruction for security can not be found as the last statement of a section.
  • the last INS k statement of a section is: • either an instruction of S. In this case, its execution may or may not trigger a signature check, according to the Alert security policy (INS, ⁇ ) • either end of program instruction ( ⁇ halt 'in XJVML), which interrupts the execution.
  • the fifth embodiment of the invention is a method of securing an electronic portable object, of the second-part type of the invention (ie with a given program P in the form of sections), characterized in that that the verification sub-phase in the execution phase is a verification of the signature ⁇ taking place before the execution of the final instruction of each section, if said instruction is a instruction critical for security.
  • this fifth mode is characterized in that the execution phase comprises the following sub-phases: b-1) the X ⁇ P requires a section at XT; b-2) for each non-final instruction of the requested section, the X ⁇ P checks whether this instruction is critical, performing in this case the reaction phase, and otherwise executes this instruction and proceeds to the next instruction; b-3) for the final instruction of the requested section: b-31) if the instruction is critical for security, the X ⁇ P requires a signature ⁇ constructed from the signatures ⁇ ⁇ generated during the initialization phase and using the function HASH 2 , and, in case of non-validity of this signature G, executes the reaction phase; b-32) the X ⁇ P executes the instruction; b-4) the X ⁇ P then returns to the sub-phase b-1.
  • this fifth mode is characterized in that it uses a set of instructions critical for the security S and in that the protocol comprises the following steps: -2.
  • the X ⁇ P generates a session random key K, asks the XT for the identifier ID of the program, the number of sections G that it contains and initializes h A IV -1.
  • the X ⁇ P asks the XT the section number j, the number t of instructions in this section and initializes - A / F 3
  • the XT sends the INS statement ,.
  • X ⁇ P updates g AH 3 (g, INS ( )
  • X ⁇ P calculates the signature G, A l ⁇ (ID, j, g) of the section and updates h ⁇ - H ⁇ h j g )
  • the X ⁇ P sends O "to the XT (no copy of G - is kept in the X ⁇ P)
  • the XT records O", 0.
  • the X ⁇ P initializes V ⁇ r- IV 2 2.
  • the XT initializes ⁇ - IV 2 3.
  • the X ⁇ P asks the XT the section number j, the number t of instructions which composes it and initialises g A IV 3 and z ' Al 4.
  • the XT updates G ⁇ r- H 2 (G, G j ) and initializes z -l 5.
  • the XT sends INS ,. to X ⁇ P and increments z * - z ' + l 6.
  • the X ⁇ P knows that the supplied program is a non-authentic program, and therefore takes all necessary protective defensive measures.
  • step (8) we test the final instruction: if it is critical, we ask for a signature. On the other hand, if the final instruction is not critical, then, in step (9), the instruction is executed without asking for a signature, and the protocol is continued by returning to step 3.
  • step (8) we test the final instruction: if it is critical, we ask for a signature.
  • step (9) the instruction is executed without asking for a signature, and the protocol is continued by returning to step 3.
  • the advantage is great: only certain final instructions will be the subject of a verification of signature, and thus, the protocol will be all the more fast. But it is still possible to make a last improvement to the protocol, subject of the sixth embodiment of the invention.
  • This is a method for securing an electronic portable object, characterized in that the verification sub-phase in the execution phase is a verification of the signature ⁇ taking place before the execution of the final instruction of each section. , if said instruction is a security-critical instruction, and if at least one of the data used by that instruction is secret data.
  • the sixth embodiment of the invention is a method for securing an electronic portable object, characterized in that it uses a variable ⁇ defining the set of security levels defined at a given instant by the execution of a given program and in that the execution phase comprises the following sub-phases: b-1) the X ⁇ P requires a section to the XT; b-2) for each non-final instruction of the requested section, the X ⁇ P checks whether this instruction is critical, in this case performing the phase of reaction, and otherwise execute this instruction and proceed to the next instruction; b-3) for the final instruction of the requested section: b-31) if the instruction is critical for security and if at least one of the data used by the instruction is secret, the X ⁇ P requests a signature ⁇ constructed from the signatures ⁇ generated during the initialization phase and using the HASH 2 function, and, in case of non-validity of this signature ⁇ , executes the reaction phase; b-32) the X ⁇ P executes the instruction; b-33) the X ⁇ P updates the security
  • Another way of carrying out the sixth embodiment of the invention is to use a protocol, characterized in that it uses a variable ⁇ defining the set of security levels defined at a given instant by the execution of a given program, in that it uses a Boolean function Alert and in that the execution phase comprises the following sub-phases: b-1) the X ⁇ P requests an instruction to the XT; b-2) for each non-final instruction of the requested section, the X ⁇ P checks whether this instruction is critical, performing in this case the reaction phase, and otherwise executes this instruction and proceeds to the next instruction; b-3) for the final instruction of the requested section: b-31) if the instruction is critical for security and if the Alert boolean function is determined from the data security level used by the instruction and by the The nature of the instruction itself is evaluated in TRUE, the X ⁇ P requires a signature ⁇ constructed from the signatures ⁇ .
  • the sixth embodiment of the invention is characterized in that it uses a set of instructions critical for the security S, and in that it comprises the following steps: -2.
  • the X ⁇ P generates a session random key K, asks the XT for the identifier ID of the program, the number of sections G it contains and initializes h ⁇ r-IV l -1.
  • For J ⁇ -1 to G (a) The X ⁇ P asks the XT section number j, the number t of instructions in this section and initializes
  • the XT sends the INS, instruction. to X ⁇ P which updates g ⁇ - H 3 (g, INS.)
  • the X ⁇ P calculates the signature ⁇ . ⁇ - ⁇ ⁇ (ID, j, g) of the section and update h ⁇ r- H ⁇ (h, g)
  • the X ⁇ P sends G • to the XT (no copy of O "• is kept in the X ⁇ P)
  • the XT records ⁇ , 0
  • the XT initializes ⁇ ⁇ - IV 2 3.
  • the X ⁇ P asks the XT the section number j, the number t of instructions that compose it and initialises g ⁇ r- IV 3 and z ⁇ 1
  • the XT updates ⁇ ⁇ r- H 2 (G, G j ) and initializes i ⁇ - 1
  • the XT sends INS ,. at X ⁇ P and increments i r- z ' + l
  • X ⁇ P (a) updates V ⁇ H 2 (y, ⁇ ⁇ (ID, g)) (b) executes I ⁇ S ,. (c) update ⁇ (d) returns to step 3 10.
  • the X ⁇ P knows that the program provided is a non-authentic program, and therefore takes all the necessary protective defensive measures.
  • the last protocol minimizes the maximum number of signatures requested from the XT, while ensuring the security of X ⁇ P.
  • the method is characterized in that at least one of the following types of instructions are critical for security: test instructions and / or instructions transmitting information to the outside via a means of communication and / or - instructions modifying the contents of the non-volatile memory and / or calculation instructions that present special cases when they are executed, such as throwing exceptions.
  • the third and sixth modes are preferably characterized in that the alert Boolean function evaluates to TRUE for at least one of the following types of instructions: test instructions and / or instructions transmitting information to the user. external by means of communication and / or instructions modifying the contents of the non-volatile memory and / or calculation instructions presenting particular cases during their execution, such as the launching of exceptions.
  • the third and sixth modes are characterized in that the Alert Boolean function evaluates to TRUE for at least one of the following types of instructions, if at least one of the input data is secret, and FALSE if all the data tested are public: the test instructions and / or the instructions transmitting information to the outside by a means of communication and / or the instructions modifying the contents of the non-volatile memory and / or the calculation instructions that present special cases when they are executed, such as throwing exceptions.
  • the values of the function ⁇ are calculated by means of a hardware implementation of a "logical OR" function carried out on the values of the function ⁇ for the input data of the instructions.
  • the hash functions HASHi, HASH 2 and HASH 3 can be identical.
  • the present invention applies to an electronic object characterized in that it implements all the embodiments of the invention as described above.

Abstract

La présente invention décrit un procédé permettant d'authentifier dynamiquement le contenu d'un programme exécutable, c'est-à-dire la suite des instructions que celui-ci définit. Plus précisément, l'authentification d'un programme est réalisée de manière répétée au cours de l'exécution même dudit programme. Le procédé de sécurisation d'un objet portable électronique exécutant un programme P fourni par un autre objet électronique non sûr, utilise, entre autre, un protocole à clé secrète.

Description

PROCEDE D'AUTHENTIFICATION DYNAMIQUE DE PROGRAMMES PAR UN OBJET PORTABLE ELECTRONIQUE '
Ce brevet d' invention décrit un procédé permettant d'authentifier dynamiquement le contenu d'un programme exécutable, c'est-à-dire la suite des instructions que celui-ci définit. Plus précisément, l'authentification d'un programme est réalisée de manière répétée au cours de l'exécution même dudit programme. Le principe de fonctionnement de l'invention permet de concevoir un nouveau type d'élément sécurisé appelé « Externalized Microprocessor » où XμP qui, contrairement à d'autres dispositifs de calcul tels que la carte à puce {objet de nombreux brevets comme par exemple FR.2 266 222) ne contient pas de mémoire programme (classiquement appelée mémoire ROM, de l'anglais « Read Only Memory ») . A la différence des dispositifs classiques, en effet, le XμP peut exécuter des programmes qui lui sont transmis au moment même de leur exécution, en toute sécurité. Les avantages qu'un dispositif mobile de calcul sans mémoire ROM présente par rapport aux technologies de calcul embarqué classiques (nous prendrons la carte à puce comme technologie de référence) sont extrêmes : le masquage, opération industrielle au cours de laquelle on grave une mémoire ROM spécifique, disparaît totalement; la correction des bogues se résume à une mise à jour des programmes stockés dans le disque dur des terminaux ou sur un réseau de communication tel qu'Internet, et ne nécessite donc pas de devoir retirer du marché ou renouveler des cartes à puce défectueuses ; plus important encore, la taille des programmes n'est plus un facteur limitant.
Ce dernier avantage est d'autant plus attractif que la tendance technologique a toujours été de faire exécuter à la carte à puce des programmes de plus en plus complexes et donc de plus en plus volumineux. D'un point de vue industriel et fonctionnel, une carte à puce est un ordinateur miniature. Une petite mémoire volatile RAM (de l'anglais « Random Access Memory ») embarquée avec le microprocesseur sert à stocker les résultats temporaires d'un calcul et le microprocesseur de la puce exécute un programme écrit de manière non modifiable dans la mémoire ROM : l'homme de métier emploie le terme de gravure, cette gravure ayant été effectuée à l'étape dite de masquage. Ce programme ne peut ensuite plus être modifié de quelque façon. Pour le stockage de données spécifiques à l'utilisateur, les puces contiennent une mémoire non volatile EEPROM (pour « Electrically Erasable and Programmable ROM ») ou Flash, ces deux types de mémoires pouvant autoriser à la fois lectures et écritures par centaines de milliers. Les cartes Java, cartes à puce particulières, permettent même l'importation de programmes exécutables (appelés « applets », acronyme de l'anglais) dans leur mémoire non volatile selon les besoins du détenteur de la carte. En outre, les cartes Java de dernière génération embarquent un éditeur de lien (« linker ») , un module de chargement (« loader ») , une machine virtuelle Java, des modules d'appels de méthode à distance (« remote method invocation module» en anglais) , un vérificateur d' applet (« bytecode vérifier»), un pare- feu pour applications Java résidentes (« applet firewall ») , un ramasse-miettes (« garbage collector ») , des librairies cryptographiques, des gestionnaires complexes de pile, etc. Finalement, une carte à puce comprend un port de communication pour l'échange de données et d'information de contrôle avec le monde externe. Un taux de communication classique est de 9,600 bits par seconde, mais des taux beaucoup plus rapides compatibles avec la norme définie par l'ISO (« International Organization for Standardization ») sont généralement employés (de 19,200 jusqu'à 115,200 bits par seconde). L'apparition du protocole USB dans le monde de la carte à puce ouvre de nouveaux horizons et permet facilement d'atteindre des débits de l'ordre du mégabit par seconde. Dans ce contexte, il devient tentant d'extraire la mémoire ROM du modèle de fonctionnement de la carte à puce, et de s'appuyer sur un protocole de communication ultrarapide pour transmettre lorsque nécessaire les programmes qu'elle contenait auparavant. D'un autre côté, faire exécuter par un dispositif mobile un programme exécutable transmis par un terminal potentiellement non-sûr et malveillant pose d' importants problèmes de sécurité. Le problème essentiel d'une telle approche réside dans la présence de clés cryptographiques stockées dans la mémoire du dispositif lui-même. Un programme malveillant (distinct par voie de conséquence des programmes s'exécutant légitimement sur le dispositif) pourrait en effet tenter de révéler ou modifier la valeur desdites clés, invalidant ainsi totalement la sécurité des applications les utilisant pour fonctionner. L'invention que nous allons décrire permet de répondre très efficacement à cette problématique avec l'aide de fonctions de cryptographie symétrique (dite aussi cryptographie à clé secrète) classiques et efficaces : une fonction de MAC (selon l'acronyme anglais « Message
Authentification code ») et quelques fonctions de hachage, traduction du terme anglais « hashing » provenant du verbe
« to hash ». Ces fonctions de hachage seront notées HASHi, HASH2 et HASH3 dans le brevet. Conformément à l'état de l'art, ces fonctions sont définies par une fonction dite de compression. Par définition, on dit que HASH est une fonction de hachage définie par une fonction de compression H et par une constante IV (de l'anglais « initialization vector ») , lorsque la définition suivante s'applique:
Figure imgf000005_0001
H (HASH (ai,..., ak_ι) ,ak) avec le cas particulier suivant :
Figure imgf000005_0002
les nombres entiers ai, a2, ..., ak désignant ici les arguments de la fonction de hachage. Dans ce document, nous utilisons donc les fonctions de hachage HASHi, HASH2 et HASH3 qui sont respectivement définies par (Hι,IVι), (H2,IV2) et (H3,IV3). Ainsi, le résultat d'un hachage se calcule itérativement à l'aide d'une boucle et plusieurs appels à la fonction de compression déterminant le hachage. De telles fonctions de hachage sont très classiques en cryptographie : citons par exemple les fonctions de hachage SHA et MD5 dont les spécifications reposent sur la description donnée ci-dessus. La présente invention sera plus facilement comprise à l'aide des figures jointes. La Figure 1 décrit la sémantique dynamique d' un exemple de jeu d'instructions appelé XJVML permettant d'illustrer de façon non limitative les différents modes de réalisation de l'invention. La Figure 2 décrit le procédé naïf de l'état de l'art permettant, de façon non sûre, d'exécuter un programme P fournit par le monde extérieur au XμP. La Figure 3 décrit une politique de sécurité en XJVML selon l'invention, autorisant la lecture et l'écriture de données dites publiques . La Figure 4 décrit une politique de sécurité en XJVML selon l'invention, autorisant uniquement la lecture de données dites publiques . La Figure 5 explique la gestion de la politique de sécurité au cours de l'exécution du programme P. Dans la suite du texte, nous verrons un programme donné P défini sur un jeu d'instruction (ou langage de programmation) comme une suite ordonnée d'instructions : 1 : INSi 2 : INS2 3 F : INSF,
ces instructions étant positionnées à des adresses appartenant à l'ensemble {1,...,F}, F désignant le nombre d'instructions du programme P. Nous définissons également, à titre d'exemple illustratif non limitatif, un jeu d'instruction appelé XJVML qui servira à illustrer les modes de réalisation de 1' invention. XJVML décrit une architecture simpliste basée sur le processeur virtuel JVMLO défini dans le document de R. Stata et M. Abadi intitulé en langue anglaise « A type System for java Bytecode Subroutines » publié dans le document référencé SRC Research Report 158 le 11/06/1998 disponible à l'adresse électronique suivante : ttp: //www. researc . digital . com/SRC/ . L'architecture sur laquelle opère XJVML est semblable au modèle de calcul connu de l'homme de l'art comme étant celui de von Neumann, à ceci près qu'elle ne contient pas de mémoire programme. L'architecture de XJVML comporte : une mémoire volatile appelée RAM, une mémoire non volatile appelée NVM, - un générateur de nombre aléatoire appelé RNG, une pile d'opérande appelée ST, un port de communication (dit aussi d'entrée/ sortie) appelé 10. Le jeu d'instructions de XJVML est défini par les instructions suivantes, où x dénote une donnée immédiate, L est l'adresse d'une instruction avec 1 < L < F et F est le nombre d'instruction du programme considéré :
• L'instruction Λinc' incrémente la donnée se trouvant sur le sommet de la pile. L'instruction λpop' retire l'élément de pile se trouvant à son sommet : on utilisera le vocable « dépiler ». L'instruction push0' ajoute la donnée constante 0 au-dessus de l'élément se trouvant au sommet de la pile : on utilisera le vocable « empiler » . • L'instruction Λload x' empile la donnée se trouvant à l'adresse x en RAM. L'instruction λstore x' dépile la donnée au sommet de la pile et la recopie à l'adresse x en RAM. L'instruction *load 10' capture la donnée présentée sur le port de communication et l'empile tandis que l'instruction xstore 10' dépile la donnée supérieure de la pile et la recopie sur le port 10. L'instruction load RNG' produit un nombre aléatoire et l'empile. L'instruction store RNG' n'existe pas.
• L'instruction if L' observe la donnée au sommet de la pile et initialise le compteur de programme à L si cette donnée n'est pas nulle.
• L'instruction Λhalt' arrête l'exécution du programme .
• L'instruction Λgetstatic x' empile la donnée stockée en NVM à l'adresse x et l'instruction putstatic x' dépile la donnée supérieure de la pile et la stocke dans la mémoire non volatile à l'adresse x.
• L' instruction xor' dépile les deux données supérieures de la pile, calcule le XOR (OU EXCLUSIF) de ces données et empile le résultat. L'effet de l'instruction Λdec' est l'exact opposé de celui de l'instruction Λinc' , c'est à dire que la donnée supérieure est décrémentée de 1. L'instruction Λmul' dépile les deux données supérieures, les multiplie et empile les deux données représentant le résultat sous forme de deux mots, l'un de poids fort, l'autre de poids faible. L'instruction goto L' est un simple saut à l'adresse de programme L. Enfin, l'instruction λdiv' dépile les deux données supérieures, divise la moins haute de ces deux données (le numérateur) par la donnée la plus haute dans la pile (le dénominateur) , et empile la donnée résultant de l'évaluation du quotient. Il est à noter que si, pour l'instruction Λdiv' , le dénominateur est nul, une exception est exécutée, et le compteur de programme est réinitialisé à l'adresse du début de l'exception, adresse appelée AdExcDiv par la suite. Cette exception est appelée l'exception « division par zéro ».
La sémantique dynamique de notre jeu d'instructions est schématisée à la Figure 1 (à noter qu'il n'y a aucune règle pour l'instruction halt' . Dans la Figure 1, « undef » désigne la donnée par défaut d'une cellule de la mémoire. Il est implicite que les instructions qui utilisent la pile provoquent une interruption si la pile est vide, c'est à dire, en dénotant par s le nombre d'éléments de la pile, si s = 0, ou bien si elle contient insuffisamment de données, par exemple lors de l'exécution d'une instruction xor' alors que s = 1. On rappelle que le terme XμP désigne le dispositif soumis au procédé de l'invention, c'est à dire un dispositif électronique dépourvu de mémoire programme, et que similairement, le terme XT désigne l'« Externalized
Terminal », c'est à dire le terminal qui communique avec le
XμP et contient le programme P que celui-ci exécute. On rappelle aussi que le programme P introduit dans chaque terminal XT (que l'on rappelle être non sûr et possiblement malveillant) se présente sous la forme d'une suite d' instructions :
1 : INSi 2 : INS2 3 F : INSF Le principe de l'échange entre le XμP et le XT est très simple: lorsque l'exécution commence, le XμP initialise à 1 son compteur de programme, référencé ci- dessous par la variable i, et demande l'instruction d'adresse i au XT. Le XμP exécute INSi, mettant ainsi à jour son état interne et déterminant par conséquent la nouvelle valeur du compteur de programme. Le compteur de programme i et l'adresse de INSi se confondent lors de l'exécution du programme. Ainsi, lors de l'exécution du programme, i désignera de façon égale l'adresse comme le compteur de programme . Ce procédé est répété tant que l'instruction de fin de programme n'est pas atteinte. A titre d'illustration, le protocole naïf (simple et non sûr) d'échange entre le XT et le XμP s'écrit comme mentionné en Figure 2 (en se rappelant qu'exécuter INSi met à jour i) . Ainsi qu'il apparaît clairement, ce procédé simple est sujet à de nombreuses attaques. Typiquement, un attaquant peut retrouver la valeur d'une clé secrète stockée dans la mémoire du XμP, avec l'aide du programme XJVML suivant :
1 getstatic 1 2 store 10 3 getstatic 2 4 store 10 5 getstatic 3 6 store 10 Un attaquant pourrait également, par exemple, modifier le montant d'un porte-monnaie électronique en sa faveur . Nous proposons donc plusieurs modes de réalisation de l'authentification du programme P qui est transmis au XμP. De manière générale, l'invention concerne un procédé de sécurisation d'un objet portable électronique XμP exécutant un programme P fourni par un autre objet électronique non sûr XT, caractérisé en ce qu' il utilise : - un protocole à clé secrète; - une clé secrète éphémère K; - une fonction de MAC μκ; - une fonction de hachage HASHi définie par une fonction de compression Hi et une constante IVi; - une fonction de hachage HASH2 définie par une fonction de compression H2 et une constante IV2; - un identifiant de programme ID stocké dans l'objet électronique XμP et valant un hachage de P. Dans une première partie de l'invention, ce procédé de sécurisation d'un objet portable électronique est caractérisé en ce que le programme P est fourni sous la forme d'une suite de F instructions, F dénotant ainsi le nombre d'instructions de ce programme P. Dans cette première partie de l'invention, la valeur de ID, qui correspond au hachage du programme P, se calcule en hachant, une à une, les instructions, dans l'ordre croissant des adresses.
De façon plus précise, la première partie de l'invention est caractérisée en ce que ledit protocole comporte les phases suivantes : a) une phase d'initialisation durant laquelle le XμP génère une clé éphémère K, puis reçoit du XT l'ensemble du programme P, le nombre d'instructions F et son identifiant ID, calcule le haché h de ce programme P avec la fonction HASHX, en utilisant la fonction de compression Hi et la constante IVi, et enfin génère des signatures σt à l'aide de la fonction μκ et de la clé K, signatures σ(. qu'il transmet au XT; b) une phase d'exécution durant laquelle le XμP vérifie l'égalité entre les valeurs de h et de ID, vérifie également que ID est stocké dans sa mémoire non volatile, puis demande, l'une après l'autre, les instructions de P pour les exécuter, et pour certaines d'entre elles, effectue une sous-phase de vérification qui consiste à demander une signature σ, construite à partir des signatures σ. générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et à vérifier cette signature σ; c) une phase de réaction qui se déroule dès qu'une signature σ est non valable, et qui consiste pour le XμP à prendre les mesures nécessaires contre le XT frauduleux. Cette première partie de l'invention se décline alors en plusieurs modes, appelés premier, deuxième et troisième modes de réalisation de l'invention. Dans le premier mode de réalisation, le procédé de sécurisation d'un objet portable électronique est caractérisé en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature σ se déroulant avant l'exécution de chaque instruction. De façon plus précise, ce premier mode de réalisation est caractérisé en ce que la phase d'exécution comporte les sous-phases suivantes : b-1) le XμP demande une instruction au XT; b-2) le XμP demande une signature σ construite à partir des signatures σ,. générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et, en cas de non- validité de cette signature σ, exécute la phase de réaction; b-3) le XμP exécute l'instruction et retourne à la sous-phase b-1. Ainsi, de façon préférentielle, le premier mode de sécurisation d'un objet portable électronique selon l'invention est caractérisé en ce qu'il utilise un protocole à clé secrète comprenant les étapes suivantes : -2. Le XμP génère une clé aléatoire de session K, demande au XT l'identifiant ID du programme, le nombre d'instructions F qu'il contient et initialise hi—IVγ -1. Pour i<— 1 à F (a) Le XμP demande au XT l'instruction numéro i (b) Le XT envoie l'instruction INS,. au XμP (c) Le XμP calcule la signature σ,. <— μ^ID.î.INS,.) et met à jour h<r- _Qr 1(A,ZMS, J.) (d) Le XμP envoie Gt au XT (aucune copie de 0" (. n'est gardée dans le XμP ) (e) Le XT enregistre Ot 0. Le XμP vérifie que h = ID , que ID est présent en mémoire non volatile (en cas d'échec aller à l'étape 7) et initialise z <— 1 1. Le XμP initialise V <- IV2 2. Le XT initialise O" A IV2 3. Le XμP demande au XT l'instruction numéro i 4. Le XT (a) met à jour σ <— H2 (σ ,σ .) (b) envoie INS,. au XμP 5. Le XμP met à jour V A H2(V , μκ(ID,i,INSi)) 6. Le XμP (a) demande O" au XT et vérifie que 0"=V; en cas d'échec, aller à l'étape 7 (b) exécute INS,. (c) retourne à l'étape 1 7. Le XμP sait que le programme fourni est un programme non authentique, et prend donc toutes les mesures nécessaires défensives de protection .
Dans le précédent paragraphe, IVX et IV2 désignent les vecteurs initiaux des fonctions de hachage ΗASΗi et ΗASΗ2; i est toujours la valeur représentant le compteur de programme; o* désigne la signature de l'instruction INSi. On rappelle que l'exécution de INSi modifie la valeur de i. Les lettres h, V et σ désignent des variables du protocole dont l'utilisation est expliquée dans ce qui suit. Le protocole ci-dessus comprend différentes étapes. Nous avons noté par (-2) et (-1) les étapes dites négatives qui se déroulent avant l'exécution du programme P et par (0) à (7) les étapes dites positives qui se déroulent durant l'exécution du programme P. En étape (-2), le XμP génère de façon aléatoire une clé K éphémère. Cette génération aléatoire peut se faire à l'aide d'un générateur de nombre aléatoire (« random number generator » en anglais) matériel ou à l'aide d'un autre moyen. De plus, la valeur h est initialisée à la valeur initiale IVj. L'étape (-1) est une boucle sur les adresses de programme i. Elle est constituée de sous étapes. • Dans la sous étape (-l.a), le XμP demande à XT l'instruction d'adresse i • Dans la sous étape (-l.b), le XT envoie au XμP l'instruction demandée • Dans la sous étape (-l.c), le XμP calcule la signature symétrique (aussi appelée signature ou MAC) θι de l'instruction. De plus, le XμP accumule le hachage du programme dans la valeur h au moyen de la fonction de compression Hi . • Dans la sous étape (-l.d), le MAC σi est envoyé par le XμP au XT. • Enfin, dans la sous étape (-l.e), le MAC G± reçu du XμP est stocké par le XT. Se déroulent par la suite les étapes ayant lieu pendant l'exécution du programme P. A l'étape (0), le XμP vérifie que la valeur finale de h (calculée durant la boucle de l'étape (-1)) est égale à la valeur ID, stockée dans sa mémoire non volatile. Grâce à la propriété de non-collision de la fonction de hachage, le
XμP est ainsi sûr que le programme pour lequel il a calculé la séquence des MACs G± pendant les étapes négatives est effectivement autorisé à l'exécution. De plus, pendant l'étape (0), le compteur de programme i est initialise à 1. Si la valeur de h diffère de celle de ID, le programme envoyé n'est pas authentique, et la section (7) est exécutée : le XμP prend alors les mesures adéquates contre l'agression supposée (par exemple, le XμP efface sa mémoire) . Les étapes (1), (2), (3), (4), (5), (6) sont alors répétées un certain nombre de fois, jusqu'à ce que l'instruction finale soit exécutée. Ce procédé de boucle est expliqué dans ce qui suit. En étape (1), le XμP initialise la variable V à IV2. En étape (2), le XT initialise la variable σà IV2. A l'étape (3), le XμP demande au XT l'instruction d'adresse i. A l'étape (4), le XT remet à jour la variable σ et envoie au XμP l'instruction demandée. A l'étape (5), le XμP remet à jour la variable V. L'étape (6) est l'étape critique pour la sécurité. Les sous-étapes (6. a), (6.b) et (6.c) sont effectuées. La sous-étape (6. a) est une sous-étape durant laquelle le XμP demande au XT de lui envoyer la signature collective σ. Le
XμP fait alors la comparaison avec la valeur V qu'il a calculée auparavant. Si ces valeurs diffèrent, le programme P reçu n'est pas authentique et l'étape (7) est alors exécutée : le XμP prend alors les mesures appropriées contre cette agression. Si ces valeurs sont égales, le XμP continue l'exécution du protocole en exécutant l'instruction reçue et en retournant à l'étape (1). Ainsi, dans les étapes négatives, le XμP signe lui- même le programme qui lui est envoyé avec l'aide d'une clé éphémère K, tout en vérifiant que celui ci est correct en comparant le hachage du programme qui lui est envoyé à l'identifiant qu'il contient dans sa mémoire (ID) . Dans les étapes positives, il ne reste alors plus qu'à comparer, pour chaque instruction, la signature fournie par le XT à celle que le XμP recalcule. Il est ainsi impossible pour le XT d'envoyer une instruction étrangère: il n'a pu faire signer à l'étape (- 1) un programme autre que celui d'identifiant ID sans être détecté à l'étape (0), du fait de la propriété de non- collision de la fonction de hachage. Par suite, durant l'exécution des étapes positives, le XT ne peut qu'envoyer des instructions signées par le XμP au cours de l'exécution des étapes négatives, c'est à dire les instructions correspondant effectivement au programme; dans le cas contraire, si le XT essaie d'envoyer des instructions différentes, il ne pourra envoyer la signature correcte lors de la vérification car il ne peut calculer par lui- même les signatures d'autres instructions du fait qu'il ne connaît pas la clé de signature K. Cette solution est sûre, mais peut être sujette à améliorations . Le premier mode fait l'objet d'une amélioration qui est un deuxième mode de réalisation de vérification dynamique du programme P qui est envoyé au XμP. Dans ce deuxième mode de réalisation, seules certaines instructions déclenchent une vérification de la signature collective σ. Pour cela, nous répertorions dans une liste les instructions qui émettent vers l'extérieur du XμP de l'information relative aux données utilisées lors de leur exécution dans le XμP (par exemple les instructions du commandement du port d'entrée-sortie). Ensuite, on ajoute à cette liste d'instructions les instructions qui susceptibles de modifier l'état de la mémoire non volatile du dispositif. Toutes ces instructions sont appelées critiques pour la sécuri té dans les sections suivantes et l'ensemble des instructions critiques pour la sécurité est noté S. Reprenant l'exemple illustratif du langage élémentaire XJVML, nous répertorions ainsi les instructions qui ont, pour certaines valeurs de leurs entrées, un comportement spécial, reconnaissable de l'extérieur. Une instruction est alors appelée "traçable" si la valeur des données utilisées par l'instruction peut influencer la valeur d'une variable physiquement observable (par exemple le compteur de programme) . Les instructions if L' et div' sont donc traçables en raison de leur influence sur le compteur de programme (l'instruction div' pouvant provoquer une interruption en cas de nullité du dénominateur) . L'inverse de cette notion est celui d' "indistinguabilité en données" qui caractérise les instructions pour lesquelles les données utilisées n'ont aucune influence sur les variables environnementales . Par exemple, l'exécution de l'instruction xor' ne révèle pas d'information sur les deux éléments du haut de la pile qui pourrait être observée de l'extérieur du XμP. Comme l'exécution d'instructions traçables peut révéler de l'information sur des valeurs internes du programme, ces instructions sont par définition critiques pour la sécurité et nous les incluons donc dans S. Par exemple, dans notre jeu d'instruction illustratif XJVML, seules les instructions xif L' et iv' sont traçables et l'ensemble S est donc défini comme ci-dessous:
S = {putstatic x, store 10, if L, div}
L'instruction xstore 10' est dans S car elle pourrait déclencher l'émission d'un signal électrique à l'extérieur (par le port d'entrée-sortie) . L'instruction putstatic x' est également dans S car elle peut effectuer une modification de la mémoire non volatile. Ainsi, pour un jeu d'instructions donné, la classification des instructions permettant de définir S nous conduit donc au deuxième mode de réalisation de l'invention tel que décrit dans la section suivante. Dans ce deuxième mode de réalisation de l'invention, le procédé de sécurisation d'un objet portable électronique est caractérisé en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature σ se déroulant avant l'exécution de l'instruction, si celle-ci est une instruction critique pour la sécurité. De façon plus précise, dans ce second mode, le procédé de sécurisation d'un objet portable électronique est caractérisé en ce que la phase d'exécution comporte les sous-phases suivantes : b-1) le XμP demande une instruction au XT; b-2) si cette instruction est critique pour la sécurité, alors le XμP demande une signature σ construite à partir des signatures σ,. générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et, en cas de non-validité de cette signature σ, exécute la phase de réaction; b-3) le XμP exécute l'instruction et retourne à la sous-phase b-1.
De façon préférentielle, toujours dans ce second mode, le procédé de sécurisation d'un objet portable électronique est caractérisé en ce qu'il utilise un ensemble d' instructions critiques pour la sécurité S et en ce que le protocole comprend les étapes suivantes : -2. Le XμP génère une clé aléatoire de session K, demande au XT l'identifiant ID du programme, le nombre d'instructions F qu'il contient et initialise h *— IV1 -1. Pour i<-l à F (a) Le XμP demande au XT l'instruction numéro i (b) Le XT envoie l'instruction INS. au XμP (c) Le XμP calcule la signature σ,. — μ^ (ID, t,INS,. ) et met à jour h <r- H^^INS.) (d) Le XμP envoie σ,. au XT (aucune copie de G{ n'est gardée dans le XμP ) (e) Le XT enregistre G{
0. Le XμP vérifie que h = ID , que ID est présent en mémoire non volatile (en cas d'échec aller à l'étape 8) et initialise i A 1 1. Le XμP initialise V A IV2
2. Le XT initialise σ <— IV2
3. Le XμP demande au XT l'instruction numéro i
4. Le XT (a) met à jour G <— H2 ( ,G,) (b) envoie INS,. au XμP
5. Le XμP met à jour V A H2 (V , \lκ (ID, i, INS{ ))
Figure imgf000020_0001
(a) demande G au XT et vérifie que 0"=V; en cas d'échec, aller à l'étape 8 (b) exécute INS,. (c) retourne à l' étape 1
7. Sinon, le XμP (a) exécute INS,. (b) retourne à l' étape 3 8. Le XμP sait que le programme fourni est un programme non authentique, et prend donc toutes les mesures nécessaires défensives de protection
Dans le précédent paragraphe, IVi et IV2 désignent les vecteurs initiaux des fonctions de hachage HASHi et
HASH2; i dénote toujours la valeur représentant le compteur de programme; G± désigne la signature de l'instruction INSi. On rappelle que l'exécution de INSi modifie la valeur de i. Les lettres h, v et σ désignent des variables du protocole dont l'utilisation est expliquée dans ce qui suit. Le protocole se compose de différentes étapes . Nous avons noté par (-2) et (-1) les étapes dites négatives qui se déroulent avant l'exécution du programme P et par (0) à (8) les étapes dites positives qui se déroulent durant l'exécution du programme P. En étape (-2) , le XμP génère de façon aléatoire une clé K éphémère. Cette génération aléatoire peut se faire à l'aide d'un générateur de nombre aléatoire (« random number generator » en anglais) matériel ou à l'aide d'un autre moyen. De plus, la valeur h est initialisée à la valeur initiale IV. L'étape (-1) est une boucle sur les adresses de programme i. Elle est constituée de sous étapes. • Dans la sous étape (-l.a), le XμP demande à XT l'instruction d'adresse i • Dans la sous étape (-l.b), le XT envoie au XμP l'instruction demandée • Dans la sous étape (-l.c), le XμP calcule la signature symétrique (aussi appelée signature ou MAC) G± de l'instruction. De plus, le XμP accumule le hachage du programme dans la valeur h au moyen de la fonction de compression Hx . • Dans la sous étape (-l.d), le MAC Gι est envoyé par le XμP au XT. • Enfin, dans la sous étape (-l.e), le MAC G± reçu du XμP est stocké par le XT. Se déroulent par la suite les étapes ayant lieu pendant l'exécution du programme P. A l'étape (0), le XμP vérifie que la valeur finale de h calculée durant la boucle de l'étape (-1) est égale à la l'identifiant ID, stocké dans sa mémoire non volatile.
Grâce à la propriété de non-collision de la fonction de hachage, le XμP est ainsi certain que le programme pour lequel il a calculé la séquence des MACs G± pendant les étapes négatives est effectivement autorisé à l'exécution. De plus, pendant l'étape (0), le compteur de programme i est initialise à 1. Si la valeur de h diffère de celle de ID, le programme envoyé n'est pas authentique, et la section (8) est exécutée : le XμP prend alors les mesures adéquates contre l'agression supposée (par exemple, le XμP efface sa mémoire) . Les étapes (1), (2), (3), (4), (5), (6), (7) sont alors répétées un certain nombre de fois, jusqu'à ce que l'instruction finale soit exécutée. Ce procédé de boucle est expliqué dans ce qui suit . En étape (1), le XμP initialise la variable V à IV2. En étape (2), le XT initialise la variable σà IV2. A l'étape (3), le XμP demande au XT l'instruction d'adresse i. A l'étape (4), le XT remet à jour la variable σ et envoie au XμP l'instruction demandée. A l'étape (5), le XμP remet à jour la variable V. L'étape (6) est l'étape critique pour la sécurité. Celle ci commence d'abord par un test. • Si l'instruction reçue INSi est dans l'ensemble des instructions critiques pour la sécurité S, les sous-étapes (6. a), (6.b) et <6.c) sont effectuées. La sous-étape (6. a) est une sous- étape durant laquelle le XμP demande au XT de lui envoyer la signature collective σ. Le XμP effectue alors la comparaison avec la valeur V qu'il a calculée auparavant. Si ces valeurs sont différentes, le programme P reçu est un programme non-authentique et l'étape (8) est alors exécutée : le XμP prend alors les mesures adéquates contre cette agression (par exemple, le XμP ré-initialise sa mémoire) . Si ces valeurs sont égales, le XμP continue l'exécution du protocole en exécutant l'instruction reçue et en retournant à l'étape (1) . • Si l'instruction reçue INSi n'est pas dans l'ensemble des instructions critiques pour la sécurité S, l'étape (7) est exécutée : le XμP exécute simplement INSi et continue d'exécuter le procédé en retournant à l'étape (3) .
Ainsi, dans les étapes négatives, le XμP signe lui- même le programme qui lui est envoyé (encore une fois avec une clé éphémère) , tout en vérifiant que celui ci est authentique en comparant le hachage du programme qui lui est envoyé à l'identifiant de programme qu'il contient dans sa mémoire (ID) . Dans les étapes positives, le procédé permet de vérifier collectivement, aux moments opportuns (c'est à dire pour toutes les instructions critiques pour la sécurité, répertoriées dans l'ensemble S), que les signatures fournies par le XT sont identiques à celles que le XμP avait calculé dans les étapes négatives . A l'instar du premier mode de réalisation, il est impossible pour le XT d'envoyer au XμP une instruction étrangère au programme: il n'a pu faire signer à l'étape (- 1) un programme différent de celui d'identifiant ID sans être détecté à l'étape (0), du fait de la propriété de non- collision de la fonction de hachage. En conséquence, durant l'exécution des étapes positives, le XT ne peut qu'envoyer des instructions signées par le XμP au cours de l'exécution des étapes négatives, c'est à dire les instructions correspondant effectivement au programme; dans le cas contraire, si le XT essaie d'envoyer des instructions différentes, il ne pourra envoyer la signature correcte lors de la vérification car il ne peut calculer par lui- même les signatures d'autres instructions du fait qu'il ne connaît pas la clé de signature K. Il est cependant encore possible d'améliorer les performances de l'invention à l'aide d'un troisième mode de réalisation de l'invention. Dans ce troisième mode de réalisation de l'invention, un niveau de sécurité est associé à chacune des données manipulées par le XμP. Il permet de distinguer une donnée secrète (par exemple une clé cryptographique stockée en mémoire non volatile) d'une donnée publique (connue ou pouvant être recalculée à partir de données connues) . Par concision, nous dénotons par Φ l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné. Il existe plusieurs façon de définir un niveau de sécurité sur une donnée de calcul, mais l'on peut supposer en toute généralité que l'ensemble Φ des niveaux de sécurité est initialise à certaines valeurs spécifiques avant l'exécution du programme P, et que le fait d'exécuter une instruction de P peut modifier Φ selon des règles arbitrairement choisies par le concepteur du dispositif. A titre d'exemple illustratif non limitatif, nous décrivons ci-après une réalisation particulière de ce procédé appliqué à l'architecture XJVML définie plus haut. Le niveau de sécurité est mis en œuvre sous la forme d'un bit d'information φ selon la convention que sa valeur vaut zéro lorsque la donnée concernée est publique et un lorsque celle-ci est secrète. Plus spécifiquement, la mise en œuvre du procédé concerne les cellules mémoires volatiles (RAM), non volatiles (NVM) et les cellules de pile (ST) . Ainsi, on dénote par φ(RAM[j]) le bit de sécurité associé au mot mémoire RAM[j], par φ(NVM[j]) le bit de sécurité associé à NVM[j] et par φ(ST[j]) le bit de sécurité associé à ST[j]. Par convention, les bits de sécurité des cellules NVM sont non volatiles et positionnés à 0 ou 1 par le fabricant du XμP à l'étape de production ou de personnalisation, suivant la nature des données non volatiles correspondantes . Ceux de la mémoire RAM sont initialisées à 0 lors du reset du dispositif. Par convention, φ(IO) est laissé constant à 0 et φ (RNG) est laissé constant à 1. Enfin, les bits de sécurité des éléments de pile désaffectés sont automatiquement remis à 0. Nous présentons aussi deux règles élémentaires par lesquelles le bit de sécurité d'une nouvelle variable de programme, c'est-à-dire d'une donnée issue d'un calcul à partir de données précédentes, est établi en fonction de celui desdites données précédentes. La première règle est que toutes les instructions de transfert ( load' , getstatic' , store' et Λputstatic' ) transfèrent également le bit de sécurité de la variable transférée. La seconde règle est appliquée aux instructions arithmétiques et logiques . Elle définit chaque bit de sécurité des variables de sortie de l'instruction concernée comme le OU logique des bits de sécurité de toutes les variables d'entrée de l'instruction. Autrement dit, aussitôt qu'une donnée secrète entre dans le calcul, toutes les données qui en découlent sont répertoriées comme étant secrètes. Cette règle peut notamment mais non uniquement être facilement câblée en hardware comme un simple OU booléen ("OR", dénoté V dans la Figure 5) pour les instructions binaires (c'est à dire avec deux arguments d'entrée). Par souci de clarté, nous fournissons dans la Figure 5 la sémantique dynamique des instructions de XJVML sur Φ. Etant donné maintenant un jeu d'instruction quelconque, et les règles permettant de définir au cours du temps l'ensemble des niveaux de sécurité Φ des données utilisées par l'exécution d'un programme, nous y associons le procédé de l'invention tel que décrit par son second mode de réalisation. Le principe du troisième mode de réalisation repose sur le fait que la vérification collective des instructions émises par le XT, jusqu'alors déclenchée par la détection d'une instruction critique pour la sécurité, peut être épargnée dès lors que cette instruction n'utilise par exemple que des données répertoriées comme publiques. Une vérification de MAC n'est effectivement pas nécessairement invoquée dans ce cas puisque le danger inhérent à l'exécution d'une instruction critique se trouve annulé par le fait que celle-ci ne peut fournir des informations que sur des données préalablement connues ou modifier de telles données . Par concision, on dénote par Alert(INS,Φ) la fonction booléenne (c'est-à-dire retournant VRAI ou FAUX) qui détermine si l'exécution de l'instruction critique INS occasionne ou non une vérification lorsque le niveau de sécurité des données d'entrée que cette instruction manipule est donné par Φ. Dans notre exemple de mise en œuvre dans le cadre du langage XJVML, la fonction Alert peut être définie de plusieurs manières différentes ainsi qu'illustré sur les Figures 3 et . Ainsi, nous définissons un troisième mode de réalisation de l'invention, caractérisé en ce que la sous- phase de vérification dans la phase d'exécution est une vérification de la signature σ se déroulant avant l'exécution de l'instruction si celle-ci est une instruction critique pour la sécurité, et si l'une au moins des données utilisées par cette instruction est une donnée secrète. De façon plus précise, dans ce troisième mode, ce procédé de sécurisation d'un objet portable électronique est caractérisé en ce qu' il utilise une variable Φ définissant l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné P et en ce que la phase d'exécution comporte les sous-phases suivantes : b-1) le XμP demande une instruction au XT; b-2) si cette instruction est critique pour la sécurité et si l'une au moins des données utilisées par l'instruction est secrète, alors le XμP demande une signature σ construite à partir des signatures σ,. générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et, en cas de non- validité de cette signature σ, exécute la phase de réaction; b-3) le XμP exécute l'instruction, met à jour le niveau de sécurité (donnée secrète ou donnée non secrète) de chacune des données issues de l'exécution, et retourne à la sous-phase b-1.
Décliné avec l'utilisation de la fonction booléenne Alert, ce troisième mode de réalisation est caractérisé en ce qu'il utilise une variable Φ définissant l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné P, et en ce que la phase d'exécution comporte les sous-phases suivantes : b-1) le XμP demande une instruction au XT; b-2) si cette instruction est critique pour la sécurité et si la fonction booléenne Alert déterminée à partir du niveau de sécurité des données utilisées par l'instruction et par la nature de l'instruction elle-même s'évalue en VRAI, alors le XμP demande une signature σ construite à partir des signatures σ; générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et, en cas de non- validité de cette signature σ, exécute la phase de réaction; b-3) le XμP exécute l'instruction, met à jour le niveau de sécurité (donnée secrète ou donnée non secrète) de chacune des données issues de l'exécution, et retourne à la sous-phase b-1. De façon préférentielle, ce troisième mode de réalisation est caractérisé en ce qu'il utilise un ensemble d'instructions critiques pour la sécurité S et en ce que le protocole comprend les étapes suivantes: -2. Le XμP génère une clé aléatoire de session K, demande au XT l'identifiant ID du programme, le nombre d'instructions F qu'il contient et initialise h A IV -1. Pour i<-l à F (a) Le XμP demande au XT l'instruction numéro i (b) Le XT envoie l'instruction INS,. au XμP (c) Le XμP calcule la signature σ,. A μ^ (ID, z, INS. ) et
Figure imgf000029_0001
(d) Le XμP envoie Gt au XT (aucune copie de O",. n'est gardée dans le XμP ) (e) Le XT enregistre Gt 0. Le XμP vérifie que h = ID , que ID est présent en mémoire non volatile (en cas d'échec aller à l'étape 8) et initialise z" A 1 1. Le XμP initialise V A IV2 2. Le XT initialise G A IV2 3. Le XμP demande au XT l'instruction numéro i 4. Le XT (a) met à jour σ <— H2(σ,σ,) (b) envoie INS,. au XμP 5. Le XμP met à jour V <- H2(V ,μκ(ID,i,INSi)) 6. Si INS,. € S et Alert ( ZNS.,Φ ) =VRAI, le XμP (a) demande G au XT et vérifie que G =V ; en cas d'échec, aller à l'étape 8 (b) exécute INS,. (c) met à jour Φ (d) retourne à l' étape 1 7. Sinon, le XμP (a) exécute INS,. (b) met à jour Φ (c) retourne à l'étape 3 8. Le XμP sait que le programme fourni est un programme non authentique, et prend donc toutes les mesures nécessaires défensives de protection . Ainsi, par différence avec le protocole décrit dans le second mode de réalisation de l'invention, une vérification de la signature collective à l'étape 6 n'est effectuée que lorsque la fonction Alert s'évalue en VRAI juste avant que l'instruction critique soit exécutée. En fonction de la mise en œuvre de ladite fonction, le concepteur de l'architecture obtient ainsi un moyen de vérifier le programme en fonction du contexte, c'est-à-dire en évitant dans le protocole le déclenchement d' une vérification considérée comme inutile au regard du niveau de sécurité des données en jeu. Dans une deuxième partie de l'invention, le programme est authentifié par groupe d'instructions, et non plus par instructions simples. Les instructions peuvent en effet être regroupées sous la forme de petits blocs appelés sections qui permettent de limiter le nombre de signatures générées et vérifiées par le XμP . Suivant la définition classique des documents « Advanced Compiler Design and Implementation », de S. Muchnick, publié en 1997 et « Compilers : Principles, Techniques, and Tools », de A. Aho, R. Sethi et J. Ullman, publié en 1986, nous appelons « bloc de base » une suite séquentielle et ordonnée d'instructions, que l'on ne peut exécuter qu'en exécutant la première et la dernière instruction. L'homme de métier décrit habituellement l'ensemble des blocs de base d'un programme P sous la forme d'un graphe CFG(P) (CFG signifiant « control flow graph » en anglais) , calculé par des moyens connus d'analyse de flot de contrôle (expliqués notamment dans les documents « Identifying Loops in Almost Linear Time », de G. Ramalingam, publié en 1999, et « Advanced Compiler Design and Implementation », de S. Muchnick, publié en 1997) . Dans un tel graphe, les nœuds sont identifiés aux blocs de base et les arêtes symbolisent les dépendances de flot de contrôle (« control flow dependancies »)•. La présence d'une arête B0 -> Bi dans le graphe (on dit alors que Bi est un fils de B0 et B0 un père de Bi) signifie que la dernière instruction du bloc B0 peut transférer le contrôle du programme à la première instruction de Bi . Lorsque B0 -> Bi, Bo => Bi signifie que B0 n'a aucun autre fils que Bi (mais Bi peut avoir d'autres pères que Bo) . Nous définissons maintenant une notion légèrement différente de celle des blocs de base, que nous appelons section de programme . De manière rigoureuse, une section de programme est une suite maximale de blocs de base Bo => Bi => B2 => ... => Bz telle que ni l'instruction de fin de programme (Λhalt' en XJVML) ni aucune instruction de S (instruction critique) n'apparaisse dans les blocs sauf éventuellement comme dernière instruction de Bz. La section est alors dénotée par s = <B0,Bι,..„ Bz>. Dans une section de programme, comme dans les blocs de base, le flot de contrôle est déterministe, c'est à dire indépendant de la valeur que les variables de programme sont susceptibles de prendre pendant 1' exécution. Il est connu que le calcul des blocs de base d'un programme peut être fait dans un temps presque linéaire en le nombre d'instruction de ce programme (« Identifying Loops in Almost Linear Time », de G. Ramalingam, publié en 1999) et l'homme de l'art verra facilement que les algorithmes permettant de calculer CFG(P) à partir de P peuvent être modifiés de façon simple pour calculer, de manière également performante, l'ensemble des sections du programme P. Ainsi, les sections de P peuvent être calculées facilement lors la compilation de P. La deuxième partie de l'invention se décline en un quatrième, cinquième et sixième modes de réalisation de l'invention que nous décrivons maintenant. Dans ces modes, les signatures symétriques générées par le XμP authentifient des sections plutôt que des instructions individuelles du programme. Au contraire des trois premiers modes de réalisation de la première partie de l'invention, dans lesquels le programme était fourni sous forme de suite d'instructions, ces quatrième, cinquième et sixième modes de réalisation de l'invention sont des procédés de sécurisation d'un objet portable électronique caractérisés en ce que le programme P est fourni sous la forme d'une suite de sections ou blocs d'instructions, G dénotant le nombre de sections de ce programme P, et en ce qu'il utilise une troisième fonction de hachage, nommée HASH3, définie par une fonction de compression H3 et une constante IV3. Dans cette seconde partie de l'invention, la valeur de ID, qui correspond au hachage du programme P, se calcule en hachant, une à une, les sections, dans l'ordre croissant des adresses de ces sections, puis finalement en hachant les hachés des sections dans l'ordre croissant des adresses de départ des sections. De façon plus précise, la deuxième partie de l'invention est caractérisée en ce que ledit protocole comporte les phases suivantes : a) une phase d'initialisation durant laquelle le XμP génère une clé éphémère K, puis reçoit du XT l'ensemble du programme P, son nombre de sections G et son identifiant ID, calcule le haché h de ce programme P à l'aide de la fonction HASHi, en utilisant la fonction de compression Hi et la constante IVlf et à l'aide de la fonction HASH3, en utilisant la fonction de compression H3 et la constante IV3, et enfin génère des signatures σ, à l'aide de la fonction μκ et de la clé K, signatures G j qu' il transmet au XT; b) une phase d'exécution durant laquelle le XμP vérifie l'égalité entre les valeurs de h et de ID, vérifie également que ID est stocké dans sa mémoire non volatile, puis demande, l'une après l'autre, les sections de P pour les exécuter, effectue ensuite une sous-phase de vérification de conformité de ces sections, puis finalement, pour l'instruction finale de certaines sections, effectue une sous-phase de vérification qui consiste à demander une signature σ, construite à partir des signatures σ. générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et à la vérifier; c) une phase de réaction qui se déroule dès qu'une signature σ est non valable ou qu'une section est non conforme, et qui consiste pour le XμP à prendre les mesures nécessaires contre le XT frauduleux. Plus précisément, la sous-phase de vérification de conformité d'une section donnée consiste à vérifier qu'aucune instruction de cette section, sauf éventuellement la dernière, n'est une instruction critique pour la sécurité. Cette deuxième partie de l'invention se décline alors en plusieurs modes, appelés quatrième, cinquième et sixième mode de réalisation de l'invention. Le quatrième mode de réalisation se caractérise en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature σ se déroulant avant l'exécution de l'instruction finale de chaque section. De façon plus précise, ce quatrième mode de réalisation est caractérisé en ce que la phase d'exécution comporte les sous-phases suivantes : b-1) le XμP demande une section au XT; b-2) pour chaque instruction non finale de la section demandée, le XμP vérifie si cette instruction est critique, effectuant dans ce cas la phase de réaction, et sinon exécute cette instruction et passe à l'instruction suivante; b-3) pour l'instruction finale de la section demandée : b-31) le XμP demande une signature σ construite à partir des signatures σy. générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et, en cas de non-validité de cette signature σ, exécute la phase de réaction; b-32) le XμP exécute l'instruction; b-4) le XμP retourne alors à la sous-phase b-1. De façon préférentielle, le quatrième mode de réalisation de l' invention est caractérisé en ce qu' il utilise un protocole à clé secrète comprenant les étapes suivantes : -2 . Le XμP génère une clé aléatoire de session K, demande au XT l' identifiant ID du programme, le nombre de sections G qu' il contient et initialise h <r- IVl -1. Pour J<-1 à G (a) Le XμP demande au XT la section numéro j, le nombre t d' instructions dans cette section et initialise g ^- IV3 (b) Pour i<—1 à t, le XT envoie l'instruction INS,- au XμP qui met à jour g A H3(g,INS{) (c) Le XμP calcule la signature G j <— iκ (ID,j, g) de la section et met à jour h <r—
Figure imgf000035_0001
(d) Le XμP envoie G , au XT (aucune copie de G • n'est gardée dans le XμP ) (e) Le XT enregistre O" • 0. Le XμP vérifie que h = TD , que ID est présent en mémoire non volatile (en cas d'échec aller à l'étape 9) et initialise <— 1 1. Le XμP initialise V A IV2 2. Le XT initialise σ <r- IV2 3. Le XμP demande au XT la section numéro , le nombre t d'instructions qui la compose et initialise g ^— IV3 et ! -l 4. Le XT met à jour G <r- H2(G ,G j) et initialise z'<— 1 5. Le XT envoie INS,. au XμP et incrémente z" <— z'+l 6. Le XμP met à jour g <- H3(g,INS.) 7. Si i<t, alors le XμP (a) teste si TAS. e S , et dans ce cas, aller à l' étape 9 (b) exécute INS,. (c) retourne à l' étape 5 8. Si i=t, alors le XμP (a) met à jour V ^H2(y ,μκ(ID,j,g)) (b) demande σ au XT et vérifie que σ=V; en cas d'échec, aller à l'étape 9 (c) exécute INS,. (d) retourne à l'étape 1 9. Le XμP sait que le programme fourni est un programme non authentique, et prend donc toutes les mesures nécessaires défensives de protection.
Dans le précédent paragraphe, et dans la suite (pour les cinquièmes et sixième mode de réalisation) , la signature d'une section Sj dont la première instruction a pour adresse j et constituée des instructions INSi, -r INSk peut être définie à titre d' exemple par : Gj = μ(ID, j, g) où g désigne g = HASH3 (INSi,..., INSk)
HASH3 étant ici une fonction de hachage définie par une fonction de compression H3 et un vecteur d'initialisation IV3 conformément à l'état de l'art. Le fait d'employer la définition classique du hachage par itération est indispensable à notre quatrième, cinquième et sixième mode de réalisation. Le quatrième mode de réalisation se compose lui aussi d' étapes négatives et positives . Nous expliquons brièvement son fonctionnement, celui ci étant très proche des premiers modes de réalisation. Dans l'étape (-2), une clé aléatoire K est générée, l'identifiant ID et le nombre de sections G sont demandés. Puis h est initialise à IVi. Dans l'étape (- 1), le programme P est signé à l'aide de la clé K et de la fonction de MAC μK. Ici, les signatures sont des signatures par section. Les signatures Oj sont générées par le XμP et envoyées ensuite au XT, qui les stocke. Dans l'étape (0), le XμP vérifie que le programme est correct, en vérifiant que le haché calculé est identique à ID, et que ID est présent dans sa mémoire non volatile. Les étapes (1) et (2) sont des étapes d'initialisation pour le XμP et le XT. En étape (3), le XμP demande au XT le nombre d'instruction t de la section courante, et initialise g à IV3. Le XT remet quant à lui à jour la variable σ en étape (4) et initialise i à 1. En étape (5), l'instruction courante de la section courante est envoyée au XμP et i est incrémenté. Le XμP remet alors à jour g, variable qui lui sert à accumuler le hachage de la section courante. L'étape (6) est celle de la vérification de conformité de la section : le XμP y vérifie que toutes les instructions non finales sont non critiques. Il exécute également ces instructions. L'étape (7) est celle qui se déroule pour l'instruction finale de la section : le XμP demande alors une signature et en vérifie l'authenticité. En cas de succès, l'instruction est exécutée, et le procédé repart de l'étape 1. Enfin, à tout moment, si une section est non conforme, ou si une signature est fausse, l'étape (9), qui est celle de l'étape de réaction, est exécutée : le XμP prend alors les mesures nécessaires de protection. A la différence des modes de réalisation précédents, chaque section ne peut occasionner au plus qu'une vérification de MAC. On se rappellera en effet qu'une instruction critique pour la sécurité ne peut se trouver qu'en tant que dernière instruction d'une section. Par définition, la dernière instruction INSk d'une section est: • soit une instruction de S. Dans ce cas, son exécution peut déclencher ou non une vérification de signature, selon la politique de sécurité Alert (INS, Φ) • soit l'instruction de fin de programme (Λhalt' en XJVML), qui interrompt l'exécution. Reprenant les idées des deuxième et troisième modes de réalisation, mais appliquées à un programme P donné sous la forme de sections, nous dérivons les cinquièmes et sixièmes modes de réalisation de l'invention. Le cinquième mode de réalisation de l'invention est un procédé de sécurisation d'un objet portable électronique, du type deuxième partie de l'invention (c'est à dire avec un programme P donné sous la forme de sections) , caractérisé en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature σ se déroulant avant l'exécution de l'instruction finale de chaque section, si ladite instruction est une instruction critique pour la sécurité. Plus précisément, ce cinquième mode est caractérisé en ce que la phase d'exécution comporte les sous-phases suivantes : b-1) le XμP demande une section au XT; b-2) pour chaque instruction non finale de la section demandée, le XμP vérifie si cette instruction est critique, effectuant dans ce cas la phase de réaction, et sinon exécute cette instruction et passe à l'instruction suivante; b-3) pour l'instruction finale de la section demandée : b-31) si l' instruction est critique pour la sécurité, le XμP demande une signature σ construite à partir des signatures σ } générées lors de la phase d' initialisation et à l' aide la fonction HASH2, et, en cas de non-validité de cette signature G, exécute la phase de réaction; b-32 ) le XμP exécute l' instruction; b-4 ) le XμP retourne alors à la sous-phase b-1. De façon préférentielle, ce cinquième mode est caractérisé en ce qu' il utilise un ensemble d' instructions critiques pour la sécurité S et en ce que le protocole comprend les étapes suivantes : -2 . Le XμP génère une clé aléatoire de session K, demande au XT l' identifiant ID du programme, le nombre de sections G qu' il contient et initialise h A IV -1 . Pour jAL à G (a) Le XμP demande au XT la section numéro j, le nombre t d' instructions dans cette section et initialise - A /F3 (b) Pour i<-l à t, le XT envoie l'instruction INS,. au XμP qui met à jour g A H3(g,INS() (c) Le XμP calcule la signature G , A lκ(ID,j,g) de la section et met à jour h <— H^hjg) (d) Le XμP envoie O" . au XT (aucune copie de G - n'est gardée dans le XμP ) (e) Le XT enregistre O" , 0. Le XμP vérifie que h = ID , que ID est présent en mémoire non volatile (en cas d'échec aller à l'étape 10) et initialise j <r- 1 1. Le XμP initialise V <r- IV2 2. Le XT initialise σ - IV2 3. Le XμP demande au XT la section numéro j, le nombre t d'instructions qui la compose et initialise g A IV3 et z'Al 4. Le XT met à jour G <r- H2 (G ,G j) et initialise z -l 5. Le XT envoie INS,. au XμP et incrémente z* — z'+l 6. Le XμP met à jour g A H3(g,INS.) 7. Si i<t, alors le XμP (a) teste si INSt €. S , et dans ce cas, aller à l'étape 10 (b) exécute INS,- (c) retourne à l'étape 5 8. Si i=t et INS. € S , alors le XμP (a) met à jour V A H2 (y , μκ(ID, j,g)) (b) demande G au XT et vérifie que 0"=V; en cas d'échec, aller à l'étape 10 (c) exécute IΝS,- (d) retourne à l' étape 1 9. Si i=t et INSt £ S , alors le XμP (a) met à j our V A H2(V , μκ (ID, j, g)) (b) exécute IΝS,- (c) retourne à l' étape 3 10 . Le XμP sait que le programme fourni est un programme non authentique, et prend donc toutes les mesures nécessaires défensives de protection .
Ce cinquième mode de réalisation de l' invention est très proche du quatrième, et nous n' allons expliquer ici que les phases différentes de celui ci, c' est à dire les phases 8 et 9. Dans le quatrième mode de réalisation, toutes les instructions finales des sections faisaient l'objet d'une vérification de signature. Ici, en étape (8), on teste l'instruction finale : si elle est critique, on demande une signature. Par contre, si l'instruction finale n'est pas critique, alors, dans l'étape (9), on exécute l'instruction sans demander de signature, et on continue le protocole en retournant à l'étape 3. Comme on peut le voir, l'avantage est grand : seules certaines instructions finales feront l'objet d'une vérification de signature, et ainsi, le protocole sera d' autant plus rapide . Mais il est encore possible d'apporter une dernière amélioration au protocole, faisant l'objet du sixième mode de réalisation de l'invention. Celui ci est un procédé de sécurisation d'un objet portable électronique caractérisé en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature σ se déroulant avant l'exécution de l'instruction finale de chaque section, si ladite instruction est une instruction critique pour la sécurité, et si l'une au moins des données utilisées par cette instruction est une donnée secrète. Plus précisément, le sixième mode de réalisation de l'invention est un procédé de sécurisation d'un objet portable électronique caractérisé en ce qu'il utilise une variable Φ définissant l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné et en ce que la phase d'exécution comporte les sous- phases suivantes : b-1) le XμP demande une section au XT; b-2) pour chaque instruction non finale de la section demandée, le XμP vérifie si cette instruction est critique, effectuant dans ce cas la phase de réaction, et sinon exécute cette instruction et passe à l'instruction suivante; b-3) pour ' l'instruction finale de la section demandée : b-31) si l'instruction est critique pour la sécurité et si l'une au moins des données utilisées par l'instruction est secrète, le XμP demande une signature σ construite à partir des signatures σ générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et, en cas de non- validité de cette signature σ, exécute la phase de réaction; b-32) le XμP exécute l'instruction; b-33) le XμP met à jour le niveau de sécurité (donnée secrète ou donnée non secrète) de chacune des données issues de l'exécution ; b-4) le XμP retourne alors à la sous-phase b-1.
Une autre façon de réaliser le sixième mode de réalisation de l'invention est d'utiliser un protocole, caractérisé en ce qu'il utilise une variable Φ définissant l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné, en ce qu'il utilise une fonction booléenne Alert et en ce que la phase d'exécution comporte les sous-phases suivantes : b-1) le XμP demande une instruction au XT; b-2) pour chaque instruction non finale de la section demandée, le XμP vérifie si cette instruction est critique, effectuant dans ce cas la phase de réaction, et sinon exécute cette instruction et passe à l'instruction suivante; b-3) pour l'instruction finale de la section demandée : b-31) si l'instruction est critique pour la sécurité et si la fonction booléenne Alert déterminée à partir du niveau de sécurité des données utilisées par l'instruction et par la nature de l'instruction elle- même s'évalue en VRAI, le XμP demande une signature σ construite à partir des signatures σ . générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et, en cas de non-validité de cette signature σ, exécute la phase de réaction; b-32) le XμP exécute l'instruction; b-33) le XμP met à jour le niveau de sécurité (donnée secrète ou donnée non secrète) de chacune des données issues de l'exécution ; b-4) le XμP retourne alors à la sous-phase b-1.
Ainsi, de manière préférentielle, le sixième mode de réalisation de l'invention est caractérisé en ce qu'il utilise un ensemble d'instructions critiques pour la sécurité S, et en ce qu'il comprend les étapes suivantes: -2. Le XμP génère une clé aléatoire de session K, demande au XT l'identifiant ID du programme, le nombre de sections G qu'il contient et initialise h<r-IVl -1. Pour J<-1 à G (a) Le XμP demande au XT la section numéro j, le nombre t d'instructions dans cette section et initialise
(b) Pour ic— 1 à t, le XT envoie l'instruction INS,. au XμP qui met à jour g <— H3(g,INS.) (c) Le XμP calcule la signature σ . <— μκ(ID,j,g) de la section et met à jour h <r- Hχ(h,g) (d) Le XμP envoie G • au XT (aucune copie de O" • n'est gardée dans le XμP ) (e) Le XT enregistre σ , 0. Le XμP vérifie que h = ID , que ID est présent en mémoire non volatile (en cas d'échec aller à l'étape 10) et initialise /<—1
1. Le XμP initialise V <- IV2
2. Le XT initialise σ <— IV2 3. Le XμP demande au XT la section numéro j, le nombre t d'instructions qui la compose et initialise g <r— IV3 et zΑ 1
4. Le XT met à jour σ <r— H2(G ,Gj) et initialise i <— 1
5. Le XT envoie INS,. au XμP et incrémente i r- z'+l
6. Le XμP met à jour g A H3(^,ZNS.) 7. Si i<t, alors le XμP (a) teste si INS,. € S , et dans ce cas, aller à l'étape 10 (b) exécute IΝS,. (c) met à jour Φ (d) retourne à l'étape 5 8. Si i=t et INSt S S et Alert ( ZNS,., Φ )=VRAI, alors le XμP (a) met à jour V ^ H2(y , μκ(ID,j,g)) (b) demande G au XT et vérifie que 0~=V; en cas d'échec, aller à l'étape 10 (c) exécute IΝS,. (d) met à jour Φ (e) retourne à l'étape 1
9. Si i=t et ( INS,. g S ou Alert ( INS., Φ )=FAUX) , alors le XμP (a) met à jour V <^ H2(y, μκ (ID , g)) (b) exécute IΝS,. (c) met à jour Φ (d) retourne à l'étape 3 10. Le XμP sait que le programme fourni est un programme non authentique, et prend donc toutes les mesures nécessaires défensives de protection.
La différence de ce dernier mode de réalisation avec le cinquième mode de réalisation est minime, et est expliquée dans ce qui suit : en étape (8) , on ne teste pas seulement si l'instruction finale est critique pour la sécurité, mais aussi si une des données d'entrée de l'instruction est secrète (ceci nous est donné par la condition Alert ( INSt, Φ ) =VRAI) . Si ces deux conditions sont réunies, une vérification de signature est enclenchée, l'instruction est ensuite exécutée, et le protocole redémarre de l'étape (1). Par contre, dans le cas contraire, l'instruction est exécutée sans déclencher de vérification de signature, et le protocole redémarre de 1' étape (3) . Comme pourra le voir l'homme de l'art, le dernier protocole minimise au maximum le nombre de signatures demandées au XT, tout en garantissant la sécurité du XμP . Dans le deuxième ou troisième modes de la première partie de l'invention, et dans le quatrième, cinquième ou sixième mode de la deuxième partie de l'invention, le procédé est caractérisé en ce qu'au moins un des types suivants d'instructions sont critiques pour la sécurité : les instructions de test et/ou les instructions émettant de l'information vers l'extérieur par un moyen de communication et/ou - les instructions modifiant le contenu de la mémoire non-volatile et/ou les instructions de calcul présentant des cas particuliers lors de leur exécution, tels que le lancement d' exceptions . De plus, les troisième et sixième modes sont preferentiellement caractérisés en ce que la fonction booléenne Alert s'évalue en VRAI pour au moins un des types suivants d'instructions: les instructions de test et/ou les instructions émettant de l'information vers l'extérieur par un moyen de communication et/ou les instructions modifiant le contenu de la mémoire non-volatile et/ou les instructions de calcul présentant des cas particuliers lors de leur exécution, tels que le lancement d' exceptions .
Dans une solution encore plus efficace, les troisième et sixième modes sont caractérisés en ce que la fonction booléenne Alert s'évalue en VRAI pour au moins un des types suivants d'instructions, si au moins une des données d'entrée est secrète, et FAUX si toutes les données testées sont publiques: les instructions de test et/ou les instructions émettant de l'information vers l'extérieur par un moyen de communication et/ou les instructions modifiant le contenu de la mémoire non-volatile et/ou les instructions de calcul présentant des cas particuliers lors de leur exécution, tels que le lancement d' exceptions . Pour les troisième et sixième modes, l'ensemble des niveaux de sécurité Φ utilisé lors de l'exécution d'un programme P est preferentiellement indiqué par la valeur d'une fonction φ, telle que, pour toute donnée u utilisée par le programme, φ(u)=0 désigne le fait que u est publique et φ(u)=l désigne le fait que u est privée, et telle que, pour toute donnée v résultant de l'exécution d'une instruction du programme P, φ (v) =1 si au moins une des données d'entrée de l'instruction est privé, et, sinon, φ(v)=0. Plus précisément, les valeurs de la fonction φ sont calculées au moyen d'une mise en œuvre matérielle d'une fonction « OU logique » réalisée sur les valeurs de la fonction φ pour les données d'entrée des instructions. Enfin, par souci de simplicité et de pratique, les fonctions de hachage HASHi, HASH2 et HASH3 peuvent être identiques . La présente invention s'applique à un objet électronique caractérisé en ce qu'il met en œuvre l'ensemble des modes de réalisation de l'invention tels que décrits ci-dessus.

Claims

REVENDICATIONS
1. Procédé de sécurisation d'instructions d'un objet portable électronique XμP exécutant un programme P fourni par un autre objet électronique non sûr XT sous la forme d'une suite de F instructions, F dénotant ainsi le nombre d'instructions de ce programme P, procédé utilisant - un protocole à clé secrète coopérant avec une clé secrète éphémère K; - une fonction cryptographique symétrique MAC μκ coopérant avec une fonction de hachage HASHi, définie par une fonction de compression Hi et une constante IVi, et une fonction de hachage HASH2 définie par une fonction de compression H2 et une constante IV2; - un identifiant de programme ID stocké dans l'objet électronique XμP et valant un hachage de P, procédé caractérisé en ce que ledit protocole à clé publique comporte les phases suivantes : a) une phase d'initialisation durant laquelle le XμP génère une clé éphémère K, puis reçoit du XT l'ensemble du programme P, le nombre d'instructions F et son identifiant ID, calcule le haché h de ce programme P avec la fonction HASHi, en utilisant la fonction de compression Hi et la constante IVX, et enfin génère des signatures Gt à l'aide de la fonction μ et de la clé K, signatures σ,- qu'il transmet au XT; b) une phase d'exécution durant laquelle le XμP vérifie l'égalité entre les valeurs de h et de ID, vérifie- également que ID est stocké dans sa mémoire non volatile, puis demande, l'une après l'autre, les instructions de P pour les exécuter, et pour certaines d'entre elles, effectue une sous-phase de vérification qui consiste à demander une signature σ, construite à partir des signatures σ. générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et à vérifier cette signature σ; c) une phase de réaction qui se déroule dès qu'une signature σ est non valable.
2. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 1 caractérisé en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature σ se déroulant avant l'exécution de chaque instruction.
3. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 2 caractérisé en ce que la phase d'exécution comporte les sous-phases suivantes : b-1) le XμP demande une instruction au XT; b-2 ) le XμP demande une signature σ construite à partir des signatures σ,- générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et, en cas de non-validité de cette signature σ, exécute la phase de réaction; b-3) le XμP exécute l'instruction et retourne à la sous-phase b-1.
4. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 1 caractérisé en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature σ se déroulant avant l'exécution de l'instruction, si celle-ci est une instruction critique pour la sécurité.
5. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 4 caractérisé en ce que la phase d'exécution comporte les sous-phases suivantes : b-1) le XμP demande une instruction au XT; b-2) si cette instruction est critique pour la sécurité, alors le XμP demande une signature σ construite à partir des signatures σ,. générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et, en cas de non-validité de cette signature σ, exécute la phase de réaction; b-3) le XμP exécute l'instruction et retourne à la sous-phase b-1.
6. Procédé de sécurisation d'un objet portable électronique selon la revendication 1 caractérisé en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature σ se déroulant avant l'exécution de l'instruction si celle-ci est une instruction critique pour la sécurité, et si l'une au moins des données utilisées par cette instruction est une donnée secrète.
7. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 6 caractérisé en ce qu'il utilise une variable Φ définissant l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné P et en ce que la phase d'exécution comporte les sous-phases suivantes : b-1) le XμP demande une instruction au XT; b-2) si cette instruction est critique pour la sécurité et si l'une au moins des données utilisées par l'instruction est secrète, alors le XμP demande une signature σ construite à partir des signatures σ,. générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et, en cas de non-validité de cette signature σ, exécute la phase de réaction; b-3) le XμP exécute l'instruction, met à jour le niveau de sécurité (donnée secrète ou donnée non secrète) de chacune des données issues de l'exécution, et retourne à la sous-phase b-1.
8. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 7 caractérisé en ce qu'il utilise une variable Φ définissant l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné P, en ce qu'il utilise une fonction booléenne Alert et en ce que la phase d'exécution comporte les sous-phases suivantes : b-1) le XμP demande une instruction au XT; b-2) si cette instruction est critique pour la sécurité et si la fonction booléenne Alert déterminée à partir du niveau de sécurité des données utilisées par l'instruction et par la nature de l'instruction elle-même s'évalue en VRAI, alors le XμP demande une signature σ construite à partir des signatures σ. générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et, en cas de non-validité de cette signature σ, exécute la phase de réaction; b-3) le XμP exécute l'instruction, met à jour le niveau de sécurité (donnée secrète ou donnée non secrète) de chacune des données issues de l'exécution, et retourne à la sous-phase b-1.
9. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 1, caractérisé en ce qu'il utilise une fonction de hachage HASH3 définie par une fonction de compression H3 et une constante IV3, et en ce que le programme P est fourni sous la forme d'une suite de G sections ou blocs d'instructions, G dénotant ainsi le nombre de sections dudit programme.
10. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 9 caractérisé en ce que ledit protocole comporte les phases suivantes : a) une phase d'initialisation durant laquelle le XμP génère une clé éphémère K, puis reçoit du XT l'ensemble du programme P, son nombre de sections G et son identifiant ID, calcule le haché h de ce programme P à l'aide de la fonction HASHi, en utilisant la fonction de compression Hi et la constante IVi, et à l'aide de la fonction HASH3, en utilisant la fonction de compression H3 et la constante IV3, et enfin génère des signatures j à l'aide de la fonction μκ et de la clé K, signatures σ^ qu'il transmet au XT; b) une phase d'exécution durant laquelle le XμP vérifie l'égalité entre les valeurs de h et de ID, vérifie également que ID est stocké dans sa mémoire non volatile, puis demande, l'une après l'autre, les sections de P pour les exécuter, effectue ensuite une sous-phase de vérification de conformité de ces sections, puis finalement, pour l'instruction finale de certaines sections, effectue une sous-phase de vérification qui consiste à demander une signature σ, construite à partir des signatures σ. générées lors de la phase d' initialisation et à l'aide la fonction HASH2, et à la vérifier; c) une phase de réaction qui se déroule dès qu'une signature σ est non valable ou qu'une section est non conforme.
11. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 10 caractérisé en ce que la sous-phase de vérification de conformité d'une section donnée consiste à vérifier qu'aucune instruction de cette section, sauf éventuellement la dernière, n'est une instruction critique pour la sécurité.
12. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 11 caractérisé en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature σ se déroulant avant l'exécution de l'instruction finale de chaque section.
13. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 12 caractérisé en ce que la phase d'exécution comporte les sous-phases suivantes : b-1) le XμP demande une section au XT; b-2) pour chaque instruction non finale de la section demandée, le XμP vérifie si cette instruction est critique, effectuant dans ce cas la phase de réaction, et sinon exécute cette instruction et passe à l'instruction suivante; b-3) pour l'instruction finale de la section demandée : b-31) le XμP demande une signature σ construite à partir des signatures σ- générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et, en cas de non-validité de cette signature σ, exécute la phase de réaction; b-32) le XμP exécute l'instruction; b-4) le XμP retourne alors à la sous- phase b-1.
14. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 11 caractérisé en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature σ se déroulant avant l'exécution de l'instruction finale de chaque section, si ladite instruction est une instruction critique pour la sécurité.
15. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 14 caractérisé en ce que la phase d'exécution comporte les sous-phases suivantes : b-1) le XμP demande une section au XT; b-2) pour chaque instruction non finale de la section demandée, le XμP vérifie si cette instruction est critique, effectuant dans ce cas la phase de réaction, et sinon exécute cette instruction et passe à l'instruction suivante; b-3) pour l'instruction finale de la section demandée : b-31) si l'instruction est critique pour la sécurité, le XμP demande une signature σ construite à partir des signatures σ, générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et, en cas de non-validité de cette signature σ, exécute la phase de réaction; b-32) le XμP exécute l'instruction; b-4) le XμP retourne alors à la sous-phase b-1.
16. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 11 caractérisé en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature σ se déroulant avant l'exécution de l'instruction finale de chaque section, si ladite instruction est une instruction critique pour la sécurité, et si l'une au moins des données utilisées par cette instruction est une donnée secrète.
17. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 16 caractérisé en ce qu'il utilise une variable Φ définissant l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné et en ce que la phase d'exécution comporte les sous-phases suivantes : b-1) le XμP demande une section au XT; b-2) pour chaque instruction non finale de la section demandée, le XμP vérifie si cette instruction est critique, effectuant dans ce cas la phase de réaction, et sinon exécute cette instruction et passe à l'instruction suivante; b-3) pour l'instruction finale de la section demandée : b-31) si l'instruction est critique pour la sécurité et si l'une au moins des données utilisées par l'instruction est secrète, le XμP demande une signature o" construite à partir des signatures σ . générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et, en cas de non-validité de cette signature σ, exécute la phase de réaction; b-32) le XμP exécute l'instruction; b-33) le XμP met à jour le niveau de sécurité (donnée secrète ou donnée non secrète) de chacune des données issues de l'exécution ; b-4) le XμP retourne alors à la sous-phase b-1.
18. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 16 caractérisé en ce qu'il utilise une variable Φ définissant l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné, en ce qu'il utilise une fonction booléenne Alert et en ce que la phase d'exécution comporte les sous-phases suivantes : b-1) le XμP demande une instruction au XT; b-2) pour chaque instruction non finale de la section demandée, le XμP vérifie si cette instruction est critique, effectuant dans ce cas la phase de réaction, et sinon exécute cette instruction et passe à l'instruction suivante; b-3) pour l'instruction finale de la section demandée : b-31) si l'instruction est critique pour la sécurité et si la fonction booléenne Alert déterminée à partir du niveau de sécurité des données utilisées par l'instruction et par la nature de l'instruction elle-même s'évalue en VRAI, le XμP demande une signature σ construite à partir des signatures σ- générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et, en cas de non-validité de cette signature σ, exécute la phase de réaction; b-32) le XμP exécute l'instruction; b-33) le XμP met à jour le niveau de sécurité (donnée secrète ou donnée non secrète) de chacune des données issues de l'exécution ; b-4) le XμP retourne alors à la sous-phase b-1.
19. Procédé de sécurisation d'instructions d'un objet portable électronique selon l'une quelconque des revendications 4 à 8 ou 11 à 18, caractérisé en ce qu'au moins un des types suivants d'instructions sont critiques pour la sécurité : les instructions de test et/ou - les instructions émettant de l'information vers l'extérieur par un moyen de communication et/ou les instructions modifiant le contenu de la mémoire non-volatile et/ou les instructions de calcul présentant des cas particuliers lors de leur exécution, tels que le lancement d'exceptions.
20. Procédé de sécurisation d'instructions d'un objet portable électronique selon l'une quelconque des revendications 8 ou 18, caractérisé en ce que la fonction booléenne Alert s'évalue en VRAI pour au moins un des types suivants d'instructions: les instructions de test et/ou les instructions émettant de l'information vers l'extérieur par un moyen de communication et/ou les instructions modifiant le contenu de la mémoire non-volatile et/ou les instructions de calcul présentant des cas particuliers lors de leur exécution, tels que le lancement d'exceptions.
21. Procédé de sécurisation d'instructions d'un objet portable électronique selon l'une quelconque des revendications 8 ou 18, caractérisé en ce que la fonction booléenne Alert s'évalue en VRAI pour au moins un des types suivants d'instructions, si au moins une des données d'entrée est secrète, et FAUX si toutes les données testées sont publiques: les instructions de test et/ou les instructions émettant de l'information vers l'extérieur par un moyen de communication et/ou - les instructions modifiant le contenu de la mémoire non-volatile et/ou les instructions de calcul présentant des cas particuliers lors de leur exécution, tels que le lancement d'exceptions.
22. Procédé de sécurisation d'instructions d'un objet portable électronique selon l'une quelconque des revendications 7 à 8 ou 17 à 18, caractérisé en ce que l'ensemble des niveaux de sécurité Φ utilisé lors de l'exécution d'un programme P est indiqué par la valeur d'une fonction φ, telle que, pour toute donnée u utilisée par le programme, φ(u)=0 désigne le fait que u est publique et φ(u)=l désigne le fait que u est privée, et telle que, pour toute donnée v résultant de l'exécution d'une instruction du programme P, φ (v) =1 si au moins une des données d'entrée de l'instruction est privée, et sinon φ(v)=0.
23. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 22, caractérisé en ce que les valeurs de la fonction φ sont calculées au moyen d'une mise en œuvre matérielle d'une fonction « OU logique » réalisée sur les valeurs de la fonction φ pour les données d'entrée des instructions.
24. Procédé de sécurisation d'instructions d'un objet portable électronique selon l'une quelconque des revendications 1 à 23, caractérisé en ce que les fonctions de hachage HASHi, HASH2 et HASH3 sont identiques .
25. Objet électronique caractérisé en ce qu'il met en œuvre l'une quelconque des revendications 1 à 24.
PCT/EP2005/050828 2004-03-19 2005-02-25 Procede d'authentification dynamique de programmes par un objet portable electronique WO2005101725A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP05716818A EP1728354A1 (fr) 2004-03-19 2005-02-25 Procede d'authentification dynamique de programmes par un objet portable electronique
US10/593,411 US20080232582A1 (en) 2004-03-19 2005-02-25 Method for Dynamically Authenticating Programmes with an Electronic Portable Object

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0450553A FR2867929B1 (fr) 2004-03-19 2004-03-19 Procede d'authentification dynamique de programmes par un objet portable electronique
FR0450553 2004-03-19

Publications (1)

Publication Number Publication Date
WO2005101725A1 true WO2005101725A1 (fr) 2005-10-27

Family

ID=34896797

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/050828 WO2005101725A1 (fr) 2004-03-19 2005-02-25 Procede d'authentification dynamique de programmes par un objet portable electronique

Country Status (4)

Country Link
US (1) US20080232582A1 (fr)
EP (1) EP1728354A1 (fr)
FR (1) FR2867929B1 (fr)
WO (1) WO2005101725A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1881404A1 (fr) * 2006-07-20 2008-01-23 Gemplus Procédé de protection dynamique des données lors de l'exécution d'un code logiciel en langage intermédiaire dans un appareil numérique

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE550725T1 (de) * 2005-12-13 2012-04-15 Gemalto Sa Verfahren zur sicherung der ausführung eines vermittelnden sprachsoftwarecodes bei einer tragbaren anwendung
US7818264B2 (en) 2006-06-19 2010-10-19 Visa U.S.A. Inc. Track data encryption
US8700915B2 (en) 2006-07-12 2014-04-15 Irdeto Corporate B.V. Method and system for verifying authenticity of at least part of an execution environment for executing a computer module
US7502856B1 (en) * 2008-03-31 2009-03-10 International Business Machines Corporation Redirecting file access through a HTTP web server
US9858207B2 (en) 2013-02-06 2018-01-02 International Business Machines Corporation Page level key-based memory protection
US11044076B2 (en) * 2013-02-25 2021-06-22 Hecusys, LLC Encrypted data processing
WO2018160341A1 (fr) * 2017-03-03 2018-09-07 Google Llc Déclenchement d'exécution et de saut de code sécurisé

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0816970A2 (fr) * 1996-07-01 1998-01-07 Sun Microsystems, Inc. Méthode et dispositif d'authentification de microprogrammes
SE517116C2 (sv) * 2000-08-11 2002-04-16 Ericsson Telefon Ab L M Metod och anordning för säkra kommunikationstjänster
EP1369764A2 (fr) * 2002-06-07 2003-12-10 Microsoft Corporation Utilisation de fonctions de hachage dans un système sécurisé de chargement au démarrage d'un ordinateur

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5978484A (en) * 1996-04-25 1999-11-02 Microsoft Corporation System and method for safety distributing executable objects
US6128774A (en) * 1997-10-28 2000-10-03 Necula; George C. Safe to execute verification of software
US7117371B1 (en) * 2000-06-28 2006-10-03 Microsoft Corporation Shared names
US7093132B2 (en) * 2001-09-20 2006-08-15 International Business Machines Corporation Method and apparatus for protecting ongoing system integrity of a software product using digital signatures
EP1429224A1 (fr) * 2002-12-10 2004-06-16 Texas Instruments Incorporated Autentification du firmware en temps d'exécution
US7290138B2 (en) * 2003-02-19 2007-10-30 Microsoft Corporation Credentials and digitally signed objects
US7257712B2 (en) * 2003-05-30 2007-08-14 Microsoft Corporation Runtime digital signatures

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0816970A2 (fr) * 1996-07-01 1998-01-07 Sun Microsystems, Inc. Méthode et dispositif d'authentification de microprogrammes
SE517116C2 (sv) * 2000-08-11 2002-04-16 Ericsson Telefon Ab L M Metod och anordning för säkra kommunikationstjänster
US20040103316A1 (en) * 2000-08-11 2004-05-27 Christian Gehrmann Securing arbitrary communication services
EP1369764A2 (fr) * 2002-06-07 2003-12-10 Microsoft Corporation Utilisation de fonctions de hachage dans un système sécurisé de chargement au démarrage d'un ordinateur

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
TUAL J-P: "MASSC: A GENERIC ARCHITECTURE FOR MULTIAPPLICATION SMART CARDS", IEEE MICRO, IEEE INC. NEW YORK, US, vol. 19, no. 5, September 1999 (1999-09-01), pages 52 - 61, XP000862509, ISSN: 0272-1732 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1881404A1 (fr) * 2006-07-20 2008-01-23 Gemplus Procédé de protection dynamique des données lors de l'exécution d'un code logiciel en langage intermédiaire dans un appareil numérique
WO2008009697A1 (fr) * 2006-07-20 2008-01-24 Gemalto Sa Procédé de protection dynamique de données pendant l'exécution d'un code logiciel dans un langage intermédiaire dans un appareil numérique
US8646092B2 (en) 2006-07-20 2014-02-04 Gemalto Sa Method of dynamic protection of data during the execution of a software code in intermediate language in a digital apparatus

Also Published As

Publication number Publication date
US20080232582A1 (en) 2008-09-25
FR2867929A1 (fr) 2005-09-23
FR2867929B1 (fr) 2007-03-02
EP1728354A1 (fr) 2006-12-06

Similar Documents

Publication Publication Date Title
US10419216B2 (en) Keying infrastructure
EP1728354A1 (fr) Procede d&#39;authentification dynamique de programmes par un objet portable electronique
KR20150008546A (ko) 보안 다운로드 및 기능 실행방법 및 장치
EP0621569A1 (fr) Dispositif de protection des clés d&#39;une carte à puce
WO2001095274A1 (fr) Procede de securisation de la phase de pre-initialisation d&#39;un systeme embarque a puce electronique, notamment d&#39;une carte a puce, et systeme embarque mettant en oeuvre le procede
CN107908977B (zh) 基于TrustZone的智能移动终端信任链安全传递方法及系统
WO2021249359A1 (fr) Procédé et appareil de protection d&#39;intégrité de données
EP2565810A1 (fr) Microprocesseur protégé contre le vidage de mémoire
WO2007132122A1 (fr) Procede et dispositif de configuration securisee d&#39;un terminal au moyen d&#39;un dispositif de stockage de donnees de demarrage
WO2007068706A1 (fr) Procede pour securiser l&#39;execution d&#39;un code logiciel en langage intermediaire dans un appareil portatif
WO2009138641A1 (fr) Procede d&#39;utilisation d&#39;un terminal hote par un dispositif externe connecte au terminal
EP2043017A1 (fr) Procédé d&#39;exécution sécurisée d&#39;une application
EP2252978B1 (fr) Carte a circuit integre ayant un programme d&#39;exploitation modifiable et procede de modification correspondant
EP3179400B1 (fr) Procédé de chargement d&#39;une ressource informatique au sein d&#39;un dispositif électronique, module électronique et programme d&#39;ordinateur correspondant
EP3203405B1 (fr) Procede d&#39;execution d&#39;instructions d&#39;applications orientees objet par un interpreteur
WO2011000722A1 (fr) Procédé de validation distante d&#39;un code exécutable
EP4174709A1 (fr) Procede de verrouillage d&#39;une zone de memoire non-volatile reinscriptible et dispositif electronique mettant en uvre ledit procede
WO2012172245A1 (fr) Transfert securise entre memoire non-volatile et memoire volatile
EP3948596A1 (fr) Procédé d&#39;exécution de code sécurisé, dispositifs, système et programmes correspondants
WO2003069841A1 (fr) Procede de detection des attaques par mise en defaut contre les algorithmes cryptographiques
CN114996773A (zh) 一种soc芯片启动方法、装置及可读存储介质
FR2910658A1 (fr) Systemes electroniques securises,procedes de securisation et utilisations de tels systemes

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 NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM 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): GM KE LS MW MZ NA 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 IS IT LT LU MC NL PL 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
WWE Wipo information: entry into national phase

Ref document number: 2005716818

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

WWP Wipo information: published in national office

Ref document number: 2005716818

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10593411

Country of ref document: US

WWW Wipo information: withdrawn in national office

Ref document number: 2005716818

Country of ref document: EP