EP1728354A1 - Procede d'authentification dynamique de programmes par un objet portable electronique - Google Patents
Procede d'authentification dynamique de programmes par un objet portable electroniqueInfo
- Publication number
- EP1728354A1 EP1728354A1 EP05716818A EP05716818A EP1728354A1 EP 1728354 A1 EP1728354 A1 EP 1728354A1 EP 05716818 A EP05716818 A EP 05716818A EP 05716818 A EP05716818 A EP 05716818A EP 1728354 A1 EP1728354 A1 EP 1728354A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- instruction
- xμp
- phase
- instructions
- execution
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- 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.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- General Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Health & Medical Sciences (AREA)
- Power Engineering (AREA)
- Storage Device Security (AREA)
Abstract
Description
Claims
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 |
PCT/EP2005/050828 WO2005101725A1 (fr) | 2004-03-19 | 2005-02-25 | Procede d'authentification dynamique de programmes par un objet portable electronique |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1728354A1 true EP1728354A1 (fr) | 2006-12-06 |
Family
ID=34896797
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP05716818A Withdrawn EP1728354A1 (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) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2007068706A1 (fr) * | 2005-12-13 | 2007-06-21 | Gemplus | Procede pour securiser l'execution d'un code logiciel en langage intermediaire dans un appareil portatif |
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 |
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 |
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é |
Family Cites Families (10)
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 |
US6138236A (en) * | 1996-07-01 | 2000-10-24 | Sun Microsystems, Inc. | Method and apparatus for firmware authentication |
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 |
SE517116C2 (sv) * | 2000-08-11 | 2002-04-16 | Ericsson Telefon Ab L M | Metod och anordning för säkra kommunikationstjänster |
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 |
US6907522B2 (en) * | 2002-06-07 | 2005-06-14 | Microsoft Corporation | Use of hashing in a secure boot loader |
EP1429224A1 (fr) * | 2002-12-10 | 2004-06-16 | Texas Instruments Incorporated | Autentification du firmware en temps d'exécution |
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 |
-
2004
- 2004-03-19 FR FR0450553A patent/FR2867929B1/fr not_active Expired - Fee Related
-
2005
- 2005-02-25 EP EP05716818A patent/EP1728354A1/fr not_active Withdrawn
- 2005-02-25 US US10/593,411 patent/US20080232582A1/en not_active Abandoned
- 2005-02-25 WO PCT/EP2005/050828 patent/WO2005101725A1/fr not_active Application Discontinuation
Non-Patent Citations (1)
Title |
---|
See references of WO2005101725A1 * |
Also Published As
Publication number | Publication date |
---|---|
FR2867929B1 (fr) | 2007-03-02 |
US20080232582A1 (en) | 2008-09-25 |
FR2867929A1 (fr) | 2005-09-23 |
WO2005101725A1 (fr) | 2005-10-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10419216B2 (en) | Keying infrastructure | |
EP1728354A1 (fr) | Procede d'authentification dynamique de programmes par un objet portable electronique | |
KR20150008546A (ko) | 보안 다운로드 및 기능 실행방법 및 장치 | |
EP0621569A1 (fr) | Dispositif de protection des clés d'une carte à puce | |
WO2001095274A1 (fr) | Procede de securisation de la phase de pre-initialisation d'un systeme embarque a puce electronique, notamment d'une carte a puce, et systeme embarque mettant en oeuvre le procede | |
CN107908977B (zh) | 基于TrustZone的智能移动终端信任链安全传递方法及系统 | |
WO2021249359A1 (fr) | Procédé et appareil de protection d'intégrité de données | |
EP2565810A1 (fr) | Microprocesseur protégé contre le vidage de mémoire | |
EP2024798B1 (fr) | Procédé et dispositif de configuration sécurisée d'un terminal au moyen d'un dispositif de stockage de données de démarrage | |
WO2007068706A1 (fr) | Procede pour securiser l'execution d'un code logiciel en langage intermediaire dans un appareil portatif | |
WO2009138641A1 (fr) | Procede d'utilisation d'un terminal hote par un dispositif externe connecte au terminal | |
EP2043017A1 (fr) | Procédé d'exécution sécurisée d'une application | |
EP1410152B1 (fr) | Securisation de lecture d'instructions dans un systeme de traitement de donnees | |
EP2252978B1 (fr) | Carte a circuit integre ayant un programme d'exploitation modifiable et procede de modification correspondant | |
EP3179400B1 (fr) | Procédé de chargement d'une ressource informatique au sein d'un dispositif électronique, module électronique et programme d'ordinateur correspondant | |
EP3203405B1 (fr) | Procede d'execution d'instructions d'applications orientees objet par un interpreteur | |
WO2011000722A1 (fr) | Procédé de validation distante d'un code exécutable | |
EP4174709A1 (fr) | Procede de verrouillage d'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'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 | |
Pedapati et al. | Public Key Infrastructure in SCOSTA |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20061019 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU MC NL PL PT RO SE SI SK TR |
|
17Q | First examination report despatched |
Effective date: 20070125 |
|
DAX | Request for extension of the european patent (deleted) | ||
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: GEMPLUS |
|
GRAS | Grant fee paid |
Free format text: ORIGINAL CODE: EPIDOSNIGR3 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20080229 |