• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    In this method, a hardware module for securing a microprocessor: 1) checks (176) the integrity and authenticity of a cryptogram contained in a line of code loaded with an authentication code of message contained in this same line and triggers (172) the report of an execution fault if the integrity or authenticity of the cryptogram is not confirmed, then 2) decrypts (178) the cryptogram to obtain a decrypted instruction or decrypted data if the integrity and authenticity of the cryptogram are confirmed, then: - in the case of a decrypted instruction, the decrypted instruction is recorded (180) in a statement queue to be executed successively after the others by an arithmetic and logic unit of the microprocessor, and - in the case of a decrypted datum, the deciphered datum is recorded in an internal register of the microprocessor waiting to be processed by the uni arithmetic and logical.
    公开号:FR3071121A1
    申请号:FR1758506
    申请日:2017-09-14
    公开日:2019-03-15
    发明作者:Olivier Savry
    申请人:Commissariat a lEnergie Atomique CEA；Commissariat a lEnergie Atomique et aux Energies Alternatives CEA；
    IPC主号:
    专利说明:

    METHOD FOR EXECUTING A BINARY CODE OF A SECURE FUNCTION
    BY A MICROPROCESSOR [001] The invention relates to a method for executing a binary code of a function secured by a microprocessor. The invention also relates to:
    a binary code of a secure function, an information recording medium and a microprocessor for the implementation of this execution method, and
    - a compiler to generate this binary code.
    To obtain information on a binary code or cause an unexpected operation of the binary code, many attacks are possible. For example, attacks known as "fault injection" or "fault attack" in English can be implemented. These attacks consist in disturbing the operation of the microprocessor or of the memory containing the binary code, by various physical means such as modifications of the supply voltages, modifications of the clock signal, the exposure of the microprocessor to electromagnetic waves and others. .
    [003] With the aid of such attacks, an attacker can alter the integrity of machine instructions or data to, for example, find a secret key of a cryptographic system, bypass security mechanisms such as verification of a PIN code during authentication or simply preventing the execution of a function essential for the security of a critical system.
    These attacks can in particular cause three types of faults, called execution faults, during the execution of the binary code:
    1) an alteration of the instructions of the machine code executed,
    2) alteration of the data stored in the main memory or in microprocessor registers, and
    3) an alteration of the machine code control flow.
    The control flow corresponds to the execution path followed during the execution of the machine code. The control flow is conventionally represented in the form of a graph known as the control flow graph or "control flow graph" in English.
    The binary code of a function can be instrumented to allow detection and reporting of execution faults. When the binary code of a function is thus instrumented, this binary code is qualified as “binary code of a secure function”. In fact, unlike the binary code of an unsecured function, this binary code is able to allow the reporting of execution faults typically encountered in the event of attacks.
    The objective here is to propose a method for executing a binary code of a secure function which offers at least one of the following possibilities:
    - detect an execution fault if an instruction of the machine code of the secure function is altered,
    - detect an execution fault if the control flow is altered,
    - detect an execution fault in the event of a malfunction of an arithmetic and logical unit during the execution of an instruction by this unit,
    - detect an execution fault if the data processed during the execution of the secure function are altered.
    The invention therefore relates to such a method of executing a binary code of a function secured by a microprocessor, in which this method comprises:
    a) the supply of the binary code, this binary code comprising lines of code, each line of code containing:
    - a cryptogram of a single instruction executable by the microprocessor or of a single datum to be processed by the microprocessor, and
    - a message authentication code to verify the integrity and authenticity of the cryptogram,
    b) during the execution of the binary code by the microprocessor, each time the microprocessor loads a line of code, the process comprises the following operations:
    1) a hardware module for securing the microprocessor checks the integrity and authenticity of the cryptogram contained in the line of code loaded using the message authentication code contained in this same line and triggers the reporting of a fault if the integrity or authenticity of the cryptogram is not confirmed, then
    2) the hardware security module decrypts the cryptogram to obtain a decrypted instruction or a decrypted data if the integrity and authenticity of the cryptogram are confirmed, then:
    - in the case of a decrypted instruction, the deciphered instruction is recorded in a queue of instructions to be executed successively one after the other by an arithmetic and logic unit of the microprocessor, and
    - in the case of decrypted data, the decrypted data is recorded in an internal register of the microprocessor while waiting to be processed by the arithmetic and logic unit.
    The embodiments of this execution process can include one or more of the following characteristics:
    - during step a), the cryptogram contained in the line of code is a cryptogram of a concatenation of said instruction or given and of a first error detecting code making it possible to detect an error in the instruction or in the data with which it is concatenated,
    - during operation 2), the decryption of the cryptogram by the hardware security module makes it possible to obtain, in addition to the decrypted instruction or the decrypted data, the first decrypted error detector code, then:
    - in the case of a decrypted instruction, the first decrypted error code is recorded in the instruction queue with the decrypted instruction, and
    - in the case of decrypted data, the decrypted data and the first decrypted error detecting code are recorded in the same microprocessor register, and
    - after operation 2), the process includes operation 3) as follows:
    - when the next instruction to be executed contained in the instruction queue is the instruction deciphered during operation 2), the security hardware module checks, using the first error detector code recorded with this deciphered instruction , if there is an error in this decrypted instruction, and, in the case where such an error is detected in this decrypted instruction, the hardware security module triggers the signaling of an execution fault, and, in the case where no error was detected in this deciphered instruction, the microprocessor decodes the deciphered instruction and transmits it to the arithmetic and logical unit which executes it, or
    - when the next data item to be processed by the arithmetic and logic unit is the data decrypted during operation 2), the hardware security module checks, using the first recorded error detection code associated with this decrypted data , if there is an error in this decrypted data, and, in the case where such an error is detected, the hardware security module triggers the signaling of an execution fault, and, in the case where no error is detected, the arithmetic and logical unit processes this deciphered data;
    - during step a), the first error detecting code is an error correcting code allowing, in addition, to correct the error detected in the instruction or in the data with which it is concatenated,
    - during operation 3):
    - when the security hardware module detects an error in the decrypted instruction, in addition to triggering the signaling of an execution fault, the security hardware module corrects this error using the first decrypted error detector code recorded together with this deciphered instruction, then the microprocessor decodes the instruction thus corrected and transmits it to the arithmetic and logical unit which executes it, or
    - when the security hardware module detects an error in the decrypted data, in addition to triggering the reporting of an execution fault, the security hardware module corrects this error using the first associated decrypted error detector code to this deciphered data, then the arithmetic and logical unit processes the corrected data;
    - during step a), each line of code comprises, in addition to the cryptogram and the message authentication code, a second error detecting code making it possible to detect an error in the cryptogram or the authentication code of message contained in the same line of code,
    - during step b) before the execution of operation 1), the method includes an operation during which the hardware security module verifies, using the second error detector code contained in the line of code loaded, if there is an error in the cryptogram or message authentication code contained in the loaded line of code, and in the event that such an error is detected, the hardware security module triggers the reporting of a failure to execute and, if no error is detected, the process continues with operation 1);
    - during step a), the second error detecting code is an error correcting code allowing, in addition, to correct the error detected in the cryptogram or the message authentication code contained in the same line of code,
    - if the security hardware module detects an error in the cryptogram or message authentication code, in addition to triggering the signaling of an execution fault, the security hardware module corrects this error using the second error detection code, then the process continues with operation 1) during which the corrected cryptogram and the corrected message authentication code are used;
    - during operation 1), a first encryption key is used to verify the authenticity of the cryptogram contained in the loaded line of code, and during operation 2), a second decryption key is used to decrypt the cryptogram, this second decryption key being different from the first decryption key;
    - during step a), the binary code provided includes a machine code containing a succession of basic blocks in which:
    each basic block comprises a succession of lines of code each containing the cryptogram of an instruction, the instructions encrypted in these successive lines of code being intended to be executed by the microprocessor systematically in the order of these lines of code, and
    each base block begins at a branch address and ends with a line of code containing the cryptogram of a branch instruction to a branch address of another base block, this other base block being called "the next basic block "and the basic block which ends with the line of code containing the cryptogram of this instruction to connect to this next basic block being called" previous basic block ",
    the cryptogram contained in a specific line of code of a following basic block having been obtained using an initialization vector different from the initialization vectors used to obtain the cryptograms of lines of code of the other blocks of based,
    each preceding basic block comprising a line of code containing the cryptogram of a loading instruction which, when executed by the microprocessor, causes the loading into the microprocessor of the initialization vector to be used to decrypt the cryptogram of the specific line of code for the next base block,
    - during operation 2), the hardware security module decrypts the cryptogram of the specific line of code of a following basic block using the initialization vector loaded in the microprocessor during the execution of the block previous basic;
    - during step a), the binary code includes a machine code containing:
    - a basic block called “calling block” which ends with a line of code containing the cryptogram of a branching instruction which, when executed by the microprocessor, performs a branching to a branching address of a sub - secure function,
    - another basic block called “return block”, and
    the secure sub-function formed by one or more basic blocks, this secure sub-function being callable from the various basic blocks of the secure function and starting with a first basic block and ending with a last block of base, the first base block starts at the branching address of the secure sub-function and the last base block ends with a line of code containing the cryptogram of a particular branching instruction called "return instruction" which , when executed by the microprocessor, makes a connection to the connection address of the return block,
    - during a first execution of operation 2), the security hardware module records in a first microprocessor register the connection address of the return block and the initialization vector necessary to decrypt this return block, then
    - during a second execution of operation 2) during which the return instruction of the secure sub-function is decrypted, the branch address used for the execution of the return instruction is read in the first register and then
    - during a third execution of operation 2) during which the specific line of code of the return block is decrypted, the hardware security module uses the initialization vector recorded in the first register to decrypt the cryptogram of the line of code specific to the return block;
    - before step b), the process includes recording:
    - a first cryptographic certificate allowing authentication of a public key of an operating system executed by the microprocessor,
    - a second cryptographic certificate allowing authentication of a public key of the microprocessor,
    - a third cryptographic certificate used to authenticate a public key of the author of the secure function,
    - a cryptogram of a decipherable application key using the public key of the microprocessor,
    - a signature of the verifiable application key using the author's public key,
    - at the start of step b) the hardware security module checks in order:
    - the authenticity of the first and third cryptographic certificate using the public key of the operating system,
    - only if the authenticity of the author's public key has been confirmed, the authenticity of the signing of the application key using the author's public key,
    - only if the authenticity of the signature of the application key has been confirmed, the decryption of the cryptogram of the application key with the public key of the microprocessor, then
    - during operation 2), the decryption of the cryptogram is carried out using this decrypted application key;
    during operation 1), the hardware security module:
    - builds a label from the cryptogram contained in the loaded line of code, then
    - encrypts the label constructed using a secret key recorded in a non-volatile memory of the security hardware module, then
    - compare the encrypted label with the message authentication code contained in the loaded line of code, then
    - confirms the integrity and authenticity of the cryptogram only if the encrypted label is identical to this message authentication code;
    - during step a), the binary code provided contains:
    - an arithmetic and logic instruction comprising an opcode and one or more operands which, when executed by an arithmetic and logic unit of the microprocessor, causes the operation Di * D 2 * ... * D n and l 'recording of the result of this operation in a Rresj register where:
    Di to D n are data recorded, respectively, in registers Ri to R n of the microprocessor,
    - the registers Ri to R n are the registers designated by the operands of the arithmetic and logic instruction,
    - the symbol "*" is the arithmetic and logic operation designated by the opcode of the arithmetic and logic instruction, and
    - the index n is an integer greater than or equal to one,
    - for each register Ri to R n , a loading instruction which, when executed by the microprocessor, causes the loading of data D, in the register R ,, where the index i is an identifier of the register R , among the registers Ri to R n ,
    - during the execution of step b), the process includes the following operations:
    - each time an instruction to load a data item Di into the register R, is executed by the microprocessor, a hardware module for securing the microprocessor calculates a code C ,, * using a relation C, , * = F * (Di), and the loaded data D, is recorded in the register R, and the calculated code C ,, * is recorded in the same register R, or in a register associated with the register R ,, the function F * being a preprogrammed function of the security hardware module,
    - in the case where n is greater than or equal to two, this function F * being a homomorphism from a set A of numbers provided with the operation "*" to a set B of numbers provided with the operation "#", which verifies the relation: F. (Di * D 2 * ... * D n ) = F. (Di) # F. (D 2 ) # ... # F. (Dn) = C v # C 2 , * # ... # Cn, *,
    - in the case where n is equal to one, this function F * is such that F * (Di) = T * (F. (Di)), where the function T * is a function preprogrammed in the hardware security module,
    the execution by the arithmetic and logical unit of the arithmetic and logical instruction contained in the binary code and the recording of the result D re s- P of this execution in the register R re s, then
    - the hardware security module:
    - calculates a code C re sp using the relation C re sp = F. (D res - P ) if n is greater than one and, otherwise, using the relation C re sp = T <D re sp) if n is equal to one, and
    - calculates a code C res -t using the relation C res -t = C v # C 2 , * # ... # C n , *, then
    - compares the codes C res - P and Cres-t and triggers the signaling of an execution fault if the code C res - P does not correspond to the code Cres-t and, if not, inhibits this signaling;
    - the method comprises recording in a main memory at an address @j of a line of code, this line of code containing:
    a Dj data to be processed by the microprocessor or a cryptogram of this Dj data, and
    a first error detecting code making it possible to detect an error in the data Dj or in its cryptogram if this data Dj or its cryptogram is modified after its recording in the main memory, at least one of the data Dj, of its cryptogram and of the first error detecting code being encrypted as a function of an initialization vector ivj, this initialization vector ivj varying according to the address @j at which the line of code is registered according to a relation ivj = F iv (@j), where the function F iv is a preprogrammed function of a hardware module for securing the microprocessor which associates a different initialization vector ivj with each address @j different from the main memory,
    - during the execution of the binary code by the microprocessor, the process includes the following operations:
    - the execution of a loading instruction by the microprocessor which causes the loading in the registers of the microprocessor of the line of code recorded at the address @j, then
    - the hardware security module calculates the initialization vector ivj using the relation ivj = Fk (@j), where @j is the address from which the line of code was loaded, then
    - the hardware security module decrypts the line of code loaded using the ivj initialization vector calculated to obtain:
    - the Dj data or its cryptogram, and
    - the first error detection code, then
    - the security hardware module checks, using the first error detection code obtained, if there is an error in the data Dj or its cryptogram and, if such an error exists, triggers the reporting of a fault d execution and, if such an error does not exist, inhibits this signaling of a failure to perform.
    The invention also relates to a binary code of a secure function executable by a microprocessor for the implementation of the claimed method, in which the binary code comprises lines of code, each line of code containing:
    - a cryptogram of a single instruction executable by the microprocessor or of a single datum to be processed by the microprocessor, and
    - a message authentication code to verify the integrity and authenticity of the cryptogram.
    The invention also relates to an information recording medium readable by a microprocessor, this information recording medium containing the claimed binary code.
    The invention also relates to a microprocessor for the implementation of the claimed method, this microprocessor comprising an arithmetic and logic unit and a hardware security module, in which the hardware security module is configured to execute operations 1 ) and 2) of the claimed process.
    Finally, the invention also relates to a compiler capable of automatically transforming a source code of a secure function into a binary code of this secure function, in which the compiler is capable of automatically transforming the source code into a code binary claimed.
    The invention will be better understood on reading the description which follows, given solely by way of nonlimiting example and made with reference to the drawings in which:
    - Figure 1 is a schematic illustration of the architecture of an electronic device capable of executing a binary code of a secure function;
    FIG. 2 is a schematic illustration of the structure of a line of code coding an instruction of the binary code executed by the apparatus of FIG. 1,
    - Figures 3 to 5 are schematic illustrations of different portions of the binary code of the secure function that can be executed by the device of Figure 1;
    - Figure 6 is a flowchart of a method for executing the binary code of the secure function;
    FIG. 7 is a schematic illustration of the structure of a register of the microprocessor of the device of FIG. 1,
    FIG. 8 is a flow diagram of a detail of a step of the method of FIG. 6 implemented to secure the operation of an arithmetic and logic unit of the microprocessor of the device of FIG. 1,
    FIG. 9 is a schematic illustration of the structure of a line of code encoding a data item processed during the execution of the binary code by the device of FIG. 1,
    - Figure 10 is a flowchart of a detail of a step of the method of Figure 6 implemented to secure the data processed during the execution of the binary code by the device of Figure 1
    FIG. 11 is a schematic illustration of a compiler capable of generating the machine code executed by the device of FIG. 1.
    Chapter I: Conventions, notations and definitions:
    In the figures, the same references are used to designate the same elements. In the remainder of this description, the characteristics and functions well known to those skilled in the art are not described in detail.
    In this description, the following definitions are adopted.
    A “program” designates a set of one or more predetermined functions which it is desired to have executed by a microprocessor.
    A “source code” is a representation of the program in a computer language, not being directly executable by a microprocessor and being intended to be transformed by a compiler into machine code directly executable by the microprocessor.
    A program or code is said to be "directly executable" when it is capable of being executed by a microprocessor without this microprocessor needing to first compile it by means of a compiler or to interpret it. by means of an interpreter.
    An “instruction” designates a machine instruction executable by a microprocessor. Such an instruction consists of:
    - an opcode, or operation code, coding the nature of the operation to be performed, and - one or more operands defining the value or values of the parameters of this operation.
    A “machine code” is a set of machine instructions. It is typically a file containing a succession of bits carrying the value "0" or "1", these bits coding the instructions to be executed by the microprocessor. The machine code is directly executable by the microprocessor, that is to say without requiring prior compilation or interpretation.
    A “binary code” is a file containing a succession of bits carrying the value “0” or “1”. These bits encode data and instructions to be executed by the microprocessor. Thus, the binary code comprises at least one machine code and in addition, generally, digital data processed by this machine code.
    An “instruction stream” is a succession of instructions classified one after the other and which forms, in the machine code, an ordered sequence of bits. The instruction stream begins with an initial instruction and ends with a final instruction. Compared to a given instruction in the instruction flow, the instructions located on the side of the initial instruction are called "previous instructions" and the instructions located on the side of the final instruction, are called "following instructions". In this text, this flow of instructions in memory is divided into a succession of basic blocks immediately consecutive or separated by blocks of data.
    In this text, a "basic block" is a group of successive instructions from the instruction stream which begins at a branch address and which ends with a single explicit or implicit branch instruction. An explicit branching instruction is characterized by the explicit presence of an opcode in the machine code which codes the branching instruction. An implicit branch instruction corresponds to the case where the execution of a previous base block systematically continues with the execution of a next base block located, in the machine code, immediately after the previous base block. In this case, since in the absence of an explicit connection instruction, the machine code instructions are executed in order one after the other, it is not necessary to introduce at the end of the basic block preceding an explicit branch instruction to the next base block. In this description, it is said that in this case, the previous basic block ends with an implicit branch instruction because it is not explicitly coded in the machine code. In this case, the previous base block ends just before the branch address of the next base block. In this request, the expression “branching instruction” designates an explicit branching instruction unless otherwise stated. Thus, the execution of a basic block systematically begins with the execution of the instruction located at its branching address and systematically ends with the execution of the branching instruction which terminates this basic block. A basic block does not have any other connection instructions than the one located at the end of this basic block. Thus, the instructions of a basic block are systematically all read by the microprocessor one after the other in the order in which they are present in this basic block. The branching instruction can direct, when executed, the control flow systematically to the same branching address or, alternately, to different branching addresses. This latter scenario occurs, for example, when at the end of the basic block executed, the control flow can continue towards a first and, alternately, towards a second basic block.
    A “connection instruction” is an instruction which, when executed by the microprocessor, triggers a jump to the connection address of another base block. This branch instruction therefore includes at least the branch address of this other basic block. Typically, for this purpose, this instruction replaces the current value of the ordinal counter with the value of the branch address. It will be recalled that the ordinal counter contains the address of the next instruction to be executed by the microprocessor. In the absence of a branch instruction, each time an instruction is executed, the ordinal counter is incremented by the size of the instruction currently executed. In the absence of a connection instruction, the instructions are systematically executed sequentially one after the other in the order in which they are recorded in a main memory. The connection instruction can be unconditional, that is to say that the jump to the connection address is systematically carried out as soon as this instruction is executed. An unconditional connection instruction is for example the “JMP” instruction in assembly language for microprocessors of the x86 series. The branching instruction can also be conditional, that is to say that the jump to the branching address is triggered during its execution only if a particular condition is verified. For example, a conditional branch instruction is a “JE”, “JA” or “JNE” instruction in assembler. The connection instruction can also be a call to a function. In this text, the term “connection instruction” designates both direct and indirect connection instructions. A direct branch instruction is a branch instruction which directly contains the numerical value of the branch address. An indirect branch instruction is a branch instruction to a branch address contained in a memory or a register of the microprocessor. Thus, unlike a direct branch instruction, an indirect branch instruction does not directly contain the numerical value of the branch address.
    A “branch address” is the address in the main memory at which the first instruction executed from a basic block is located. Subsequently, we speak of a branch address even for basic blocks whose first instruction is executed following the execution of an implicit branch instruction. We speak of execution of a function to designate the execution of instructions performing this function.
    For the sake of simplification, in this description and in the figures, the instructions are not represented in binary form, but rather in a symbolic form expressed in an advanced language of a higher level.
    Chapter II: Architecture of the device:
    Figure 1 shows an electronic device 1 comprising a microprocessor 2, a main memory 4 and a mass storage medium 6. For example, the device 1 is a computer, a smartphone, an electronic tablet or the like.
    The microprocessor 2 here comprises:
    - an arithmetic and logical unit 10;
    - a set 12 of registers;
    - a control module 14;
    a data input / output interface 16,
    an instruction loader 18 comprising an ordinal counter 26,
    a queue 22 of instructions to be executed, and
    a hardware module 28 for securing.
    The memory 4 is configured to store instructions of a binary code 30 of a program to be executed by the microprocessor 2. The memory 4 is a random access memory. Typically, the memory 4 is a volatile memory. The memory 4 can be a memory external to the microprocessor 2 as shown in FIG. 1. In this case, the memory 4 is produced on a substrate mechanically separated from the substrate on which the various elements of the microprocessor 2 are produced such as the unit 10.
    Here, the memory 4 is divided into successive machine words of fixed length. Each machine word can be transferred in a single clock cycle from memory 4 to a microprocessor register. For this purpose, the size N mm of a machine word is equal to the maximum number of bits which can be transferred simultaneously from the memory 4 to a register of the set 12. Here, the size N mm is strictly greater N ins t bits, where N ins t bits is the number of bits in the instructions in the microprocessor 2 instruction set. Typically, N ins t is an integer greater than or equal to 8, 16, 32 or 64. In this example, N inst is equal to 32 and the size N M m is equal to 128 bits.
    By way of illustration, the binary code 30 includes in particular a machine code 32 of a secure function and a block 34 of data necessary for the decryption of the binary code 30. Each secure function corresponds to a set of several lines of code , for example several hundred or thousands of lines of code, recorded at successive addresses in the memory 4. Here, each line of code corresponds to a machine word. Thus, a line of code is loaded into a register of the microprocessor 12 in a single read operation. Likewise, a line of code is written into the memory 4 by the microprocessor 2 in a single write operation. Each line of code codes either a single instruction or a single data item. The structure of a line of code for secure functions is described in detail with reference to Figures 2 and 9.
    Block 34 is typically located in a predetermined address range at the start of binary code 30. Thus, the execution of binary code 30 begins with the loading and processing of data from block 34. Here, block 34 includes in particular:
    a cryptogram ka * obtained by encrypting a key ka using a public key pk CPU of the microprocessor 2,
    the cryptogram iv in i * obtained by encrypting, using the public key pk CP u, an initialization vector iv in i used to encrypt the first basic block by which the execution of the machine code 32 systematically begins ,
    a signature S ka * of the cryptogram ka * obtained by encrypting a label, constructed from the cryptogram ka *, using a private key sk aut of an author of the binary code 30,
    - a cryptographic certificate C au t which makes it possible to verify the Ska * signature, this certificate being signed using a private key sk 0S of an operating system and containing a public key pk aut which makes it possible to verify the authenticity of the Ska * signature.
    The label of the ka * cryptogram is typically obtained by applying a predetermined hash function ("hash function" in English) on the ka * cryptogram. Such a label is better known by the English term "digest".
    By way of illustration, the microprocessor 2 conforms to the RISC architecture ("Reduced Instructions Set Computer").
    Here, the unit 10 is an arithmetic and logical unit of N ins t bits.
    The loader 18 loads into the queue 22 the next instruction to be executed by the unit 10 from the memory 4. More specifically, the loader 18 loads the instruction pointed to by the ordinal counter 26. In this mode of embodiment, the loader 18 systematically loads into the queue 22 and each time an instruction lj and an error correcting code ECCij. The ECCij code is coded on N EC cij bits, where Necci] is an integer often strictly less than N ins t and, generally, greater than 1 or 2 or 3 bits. To this end, the queue 22 comprises a succession of several registers each of width equal to N ECCij + Ninst bits.
    The unit 10 is in particular configured to execute one after the other the instructions loaded in the queue 22. The instructions loaded in the queue 22 are generally systematically executed in the order in which these instructions have been recorded in this queue 22 The unit 10 is also capable of recording the result of these instructions executed in one or more of the registers of the set 12.
    In this description, we will use as synonyms "execution by microprocessor 2" and "execution by unit 10".
    The module 14 is configured to move data between the set 12 of registers and the interface 16. The interface 16 is in particular capable of acquiring data and instructions, for example, from the memory 4 and / or the support 6 external to the microprocessor 2.
    The module 28 is capable of automatically executing the various operations described in detail in the following chapters to secure the execution of the secure functions. The module 28 operates independently and without using the unit 10. Thus, it is capable of processing the lines of code before and / or after they are processed by the unit 10. For this purpose, it notably includes a memory secure non-volatile 29. No access to this memory 29 without passing through the module 28 is provided. In this embodiment, the module 28 is pre-programmed, for example during its design, to execute operations such as the following operations:
    - check an error correcting code and correct the error from this code if necessary,
    - check an error detector code,
    - build a detector code or error corrector from data,
    - check the integrity and authenticity of a data using a message authentication code better known by the acronym MAC (“Message Authentication Code”),
    - encrypt data to obtain a cryptogram,
    - decipher a cryptogram to obtain clear data,
    - verify a cryptographic signature and / or a cryptographic certificate,
    - execute a preprogrammed function F iv .
    The memory 29 is used to store the secret information necessary for the implementation of the method of FIG. 6. Here, it therefore notably includes secret information pre-recorded before the start of the execution of the binary code 30. In particular, it includes the following pre-recorded information:
    a secret key k ′ used for verifying the message authentication codes,
    - a cryptographic certificate C os issued by a trusted authority and comprising a public key pk os of this trusted authority,
    - a cryptographic certificate Ccpu which is signed by the trusted authority using a private key sk 0S which makes it possible to encrypt data which must be decrypted using the public key pk os , this certificate containing a pk CPU public key,
    a secret private key sk CPU which makes it possible to decrypt the data which has been encrypted using the public key pk CPU- In this embodiment, the set 12 comprises general registers usable for storing any type of data. The size of each of these registers is, for example, equal to Nmm.
    A data exchange bus 24 which connects the different components of the microprocessor 2 to each other is shown in Figure 1 to indicate that the different components of the microprocessor can exchange data with each other. The support 6 is typically a non-volatile memory. For example, it is an EEPROM or Flash type memory. It contains here a backup copy 40 of the binary code 30. Typically, it is this copy 40 which is automatically copied into memory 4 to restore the code 30, for example, after a power cut or similar or just before it starts execution of code 30.
    CHAPTER III: SECURING THE MACHINE CODE:
    Here, the structure of the machine code of the secure function is described in the particular case of machine code 32. However, what is described in this particular case easily transposes to any machine code of a secure function.
    The machine code 32 comprises a succession of lines of code Llj recorded one after the other in the memory 4. Subsequently, in this chapter, the index j is used to identify the line of code Llj among the others lines of code of machine code 32. In addition, the index j is also used as a serial number indicating in what order the lines Llj are classified. Thus, we denote LI J + i the line of code located immediately after the line Llj. Each line of code Llj codes an instruction from the instruction set of the microprocessor 2 capable of being executed after being decrypted and decoded by the unit 10 of this microprocessor.
    The structure of all the lines Llj are identical. It is shown in detail in Figure 2 in the particular case of the line Llj. The Llj line includes a cryptogram Clj *, a MACj code, and an ECClj code.
    The cryptogram Clj * is obtained by encrypting a concatenation Clj using the secret key ka and an initialization vector iv k . More precisely, the cryptogram Clj * is obtained using the following relation: Clj * = f ka (Clj; iv k ), where f ka is an encryption function corresponding to a deciphering function fio 1 preprogrammed in the module 28. Typically, the function f ka is a symmetric encryption function. Consequently, the key ka making it possible to decrypt the cryptogram Clj * is prerecorded in the memory 29 in order to allow the module 28 to decrypt this cryptogram Clj *. As explained below, the initialization vector iv k is contained in a preceding line of code of the machine code 32.
    The concatenation CI; here is the concatenation of an instruction lj to be executed by the microprocessor 2 and an ECCy code. The ECCy code is used to detect an error in the lj instruction and to correct this error. For example, the ECCy code can be the code known by the acronym BCH (Bose, Ray-Chaudhuri, Hocquenghem) which has the advantage of being particularly easy to implement. However, any other known error correcting code can be implemented. The size of the ECCy code is greater than or equal to 1 or 2 or 3 bits and, generally, less than N ins t. The size of the ECCij code is determined according to the desired robustness. The more we want to be able to correct a large number of erroneous bits in the instruction lj, the larger the size of the ECCy code.
    The MACj code is a code used to verify the integrity and authenticity of the Clj * cryptogram. This code is commonly called "message authentication code" and known by the acronym MAC ("Message Authentication Code"). Such a MACj code is obtained by constructing a label from the cryptogram Clj * which normally has fewer bits than the cryptogram Cij *. This label is constructed using a predetermined function such as a hash function. Then, this label is encrypted with the secret key k ’known only to the author of the binary code 30 and to the microprocessor 2. Here, the key k’ is prerecorded in memory 29.
    As an example, to generate the cryptogram Clj * and the MAC code; an authenticated stream encryption algorithm is used. This authenticated stream encryption algorithm can be chosen from the various candidates for the CAESAR competition (“Competition for Authentified Encryption: Security, Applicability, and Robustness”), such as one of the algorithms designated by the following names: “ACORN” , "ASCON", "SILC", "CLOC", "JAMBU", "KETJE".
    The ECC code L j is an error correcting code which makes it possible to detect and correct an error in the cryptogram Clj * and the code MACj. It is for example constructed as described in the case of the ECCij code.
    Thereafter, we note @j the address in memory 4 to which the line Llj is recorded.
    The machine code 32 consists of a succession of basic blocks which must be executed one after the other. Here, each basic block consists of a succession of lines of code which each includes the cryptogram Clj * of the instruction lj to be executed.
    3 shows a first arrangement of two base blocks 50 and 52 of the machine code 32. In this first arrangement, the base blocks 50 and 52 are systematically executed one after the other. In the order of execution, the base block 50 precedes the base block 52. In this figure and the following figures:
    - the order of execution of the basic blocks is represented by an arrow which points from the previous basic block to the next basic block,
    a dotted arrow pointing towards a basic block shown indicates that the basic block or blocks which precede this basic block have not been shown to simplify the figure,
    a dotted arrow which points in a vacuum from a represented base block indicates that the base block or blocks following this represented base block have not been shown to simplify the figure,
    - the symbol "..." inside a basic block indicates that all the lines of code of this basic block have not been represented.
    Each base block begins with a branch address and ends with a line of code which contains the cryptogram of a branch instruction. In FIG. 2, the symbols “@ 50” and “@ 52” next to the first line of code of each base block designate the branching addresses, respectively, of base blocks 50 and 52. The symbol “@XX "Designates the connection address of another basic block not shown in FIG. 2.
    The symbol “Load iv xx ” indicated in the penultimate line of code of the basic block indicates that this line of code comprises the cryptogram of an instruction which, when executed by the microprocessor 2, causes the loading of a new initialization vector iv xx into the memory 29. Thus, the symbol “Load iv 52 ” indicates that the initialization vector iv 52 is loaded into the memory 29 before the execution of the execution of the basic block 52.
    The symbol "Branch @XX" indicated inside the last line of code in the basic block indicates that this last line contains the cryptogram of an instruction which, when executed by the microprocessor 2, causes an unconditional connection to the connection address @XX.
    Here, the same initialization vector iv k is used to decrypt all the cryptograms Clj * of all the lines of code of the same basic block BB k . The index k unambiguously identifies the basic block BB k among all the basic blocks of the machine code 32. In the figures and in the description, the symbol iv k is subsequently used to generally designate the vector of initialization to be used to decipher the basic block BB k . In addition, in simple cases like the one represented in FIG. 3 where two basic blocks follow each other in the order of execution of the machine code 32, the index k is also used to indicate the order in which these blocks of base are executed. For example, the notation BB k _i is, in these simple cases, used to denote the basic block systematically executed immediately before the basic block BB k .
    Here, the initialization vector iv k is unique for each basic block BB k . By “unique for each basic block”, we designate the fact that the probability that two different basic blocks of machine code 32 are encrypted with the same initialization vector iv k is less than a chance in 100 or in 1000. In in particular, the expression “unique for each basic block” therefore covers the case where the initialization vectors iv k of all the basic blocks are systematically different from each other. For example, in a simple embodiment, during the generation of code 32, the initialization vectors iv k of each base block are drawn randomly or pseudo-randomly in the set {1; ...; 2 Ninst }.
    As shown in FIG. 3, in code 32, the initialization vector iv k is loaded into memory 29 only during the execution of a basic block preceding the basic block BB k . In FIG. 3, the initialization vector iv 52 necessary to decipher the block 52 is loaded during the execution of the block 50.
    FIG. 4 represents another possible arrangement of several basic blocks of code 32 in the particular case of two preceding basic blocks 60 and 62 and of a following basic block 64. Here, blocks 60 and 64 are , for example, identical, respectively, to blocks 50 and 52 except that the initialization vector of block 64 is denoted “iv 64 ”. Block 62 is constructed like block 60 and, in particular, it ends with two lines of code which code the same instructions as those coded in the last two lines of block 60. However, even if these last two lines code the same instructions, the cryptograms of these instructions are different because block 62 is encrypted using an iv initialization vector 62 different from the iv vector 60 used to encrypt block 60. The other lines of code in block 62 are different from those of block 60.
    FIG. 5 represents part of the architecture of the machine code 32 when a basic block ends with a call to a machine code 68 from a secure subfunction. The machine code 68 is arranged as previously described for the machine code 32. It therefore consists of a succession of basic blocks. To simplify FIG. 5, only the first base block 80 and the last base block 82 of this machine code 68 have been shown.
    The machine code 68 can be called from different basic blocks of the machine code 32 and, when the execution of the machine code 68 is finished, the flow of instructions can return to different basic blocks of the machine code 32 Thus, the basic block which must be executed after the basic block 82 depends on the basic block which has called the machine code 68. Consequently, contrary to what has been described with reference to FIGS. 3 and 4, the block base 80 does not end with a line of code which codes a connection instruction systematically to the same address but with a line of code which codes a "Return" instruction. Consequently, in FIG. 5, the symbol "Return" is used to identify the last line of block 82.
    Unlike the "Branch" instruction previously described, the "Return" instruction does not explicitly include the address of the next basic block to be executed. The "Return" instruction is also not preceded by an instruction for loading an initialization vector to be used to decrypt the next basic block to be executed.
    Here, when the "Return" instruction is executed by the microprocessor 2, it causes:
    - loading a new initialization vector contained in a register R p2 of the microprocessor, then
    - an unconditional jump to an address contained in a register R pi of the microprocessor 2.
    These registers R pi and R p2 are loaded with the appropriate values during the execution of the basic block from which the machine code 68 is called. For example, in FIG. 5, the machine code 68 is called from a basic block 70 and, after the execution of the machine code 68, the execution of the machine code 32 must continue with the execution of a base block 72. The base block 70 ends with two lines coding respectively, the loading of the initialization vector iv 80 in the memory 29 and an unconditional jump to the address @ 80 of the base block 80 of the machine code 68.
    In addition, before these lines, the block 70 also includes:
    a line which codes a loading instruction in the register R pi of the address @ 72 of the base block 72, and
    a line which codes an instruction for loading into the register R p2 the initialization vector iv 72 necessary for decrypting the basic block 72.
    In Figure 5, these lines are designated by the symbols, respectively "Load R p i, @ 72" and "Load R p2 , iv 72 ".
    Thus, during the execution of the "Return" instruction, the next basic block executed will be the basic block 72 and the initialization vector used to decrypt it will be the vector iv 72 loaded in the register R p2 .
    Preferably, the registers R pi and R p2 are registers of a call stack so as to allow calls to sub-functions from the basic blocks of other sub-functions.
    FIG. 6 represents a method of executing binary code 30 by the microprocessor 2.
    The method begins with a step 150 of supplying the binary code 30 in the memory 4. For this, for example, the microprocessor 2 copies the copy 40 inside the memory 4 to obtain the binary code 30 recorded in Memory
    4.
    Then, during a phase 152, the microprocessor 2 executes the binary code 30 and, in particular, the machine code 32.
    The execution of the binary code 30 begins with a step 154 of authentication of the author of this binary code. During this step, the module 28 successively performs the following operations:
    - during an operation 156, the module 28 verifies the authenticity of the certificate Ccpu using the public key pk os contained in the certificate Cos.
    - during an operation 158, the module 28 loads the Caut certificate from block 34 then verifies its authenticity using the public key pkos contained in the Cos certificate-
    - during an operation 160, the module 28 loads the signature S ka * from block 34 and checks its authenticity using the key pk AUT contained in the certificate Caut.
    If all the verification operations 156, 158 and 160 have been successfully completed, then the binary code is correctly authenticated and the process continues with a step 162. Conversely, if one of the operations 156, 158 or 160 has not been successfully passed, the module 28 then considers that the authentication of the author of the binary code 30 has failed and the method continues with a step 163. During step 163, the execution of binary code 30 is stopped.
    In step 162, the module 28 loads the cryptograms ka * and iv in i * contained in the block 34 and decrypts them using the key sk C pu contained in the memory 29. At after step 162, the key ka and the initialization vector ivmi used to decrypt the first basic block of the machine code 32 are contained in the memory 29.
    After step 162, the microprocessor 2 executes, one after the other, the basic blocks starting with the first basic block BB ini of the machine code 32. [0084] The execution of each basic block consists in executing, in the order in which the lines of code Llj of this basic block are stored in memory 4, the instructions coded by each of these lines of code.
    For each of the lines of code Llj to be executed from the machine code 32, the microprocessor 2 performs the following steps.
    In a step 164, the microprocessor 2 loads into a register of the assembly 12, the line of code recorded at the address @j contained in the ordinal counter 26.
    Then, the module 28 proceeds to a step 166 of securing the coded instruction in the loaded line of code.
    The operation of step 166 is now described in the case of the line Llj. More specifically, during step 166, the module 28 successively performs the following operations.
    During an operation 170, the module 28 checks whether there is an error in the cryptogram Clj * or the code MACj using the ECC code L j contained in the loaded line Llj. For example, for this, the module 28 constructs, using a preprogrammed function and the cryptogram Clj * and the code MACj, an ECC code L j '. If the ECC code L j 'is different from the ECC code L j 5 then an error is detected. If an error is detected, the module 28 immediately proceeds to a step 172.
    In step 172, the module 28 triggers the reporting of an execution fault.
    Here, in parallel with step 172, if an error is detected, the module 28 performs an operation 174. During operation 174, it corrects the cryptogram Clj * and the code MACj from the information contained in the ECC code L j. At the end of step 174, the corrected cryptogram Clj * and the corrected code MACj are used in place of, respectively, the cryptogram Clj * and the code MACj contained in the line Llj [0092] Operation 170 allows in particular detecting and correcting faults introduced in the lines of code stored in the memory 4 or in the medium 6. At the end of the operation 174 or if no error was detected during the operation 170, the process continues with an operation 176.
    During operation 176, the module 28 checks the integrity and authenticity of the cryptogram Clj * using the MACj code. For example, for this, the module 28 constructs a label of the cryptogram Clj * then encrypts this label with the key k 'contained in its memory 29. If the cryptogram thus constructed is identical to the loaded MAQ code, then the integrity and the authenticity of the Clj * cryptogram is confirmed. In this case, the module 28 proceeds to an operation 178. Otherwise, the module 28 proceeds to step 172.
    Operation 176 makes it possible on the one hand to validate the authenticity of the loaded line of code and also to validate that, during operation 174, the cryptogram Clj * and / or the MACj code have been correctly corrected . Verification of authenticity prevents the line of code from being replaced by another line of code constructed by an author who does not know the key k ’.
    During operation 178, the module 28 deciphers the cryptogram Clj * using the key ka and the initialization vector iv k to obtain the instruction lj and the deciphered ECCij code. The key ka was recorded in memory 29 during step 162. The vector iv k necessary to decrypt the cryptogram Clj * was recorded in memory 29 during the execution of the basic block preceding the one which contains this line Llj currently being processed. If the line Llj is contained in the first basic block
    BBini of the machine code 32, it is the vector iv in i recorded in the memory 29 during step 162 which is used.
    Here, it is the execution of the connection instruction by the unit 10 which indicates to the module 28 that it must replace the initialization vector currently used by the initialization vector loaded during the execution of the previous basic block.
    Then, during an operation 180, the module 28 stores the deciphered instruction lj and the deciphered code ECCij in the queue 22.
    Once the unit 10 has executed all the instructions which precede the instruction lj in the queue 22, that is to say when the instruction lj is the next instruction to be executed by the unit 10, the module 28 performs an operation 184.
    During operation 184, the module 28 checks whether there is an error in the instruction lj contained in the queue 22 using the code ECCij associated with the instruction lj and contained in this same queue 22 This operation is carried out in a similar manner to what has been described for operation 170.
    If the module 28 detects an error, then it immediately proceeds to step 172. In addition, in parallel, during an operation 186, the module 28 corrects the instruction lj using the code ECCij. Operation 186 is similar to operation 174.
    Then, at the end of the operation 186 or if no error was detected during the operation 184, the step 166 ends and the method continues with a step 190 of execution of the lj instruction by unit 10.
    As shown in FIG. 6, in parallel with step 190, the method can include:
    a step 198 of securing the unit 10, and / or
    a step 250 of securing the processed data.
    These steps 198 and 250 are described in more detail in the following chapters.
    The operation 184 makes it possible to detect a modification of the instruction lj which would occur between the moment when it is recorded in the queue 22 and the moment when it is executed by the unit 10. The operation 184 allows also to trigger an execution fault if the control flow of machine code 32 has been modified. Indeed, a modification of the control flow results in the fact that after the execution of the basic block BBk-ι it is not the basic block BB k which is executed but another basic block BB t . In this case, during the execution of the block BB k -i, the initialization vector iv k _i is loaded into the memory 29. Consequently, during the execution of the block BB t , the cryptogram Clj * is decrypted using the vector iv k which corresponds to the BB k and not using the vector iv t which corresponds to the block BB t . Consequently, the decryption of the cryptogram Clj * using the vector iv k leads to obtaining an incorrect instruction lj and an ECCij code and this is detected during operation 184.
    Similarly, the operation 184 also makes it possible to detect a disturbance in the execution of the operation "Return" of the basic block 82.
    During the execution of the machine code 32, if attacks lead to altering an instruction to protect or modify the control flow, the microprocessor 2 signals, during step 172, a fault in the execution of the machine code 32. In response to such a signaling, during a step 192, the microprocessor 2 implements one or more countermeasures. Many countermeasures are possible. The countermeasures implemented can have very different degrees of severity. For example, the countermeasures implemented can range from a simple display or a simple memorization of an error message without interrupting the normal execution of the machine code 32 until a definitive shutdown of the microprocessor 2. The microprocessor 2 is considered to be out of service when it is definitively placed in a state where it is unable to execute any machine code. Between these extreme degrees of severity, there are many other possible countermeasures such as:
    - indication via a man-machine interface of fault detection,
    - the immediate interruption of the execution of machine code 32 and / or its reinitialization, and
    the deletion of the machine code 32 from the memory 4 and / or the deletion of the backup copy 40 and / or the deletion of the secret data.
    In addition, here, the countermeasure implemented during step 192 can be selected according to the detected error and therefore according to the operation which led to the detection of this fault. For example, the selected countermeasure will not be the same depending on whether the error was detected during operation 170, 176 or 184.
    CHAPTER IV: SECURITY OF THE ARITHMETIC AND LOGIC UNIT 10:
    In this chapter, by “arithmetic and logic instruction”, we mean an instruction from the instruction set of microprocessor 2 which, when executed by this microprocessor, records in a register R res of the microprocessor a datum obtained:
    - either by modifying the bits of a single data item Di recorded in a register of the microprocessor, or,
    - Either by combining together the bits of several data Di to D n recorded, respectively, in registers Ri to R n of the microprocessor 2, where n is an integer equal to the number of data to be combined.
    Conventionally, n is equal to two in the case where several data must be combined, n equal to one corresponds to the case where the arithmetic and logical instruction modifies the bits of a single given Di.
    The registers in which the data or data to be processed are recorded are typically identified by one or more operands of the arithmetic and logic instruction. Similarly, the register R res in which the result D res - P of the arithmetic and logic instruction must be recorded can also be identified by an operand of this arithmetic and logic instruction.
    The arithmetic and logic instruction opcode identifies the operation to be executed by the unit 10 to modify or combine the data or data Di to D n . Subsequently, the symbol "*" is used to generically designate this operation. Thus, the notation Di * D 2 * ... * D n generically designates the operation executed by the arithmetic and logical instruction when it is executed by the microprocessor 2.
    In the case where n is equal to one, the arithmetic and logical operation is for example chosen from the group made up:
    - right and left shift operations of the bits of the data Di, and
    - operations for extracting a predefined bit range from the data Di.
    In the case where n is greater than or equal to two, the operation "*" is chosen from the group consisting of the following operations:
    - the arithmetic addition operation,
    - the arithmetic operation of subtraction,
    - the arithmetic operation of multiplication,
    - the arithmetic operation of division,
    - the logical operation "OR",
    - the logical operation "exclusive OR",
    - the logical operation "AND".
    By injecting faults during the operation of the unit 10, it is possible to disrupt its operation so that the result of the execution of the arithmetic and logical instruction does not correspond to that expected. We then say that we caused a malfunction of unit 10.
    This chapter describes a solution for detecting such a malfunction of the unit 10. Here, this solution is described in the particular case where it is implemented in combination with the solution described in the previous chapter. It corresponds to step 198 shown in FIG. 6.
    The registers Ri to R n and the register R res are, for example, registers of the assembly 12 of the microprocessor 2.
    Thereafter, step 198 is described in the particular case where the arithmetic and logic instructions whose execution we want to secure are the instructions in the following list:
    : The instruction for adding the data Di and D 2 contained in, respectively, the registers Ri and R 2 . This operation is designated by the pseudocode "ADD Ri, R 2 ".
    : The instruction to subtract the data Di and D 2 contained in, respectively, the registers Ri and R 2 . The pseudocode used to designate this operation is "SU B Ri, R 2 ".
    : The multiplication instruction of the data Di and D 2 contained in, respectively, the registers Ri and R 2 . The pseudocode used to designate this operation is "MUL Ri, R 2 ".
    : The instruction to divide the data Di by the data D 2 contained in, respectively, the registers Ri and R 2 . The pseudocode used to designate this operation is "DIV Ri, R 2 ".
    : The “EXlcusive OR” instruction between the data Di and D 2 contained in, respectively, the registers Ri and R 2 . The pseudocode used to designate this operation is "XOR Ri, R 2 ".
    : The “logical AND” instruction between the data Di and D 2 contained in, respectively, the registers Ri and R 2 . The pseudocode used to designate this operation is "AND Ri, R 2 ".
    : The “logical OR” instruction between the data Di and D 2 contained in, respectively, the registers Ri and R 2 . The pseudocode used to designate this operation is "OR Ri, R 2 ".
    : The one bit shift instruction to the right of the data Di contained in the register Ri. The pseudocode used to designate this operation is "SHIFTR Ri".
    : The instruction for removing a bit to the left of the data Di contained in the register Ri. The pseudocode used to designate this operation is "SHIFTL Ri". Thereafter, the number associated by the above list with each arithmetic and logic instruction is used to identify this instruction. Thus, the instruction k is the addition, the instruction l 2 is the subtraction and so on.
    Here, the size of each datum Di, D 2 and D res is for example equal to the size of the instructions lj of the instruction set of the microprocessor 2. Here, this size is therefore equal to 32 bits.
    The structures of the registers Ri, R 2 and R res are identical and represented in the particular case of the register Ri in FIG. 7.
    The RI register includes:
    - a 32-bit range containing the data Di,
    a range containing an ECCdi code making it possible to detect and correct an error in the data Di, and
    - nine successive bit ranges containing, respectively, codes Ci.i to Ci, 9 . The ECCdi code is for example constructed as described in the case of the ECCij code except that it is constructed from the data Di and not from the instruction lj. For example, this ECCdi code is generated during execution or when the binary code 30 is generated.
    When recording the data Di in the register Ri, each code Ci.i to Ci, g is generated by the module 28 using a preprogrammed relationship defined generically as follows: Ci, * = F * (Di) where:
    - the index i identifies a register among the registers Ri, R 2 and R re s,
    - the index * identifies the arithmetic and logical instruction among the instructions k to l 9 , and
    - the function F * is a function preprogrammed in module 28 associated with the arithmetic and logical instruction identified by the index *.
    The size of the code Ci, * is denoted Ni, *. The size N ,, * is generally less than the size of the data Di, D 2 and D res and often at least twice as small.
    Here, the values 1, 2 and 3 of the index i denote, respectively, the registers Ri, R and Rres. The values 1 to 9 of the index * denote, respectively, the instructions k to lg.
    In the case of instructions for which n is greater than or equal to 2, that is to say here in the case of instructions k to k, the function F * is a homomorphism of a set A provided with l operation “*” to a set B provided with the operation “#” such that F * (Di * D 2 ) = F * (Di) # F * (D 2 ). Here, the set A is the set of numbers codable on 32 bits, that is to say the set of data Di and D 2 possible. The set B is the set of numbers codable on N ,, * bits. In other words, using the notations previously introduced, the function F * is such that F * (D r es- p ) = Ci, * # C 2 , * in the absence of malfunction of the unit 10.
    For each instruction k to k, it is possible to find many F * functions which are suitable. Below, by way of illustration, for each of the instructions k to k, one or more possible F * functions are given.
    An EDC function (D,) which returns to an error detector code of the data D ,. This EDC function is for example a sum of checks (“checksum” in English). Such EDC (D,) functions have one or more of the following properties:
    - EDC (Di + D 2 ) = EDC (Di) + EDC (D 2 ),
    - EDC (Di - D 2 ) = EDC (Di) - EDC (D 2 ),
    - EDC (Di x D 2 ) = EDC (Di) x EDC (D 2 ), where the symbols "+", "-", and "x" respectively denote the operations of addition, subtraction and multiplication.
    Thus, such EDC functions are suitable for carrying out the functions Fi, F 2 and F 3 . It will also be noted that in this particular case, the operations “#” and “*” on the sets B and A are identical.
    The function p (D,) which returns 0 if the data D, is even and 1 otherwise. This function has the following property: p (Di + D 2 ) = p (Di) XOR p (D 2 ) and p (Di x D 2 ) = p (Di) OR p (D 2 ), where the symbols "XOR "And" OR "respectively designate the operations" exclusive OR "and" OR ". This function is therefore suitable for the implementation of the functions Fi and F 3 .
    A logarithm function denoted "Log". A logarithm function has the following properties: Log (Di x D 2 ) = Log (Di) + Log (D 2 ) and Log (Di / D 2 ) - Log (Di) Log (D 2 ), where the symbol "/ "Indicates the division operation. Thus, a logarithm is suitable for implementations of the functions F 3 and F 4 . In this case, the "#" operation is addition or subtraction.
    The function CS (D,) which returns the sum of checks of the data D ,. This function has the following properties:
    - CS (Di XOR D 2 ) = CS (Di) XOR CS (D 2 ),
    - CS (Di AND D 2 ) = CS (Di) AND CS (D 2 ),
    - CS (Di OR D 2 ) = CS (Di) OR CS (D 2 ), where the symbol “AND” designates the logical “AND” operation. Thus, this function is suitable for an implementation of the functions F 5 , F 6 and F 7 .
    In the case where n is equal to 1, that is to say here in the case of the instructions l 8 and Ig, the function F * is not a homomorphism. In this case, the function F * is such that there is a function T * such that F * (Di) = T * (F * (Di)). In other words, the function T * is invariant by F * (Di). The function T * therefore returns the code C v from the code Ci, *.
    In the case of the instruction l 9 , the function F g is for example the function which calculates a checksum on all the bits of the data Di except on its most significant bit, that is to say i.e. without taking into account the leftmost bit of the data Di. The function T 9 is then the same checksum on all the bits of F 9 (Di) except the least significant bit, that is to say the one located most to the right in Fg (Di). With such functions F 9 and T 9 , we have the following relation: F g (Di) = Tg (F g (Di)). These functions F g and T 9 are therefore suitable for the instruction l 9 .
    In addition, by choosing the functions F 8 and T 8 equal, respectively, to the functions T 9 and F 9 , one obtains a possible implementation for the functions F 8 and T 8 .
    FIG. 8 represents the detail of the operations carried out by microprocessor 2 during the execution of step 198 to secure the execution of the arithmetic and logic instructions k to l 9 .
    Each time that an instruction to load data into one of the registers R is executed by the unit 10, during step 190, the data D, and the code EECdî are written in this register R ,.
    In response, during an operation 202, for each instruction k to l 9 , the module 28 calculates each of the codes Ci, * corresponding using the relation C., * = F * (Di), or :
    - D, is the new data loaded in the register R ,, and
    - the function F * is the function preprogrammed in module 28 and associated with the operation "*".
    Each of the codes Ci, * thus calculated is recorded in the registers R, as shown in FIG. 7.
    Before the execution of the instructions k to k, the operation 202 is executed once for the data Di and once for the data D 2 . In the case of the instructions l 8 and l 9 , it suffices that the operation 202 is executed only once for the data Di before the execution of one of the instructions l 8 and l 9 .
    Then, each time an arithmetic and logic instruction is about to be executed by the unit 10, just before its execution, during an operation
    204, the module 28 checks whether there is an error in the data contained in the register R, identified by an operand of the instruction lj to be executed.
    During this operation, for each register R, concerned, the module 28 checks, using the code EECdî, whether the data D, currently recorded in this register has an error or not. This operation is, for example, carried out as described in the case of operation 170.
    If the module 28 detects an error, it proceeds to step 172 and, in parallel, to an operation 206. During the operation 206, it corrects the data D ,. Operation 206 is for example carried out in a similar manner to what has been described for operation 174.
    If the module 28 does not detect any error or at the end of the operation 206, during step 190, the microprocessor 2 decodes the instruction lj then the unit 10 executes it and records the result D res - P in the register R res .
    In response, during an operation 210, the module 28 calculates the code ECCds and all the codes C 3 , * from the data D res - P recorded in the register R res and records these various calculated codes in the register R res . Typically, the calculation of the codes C 3 , * is here carried out as described for operation 202.
    Then, during an operation 212, the module 28 checks whether a malfunction of the unit 10 has occurred during the execution of the arithmetic and logic instruction.
    If the instruction executed during step 190 is one of the instructions F to l 7 , then the module 28 executed the following sub-operations.
    During a sub-operation 214, the module 28 selects, among the instructions k to k, that which corresponds to the arithmetic operation executed. In the following sub-operations, the symbol "*" denotes the instruction thus selected and F * the preprogrammed function associated with it.
    During a sub-operation 216, the module 28 also selects, from the various codes C 3 , * recorded in the register R re s, the only code C 3 , * which corresponds to the selected instruction. Thereafter, the code C 3 , * selected during this suboperation is denoted C res - P.
    Then, during a sub-operation 218, the module 28 also calculates a code C res -t by combining the codes Ci, * and C 2 , * recorded, respectively, in the registers Ri and R 2 prior to execution of the arithmetic and logic instruction. More precisely, the module 28 calculates the code Cres-t using the following relation: Cres-t = Ci, * # C 2 , *, where the symbol “#” designates the operation such that F * (Di * D 2 ) = F * (Di) # F * (D 2 ).
    For example, in the case of the instruction k and the parity function p (..) previously described, the operation “#” is the operation “exclusive OR”. In this case, the code C res -t is the result of the following exclusive or exclusive Ci, i XOR C 2 , i.
    Finally, during a sub-operation 220, the module 28 compares the codes C res - P and Cres-t calculated. If these codes are different, the module 28 triggers the execution of step 172. Otherwise, no signaling of an execution fault is triggered and the method continues with the execution of the instruction next in line 22.
    The execution of these sub-operations 214 to 220 makes it possible to detect a malfunction of the unit 10 because the calculated codes C res - P and C re st are identical only if the unit 10 has correctly executed the operation "*". This is explained by the following relation: C res - P = F <D re s- P ) = F * (Di * D 2 ) = F * (Di) # F * (D 2 ) = C v # C 2 * = C res -t.
    If the instruction executed during step 190 is one of the instructions l 8 and l 9 , then during a sub-operation 222, the module 28 selects the function T * associated with this arithmetic instruction and logic, that is to say the function T 8 if it is the instruction l 8 , otherwise the function T 9 .
    During a sub-operation 224, the module 28 selects the code C v associated with the operation "*" executed during step 190. This selected code is denoted C res -t.
    During a sub-operation 226, the module 28 calculates a code C res - P using the relation C res - P = T * (D re s- p ) where T * is the selected function during suboperation 222.
    After the sub-operation 224, the process continues with the sub-operation 220.
    In the case of instructions l 8 and l 9 , the codes C res - P and C res -t are identical only if the unit 10 has functioned correctly. This is demonstrated by the following relation: C res - P = T * (D re s- p ) - T * (F * (Di)) - F * (Di) - Ci, * - C re st .
    CHAPTER V: SECURING DATA [00161] The binary code 30, in addition to the machine code 32, may include data to be processed during the execution of the machine code 32. In addition, during the execution of the machine code 32, it can generate data. These data are typically contained in data blocks which each correspond to a predetermined range of addresses of the memory 4 dedicated to the storage of this data. Such data blocks are also known by the term "data segment" or "data page".
    To read data from a data block, the machine code 32 includes a loading instruction which, when executed by the microprocessor 2, causes the loading of a line of code LDj located at the address @j inside this data block. In this case, unlike the lines of code Llj described in chapter III, the line LDj codes a datum Dj to be processed by the microprocessor and not an instruction lj executable by the unit 10.
    To write data in a data block, the machine code 32 includes a write instruction which, when executed by the microprocessor 2, causes the writing of a line LDj in one of the blocks of data.
    Similarly to what has been described in the case of the instructions lj, a data item Dj can be corrupted in the memory 4 or in the registers of the microprocessor 2 by the implementation of attacks such as an attack by fault injection. In addition, an attacker can also try to modify the operation of binary code 30 by moving the coded data in memory 4 or by replacing it with older data. Thus, it is also useful to secure the data recorded in memory 4 or in internal registers of the microprocessor.
    To this end, each line of LDj code coding a data has the structure shown in FIG. 9. The structure of the lines LDj is practically identical to that of the lines Llj coding instructions. More precisely, the structure of the line LDj is identical to the structure of the line Llj except that the cryptogram Clj * is replaced by a cryptogram CDj *. Since the codes MACj and ECC L j of the line LDj are calculated as already described in the case of the lines Llj, they are here designated by the same symbols and will not be described again.
    The CDj * cryptogram is obtained by encrypting, with the function f ka , a CDj concatenation. Here, the function f ka is the same as that already described in the case of the lines Llj. Thus, the cryptogram CDj * is obtained using the following relation: CDj * = f ka (CDj; ivj). The function f ka is preprogrammed in module 28.
    The CDj concatenation is the concatenation of the data Dj and an ECCdj code. The ECCdj code is used to detect and correct an error in the Dj data. It is typically constructed as described for the ECCij code.
    The cryptogram CDj * differs from the cryptogram Clj * in that the initialization vector ivj used during the encryption of the concatenation CDj is a function of the address @j where the line LDj is recorded. To this end, the module 28 includes a preprogrammed function F iv which, with each address @j of the memory 4 associates a different initialization vector ivj. Preferably, the function F iv is such that at any two consecutive addresses @j and @ j + i, it associates two different vectors, respectively ivj and iv j + i, and the difference between the numerical values of these two vectors ivj and iVj + i varies according to the index j. For example, the function F iv is a hashing or encryption function. We therefore have the following relation: ivj = F iv (@j).
    Securing the Dj data will now be described in more detail with reference to the method of FIG. 10 and in the particular case where it is implemented in combination with the teachings of the preceding chapters. More specifically, the securing of the Dj data occurs whenever the instruction executed during step 190 is an instruction for loading or writing or processing a Dj data. The method of FIG. 10 represents the operations executed during step 250 to secure the data Dj.
    Each time during step 190, the unit 10 executes an instruction which leads to recording a new datum Dj in a register noted here Rj of the microprocessor 2, during an operation 252, the module 28 calculates the ECCdj code from the Dj data. This calculated ECC code D j is then concatenated with the data
    Dj in the register Rj.
    Subsequently, during a new execution of step 190, the unit 10 executes an instruction for recording the data Dj contained in the register Rj at the address @j of the memory 4.
    In response, during an operation 254, the module 28 constructs the line of code LDj which must be registered at the address @j from the data Dj. To do this, during this operation, module 28:
    - calculates an initialization vector ivj using the relation ivj = F iv (@j), then
    - encrypts the concatenation CDj of the data Dj and the ECC code D j using the function f ka and the initialization vector ivj calculated according to the following relation: CDj * = f ka (CDj; ivj), then
    - calculates the MACj code from the CDj * cryptogram, then
    - calculates the ECC code L j from the cryptogram CDj * and the calculated MACj code.
    Then, the line LDj constructed is transferred and saved in memory 4 at the address @j.
    The address @j is located inside a predetermined block of data BD m . Each BD m data block is associated with an EDC m code which makes it possible to detect an error if one of the lines of code contained in this BD m block has been modified since the last update of the EDC m code. The EDC code m is therefore an error detecting code.
    The EDC code m can be contained in the memory 4, for example at the end of the BD m data block associated with this code or in a microprocessor register associated with the BD m block.
    During an operation 256, immediately after or in parallel with the execution of the instruction for writing the new line LDj in the block BD m , the code EDC m associated with this block BD m is set to day then saved. Here, to speed up the execution of this operation 256, the EDC code m is defined by the following relation: EDC m = MACi Φ MAC 2 Φ ... Φ MACmm, or:
    - the symbol Φ indicates the "exclusive OR" operation,
    the codes MACi to MACmm are the codes MACj of all the lines LDj of the block BD m , and
    - mm is the number of lines LDj contained in the block BD m .
    When the EDC code m is thus defined, the operation 256 can be performed using the following relation: EDC m = EDC m Φ MAC jO id Φ MACjnew, where:
    - the EDC m symbols to the right and to the left of the "=" sign denote, respectively, the old value of the EDC code m before the recording of the new line LDj and the new value of the EDC code m after the recording of this new LDj line,
    - MACjoid designates the MACj code of the old line LDj which is replaced by the new line LDj, and
    - MACjnew designates the MACj code for the new LDj line, which is registered at the address @j.
    Thus, the number of operations to be executed to update the EDC code m is limited.
    Operation 256 can be performed by the module 28 or by a calculation unit incorporated in the memory 4. Such memories 4 incorporating a calculation unit are known by the English term of “Smart RAM” or “ln- memory computing ”.
    If the next instruction to be executed during step 190 is an instruction for loading a line LDj, then, during an operation 260, the module 28 checks, using the EDC code m , s 'there is an error in the block BD m which contains this line LDj.
    If the module 28 detects that there is an error, then the method continues with the execution of step 172 and the line LDj is not loaded in the microprocessor 2.
    If the module 28 does not detect any error, then the unit 10 executes an instruction for loading the line LDj and the latter is loaded into a register of the microprocessor 2. Typically, this loading instruction includes an operand which indicates at which address @j is the LDj line to load. Here, when the unit 10 executes this loading instruction, it loads the line LDj into a register Rj of the set 12 for example.
    Then, the module 28 performs operations 270, 274, 276 and 278 identical, respectively, to operations 170, 174, 176 and 178 of the method of FIG. 6 except that these are the corresponding codes contained in the line LDj which are used and not those contained in an Llj line.
    In addition, during operation 278, the module 28 calculates the initialization vector ivj necessary to decrypt the cryptogram CDj * from the address @j and using the relation ivj = F iv (@j).
    Once the cryptogram CDj * has been decrypted, during an operation 280, the module 28 stores the deciphered data Dj and the ECC code D j deciphered in the register Rj while waiting for this data to be processed by the unit 10.
    When the next instruction which will be executed by the unit 10 is an instruction which processes the data Dj, the module 28 proceeds to operations 284 and 286. The module 28 identifies that the next instruction to be executed will process the data Dj because this instruction generally includes an operand which identifies the register Rj in which the data Dj is recorded. The operations 284 and 286 are, for example, identical, respectively, to the operations 184 and 186 of the method of FIG. 6, except that here, it is the data Dj and the code ECC D j which are used and not the lj instruction and ECCij code.
    Then, at the end of the operation 286 or if no error was detected during the operation 284, the unit 10 executes the instruction which processes the data Dj.
    The method of securing the data described here also has the same advantages as those presented in Chapter III in particular because of the fact that the structure of the line LDj is practically identical to that of the line Llj.
    In addition, the fact of encrypting the data Dj using an initialization vector ivj which depends on the address @j makes it possible to detect whether a line LDj has been moved inside a BD data block m . Indeed, if two lines LDi and LD 2 of the same block BD m are swapped, this does not necessarily modify the EDC code m and such a permutation of the lines LDi and LD 2 is not necessarily detected during the operation 260. On the other hand, since the data Di is encrypted with an initialization vector ivi which depends on the address @i, if the line LDi is moved and is located at an address @ 2 in the memory 4, when loading of this line from this address @ 2 , the CD cryptogram will be decrypted using the initialization vector iv 2 and not using the vector ivi. Such incorrect decryption of the data Di and of the code ECCdi is then detected during operation 284.
    The step 250 described here also makes it possible to detect an attack consisting in replacing a line LDi by a line LDi O i d different and previously recorded at the same address @i. Such a replacement cannot be detected during the execution of operation 284. On the other hand, it will be detected during the execution of operation 260 because the lines LDi and LDi 0 | d are different.
    FIG. 11 represents a compiler 300 capable of automatically generating the binary code 30 from a source code 302. For this purpose, the compiler 300 typically comprises a programmable microprocessor 304 and a memory 306. The memory 306 contains the instructions and data necessary for, when executed by the microprocessor 304, automatically generate the binary code 30 from the source code 302. In particular, during the compilation of the source code 302, the microprocessor 304 automatically generates the vectors of 'appropriate iv k initialization and lines of code Llj and LDj. The design and production of such a compiler are within the reach of those skilled in the art from the explanations given in this description.
    Chapter VI: VARIANTS:
    Variants of the device 1:
    The memory 4 can also be a non-volatile memory. In this case, it is not necessary to copy the binary code 30 inside this memory before launching its execution since it is already there.
    As a variant, the memory 4 can also be an internal memory integrated inside the microprocessor 2. In the latter case, it is produced on the same substrate as the other elements of the microprocessor 2. Finally, in other configurations, memory 4 is made up of several memories, some of which are internal memories and others are external memories.
    The main memory 4 may include a first volatile memory of large capacity and a second volatile memory of smaller capacity but in which the read and write operations are faster. The second memory is known by the term "cache memory". The cache memory can be a memory external to the microprocessor 2 or an internal memory from the microprocessor 2. In certain embodiments, several cache memories of different levels can be used.
    Many different hardware architectures are possible to make the module 28. In particular, the module 28 can be composed by the combination of several hardware blocks of the microprocessor 2 fulfilling respective functions and each located in a different area of the chip of the microprocessor 2.
    Variants of securing the machine code:
    As a variant, certain functions or parts of the binary code 30 are not secure. To manage the execution of such a binary code which includes both a secure function and non-secure functions, the instruction set of microprocessor 2 can be supplemented by:
    - an instruction to activate a secure operating mode of the microprocessor 2, and
    - an instruction to deactivate this secure mode.
    In this case, the instruction for activating the secure mode is in the binary code 30 just before the call to the secure function and the instruction for deactivating the secure mode is just after the end of the function. secure. When the instruction for activating the secure mode is loaded by the microprocessor 2, in response, the module 28 begins to process the instructions and the following data of the binary code as described in the preceding chapters. When the instruction to deactivate the secure mode is loaded by the microprocessor 2, in response, the module 28 is deactivated. In the latter case, the processing of the instructions and the following data of the binary code are not processed by the module 28 but directly loaded into the queue 22 or into the registers of the assembly 12.
    As a variant, an “update” instruction is added to the instruction set of the microprocessor. When this “update” instruction is executed by the microprocessor 2, it indicates to the module 28 that from now on, the new vector iv k previously loaded in the memory 29 must be used to decipher the lines of code Llj. Consequently, in this case, the use of a new initialization vector iv k can be triggered other than by the execution of a branching instruction. In this case, the described method can also be implemented with implicit connection instructions. Indeed, the last instruction which ends with an implicit branch instruction, is then the "update" instruction. Instead of implementing an “update” instruction as a separate instruction in the microprocessor instruction set, it is possible to add an additional bit to each instruction in microprocessor 2 instruction set and to trigger the change of initialization vector iv k only when this additional bit takes a specific value.
    Variants of the structure of a line Llj or LD, [00203] As a variant, the structure of a line of code described with reference to FIG. 2 or 9 is implemented only for the instructions lj or only for instructions Dj data from the secure function.
    The ECCy code or the ECC code D j can be replaced by a simple error detector code allowing only to detect an error in the instruction lj or the data Dj with which it is concatenated. An error detection code does not correct the detected error. In this case, the error correction operation 186 or 286 is omitted. Consequently, as soon as the module 28 detects an error in a deciphered instruction lj or in a deciphered data item Dj, for example, the execution of the secure function is systematically interrupted.
    In a simplified variant, the code ECCij or ECCdj is omitted. In this case, the cryptogram Clj * or CDj * is only the cryptogram of the instruction lj or of the data Dj. In this embodiment, the microprocessor 2 is no longer capable of detecting a modification of the instruction lj or of the data Dj which would occur between the moment when it is recorded in the file 22 or a register of the set 12 and the time when it is executed or processed by unit 10.
    The ECC code L j can be replaced by a simple error detecting code allowing only to detect an error in the cryptogram Clj * or CDj * and / or the MACj code contained in the same line of code. In this case, operation 174 or 274 of correction is omitted. Consequently, as soon as the module 28 detects an error in the cryptogram Clj * or CDj * or in the code MACj, for example, the execution of the secure function is interrupted.
    In another variant, the ECC code L j is constructed so as to allow only the detection of an error, either only in the cryptogram Clj * or CDj * or only in the code MACj.
    The ECC code L j can be omitted. In this case, an error in the cryptogram Clj * or CDj * or in the code MACj can only be detected during the execution of operation 176 or 276 to verify the integrity and authenticity of the cryptogram. Detecting an error using a MAC code is generally more complex than using a simple error detecting code or a simple error correcting code. In addition, when the ECC code L j is omitted, in the event that there is an error in the cryptogram Clj * or CDj * or the MACj, it is not possible to correct this error. In the latter case, for example, the execution of the secure function is therefore systematically interrupted in the event of an error.
    The function used to generate the cryptogram CDj * may be different from that used to generate the cryptogram Clj *. For example, these two functions differ in that they use different encryption keys. Variants of securing the arithmetic and logic unit: The number of codes Ci, * calculated and associated with the data D, loaded is not necessarily equal to the total number of different arithmetic and logic instructions that exist in the microprocessor 2 instruction set. For example, the number of C ,, * codes can be reduced when the same C ,, * codes are used for different arithmetic and logic instructions. For example, the code Cj, 4 can be omitted if the functions F 3 and F 4 are both logarithmic functions. Indeed, in this case, when the arithmetic and logical instruction to be executed is a multiplication, during operation 284, the module 28 calculates the code C re st using the following relation: C res -t = Ci, 3 + C 2 , 3 . To verify that the unit 10 has correctly carried out an arithmetic and logical division instruction, the module 28 can calculate the Cres-t code using the following operation: C res -t = Ci, 3 - C 2 , 31 where the codes Ci, 3 and C 2 , 3 are the same as those used to verify the multiplication operation. In this case, it is not necessary to calculate the codes Ci, 4 and C 2 , 4 since they are identical, respectively, to the codes Ci, 3 and C 2 , 3 . On the other hand, the code C 3 , 4 must be calculated from the data D re s- P. Similarly, it is possible to detect the malfunction of the unit 10 during the execution of a subtraction instruction by calculating the code C res -t using the following relation: C res -t = Ci , i - C 2 , i in the case where the function Fi is also a homomorphism for the set B provided with the subtraction operation.
    In another embodiment, it is possible to detect a malfunction of the unit 10 only when it executes a single or a restricted group of arithmetic and logical instructions of the instruction set of the microprocessor 2. In this In this case, there are arithmetic and logic instructions for which the microprocessor does not check whether they have been correctly executed by the unit 10. This makes it possible to reduce the number of C, * codes used.
    As a variant, the code Ci, * is not recorded in the same register R, as that in which the data D is recorded, but in another register specifically associated with this register R ,.
    Variants of data security:
    The structure of the lines LDj used to secure the data can be simplified. For example, the MACj and / or ECClj codes can be omitted.
    The ECC code D j can be replaced by a simple error detecting code in the data Dj.
    As a variant, the function F iv is identical to the function f ka except that it is applied to the address @j. The function F iv can also use the same encryption algorithm as the function f ka but with an encryption key different from the key ka. In a simplified variant, the function F iv is the identity function. In this case, the initialization vector ivj is systematically equal to the address @j.
    In other embodiments, to detect a displacement of a line LDj, the code MACj is calculated as a function of the vector ivj. For example, the code MACj is calculated from the concatenation of the cryptogram CDj * and the vector ivj. The MACj code can also be calculated from a combination of the CDj * cryptogram and the vector ivj such as the following combination: CDj * © ivj. In the case where the code MACj depends on the vector ivj, then it can be used in place of the code ECC D j to detect an error in the event of displacement of the line LDj in the memory 4. Indeed, in this case, during checking the integrity and authenticity of the CDj * cryptogram, module 28:
    - calculate the vector ivj using the relation ivj = F iv (@j), then
    - combines the CDj * cryptogram read at address @j with the calculated ivj vector, then
    - checks the integrity and authenticity of this combination from the MACj code contained in the same line LDj.
    If this line LDj has been moved, the initialization vector calculated is different from that expected. Consequently, the integrity of the combination of the CDj * cryptogram and of the initialization vector cannot be verified, which triggers the signaling of an execution fault. Note that in this embodiment, it is possible to detect a displacement of the line LDj without even having to decipher the cryptogram CDj *. In this variant, to detect a displacement of the line LDj, the ECC code D j and ECClj can be omitted.
    Similar to what was described above for the MACj code, the ECC code L j can also be constructed so as to depend on the vector ivj. In this case, the displacement of the line LDj is detected during the verifications of the ECC code L j. Therefore, to detect a displacement of the line LDj, the ECC codes D j and MACj can be omitted.
    Step 250 has been described in the specific case of securing a Dj data. However, as a variant, the same step can be carried out on lines of code comprising an instruction lj in place of the data Dj. In this case, the cryptogram Clj * is obtained by using an initialization vector ivj and not the vector iv k as described in chapter III. Since the vector ivj is a function of the address @j where this line of code Llj is recorded, it is then possible to detect the displacement of a line of code coding an instruction to be executed. In this case, typically, the ECCij code is used to detect this displacement and no longer to detect a modification of the control flow.
    In the embodiments described so far, both the data Dj and the ECC code D j are coded according to the vector ivj since the cryptogram CDj * is encrypted using this vector ivj. As a variant, either only the data Dj or only the code ECCdj is coded as a function of the vector ivj. For example, in the line of code, the cryptogram of the data Dj is obtained from an encryption function which does not use the vector ivj, while the cryptogram ECCdj * of the code
    ECCdj is obtained using the encryption function f ka (ECC D j; ivj). In this case, during operation 278, the module 28 decrypts the cryptogram of the data Dj without using the vector ivj and decrypts the cryptogram ECCdj * using this vector iy. Then, the rest of the process is identical to what has already been described. In a simplified embodiment, since the data Dj does not need to be coded as a function of the vector iy, it is also possible not to encrypt it. For example, the line of code then contains the data Dj in plain text and the ECC cryptogram D j *. Consequently, during operation 278, the decryption of the data Dj is omitted since it suffices to extract it from the bit range in which it is contained in the line LDj.
    Conversely, it is also possible to modify the structure of the lines LDj so that only the data Dj is coded as a function of the vector iy. For example, the line LDj includes a cryptogram Dj * of the data Dj obtained by encrypting it using the function f ka (Dj; iy) and an ECC cryptogram D j * obtained by encrypting the code ECCdj using of an encryption function independent of the vector ivj. During operation 270, the module 28 decrypts the cryptogram Dj * using the vector iy calculated and decrypts the cryptogram ECCdj * without using this vector iy.
    Up to now, it is an encryption function which has been described as an exemplary embodiment making it possible to code the data Dj or the ECC code D j as a function of the vector ivj. This encryption function can however be as simple as a simple logical “OR” operation between the data Dj and the vector iy or between the code ECCdj and the vector iy.
    In another simplified embodiment, the ECCdj code and the MACj code are omitted. In this case, at least one of the cryptogram Dj * and of the ECC code L j is constructed as a function of the vector iy.
    For detection of the displacement of the line LDj, it is not necessary to use an error correcting code. A simple error detection code is sufficient. Thus, as a variant, the error correcting code or codes are replaced by error detecting codes.
    In another embodiment, the EDC code m is omitted. In this case, the operations for processing this EDC code m are also omitted, such as operations 256 and 260.
    It is possible to construct the EDC code m differently. For example, as a variant, the code EDC m is an error correcting code which also makes it possible to correct an error in the data block BD m . In this case, when an error is detected in the BD m block, the EDC code m is used to correct the detected error, then the process continues with operation 270.
    Other methods of calculating the EDC code m are possible. For example, as a variant, the EDC code m is a checksum or a message authentication code.
    Advantageously, the EDC code m is stored in memory 29.
    Other variants:
    In another variant, the keys ka and k ’are the same.
    The key ka can be pre-recorded in the memory 29. In this case, the cryptogram ka * can be omitted from block 34.
    A line of code can be longer than a machine word. In this case, each line of code is made up of several machine words generally located at immediately consecutive memory addresses in the memory 4. In this case, a line of code is loaded into the microprocessor 2 not in a single read operation , but by performing multiple player operations. Each read operation loads a respective machine word from the line of code into the microprocessor.
    As a variant, operation 176 or 276 is systematically continued by operation 178 or 278 even if the integrity or the authenticity of the cryptogram could not be confirmed. In this case, operation 176 or 276 is used to trigger the reporting of an execution fault without interrupting the execution of the binary code.
    Everything that has been described in Chapter III can be implemented independently of what has been described in the other chapters. For example, steps 198 and 250 can be omitted.
    In another variant, the method described in Chapter III for detecting an error in the control flow is implemented independently of what has been described in Chapters IV and V but also independently of some of the characteristics of the method described in Chapter III. In particular, to be able to detect an error in the control flow, the ECC codes L j and MACj can be omitted, as well as all the operations for processing these two codes.
    Everything that has been described in Chapter IV can be implemented independently of what has been described in the other chapters. For example, what was described in Chapter IV can be implemented:
    - without the binary code being encrypted,
    - without the MACj code being included in each line of code,
    - without the codes ECC L j and ECCij or ECC D j being used,
    - without the Dj data being encrypted using the vector ivj.
    Everything that has been described in Chapter V can also be implemented independently of what has been described in the other chapters. For example, what has been described in Chapter V can be implemented:
    - without the Dj data being encrypted,
    - by keeping only one error detecting code chosen from the group consisting of the ECC L j, MACj and ECC D j codes, and
    - without a Ci code, * being calculated each time data is loaded into a register.
    All the embodiments described in this text and, in particular, the different variants, can be combined with one another.
    CHAPTER VII: ADVANTAGES OF THE DESCRIBED EMBODIMENTS:
    Advantage of securing the binary code:
    The encryption of the instructions lj or of the data Dj makes it possible to guarantee the confidentiality of the binary code 30, which makes the "Reverse Engineering" of the binary code very difficult. Verification of the integrity of the cryptogram Clj * or CDj * makes it possible to detect the modifications of the binary code caused, for example, by attacks such as the injection of faults in the memory 4 or the medium 6. The fact of verifying the authenticity of the instructions and of the data makes it possible to detect and make it very difficult for an attacker to add additional instructions to binary code 30, for example, to introduce malware therein, such as viruses. Even if the attacker knows the algorithm used to encrypt the instructions lj or the Dj data, he does not know the secret key k ’used to build the MACj code.
    The verification, using the ECCy or ECC code D j, of the existence of an error in the instruction lj or the data Dj just before it is used makes it possible to detect a modification of this instruction or of this datum Dj while it is stored in the queue 22 or a register of the assembly 12. In fact, such modifications can be caused by injection of faults in the queue 22 or the registers of the assembly 12. Thus, the use of the ECCi code; or ECC D j can detect this type of attack.
    The fact that the ECCy or ECC D j code is an error correcting code and not just an error detecting code makes it possible to make the execution method more robust with respect to attacks by injection of faults in the queue 22 or in the registers of the set 12. Indeed, in this case, the error correcting code often makes it possible to correct the error introduced in the instruction lj or in the data Dj so that despite the presence of such errors, the secure function continues to run correctly.
    The use of the ECC code L j makes it possible to detect an error in the cryptogram Clj * or CDj * or in the code MACj more quickly than if only the code MACj was used for this. The use of the ECC code L j therefore makes it possible to speed up the execution of the binary code.
    The use of an error correcting code for the ECClj code makes it possible to make the claimed method more robust with respect to attacks by injection of faults in the memory 4 or in the support 6. In fact, in this case, the error correction code often makes it possible to correct the cryptogram Clj * or CDj * or the MAQ code so that, despite the presence of such errors, the secure function is executed correctly.
    Using different secret keys to decrypt the Clj * or CDj * cryptogram and to check the integrity and authenticity of the MACj code makes it possible to increase the security of the process.
    During the execution of a previous basic block, the fact of loading into the microprocessor the initialization vector iv k necessary for decryption of the following basic block BB k makes it possible to trigger the signaling of a fault d execution if an attacker tries to modify the order in which the basic blocks of machine code 32 should normally be executed. More precisely, such a modification of the control flow will be detected using the ECCij code during operation 184.
    The registration in a microprocessor register of the initialization vector iv k to be used to decrypt the basic block executed after the execution of a secure sub-function makes it possible to call this secure sub-function from different blocks of the machine code 32 of the secure function. Indeed, in this case, it is not possible to code the vector iv k to be used in the last basic block of the secure sub-function since the following basic block is not always the same and is not therefore not always encrypted using the same vector iv k .
    The verification of the authenticity of the application key ka from different cryptographic certificates, at least one of which is recorded in the secure memory of the microprocessor makes it possible to guarantee that the binary code 30 has been generated by an author authorized to do this and not by a third party who does not have the right to generate such binary code for microprocessor 2.
    Advantages of securing the arithmetic and logic unit:
    When faults are injected into unit 10, the result D re s- P obtained at the end of the execution of the arithmetic and logical operation may be different from the theoretical result D re st expected. The claimed method makes it possible to detect such a malfunction of the unit 10 without, for example, having to execute the faulty arithmetic and logic operation several times.
    Advantages of securing data:
    In the claimed method, if an attacker moves a line LDj, an error is then detected using an error detecting code. Thanks to this, it is therefore much more difficult to implement an attack in which the lines of code are moved without this attack being detected.
    The use of the EDC error detector code m makes it possible to detect an attack which consists in replacing a line of code located at an address @j by another line of code which was previously recorded at the same address @j. Indeed, such a replacement cannot always be detected in the absence of this EDC code m .
    Constructing the EDC code m only from the MACj codes of the lines LDj accelerates the calculation of this EDC code m because the MACj codes are generally much shorter than the complete line of code. In addition, this acceleration of the calculation is obtained without modifying the reliability of the error detection because the code MACj depends on the data Dj.
    The use of an “exclusive OR” to update the EDC code m allows this code to be updated iteratively, which is much faster than calculating, each time a new entry is written. line of code, the new EDC m code from the content of each of the lines contained in the BD m block.
    Using an error correcting code as the ECC code D j also makes it possible to correct a detected error. This therefore allows the execution of the secure function to continue even if an error has been reported.
    Saving the EDC code m in the memory 29 increases the security of the process because this memory is very difficult to modify by an attacker.
    Coding both the data Dj and the ECC code D j by encrypting it using an encryption function parameterized by the vector ivj increases the security of the process. Indeed, in addition, the confidentiality of the Dj data and the ECCoj code is ensured.
    Using a code capable of detecting an error in the CDj * cryptogram as an error detecting code makes it possible to detect a displacement of a line of code without even having to decrypt this CDj * cryptogram.
    权利要求:
    Claims (16)
    [1" id="c-fr-0001]
    1. Method for executing a binary code of a function secured by a microprocessor, characterized in that this method comprises:
    a) the supply (150) of the binary code, this binary code comprising lines of code, each line of code containing:
    - a cryptogram (Clj *, CDj *) of a single instruction executable by the microprocessor or of a single datum to be processed by the microprocessor, and
    - a message authentication code (MACj) to verify the integrity and authenticity of the cryptogram,
    b) during the execution (152) of the binary code by the microprocessor, each time the microprocessor loads a line of code, the method comprises the following operations:
    1) a hardware module for securing the microprocessor checks (176) the integrity and authenticity of the cryptogram contained in the line of code loaded using the message authentication code contained in this same line and triggers (172) reporting an execution failure if the integrity or authenticity of the cryptogram is not confirmed, then
    [2" id="c-fr-0002]
    2) the hardware security module deciphers (178) the cryptogram to obtain a decrypted instruction or a decrypted data item if the integrity and authenticity of the cryptogram is confirmed, then:
    - in the case of a decrypted instruction, the deciphered instruction is recorded (180) in a queue of instructions to be executed successively one after the other by an arithmetic and logic unit of the microprocessor, and
    - in the case of decrypted data, the decrypted data is recorded (280) in an internal register of the microprocessor while waiting to be processed by the arithmetic and logic unit.
    2. Method according to claim 1, in which:
    - during step a), the cryptogram contained in the code line is a concatenation cryptogram:
    - said instruction or given, and
    - a first error detection code (ECCij, ECC D j) making it possible to detect an error in the instruction or in the data with which it is concatenated,
    - during operation 2), the decryption of the cryptogram by the hardware security module makes it possible to obtain, in addition to the decrypted instruction or the decrypted data, the first decrypted error detector code, then:
    - in the case of a decrypted instruction, the first decrypted error code is recorded (180) in the instruction queue with the decrypted instruction, and
    - in the case of decrypted data, the decrypted data and the first decrypted error detecting code are recorded (280) in the same microprocessor register, and
    - after operation 2), the process includes operation 3) as follows:
    - when the next instruction to be executed contained in the instruction queue is the instruction deciphered during operation 2), the security hardware module checks (184), using the first error detector code recorded with this decrypted instruction, if there is an error in this deciphered instruction, and, in the case where such an error is detected in this deciphered instruction, the hardware security module triggers (172) the signaling of an execution fault, and, in the event that no error has been detected in this deciphered instruction, the microprocessor decodes the deciphered instruction and transmits it to the arithmetic and logic unit which executes it (190), or
    - when the next datum to be processed by the arithmetic and logic unit is the deciphered datum during operation 2), the security hardware module checks (284), using the first recorded error detector code associated with this decrypted data, if there is an error in this decrypted data, and, in the event that such an error is detected, the hardware security module triggers (172) the signaling of an execution fault, and, in the If no error is detected, the arithmetic and logic unit processes (190) this decrypted data.
    [0003]
    3. Method according to claim 2, in which:
    - during step a), the first error detecting code (ECCij, ECC D j) is an error correcting code allowing, in addition, to correct the error detected in the instruction or in the data with which it is concatenated,
    - during operation 3):
    - when the security hardware module detects an error in the decrypted instruction, in addition to triggering the signaling of an execution fault, the security hardware module corrects (186) this error using the first detector code d decrypted error recorded together with this decrypted instruction, then the microprocessor decodes the instruction thus corrected and transmits it to the arithmetic and logic unit which executes it (190), or
    - when the security hardware module detects an error in the decrypted data, in addition to triggering the signaling of an execution fault, the security hardware module corrects (286) this error using the first code detector decrypted error associated with this decrypted data, then the arithmetic and logical unit processes (190) the corrected data.
    [0004]
    4. Method according to any one of the preceding claims, in which:
    - during step a), each line of code comprises, in addition to the cryptogram and the message authentication code, a second error detecting code (ECC L j) making it possible to detect an error in the cryptogram or the message authentication code contained in the same line of code,
    - during step b) before the execution of operation 1), the method comprises an operation (170, 270) during which the hardware security module checks, using the second error detector code contained in the loaded line of code, if there is an error in the cryptogram or the message authentication code contained in the loaded line of code, and in the event that such an error is detected, the hardware security module triggers (172) the signaling of an execution fault and, in the case where no error is detected, the process continues with operation 1).
    [0005]
    5. Method according to claim 4, in which:
    - during step a), the second error detecting code (ECC L j) is an error correcting code making it possible, in addition, to correct the error detected in the cryptogram or the message authentication code contained in the same line of code,
    - if the security hardware module detects an error in the cryptogram or the message authentication code, in addition to triggering the signaling of an execution fault, the security hardware module corrects (174, 274) this error using the second error detecting code, then the process continues with operation 1) during which the corrected cryptogram and the corrected message authentication code are used.
    [0006]
    6. Method according to any one of the preceding claims, in which:
    - during operation 1), a first encryption key (k ‘) is used to verify the authenticity of the cryptogram contained in the loaded line of code, and
    - During operation 2), a second decryption key (ka) is used to decrypt the cryptogram, this second decryption key being different from the first decryption key.
    [0007]
    7. Method according to claim 2, in which:
    - during step a), the binary code provided includes a machine code containing a succession of basic blocks in which:
    each basic block comprises a succession of lines of code each containing the cryptogram of an instruction, the instructions encrypted in these successive lines of code being intended to be executed by the microprocessor systematically in the order of these lines of code, and
    each base block begins at a branch address and ends with a line of code containing the cryptogram of a branch instruction to a branch address of another base block, this other base block being called "the next basic block "and the basic block which ends with the line of code containing the cryptogram of this instruction to connect to this next basic block being called" previous basic block ",
    the cryptogram contained in a specific line of code of a following basic block having been obtained using an initialization vector different from the initialization vectors used to obtain the cryptograms of lines of code of the other blocks of based,
    each preceding basic block comprising a line of code containing the cryptogram of a loading instruction which, when executed by the microprocessor, causes the loading into the microprocessor of the initialization vector to be used to decrypt the cryptogram of the specific line of code for the next base block,
    - during operation 2), the hardware security module decrypts (178) the cryptogram of the specific line of code of a following base block using the initialization vector loaded into the microprocessor during execution of the previous basic block.
    [0008]
    8. Method according to claim 7, in which:
    - during step a), the binary code includes a machine code containing:
    - a basic block called “calling block” which ends with a line of code containing the cryptogram of a branching instruction which, when executed by the microprocessor, performs a branching to a branching address of a sub - secure function,
    - another basic block called “return block”, and
    the secure sub-function formed by one or more basic blocks, this secure sub-function being callable from the various basic blocks of the secure function and starting with a first basic block and ending with a last block of base, the first base block starts at the branching address of the secure sub-function and the last base block ends with a line of code containing the cryptogram of a particular branching instruction called "return instruction" which , when executed by the microprocessor, makes a connection to the connection address of the return block,
    - during a first execution of operation 2), the security hardware module records in a first microprocessor register the connection address of the return block and the initialization vector necessary to decrypt this return block, then
    - during a second execution of operation 2) during which the return instruction of the secure sub-function is decrypted, the branch address used for the execution of the return instruction is read in the first register and then
    - during a third execution of operation 2) during which the specific line of code of the return block is decrypted, the hardware security module uses the initialization vector recorded in the first register to decrypt the cryptogram of the line of code specific to the return block.
    [0009]
    9. Method according to any one of the preceding claims, in which:
    - before step b), the process includes recording:
    - a first cryptographic certificate (C os ) allowing the authentication of a public key of an operating system executed by the microprocessor,
    - a second cryptographic certificate (Ccpu) used to authenticate a public key of the microprocessor,
    - a third cryptographic certificate (C au t) used to authenticate a public key of the author of the secure function,
    - a cryptogram (ka *) of an application key that can be decrypted using the public key of the microprocessor,
    - a signature (S ka .) of the application key verifiable using the author's public key,
    - at the start of step b) the hardware security module checks (154) in order:
    - the authenticity (156, 158) of the first and third cryptographic certificate using the public key of the operating system,
    - only if the authenticity of the author's public key has been confirmed, the authenticity (160) of the signing of the application key using the author's public key,
    - only if the authenticity of the signature of the application key has been confirmed, the decryption (162) of the cryptogram of the application key with the public key of the microprocessor, then
    - during operation 2), the decryption of the cryptogram is carried out using this decrypted application key.
    [0010]
    10. Method according to any one of the preceding claims, in which, during operation 1) (178, 278), the hardware security module:
    - builds a label from the cryptogram contained in the loaded line of code, then
    - encrypts the label constructed using a secret key recorded in a non-volatile memory of the security hardware module, then
    - compare the encrypted label with the message authentication code contained in the loaded line of code, then
    - confirms the integrity and authenticity of the cryptogram only if the encrypted label is identical to this message authentication code.
    [0011]
    11. Method according to any one of the preceding claims, in which:
    - during step a) (150), the binary code provided contains:
    - an arithmetic and logic instruction comprising an opcode and one or more operands which, when executed by an arithmetic and logic unit of the microprocessor, causes the operation Di * D 2 * ... * D n and l 'recording of the result of this operation in a register R re s, where:
    Di to D n are data recorded, respectively, in registers Ri to R n of the microprocessor,
    - the registers Ri to R n are the registers designated by the operands of the arithmetic and logic instruction,
    - the symbol "*" is the arithmetic and logic operation designated by the opcode of the arithmetic and logic instruction, and
    - the index n is an integer greater than or equal to one,
    - for each register Ri to R n , a loading instruction which, when executed by the microprocessor, causes the loading of data D, in the register R ,, where the index i is an identifier of the register R , among the registers Ri to R n ,
    - during the execution of step b), the process includes the following operations:
    - each time that an instruction to load data D, in the register R, is executed by the microprocessor, a hardware module for securing the microprocessor calculates (202) a code Ci, * using a relation C ,, * = F * (Dj), and the loaded data D, is recorded in the register R, and the code C ,, * calculated is recorded in the same register R, or in a register associated with the register R, , the function F * being a preprogrammed function of the hardware security module,
    - in the case where n is greater than or equal to two, this function F * being a homomorphism from a set A of numbers provided with the operation "*" to a set B of numbers provided with the operation "#", which verifies the relation: F * (Di * D 2 * ... * D n ) = F * (Di) # F * (D 2 ) # ... # F * (D n ) = Ci, * # C 2 , * # ... #C n *,
    - in the case where n is equal to one, this function F * is such that F * (Di) = T * (F * (Di)), where the function T * is a function preprogrammed in the hardware security module,
    - the execution (190) by the arithmetic and logical unit of the arithmetic and logical instruction contained in the binary code and the recording of the result D re s- P of this execution in the register R re s, then
    - the hardware security module:
    - calculates (210, 226) a code C re s- P using the relation C re s- P = F * (D res - P ) if n is greater than one and, otherwise, using the relation C res - P = T * (D re sp) if n is equal to one, and
    - calculates a Cres-t code (218, 224) using the relation C re st = Ci, * # C 2 , * # ... # Cn, *, then
    - compares (220) the codes C res - P and C res -t and triggers (172) the signaling of an execution fault if the code C res - P does not correspond to the code C res -t and, in the otherwise, inhibits this reporting.
    [0012]
    12. Method according to any one of the preceding claims, in which:
    the method comprises recording (150) in a main memory at an address @j of a line of code, this line of code containing:
    a Dj data to be processed by the microprocessor or a cryptogram of this Dj data, and
    - a first error detection code (ECC D j, MACj, ECClj) making it possible to detect an error in the data Dj or in its cryptogram if this data Dj or its cryptogram is modified after its recording in the main memory, at least l one of the data Dj, its cryptogram and the first error detecting code being encrypted as a function of an initialization vector ivj, this initialization vector ivj varying as a function of the address @j at which the line of code is recorded according to a relation ivj = F iv (@j), where the function F iv is a preprogrammed function of a hardware module for securing the microprocessor which associates a different initialization vector ivj with each address @j different from main memory,
    - during the execution (152) of the binary code by the microprocessor, the method comprises the following operations:
    - the execution of a loading instruction by the microprocessor which causes the loading in the registers of the microprocessor of the line of code recorded at the address @j, then
    - the hardware security module calculates (278) the initialization vector ivj using the relation ivj = F iv (@j), where @j is the address from which the line of code was loaded , then
    - the hardware security module decrypts (278) the line of code loaded using the initialization vector ivj calculated to obtain:
    - the Dj data or its cryptogram, and
    - the first error detection code, then
    the hardware security module checks (284), using the first error detection code obtained, if there is an error in the data Dj or its cryptogram and, if such an error exists, triggers (172) the reporting of a failure to perform and, if such an error does not exist, inhibits this reporting of a failure to perform.
    [0013]
    13. Binary code of a secure function executable by a microprocessor for the implementation of an execution method according to any one of the preceding claims, in which the binary code comprises lines of code, each line of code containing:
    - a cryptogram (Clj *, CDj *) of a single instruction executable by the microprocessor or of a single datum to be processed by the microprocessor, and
    - a message authentication code (MACj) to verify the integrity and authenticity of the cryptogram.
    [0014]
    14. Support for recording information readable by a microprocessor, characterized in that it includes a binary code according to claim 13.
    [0015]
    15. Microprocessor (2) for implementing a method according to any one of claims 1 to 12, this microprocessor comprising an arithmetic and logic unit (10) and a hardware security module (28), characterized in that the hardware security module (28) is configured to execute operations 1) and 2) of the method according to claim 1.
    [0016]
    16. Compiler (300) capable of automatically transforming a source code of a secure function into a binary code of this secure function, characterized in that the compiler is capable of automatically transforming the source code into a binary code according to claim 13.
    类似技术:
    公开号 | 公开日 | 专利标题
    EP3457620B1|2020-01-01|Method for executing a binary code of a secure function by a microprocessor
    FR2976147A1|2012-12-07|DATA INTERLACEMENT DIAGRAM FOR AN EXTERNAL MEMORY OF A SECURE MICROCONTROLLER
    EP3457621B1|2021-01-20|Method for executing a binary code of a secure function by a microprocessor
    EP2159952B1|2011-04-13|Protection of an encryption algorithm
    FR3071082A1|2019-03-15|METHOD FOR EXECUTING A BINARY CODE OF A FUNCTION SECURE BY A MICROPROCESSOR
    EP3610372B1|2021-03-31|Method for executing a machine code of a secure function
    EP3736719B1|2021-12-08|Method for executing a binary code of a secure function by a microprocessor
    EP3712794B1|2021-08-11|Method for executing a binary code of a function secured by a microprocessor
    EP3712795A1|2020-09-23|Method for the execution, by a microprocessor, of a binary code comprising a calling function and a called function
    EP3761199B1|2021-07-21|Method for executing a binary code of a secure function by a microprocessor
    EP3832947A1|2021-06-09|Method for executing a computer program by an electronic apparatus
    EP2336931B1|2013-01-09|Method for signature verification
    EP3685259A1|2020-07-29|Method for executing a machine code of a secure function
    EP2225693B1|2012-03-28|Method for securing a conditional connection, information carrier, software and secured system for said method
    WO2007099164A1|2007-09-07|Method for making secure execution of a series of logically concatenated steps
    同族专利:
    公开号 | 公开日
    US20190080096A1|2019-03-14|
    EP3457620B1|2020-01-01|
    FR3071121B1|2020-09-18|
    EP3457620A1|2019-03-20|
    US10650151B2|2020-05-12|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US5689727A|1994-09-08|1997-11-18|Western Digital Corporation|Disk drive with pipelined embedded ECC/EDC controller which provides parallel operand fetching and instruction execution|
    US20030046563A1|2001-08-16|2003-03-06|Dallas Semiconductor|Encryption-based security protection for processors|
    WO2007010009A2|2005-07-19|2007-01-25|Gemplus|Permanent data hardware integrity|
    EP1783648A1|2005-10-10|2007-05-09|Nagracard S.A.|Secure microprocessor with instructions verification|
    EP1855476A2|2006-05-11|2007-11-14|Broadcom Corporation|System and method for trusted data processing|
    US20090235090A1|2008-03-13|2009-09-17|Chih-Chung Chang|Method for Decrypting an Encrypted Instruction and System thereof|
    WO2012010205A1|2010-07-22|2012-01-26|Nagravision S.A.|A processor-implemented method for ensuring software integrity|
    US7058877B2|2002-05-14|2006-06-06|Sun Microsystems, Inc.|Method and apparatus for providing error correction within a register file of a CPU|
    FR2841015A1|2002-06-18|2003-12-19|St Microelectronics Sa|Program execution control method, for use in ensuring security programs execute in their intended sequence, by using a digital signature for each operator in each command execution step|
    WO2004053684A2|2002-12-12|2004-06-24|Arm Limited|Processing activity masking in a data processing system|
    WO2005052795A1|2003-11-28|2005-06-09|Koninklijke Philips Electronics N.V.|Method and means for securing or verifying respectively a program that can be executed in a data processing unit|
    FR3047100B1|2016-01-26|2018-03-02|Commissariat A L'energie Atomique Et Aux Energies Alternatives|METHOD OF ENCRYPTING A FLOT OF INSTRUCTIONS AND EXECUTING A FLOAT OF INSTRUCTIONS SO DIGIT.|US10802902B2|2018-10-23|2020-10-13|GM Global Technology Operations LLC|Notification of controller fault using message authentication code|
    FR3094107B1|2019-03-21|2021-02-26|Commissariat Energie Atomique|PROCESS FOR EXECUTING A BINARY CODE OF A SECURE FUNCTION BY A MICROPROCESSOR|
    FR3094108B1|2019-03-21|2021-02-26|Commissariat Energie Atomique|PROCESS FOR EXECUTING, BY A MICROPROCESSOR, A BINARY CODE INCLUDING A CALLING FUNCTION AND A CALLING FUNCTION|
    FR3095869B1|2019-05-09|2021-04-09|Commissariat Energie Atomique|PROCESS FOR EXECUTING A BINARY CODE OF A SECURE FUNCTION BY A MICROPROCESSOR|
    FR3098319A1|2019-07-05|2021-01-08|Commissariat à l'énergie atomique et aux énergies alternatives|PROCESS FOR EXECUTING A BINARY CODE OF A SECURED FUNCTION BY A MICROPROCESSOR|
    法律状态:
    2019-03-15| PLSC| Search report ready|Effective date: 20190315 |
    2019-09-30| PLFP| Fee payment|Year of fee payment: 3 |
    2020-09-30| PLFP| Fee payment|Year of fee payment: 4 |
    2021-09-30| PLFP| Fee payment|Year of fee payment: 5 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1758506|2017-09-14|
    FR1758506A|FR3071121B1|2017-09-14|2017-09-14|PROCESS FOR EXECUTION OF A BINARY CODE OF A FUNCTION SECURE BY A MICROPROCESSOR|FR1758506A| FR3071121B1|2017-09-14|2017-09-14|PROCESS FOR EXECUTION OF A BINARY CODE OF A FUNCTION SECURE BY A MICROPROCESSOR|
    EP18193224.5A| EP3457620B1|2017-09-14|2018-09-07|Method for executing a binary code of a secure function by a microprocessor|
    US16/130,115| US10650151B2|2017-09-14|2018-09-13|Method of execution of a binary code of a secure function by a microprocessor|
    [返回顶部]