WO2012085482A1 - Protection des applets contre les analyses par canaux caches - Google Patents

Protection des applets contre les analyses par canaux caches Download PDF

Info

Publication number
WO2012085482A1
WO2012085482A1 PCT/FR2011/053160 FR2011053160W WO2012085482A1 WO 2012085482 A1 WO2012085482 A1 WO 2012085482A1 FR 2011053160 W FR2011053160 W FR 2011053160W WO 2012085482 A1 WO2012085482 A1 WO 2012085482A1
Authority
WO
WIPO (PCT)
Prior art keywords
instructions
instruction
codes
virtual machine
code
Prior art date
Application number
PCT/FR2011/053160
Other languages
English (en)
Inventor
Frédéric Boulet
Michaël BARTHE
Thanh- Ha LE
Original Assignee
Morpho
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Morpho filed Critical Morpho
Priority to RU2013134481/08A priority Critical patent/RU2603545C2/ru
Priority to EP11815528.2A priority patent/EP2656268A1/fr
Priority to CN201180066192.0A priority patent/CN103597490A/zh
Priority to US13/997,136 priority patent/US20130312110A1/en
Publication of WO2012085482A1 publication Critical patent/WO2012085482A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/14—Protecting executable software against software analysis or reverse engineering, e.g. by obfuscation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/77—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in smart cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/75—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information by inhibiting the analysis of circuitry or operation
    • G06F21/755—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information by inhibiting the analysis of circuitry or operation with measures against power attack

Definitions

  • applet any program executed by a virtual machine.
  • a program written in Java-Card language and intended to be executed by the JVM of a smart card is called applet.
  • .NET applet or Multos applet, for programs developed in a .NET environment for smart cards (respectively a Multos environment).
  • the instructions included in an applet are often called op-codes, for "operation code", in the Java- Card context.
  • a virtual machine is an entity that is able to execute an applet that is saved as a succession of statements, and that, when the applet is executed, translates each statement into an elementary operation or a sequence of elementary operations and executes this elementary operation (s).
  • a virtual machine allows to dissociate the interface by means of which the program is registered or transmitted, of the platform which carries out the elementary operations. Examples of virtual machines include Java Virtual Machine (JVM), or various Common Language Infrastructure (CLI) implementations such as Common Language Runtime (CLR) for C # (.NET environment).
  • Virtual machines are often purely software. They can then run the same applet on all kinds of platforms very different from each other provided that there is a virtual machine suitable for each of these platforms. But it is also possible to use hardware virtual machines (for example a dedicated electronic circuit) or virtual machines associating a software part and a hardware part.
  • An inverse applet is called an activity that aims to understand how the applet was designed to copy, modify, or hijack the applet, most often without the consent of its authors and / or owners.
  • Hidden channel analysis is an analysis based on information obtained from the physical implementation of an electronic device. This information is often variations of certain physical quantities that are caused by the execution of a program in the electronic device. These physical quantities (called “hidden channels”) can be, in particular, the electrical consumption of the device, or the electromagnetic field that is produced by the device, and can distinguish the tasks performed according to the power consumption they require or electromagnetic radiation they cause. We can also measure the vibrations emitted (some components may vibrate, in a different way depending on what they do), or the temperature variations, or the time spent performing a particular task (“timing attacks"). Etc.)
  • a basic analysis may simply consist in identifying a given characteristic according to a given measurement on the targeted electronic device. This is the case, for example, of so-called SPA (Simple Power Analysis) attacks. More sophisticated analyzes can rely on statistical studies based on a large number of measurements (this is the case for example DPA attacks, for Differential Power Analysis, and more particularly HODPA attacks, for High Order DPA ).
  • SPA Simple Power Analysis
  • More sophisticated analyzes can rely on statistical studies based on a large number of measurements (this is the case for example DPA attacks, for Differential Power Analysis, and more particularly HODPA attacks, for High Order DPA ).
  • an attacker can for example proceed in two stages.
  • the attacker loads learning applets on the card (for some Java cards, this manipulation is indeed allowed, for others it may be necessary to perform a first attack to load the applets learning).
  • the learning applets are encoded by the attacker in a way that allows him to characterize the instructions by corresponding models.
  • a pattern is a signal related to a hidden channel of an instruction.
  • the set of models then forms a base of models of the instructions that have been characterized.
  • the attacker measures the signal coming from a hidden channel during the execution of the applet he wishes to discover. Then, it uses the model database built in the characterization step to find the sequence of instructions of the applet. The detection is based on the coherence between the signal acquired during the detection step and the models stored in the base.
  • One of the simplest consistency measures is correlation.
  • the situation C1 corresponds, for example, to a case in which no hardware or software countermeasure is implemented, or only elementary (ineffective) countermeasures are implemented.
  • a typical example of this type of countermeasures is the addition of random noise on the channel (e.g. power consumption or electromagnetic radiation).
  • this random noise can be isolated by running the characterization applets a large number of times and averaging the signals.
  • the C2 situation can occur especially if some hardware or software countermeasures are implemented.
  • the solution using a deterministic noise proposed in the patent FR2903508B1 makes it possible to make the extraction of the models more difficult. Countermeasures to desynchronize the signals (for example: jitter, clock division ...) can disturb the obtaining of the models but it is often possible to find them thanks to techniques of signal processing.
  • the solution according to FR2903508B1 is relatively expensive in terms of performance.
  • the deterministic noise is not correctly generated (that is, it does not lead to signatures strongly resembling the signatures naturally generated during the execution of the instruction considered), an attacker could extract it from the raw signals.
  • the C3 situation could arise in case of very strong security, for example through low-level interventions, at a hardware level, directly in a component running the applet, or at a software level, in an interpreter (virtual machine running the applet).
  • the purpose of these interventions is generally to make the models constant or not constant but identical, so that it is impossible to distinguish one instruction from another.
  • it is very difficult to guarantee such a property, and the case C3 is relatively theoretical.
  • the situation C4 can occur when the attacked device is designed to provide false models (that is, models that do not match the models of the attacked applet), during the learning phase.
  • false models that is to say generate different types of noise in the two stages of characterization and detection, to disturb the detection.
  • the models are typically the same. If the attacker manages to find a way to isolate the additive noise (for example isolate a signal coming from the crypto-processor that is used as noise), it is possible that he can reverse engineer the applet attacked by the analysis of hidden channels.
  • Possibilities C1 and C2 in turn allow, in general, a detection of the instructions in the second step in which two situations can be envisaged:
  • the situation in which the models can not be detected is usually the result of the C3 situation, and is therefore not studied.
  • a noise can be superimposed on the power supply in order to make its operation more difficult, to smooth the power consumption (for example with capacitors), to limit electromagnetic emissions by adequate shielding, etc.
  • a particular internal clock whose characteristic is to have a frequency of operation which varies randomly, which makes the measurements difficult to exploit (the instructions of the applet then being carried out at a rate which varies constantly , and which is a priori unknown to the attacker).
  • Java-Card smart cards can condition the execution of an applet to the correct presentation of a PIN.
  • WO 02/50641 (Nicolas Giraud et al.) Discloses a technique for protecting the execution of an operator (in particular the XOR operator) belonging to the set of arithmetic instructions of a microprocessor. This technique consists in replacing the execution of the same operator by the execution of one of several possible sequences of operations, the different sequences being functionally identical to the operator. However, this technique protects an operator without making any distinction as to the context in which this operator is used. On the other hand, it is not intended to specifically protect an electronic device equipped with a virtual machine (this type of electronic devices not even being disclosed).
  • the invention aims to improve the situation.
  • One aspect of the invention relates to an electronic device equipped with a virtual machine for executing an applet, the virtual machine being arranged to recognize the instructions of the applet and execute a code corresponding to each instruction.
  • the electronic device is, for example, a card to puce (SIM card, bank card, health card, etc.), an electronic identity document (electronic passport, electronic identity card, electronic visa, etc.), a USB key, a token, etc.
  • the virtual machine comprises an association module arranged to associate, in the same instruction, several separate but functionally identical codes.
  • the virtual machine has several ways to execute the same instruction. It is possible to protect several instructions, each of them being associated with several different codes but functionally identical.
  • the definition of the sets of codes to be associated with each instruction can be done upstream (for example during the design of the device), and the association module can then simply memorize the list of predefined codes associated with each instruction concerned.
  • the virtual machine also comprises a selection module arranged to select the code to be executed for the instruction considered in a random manner. By random, we mean that it is not possible for an entity outside the device to easily deduce deterministic properties that would predict future selections based on past selections. The selection can take place for example by means of a so-called "pseudo-random" generator, such as a linear congruent generator, which can be software or hardware.
  • the series of random numbers generated by such a generator is deterministic, but of long duration, and relies on a secret that is not shared with the outside world.
  • the association module and the selection module are, for example, software modules executed by a processor of the device, or modules in hardwired logic (for example for a virtual machine made using a dedicated electronic component). .
  • This embodiment is also advantageous in that it allows protection performed at a level higher than the processor level. It is thus possible to protect certain instructions when they are used by an applet executed by a virtual machine.
  • This protection can be combined with a low level protection, for example the processor can, in addition, replace some operations of the processor with one of several functionally equivalent sequences.
  • an electronic device comprising a virtual machine may be required to execute many types of codes, the applets of which only constitute a subset.
  • some codes may correspond to portions of the operating system of the electronic device (or softmasks), and may be executed without the virtual machine being requested (or even informed of their execution).
  • the various codes associated with the instruction are distinguished by their duration of execution by the device.
  • the execution time of an applet fluctuates in an unpredictable way, not only globally (total duration of execution of the applet) but also at the level of each instruction associated with several codes.
  • the various codes associated with said instruction are distinguished by the power consumption or the electromagnetic radiation they generate during their execution by the device.
  • measurements of electromagnetic radiation or electrical consumption during the execution of an applet do not make it easy to deduce what the applet is doing, the electromagnetic signature (or consumption) being variable for each instruction associated with several codes.
  • the virtual machine is arranged to operate the random selection of the code to be executed for each instruction associated with several codes based on a measurement of the physical characteristic of the device. For example, it is possible to measure, using a analog-to-digital converter, the noise of a resistor, which has stochastic physical properties.
  • the physical measurement or measurements can be used directly, or used as seeds of a software pseudo-random generator, or be processed (for example using a crypto-processor) to improve their statistical properties. Relying on a physical feature increases the quality (the unpredictability) of the selection.
  • two instructions each associated with several codes at least one of the codes associated with the first instruction has at least one characteristic common to one of the codes associated with the second instruction, the common characteristics including the duration of execution by the device, as well as the power consumption and the electromagnetic radiation generated during execution of the code by the device.
  • the common characteristics are limited to one or more of these three characteristics.
  • the virtual machine is arranged to identify the most frequent instructions and to use several codes only for said most frequent instructions.
  • the virtual machine can identify the most frequent instructions (for which several codes are available), for example by using a pre-stored list of instructions (this list being defined for example during the design of the device). It can thus be statistically determined that this or that instruction is more frequent. It is also possible to analyze the code of the applet considered in order to identify the most frequent instructions for this particular applet.
  • the five most frequent instructions are the instructions sload, sconst_0, baload, getfield_a_this, sstore, and one can only modify these five instructions, or even a subset of any of these five instructions.
  • the most frequent instructions include one of the instructions of the addition, subtraction, multiplication, modulo, and exclusive orignal instructions, and it is advantageous to modify only instructions belonging to the this subset of instructions (addition, subtraction, multiplication, modulo, and or exclusive).
  • Such elementary arithmetic instructions very common, have a high probability of appearing in any applet, and appearing quite often. By focusing on the protection of some very common instructions, one can minimize the complexity of implementing the protection (by avoiding to protect the entire instruction set), while ensuring that the protection will be effective enough (thanks to the frequency of appearance of the chosen instructions, which thus induces a possible attacker in error, the signature of these instructions constantly changing).
  • the virtual machine is arranged to identify the most sensitive instructions and to use several codes for these most sensitive instructions. This protects the most critical operations (an attacker is often interested in only parts of the applet).
  • the identification of the most sensitive instructions can be static, that is to say that the list of the most sensitive instructions can be preprogrammed in the virtual machine at the time of the design of the virtual machine and / or the device that integrates it.
  • the most sensitive instructions include one of the instructions among the instructions implementing cryptographic algorithms as well as the access control instructions (including PIN code verification instructions, or passwords). ).
  • Another aspect of the invention relates to a method of securing an electronic device against concealed channel attacks, the electronic device being equipped with a virtual machine recognizing the instructions of an applet and executing a code corresponding to each instruction. Since one (at least) instruction is associated with several distinct but functionally identical codes, the virtual machine selects the code to be executed for this instruction associated with several codes in a random manner.
  • the various codes associated with said instruction are distinguished by their duration of execution by the device.
  • the various codes associated with said instruction are distinguished by the power consumption or the electromagnetic radiation they generate during their execution by the device.
  • the virtual machine selects the code to be executed for said instruction based on a measurement of the physical characteristic of the device.
  • This physical characteristic electrical noise in a component sampled by an analog-to-digital converter, etc.
  • a parameter calculated from the physical characteristic may for example have better statistical properties.
  • two instructions each associated with several codes at least one of the codes associated with the first instruction has at least one characteristic common to one of the codes associated with the second instruction, the common characteristics including the execution time by the device, as well as the power consumption and the electromagnetic radiation generated during execution of the code by the device.
  • the virtual machine identifies the most frequent instructions and uses several codes only for the most frequent instructions.
  • Figure 1 illustrates different scenarios of an inverse applet engineering by hidden channel analysis
  • Figure 2 is a diagram illustrating an implementation of applet protection performed according to an embodiment of the invention.
  • the protection of a program interpreted by a virtual machine against reverse engineering using a hidden channel analysis is based on the use of alternative models making it possible to render the phases of characterization and detection more difficult.
  • An instruction can thus correspond to several different codes, therefore to several different models.
  • an addition operation is generally very close to the subtraction operation (SUB). It is possible to code the ADD and the SUB in such a way that their signatures are identical or very similar. For example, it is conceivable to implement the ADD addition, which takes as parameters two operands Op1 and Op2, as follows:
  • this SUB operation performs exactly the same steps as the ADD operation, except that it uses as parameter, in line 4, the complement X instead of the parameter Op2.
  • this is not typically observed on the electromagnetic or other emissions generated by the execution of the ADD and SUB operations, because only the address used is changed (the address of X not being the address of Op2 ). Or read data to a first address or to another address of the same memory component generates in principle the same traces.
  • This results in an ADD operation that may be slightly slower than a conventional ADD operation since it computes a seemingly useless X complement (which is not used later), but on the other hand the fact that this complement is computed makes it possible to get the same signature as for the SUB operation.
  • the complement is a step performed in hardware in parallel with the other steps, and does not slow down the ADD operation.
  • the models of the same instruction are different not only at the form level (the consumption power, the electromagnetic radiation) but also at the duration level (the execution time), for example by adding unnecessary operations.
  • the operations unnecessary can be NOP operations. It is advisable not to use exclusively NOPs for this type of task (artificial extension of the execution time) because it is then possible for an attacker to be able to identify the NOPs and to consider them as indicators of "time stuffing", whose execution time must be deducted to determine the true execution time.
  • some models are only authorized for applets stored in a certain type of memory (for example in ROM).
  • the ROM typically contains highly controlled applets because they have necessarily been "loaded” during a step of masking the ROM component which implies knowledge of the applet by the manufacturers responsible for manufacturing this component ROM, which therefore have opportunity to check are content.
  • it is easy (and known from the state of the art) to obtain the source code of the applet even when one has only its binary code (which may be the case of the manufacturers above).
  • the ROM models are not valid for applets loaded in memories other than the ROM, such as EEPROM or FLASH memories, or battery-buffered RAM.
  • memories such as EEPROM or FLASH memories, or battery-buffered RAM.
  • the models are different according to the memory areas.
  • some electronic device operating systems partition rewritable memories (such as EEPROM and FLASH), defining at least:
  • a second zone accessible to the manufacturer of the device, for loading patches, softmasks, etc. or applets (possibly applet updates), the second zone being generally controlled according to a second level of protection (often higher than the first level of protection).
  • the second level of protection can be determined and can not be modified, while the first level of protection can be modified.
  • This first level can be modified for example by a telecommunications operator (typically in the case of electronic devices in the form of SIM cards), by a financial institution (typically in the case of bank cards), or by any entity that has purchased the electronic device and having made it available to an end user.
  • characterization applets possibly implemented by the attacker are not relevant for all the applets. , and in particular for the applets stored in certain types of memories or in certain memory zones considered more sensitive and not accessible to the attacker.
  • This may include system applets, such as applets offering authentication functions or credential sharing functions.
  • Authentication functions may include biometric authentication (fingerprint verification by match-on-card technique, Iris verification, etc.), password checks, code checks PIN, etc.
  • the credential sharing functions may include, for example, PIN sharing functions by a system applet to prevent all user applets from each having to request the same PIN code from the user, which would be detrimental the usability of the use of the electronic device (users are typically annoyed at having to enter the same secret code several times), and would even be generally harmful to security.
  • PIN sharing functions by a system applet to prevent all user applets from each having to request the same PIN code from the user, which would be detrimental the usability of the use of the electronic device (users are typically annoyed at having to enter the same secret code several times), and would even be generally harmful to security.
  • each new entry of a PIN can be the object of an attack (social engineering, for example person observing the entry of the PIN code and memorizing it, or system of espionage type "key logger" namely interceptor keystrokes).
  • each new transmission of a PIN code to the electronic device can potentially be attacked.
  • the models of the same instruction are alternately activated according to certain rules defined for the application target. For example, all the models can be activated in a random manner, the rule for an applet that can be determined according to the mechanism defined in the patent application FR2903508 ("Protection of a program interpreted by a virtual machine", filed on 10 July 2006), that is to say it is possible to take into account a condensed applet (for example the result of a SHA-1 function applied to the binary code of the applet), so vary the models differently for the same instruction depending on whether it belongs to one applet or another.
  • Alternate models can be applied to all instructions or to a set of the most critical and / or most called instructions.
  • the effects generated by this countermeasure are as follows.
  • An attacker could be aware of the existence of different models implemented by the target electronic device for the same instructions (depending on the context in which the instruction is executed by the device). Such an attacker may then seek to take this feature into account in attempting to determine which rule (s) is (are) used by the target electronic device to choose one model over another. In the case where an attacker can not characterize the models with raw signals and where he is obliged to record many occurrences of the signals then to average these signals to reduce the noise:
  • only a few instructions are protected, which makes it possible to have a low performance impact (of the order of a few cents, that is to say that the speed of execution of the applet can be almost unchanged).
  • the simple fact of changing only one very frequent instruction (for example the addition) in associating it with four possible codes instead of one may be enough to make an attack much more complex, while having a very negligible impact on the development time (at the interpreter device, applets, etc.) than on performance (the secure applet being almost as fast as an unprotected applet according to this embodiment).
  • the most frequent instructions are: sload, sconst_0, baload, getfield_a_this, sstore, and it is a subset of these instructions (or all these instructions) that is protected.
  • An embodiment limited to protecting frequent instructions is particularly advantageous, particularly for products with strong performance constraints, such as low memory capacity, slow processor, and so on.
  • smart cards have much lower computing and storage resources than those of a conventional computer, and this embodiment is particularly suitable for them.
  • Targeting only certain instructions also avoids a long development time and a large interpreter size.
  • Fig. 2 relates to an implementation of applet protection according to one embodiment.
  • OPi designates the instruction number i (having op-code OPi).
  • Ri denotes a rule of this applet corresponding to the OPi instruction.
  • the rule Ri can for example define the algorithm for selecting the code to be executed for the instruction OPi. It can be a conventional pseudo-random algorithm, but it can also be an algorithm that random in the sense that it is not easily predictable, selects the different codes with unequal probabilities.
  • OP.SEQi designates the step of executing an OPi instruction in the sequence of instructions constituted by the applet.
  • the code executed during OP.SEQi is not always the same, it depends on the one hand on the OPi instruction which determines the function that must be performed by the code, and on the Ri rule, which determines which code ( among all codes performing this function) must be executed.
  • a virtual machine generates, from an applet represented by a series of instructions (OP1, OP2, OP3, %), from a series of rules. (R1, R2, R3, ...), and from a series of sets of codes (Codes of ⁇ 1, Codes of ⁇ 2, Codes of ⁇ 3, ...), each set of codes being associated with a set of codes instruction, an execution sequence (OP.SEQ1, OP.SEQ2, OP.SEQ3, %) performing the tasks provided in the applet, but using randomly chosen codes.
  • the device embodying the invention may also be, for example, a mobile communication equipment, a contactless identification tag, a contactless identification tag reader, a smart card, a reader of such smart cards, an access control system, etc.
  • kinds of smart cards for which the invention can be advantageously implemented can be in particular health smart cards, identity or passport chip cards, bank chip cards, control chip cards. access or smart cards electronic game media.
  • Protectable applets are not limited to JavaCard applets, but can be for example .NET applets, or Multos applets.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Storage Device Security (AREA)
  • Power Sources (AREA)

Abstract

L'invention se rapporte notamment à un dispositif électronique équipé d'une machine virtuelle pour exécuter une applet. La machine virtuelle est agencée pour reconnaître les instructions de l'applet et exécuter un code correspondant à chaque instruction. La machine virtuelle comprend un module d'association agencé pour associer plusieurs codes distincts mais fonctionnellement identiques à une même instruction, et un module de sélection agencé pour sélectionner le code à exécuter pour ladite instruction de manière aléatoire. L'invention se rapporte également à un procédé de sécurisation de dispositif contre électronique contre les attaques par canaux cachés.

Description

PROTECTION DES APPLETS
CONTRE LES ANALYSES PAR CANAUX CACHES
L'invention concerne des méthodes de protection des applets contre les analyses par canaux cachés ainsi qu'un dispositif mettant en œuvre de telles protections.
On appelle applet tout programme exécuté par une machine virtuelle. Par exemple, un programme rédigé en langage Java-Card et ayant vocation à être exécuté par la JVM d'une carte à puce est appelé applet. On parle, par analogie, d'applet .NET, ou d'applet Multos, pour des programmes développés dans un environnement .NET pour cartes à puces (respectivement un environnement Multos). Les instructions comprises dans une applet sont souvent appelées op-codes, pour «opération code», dans le contexte Java- Card.
Une machine virtuelle est une entité qui est capable d'exécuter une applet enregistrée sous forme d'une succession d'instructions, et qui, lors d'une exécution de l'applet, traduit chaque instruction en une opération élémentaire ou en une séquence d'opérations élémentaires et exécute cette ou ces opération(s) élémentaire(s). Une machine virtuelle permet de dissocier l'interface au moyen de laquelle le programme est enregistré ou transmis, de la plateforme qui réalise les opérations élémentaires. Des exemples de machines virtuelles comprennent notamment les JVM (Java Virtual Machine), ou encore diverses implémentations de la CLI (Common Language Infrastructure) telles que la CLR (Common Language Runtime), pour le langage C# (environnement .NET). Les machines virtuelles sont souvent purement logicielles. Elles permettent alors d'exécuter une même applet sur toutes sortes de plateformes très différentes les unes des autres sous réserve qu'il existe une machine virtuelle adaptée pour chacune de ces plateformes. Mais il est également possible d'utiliser des machines virtuelles matérielles (par exemple un circuit électronique dédié) ou des machines virtuelles associant une partie logicielle et une partie matérielle.
On appelle ingénierie inverse d'une applet une activité qui a pour but de comprendre la manière dont l'applet a été conçue afin de copier, modifier ou détourner l'applet, le plus souvent sans l'accord de ses auteurs et/ou détenteurs.
Une analyse par canaux cachés est une analyse basée sur des informations obtenues à partir de l'implémentation physique d'un dispositif électronique. Ces informations sont souvent des variations de certaines grandeurs physiques qui sont provoquées par l'exécution d'un programme dans le dispositif électronique. Ces grandeurs physiques (appelées «canaux cachés»), peuvent être, notamment, la consommation électrique du dispositif, ou le champ électromagnétique qui est produit par le dispositif, et peuvent permettre de distinguer les tâches accomplies en fonction de la consommation électrique qu'elles requièrent ou du rayonnement électromagnétique qu'elles occasionnent. On peut aussi mesurer les vibrations émises (certains composants sont susceptibles de vibrer, et ce d'une manière différente selon ce qu'ils font), ou encore les variations de température, ou la durée passée à exécuter une tâche particulière (« timing attacks »), etc.
Une analyse élémentaire peut consister simplement à identifier une caractéristique donnée en fonction d'une mesure donnée sur le dispositif électronique ciblé. C'est le cas par exemple des attaques dites SPA (pour Simple Power Analysis). Des analyses plus sophistiquées peuvent s'appuyer sur des études statistiques sur la base d'un grand nombre de mesures (c'est le cas par exemple des attaques DPA, pour Differential Power Analysis, et plus particulièrement des attaques HODPA, pour High Order DPA).
Dans le contexte de Java-card, on cherche souvent à maintenir secrètes les successions d'instructions comprises dans les applets, afin d'éviter que certaines de ces instructions ne soient modifiées pour détourner l'applet, ou pour changer un résultat produit lors d'une exécution de l'applet.
Cependant, il est parfois possible de retrouver la succession des instructions qui constituent un programme en analysant des canaux cachés, ainsi que c'est expliqué notamment dans Dennis Vermoen, "Reverse engineering of Java Card applets using power analysis", MSc Thesis, Delft Technology University (performed in Riscure), 2006. Cela implique une vulnérabilité potentiellement importante des applets Java-card. L'analyse par canaux cachés a été également utilisée par des organisations autorisées (par exemple Information Technology Evaluation Facility - ITSEF) pour évaluer la sécurité des cartes Java, ainsi que c'est expliqué dans Serge Chaumette and Damien Sauveron "An efficient and simple way to test the security of Java Cards", in Proceedings of 3rd International Workshop on Security in Information Systems (WOSIS 2005). Sagem Sécurité est titulaire d'un brevet "Protection d'un programme interprété par une machine virtuelle", numéro FR2903508B1 proposant de masquer les instructions afin de se protéger contre ce type d'analyse.
Pour tenter de découvrir les instructions d'une applet un attaquant peut par exemple procéder en deux étapes.
Dans une étape de caractérisation, l'attaquant charge des applets d'apprentissage sur la carte (pour certaines cartes Java, cette manipulation est en effet autorisée, pour d'autres il peut être nécessaire d'effectuer une première attaque afin de charger les applets d'apprentissage). Les applets d'apprentissage sont codées par l'attaquant d'une manière lui permettant de caractériser les instructions par des modèles correspondants. Un modèle correspond à un signal lié à un canal caché d'une instruction. L'ensemble des modèles forme alors une base de modèles des instructions qui ont été caractérisées.
Dans une étape de détection, l'attaquant mesure le signal issu d'un canal caché pendant l'exécution de l'applet qu'il souhaite découvrir. Ensuite, il utilise la base de modèles construite dans l'étape de caractérisation pour retrouver la séquence d'instructions de l'applet. La détection se base sur la cohérence entre le signal acquis pendant l'étape de détection et les modèles stockés dans la base. L'une des mesures de cohérence les plus simples est la corrélation.
Ainsi, le succès d'une ingénierie inverse par l'analyse de canaux cachés dépend généralement de deux étapes de caractérisation et de détection. En ce qui concerne l'étape de caractérisation, un attaquant peut être confronté notamment à l'une des quatre situations suivantes, illustrées sur la figure 1 : C1 - obtention aisée de modèles corrects,
C2 - obtention difficile de modèles corrects,
C3 - impossibilité d'obtenir des modèles,
C4 - obtention de faux modèles.
La situation C1 correspond par exemple à un cas dans lequel aucune contre-mesure matérielle ni logicielle n'est implémentée, ou seules des contre- mesures élémentaires (peu efficaces) sont implémentées. Un exemple typique de ce type de contre-mesures est l'addition d'un bruit aléatoire sur le canal (par exemple la consommation électrique ou le rayonnement électromagnétique). Cependant, ce bruit aléatoire peut être isolé en exécutant les applets de caractérisation un grand nombre de fois et en moyennant les signaux.
La situation C2 peut se produire notamment si certaines contre-mesures matérielles ou logicielles sont implémentées. La solution utilisant un bruit déterministe proposée dans le brevet FR2903508B1 permet de rendre l'extraction des modèles plus difficile. Les contre-mesures pour désynchroniser les signaux (par exemple: jitter, division d'horloge...) peuvent perturber l'obtention des modèles mais il est souvent possible de les retrouver grâce à des techniques de traitement du signal. La solution selon FR2903508B1 est relativement coûteuse en termes de performance. De plus, si le bruit déterministe n'est pas correctement généré (c'est-à-dire s'il ne conduit pas à des signatures fortement ressemblantes aux signatures naturellement générées lors de l'exécution de l'instruction considérée), un attaquant pourrait parvenir à l'extraire des signaux bruts.
La situation C3 pourrait se présenter en cas de très forte sécurisation, par exemple grâce à des interventions de bas niveau, à un niveau matériel, directement dans un composant exécutant l'applet, ou encore à un niveau logiciel, dans un interpréteur (machine virtuelle exécutant l'applet). Le but de ces interventions est généralement de rendre les modèles soit constant, soit non constant mais identiques, de manière à ce qu'il soit impossible de distinguer une instruction d'une autre. Cependant, en pratique il est très difficile de garantir une telle propriété, et le cas C3 est relativement théorique.
La situation C4 peut se présenter lorsque que le dispositif attaqué est conçu pour fournir de faux modèles (c'est-à-dire des modèles qui ne correspondent pas aux modèles de l'applet attaquée), lors de la phase d'apprentissage. Selon le brevet FR2903508B1 on peut créer de faux types de bruit, c'est-à-dire générer des types de bruit différents dans les deux étapes de caractérisation et de détection, pour perturber la détection. Cependant, les modèles (cachés derrières le bruit) sont typiquement les mêmes. Si l'attaquant arrive à trouver un moyen pour isoler le bruit additif (par exemple isoler un signal venant du crypto-processeur qui est utilisé comme bruit), il est possible qu'il parvienne à faire une ingénierie inverse de l'applet attaquée par l'analyse de canaux cachés.
On peut généralement considérer que les possibilités C3 et C4 ne peuvent donner lieu à l'étape de détection. Les possibilités C1 et C2 permettent quant à elles, en général, une détection des instructions dans la deuxième étape dans laquelle deux situations peuvent être envisagées:
D1 - modèles facile à détecter pendant l'exécution,
D2 - modèles difficiles à détecter
La situation dans laquelle il serait impossible de détecter les modèles est en général la suite de la situation C3, et n'est donc pas étudiée.
Cinq des scénarios pouvant se produire dans une ingénierie inverse d'applet par l'analyse de canaux cachés sont représentés sur la figure 1 par S1 , S2, S3, S4 et S5. La combinaison C2-D1 est typiquement très rare. En effet, s'il est difficile pour l'attaquant de créer des applets de caractérisation pour observer le dispositif cible et déterminer des modèles, il est vraisemblable que la phase de détection ultérieure soit elle aussi difficile compte tenu de l'incertitude pesant sur la qualité des modèles.
Afin de se prémunir contre ces attaques, il est possible de sécuriser le dispositif électronique lui-même. Par exemple, on peut superposer un bruit sur l'alimentation électrique afin de rendre son exploitation plus difficile, lisser la consommation électrique (par exemple avec des condensateurs), limiter les émissions électromagnétiques par des blindages adéquats, etc. On peut aussi utiliser une horloge interne particulière, ayant pour caractéristique d'avoir une fréquence de fonctionnement variable de manière aléatoire, ce qui rend les mesures difficiles à exploiter (les instructions de l'applet étant alors effectuées à une cadence qui ne cesse de varier, et qui est a priori inconnue de l'attaquant). Il existe également d'autres techniques, consistant par exemple à contrôler l'accès physique et/ou l'accès logique au dispositif électronique. Par exemple, les cartes à puces Java-Card peuvent conditionner l'exécution d'une applet à la présentation correcte d'un code PIN. Ainsi, une personne qui volerait la carte à puce en espérant en extraire des informations, ne pourrait exécuter l'applet ciblée sans présenter le bon code PIN (qu'un utilisateur averti apprend par cœur et ne communique à personne), et ne serait donc pas en mesure d'effectuer l'attaque.
WO 02/50641 (Nicolas Giraud et al.) divulgue une technique pour protéger l'exécution d'un opérateur (en particulier l'opérateur XOR) faisant partie du jeu d'instructions arithmétiques d'un microprocesseur. Cette technique consiste à remplacer l'exécution d'un même opérateur par l'exécution d'une parmi plusieurs séquences possibles d'opérations, les différentes séquences étant fonctionnellement identiques à l'opérateur. Cependant, cette technique protège un opérateur sans faire de distinction quant au contexte dans lequel cet opérateur est utilisé. D'autre part, elle n'est pas prévue pour protéger spécifiquement un dispositif électronique équipé d'une machine virtuelle (ce type de dispositifs électroniques n'étant même pas divulgué).
Cependant ces contremesures sont imparfaites.
L'invention vise à améliorer la situation.
Un aspect de l'invention concerne un dispositif électronique équipé d'une machine virtuelle pour exécuter une applet, la machine virtuelle étant agencée pour reconnaître les instructions de l'applet et exécuter un code correspondant à chaque instruction. Le dispositif électronique est, par exemple, une carte à puce (SIM, carte bancaire, carte de santé, etc.), un document d'identité électronique (passeport électronique, carte d'identité électronique, visa électronique, etc.), une clé USB, un token, etc. La machine virtuelle comprend un module d'association agencé pour associer, à une même instruction, plusieurs codes distincts mais fonctionnellement identiques. Ainsi, la machine virtuelle dispose de plusieurs manières d'exécuter une même instruction. Il est possible de protéger plusieurs instructions, chacune d'elles étant associées à plusieurs codes distincts mais fonctionnellement identiques. La définition des ensembles de codes à associer à chaque instruction peut être effectuée en amont (par exemple lors de la conception du dispositif), et le module d'association peut alors se contenter de mémoriser la liste de codes prédéfinis associés à chaque instruction concernée. La machine virtuelle comprend également un module de sélection agencé pour sélectionner le code à exécuter pour l'instruction considérée de manière aléatoire. Par aléatoire, on entend qu'il n'est pas possible, pour une entité extérieure au dispositif, de déduire facilement des propriétés déterministes qui permettraient de prédire les sélections futures en fonction des sélections passées. La sélection peut s'opérer par exemple grâce à un générateur dit « pseudo aléatoire », tel qu'un générateur congruentiel linéaire, qui peut être logiciel ou matériel. La série de nombres aléatoires générés par un tel générateur est déterministe, mais de période longue, et s'appuie sur un secret qui n'est pas partagé avec l'extérieur. Le module d'association et le module de sélection sont, par exemple, des modules logiciels exécutés par un processeur du dispositif, ou des modules en logique câblée (par exemple pour une machine virtuelle réalisée à l'aide d'un composant électronique dédié).
Ainsi, des exécutions successives d'une même applet faisant appel à une instruction associée à plusieurs codes donnent lieu à des observations différentes, et rendent très difficile de déduire de ces observations ce qui se passe réellement dans l'applet. Cette protection est avantageuse, car l'une des caractéristiques couramment mises en avant des dispositifs mettant en œuvre des interpréteurs (par exemple des cartes à puce java) est leur caractère ouvert, et donc la possibilité pour un tiers de charger des applets. Un utilisateur malhonnête du dispositif pourrait chercher à tirer partie de cette ouverture pour charger des applets d'apprentissage et tenter d'attaquer le dispositif.
Ce mode de réalisation est également avantageux en ce qu'il permet une protection effectuée à un niveau plus haut que le niveau du processeur. Il est ainsi possible de protéger certaines instructions lorsqu'elles sont utilisées par une applet exécutée par une machine virtuelle. Cette protection peut se cumuler avec une protection bas niveau, par exemple le processeur peut, de surcroît, remplacer certaines opérations du processeur par une parmi plusieurs séquences fonctionnellement équivalentes. En règle générale, un dispositif électronique comprenant une machine virtuelle peut être amené à exécuter de nombreux types de codes, dont les applets ne constituent qu'un sous ensemble. Par exemple, certains codes peuvent correspondre à des portions de système d'exploitation du dispositif électronique (ou encore à des softmasks), et peuvent être exécutés sans que la machine virtuelle ne soit sollicitée (ni même informée de leur exécution).
Selon un mode de réalisation, les différents codes associés à l'instruction se distinguent par leur durée d'exécution par le dispositif. Ainsi, la durée d'exécution d'une applet fluctue de manière imprévisible, non seulement de façon globale (durée totale d'exécution de l'applet) mais également au niveau de chaque instruction associée à plusieurs codes.
Selon un mode de réalisation, les différents codes associés à ladite instruction se distinguent par la consommation électrique ou par le rayonnement électromagnétique qu'ils génèrent lors de leur exécution par le dispositif. Ainsi, des mesures de rayonnement électromagnétique ou de consommation électrique lors de l'exécution d'une applet ne permettent pas de déduire aisément ce que l'applet est en train de faire, la signature électromagnétique (ou de consommation) étant variable pour chaque instruction associée à plusieurs codes.
Selon un mode de réalisation, la machine virtuelle est agencée pour opérer la sélection aléatoire du code à exécuter pour chaque instruction associée à plusieurs codes en s'appuyant sur une mesure de caractéristique physique du dispositif. Par exemple, il est possible de mesurer, à l'aide d'un convertisseur analogique-numérique, le bruit d'une résistance, qui a propriétés physiques stochastiques. La ou les mesures physiques peuvent être utilisées directement, ou être utilisées comme graines d'un générateur pseudo aléatoire logiciel, ou être post traitées (par exemple à l'aide d'un crypto-processeur) afin d'améliorer leurs propriétés statistiques. S'appuyer sur une caractéristique physique permet d'augmenter la qualité (le caractère imprévisible) de la sélection.
Selon un mode de réalisation, deux instructions étant associées chacune à plusieurs codes, l'un au moins des codes associés à la première instruction possède au moins une caractéristique commune avec l'un des codes associés à la deuxième instruction, les caractéristiques communes comprenant la durée d'exécution par le dispositif, ainsi que la consommation électrique et le rayonnement électromagnétique générés lors d'une exécution du code par le dispositif. Selon un mode de réalisation, les caractéristiques communes se limitent à l'une ou à plusieurs de ces trois caractéristiques. Ainsi, un attaquant éventuel sera parfois confronté à une situation dans laquelle deux instructions différentes ont pourtant la même signature (c'est-à-dire la même durée d'exécution, et/ou la même consommation électrique, et/ou les mêmes émissions électromagnétiques), ce qui rend difficile l'identification des instructions. Pour adapter la durée d'exécution, il est possible de se caler sur la durée la plus longue (entre les deux instructions), cependant, il est recommandé de ne pas se contenter d'ajouter une simple boucle d'attente à l'instruction la plus rapide, car une boucle d'attente a une signature électromagnétique a priori différente de celle d'une instruction quelconque. Il est conseillé, au lieu d'une simple attente, de faire des calculs ou opérations semblables à ceux de l'instruction la plus longue, calcul ou opérations dont les résultats peuvent être ignorés. Ceci est avantageux par rapport à un mode de réalisation qui se limiterait à faire apparaître une même instruction comme étant plusieurs instructions distinctes (lorsque cette instruction est exécutée à plusieurs reprises). En effet, ceci est susceptible d'induire un attaquant éventuel encore plus en erreur lors de l'analyse des signatures qu'il est susceptible d'effectuer. Selon un mode de réalisation, la machine virtuelle est agencée pour identifier les instructions les plus fréquentes et pour n'utiliser plusieurs codes que pour lesdites instructions les plus fréquentes. La machine virtuelle peut identifier les instructions les plus fréquentes (pour lesquelles plusieurs codes sont disponibles), par exemple en utilisant une liste pré-stockée d'instructions (cette liste étant définie par exemple lors de la conception du dispositif). On peut ainsi déterminer statistiquement que telle ou telle instruction est plus fréquente. Il est également possible d'analyser le code de l'applet considérée afin d'identifier les instructions les plus fréquentes pour cette applet particulière.
Selon un mode de réalisation, les cinq instructions les plus fréquentes sont les instructions sload, sconst_0, baload, getfield_a_this, sstore, et l'on peut ne modifier que ces cinq instructions, voire un sous ensemble quelconque de ces cinq instructions.
Selon un mode de réalisation, les instructions les plus fréquentes comprennent l'une des instructions parmi les instructions d'addition, de soustraction, de multiplication, de modulo, et de ou exclusif, et l'on ne modifie avantageusement que des instructions appartenant à ce sous ensemble d'instructions (addition, soustraction, multiplication, modulo, et ou exclusif). De telles instructions arithmétiques élémentaires, très courantes, ont une grande probabilité d'apparaître dans n'importe quelle applet, et d'apparaître assez souvent. En se concentrant sur la protection de quelques instructions très fréquentes, on peut minimiser la complexité de mise en œuvre de la protection (en évitant de protéger l'intégralité du jeu d'instructions), tout en s'assurant que la protection sera assez efficace (grâce à la fréquence d'apparition des instructions choisies, qui induit ainsi un attaquant éventuel en erreur, la signature de ces instructions ne cessant de changer).
Selon un mode de réalisation, la machine virtuelle est agencée pour identifier les instructions les plus sensibles et pour n'utiliser plusieurs codes que pour ces instructions les plus sensibles. Ainsi, on protège les opérations les plus critiques (un attaquant s'intéresse souvent à certaines parties seulement de l'applet). De même que pour l'identification des instructions les plus fréquentes, l'identification des instructions les plus sensibles peut être statique, c'est-à-dire que la liste des instructions les plus sensibles peut être préprogrammée dans la machine virtuelle au moment de la conception de la machine virtuelle et/ou du dispositif qui l'intègre. Selon un mode de réalisation, les instructions les plus sensibles comprennent l'une des instructions parmi les instructions mettant en œuvre des algorithmes cryptographiques ainsi que les instructions de contrôle d'accès (notamment les instructions de vérification de code PIN, ou de mots de passe).
Un autre aspect de l'invention concerne un procédé de sécurisation d'un dispositif électronique contre les attaques par canaux cachés, le dispositif électronique étant équipé d'une machine virtuelle reconnaissant les instructions d'une applet et exécutant un code correspondant à chaque instruction. Une instruction (au moins) étant associée à plusieurs codes distincts mais fonctionnellement identiques, la machine virtuelle sélectionne le code à exécuter pour cette instruction associée à plusieurs codes de manière aléatoire.
Selon un mode de réalisation, les différents codes associés à ladite instruction se distinguent par leur durée d'exécution par le dispositif.
Selon un mode de réalisation, les différents codes associés à ladite instruction se distinguent par la consommation électrique ou par le rayonnement électromagnétique qu'ils génèrent lors de leur exécution par le dispositif.
Selon un mode de réalisation, la machine virtuelle opère la sélection du code à exécuter pour ladite instruction en s'appuyant sur une mesure de caractéristique physique du dispositif. On peut ne pas utiliser directement cette caractéristique physique (bruit électrique dans un composant échantillonné par un convertisseur analogique-numérique, etc.), mais plutôt un paramètre calculé à partir de la caractéristique physique, et qui peut par exemple présenter de meilleures propriétés statistiques.
Selon un mode de réalisation, deux instructions étant associées chacune à plusieurs codes, l'un au moins des codes associés à la première instruction possède au moins une caractéristique commune avec l'un des codes associés à la deuxième instruction, les caractéristiques communes comprenant la durée d'exécution par le dispositif, ainsi que la consommation électrique et le rayonnement électromagnétique générés lors d'une exécution du code par le dispositif.
Selon un mode de réalisation, la machine virtuelle identifie les instructions les plus fréquentes et n'utilise plusieurs codes que pour lesdites instructions les plus fréquentes.
D'autres aspects, buts et avantages de l'invention apparaîtront à la lecture de la description d'un de ses modes de réalisation.
L'invention sera également mieux comprise à l'aide des dessins, sur lesquels :
la figure 1 illustre différents scénarios d'une ingénierie inverse d'applet par analyse de canaux cachés ;
la figure 2 est un diagramme illustrant une mise en œuvre de protection d'applet réalisée selon un mode de réalisation de l'invention.
Selon un mode de réalisation, la protection d'un programme interprété par une machine virtuelle contre une ingénierie inverse utilisant une analyse par canaux cachés (appelée «side-channel analysis» en anglais) est basée sur l'utilisation de modèles alternatifs permettant de rendre les phases de caractérisation et de détection plus difficiles.
Une instruction (op-code) peut ainsi correspondre à plusieurs codes différents, donc à plusieurs modèles différents.
De plus, un même modèle peut correspondre à plusieurs instructions différentes. Par exemple, une opération d'addition (ADD) est généralement très proche de l'opération de soustraction (SUB). Il est possible de coder l'ADD et le SUB de telle manière que leurs signatures soient identiques ou très proches. Par exemple, on peut envisager de mettre en œuvre l'addition ADD, qui prend en paramètres deux opérandes Op1 et Op2, de la manière suivante :
Lecture Opl
Lecture Op2
X = Complément Op2 Calcul Opl+Op2
Ecriture Résultat en mémoire
On voit ici que l'on calcule le complément du deuxième paramètre de l'opération, mais que le résultat de ce calcul n'est pas utilisé. On peut mettre en œuvre l'opération SUB correspondante de la manière suivante :
Lecture Opl
Lecture Op2
X = Complément Op2
Calcul Opl+X
Ecriture Résultat en mémoire
On constate que cette opération SUB effectue exactement les mêmes étapes que l'opération ADD, sauf qu'elle utilise comme paramètre, à la ligne 4, le complément X au lieu du paramètre Op2. Cependant, ceci ne s'observe typiquement pas sur les émissions électromagnétiques ou autres générées par l'exécution des opérations ADD et SUB, car seule change l'adresse utilisée, (l'adresse de X n'étant pas l'adresse d'Op2). Or lire une donnée à une première adresse ou à une autre adresse d'un même composant mémoire génère en principe les mêmes traces. On aboutit à une opération ADD qui peut être légèrement plus lente qu'une opération ADD conventionnelle puisqu'elle calcule un complément X apparemment inutile (qui n'est pas utilisé ultérieurement), mais en revanche le fait que ce complément soit calculé permet d'obtenir la même signature que pour l'opération SUB. Selon un mode de réalisation, le complément est une étape effectuée de façon matérielle en parallèle avec les autres étapes, et ne ralentit pas l'opération ADD.
II est également possible d'obtenir une même signature pour des opérations assez différentes, par exemple une opération à un opérande (complément, négation, décalage de 1 bit, etc.) et une opération à deux opérandes (addition, multiplication, etc.). On peut notamment lire deux fois d'affilée l'opérande unique afin de simuler la lecture de deux opérandes.
Selon un mode de réalisation, les modèles d'une même instruction sont différents non seulement au niveau de forme (la puissance de consommation, le rayonnement électromagnétique) mais aussi au niveau de durée (le temps d'exécution), par exemple par ajout d'opérations inutiles. Les opérations inutiles peuvent être des opérations NOP. Il est conseillé de ne pas utiliser exclusivement des NOP pour ce type de tâche (prolongation artificielle de la durée d'exécution) car il se pourrait alors qu'un attaquant soit en mesure de repérer les NOPs et de les considérer comme des indicateurs de « bourrage temporel », dont la durée d'exécution doit être déduite pour déterminer la vraie durée d'exécution.
Selon un mode de réalisation, on n'autorise certains modèles que pour les applets stockées dans un certain type de mémoire (par exemple en ROM). La mémoire ROM contient typiquement des applets fortement contrôlées car elles ont nécessairement été « chargées » lors d'une étape de masquage du composant ROM ce qui implique une connaissance de l'applet par les industriels chargés de fabriquer ce composant ROM, qui ont donc l'opportunité de vérifier sont contenu. Pour de nombreux types d'applets (et notamment pour les applets java), il est facile (et connu de l'état de l'art) d'obtenir le code source de l'applet même lorsque l'on ne dispose que de son code binaire (ce qui peut être le cas des industriels ci-dessus).
Selon un mode de réalisation, les modèles ROM ne sont pas valables pour les applets chargées dans des mémoires autres que la ROM, telles que des mémoires EEPROM ou FLASH, ou encore RAM protégée par batterie. Ceci est avantageux, car de telles mémoires (réinscriptibles) sont généralement beaucoup plus accessibles que la mémoire ROM et peuvent notamment être éventuellement manipulées par des attaquants afin d'y stocker des applets de caractérisation choisies (ce qui est impossible ou du moins peut être rendu impossible dans le cas de la mémoire ROM, grâce à un contrôle par les industriels précités et/ou par leurs clients et/ou prescripteurs).
Selon un mode de réalisation, les modèles sont différents selon les zones de mémoire. Par exemple, certains systèmes d'exploitation de dispositifs électroniques partitionnent les mémoires réinscriptibles (telles que l'EEPROM et la FLASH), en définissant au moins :
- une première zone accessible aux tiers pour charger des applets de façon contrôlée selon un premier niveau de protection, et
- une deuxième zone accessible au fabriquant du dispositif, pour charger des correctifs (« patchs », « softmasks », etc.) ou des applets (éventuellement des mises à jour d'applet), la deuxième zone étant généralement contrôlée selon un deuxième niveau de protection (souvent plus élevé que le premier niveau de protection).
Il peut y avoir des zones supplémentaires en plus des deux zones précitées. Le deuxième niveau de protection peut être déterminé et non modifiable, alors que le premier niveau de protection peut être modifiable. Ce premier niveau peut être modifiable par exemple par un opérateur de télécommunications (typiquement dans le cas de dispositif électroniques prenant la forme de cartes SIM), par une institution financière (typiquement dans le cas de cartes bancaires), ou encore par toute entité ayant acheté le dispositif électronique et l'ayant mis à disposition d'un utilisateur final.
Ainsi, en adaptant les modèles utilisés selon les types et/ou les zones de mémoire, il est encore plus difficile pour un attaquant de caractériser les instructions, car les applets de caractérisation éventuellement implémentées par l'attaquant ne sont pas pertinentes pour toutes les applets, et en particulier pour les applets stockées dans certains types de mémoires ou dans certaines zones mémoire réputées plus sensibles et non accessibles à l'attaquant. Ceci peut notamment concerner des applets système, telles que des applets offrant des fonctions d'authentification ou encore des fonctions de partage de justificatifs d'identité (« credentials » en anglais). Les fonctions d'authentification peuvent notamment comprendre une/des authentification(s) biométriques (vérification d'empreintes digitales par technique « match-on- card », vérification d'Iris, etc.), des vérifications de mots de passe, de codes PIN, etc. Les fonctions de partage de justificatifs d'identité peuvent comprendre par exemple des fonctions de partage de code PIN par une applet système permettant d'éviter à toutes les applets utilisateurs de chacune devoir demander un même code PIN à l'utilisateur, ce qui serait nuisible à la convivialité de l'utilisation du dispositif électronique (les utilisateurs sont typiquement agacés de devoir saisir plusieurs fois le même code secret), et serait même généralement nuisible à la sécurité. En effet chaque nouvelle saisie d'un code PIN peut faire l'objet d'une attaque (ingénierie sociale, par exemple personne observant la saisie du code PIN et le mémorisant, ou encore système d'espionnage de type « key logger » à savoir intercepteur de frappes clavier). De plus chaque nouvelle transmission d'un code PIN au dispositif électronique peut potentiellement faire l'objet d'une attaque.
Les modèles d'une même instruction sont activés alternativement suivant certaines règles définies pour la cible d'application. Par exemple, tous les modèles peuvent être activés d'une manière aléatoire, la règle pour une applet pouvant être déterminée selon le mécanisme défini dans la demande de brevet FR2903508 ("Protection d'un programme interprété par une machine virtuelle", déposée le 10 juillet 2006), c'est-à-dire qu'il est possible de prendre en compte un condensé de l'applet (par exemple le résultat d'une fonction SHA-1 appliquée au code binaire de l'applet), de façon faire varier les modèles de façon différente pour une même instruction selon qu'elle appartient à une applet ou à une autre.
Les modèles alternatifs peuvent être appliqués sur toutes les instructions ou un ensemble des instructions les plus critiques et/ou les plus appelées. On peut notamment cibler, par exemple, les instructions accédant à des mémoires de type NVRAM ou EEPROM, qui, étant fortement consommatrices d'électricité, sont souvent plus facilement détectables par analyse de consommation.
Selon un mode de réalisation, les effets engendrés par cette contre- mesure sont les suivants.
Dans le cas où un attaquant peut caractériser les modèles facilement avec des signaux bruts (cette situation peut arriver si le composant fuit beaucoup et qu'aucun bruit n'est ajouté, ou si le bruit est ajouté mais qu'il est facilement filtrable), l'utilisation des modèles alternatifs permet d'augmenter le nombre de modèles à déterminer par l'attaquant dans la phase de caractérisation et le nombre de candidats à identifier ('match' en anglais) dans la phase de détection. Par conséquent, la détection de modèles est rendue plus difficile.
Ainsi, on rend plus compliquée l'extraction de bruit que des attaquants peuvent tenter de mettre en œuvre afin de retrouver les modèles liés aux instructions.
Un attaquant pourrait être au courant de l'existence de modèles différents mis en œuvre par le dispositif électronique cible pour de mêmes instructions (selon le contexte dans lequel l'instruction est exécutée par le dispositif). Un tel attaquant peut alors chercher à prendre en compte cette caractéristique en tentant de déterminer la (ou les) règle(s) qui est (sont) utilisée(s) par le dispositif électronique cible pour choisir un modèle plutôt qu'un autre. Dans le cas où un attaquant ne peut pas caractériser les modèles avec des signaux bruts et où il est obligé d'enregistrer de nombreuses occurrences des signaux puis de moyenner ces signaux pour réduire le bruit :
• Si la (les) règle(s) de l'applet d'apprentissage utilisée par l'attaquant pour déterminer des modèles et la (les) règle(s) utilisée(s) par un dispositif électronique mettant en œuvre l'applet à attaquer ne sont pas identiques, les modèles d'une même instruction obtenus pendant deux phases distinctes sont typiquement différents. Par conséquent, les modèles obtenus pendant la phase de caractérisation ne peuvent pas être utilisés (car ils sont a priori faux) pour retrouver avec succès les instructions de l'applet à attaquer.
L'attaque en devient donc bien plus difficile.
• Si la ou les règles sont identiques pour l'applet d'apprentissage et l'applet à attaquer, mais si les différents codes utilisés pour chaque instruction sont déterminés d'une manière telle que les modèles associés à ces codes n'ont pas une durée identique et ne sont pas appelés au même moment, alors on peut s'attendre à ce que la contremesure selon ce mode de réalisation génère une gigue et engendre des désynchronisations. En moyennant les signaux, les modèles moyennés d'une même instruction dans les deux étapes (caractérisation et détection) ne sont donc pas identiques. Par conséquent, la détection devient plus difficile.
Selon un mode de réalisation, on ne protège que quelques instructions (les plus fréquentes, c'est-à-dire qui sont statistiquement appelées fréquemment par les applets) ce qui permet d'avoir un faible impact de performance (de l'ordre de quelques pour cents, c'est-à-dire que la rapidité d'exécution de l'applet peut être quasiment inchangée). Ainsi, le simple fait de ne changer qu'une seule instruction très fréquente (par exemple l'addition) en lui associant par exemple quatre codes possibles au lieu d'un seul, peut suffire à rendre une attaque beaucoup plus complexe, tout en ayant un impact très négligeable aussi bien sur le temps de développement (au stade de la conception de l'interpréteur, du dispositif, des applets, etc.) que sur les performances (l'applet sécurisée étant presque aussi rapide qu'une applet non protégée selon ce mode de réalisation).
Selon un mode de réalisation, les instructions les plus fréquentes sont : sload, sconst_0, baload, getfield_a_this, sstore, et c'est un sous ensemble de ces instructions (voire toutes ces instructions) que l'on protège.
Les interpréteurs (par exemple de type JCVM pour JavaCard Virtual
Machine) sont souvent des logiciels développés en langage C. Il est alors possible de modifier l'interpréteur dans ce langage, qui présente l'avantage d'une grande portabilité (il peut facilement être adapté d'un dispositif à un autre, qui posséderait par exemple un processeur de type différent).
Un mode de réalisation se limitant à protéger des instructions fréquentes est particulièrement avantageux, en particulier pour les produits ayant de fortes contraintes affectant les performances, telles qu'une faible capacité mémoire, un processeur lent, etc. Par exemple, les cartes à puces disposent de ressource de calcul et de stockage bien plus faibles que celles d'un ordinateur conventionnel, et ce mode de réalisation leur est particulièrement adapté.
Ne cibler que certaines instructions permet aussi d'éviter un long temps de développement et une taille importante de l'interpréteur. De plus, en faisant générer de la gigue par les instructions associées à différents codes (en utilisant des codes de durées d'exécution différentes), on perturbe également la génération et la détection des modèles des autres instructions qui n'ont qu'un seul modèle.
La figure 2 concerne une mise en œuvre de protection d'applet selon un mode de réalisation. Sur la figure 2, OPi désigne l'instruction numéro i (ayant pour op-code OPi). Ri désigne une règle de cet applet correspondant à l'instruction OPi. La règle Ri peut par exemple définir l'algorithme de sélection du code à exécuter pour l'instruction OPi. Il peut s'agir d'un algorithme pseudo aléatoire conventionnel, mais il peut également s'agir d'un algorithme qui, bien qu'aléatoire au sens où il n'est pas facilement prévisible, sélectionne les différents codes avec des probabilités inégales. OP.SEQi désigne l'étape d'exécution d'une instruction OPi dans la séquence d'instructions que constitue l'applet. Le code exécuté lors de OP.SEQi n'est pas toujours le même, il dépend d'une part de l'instruction OPi qui détermine la fonction qui doit être réalisée par le code, et par la règle Ri, qui détermine quel code (parmi tous les codes réalisant cette fonction) doit être exécuté.
Ainsi, une machine virtuelle selon le mode de réalisation représenté sur la figure 2 génère, à partir d'une applet représentée par une série d'instructions (OP1 , OP2, OP3, ...), à partir d'une série de règles (R1 , R2, R3, ...), et à partir d'une série d'ensembles de codes (Codes de ΓΟΡ1 , Codes de ΟΡ2, Codes de ΙΌΡ3, ...), chaque ensemble de codes étant associé à une instruction, une séquence d'exécution (OP.SEQ1 , OP.SEQ2, OP.SEQ3, ...) effectuant les tâches prévues dans l'applet, mais faisant appel à des codes choisis aléatoirement.
Bien entendu, la présente invention ne se limite pas à la forme de réalisation décrite ci-avant à titre d'exemple ; elle s'étend à d'autres variantes.
Ainsi, il a été décrit ci-avant un dispositif pouvant être une carte à puce. Cependant le dispositif mettant en œuvre l'invention peut également être, par exemple, un équipement mobile de communication, une étiquette d'identification sans contact, un lecteur d'étiquette d'identification sans contact, une carte à puce, un lecteur de telles cartes à puces, un système de contrôle d'accès, etc. Des types de cartes à puce pour lesquelles l'invention peut être avantageusement mise en œuvre peuvent être notamment des cartes à puces de santé, des cartes à puces d'identité ou de passeport, des cartes à puces bancaires, des cartes à puces de contrôle d'accès ou des cartes à puces supports de jeux électroniques.
Les applets protégeables ne se limitent pas aux applets JavaCard, mais peuvent être par exemple des applets .NET, ou encore des applets Multos.

Claims

REVENDICATIONS
1 . Dispositif électronique équipé d'une machine virtuelle pour exécuter une applet, la machine virtuelle étant agencée pour reconnaître les instructions de l'applet et exécuter un code correspondant à chaque instruction, caractérisé en ce que la machine virtuelle comprend un module d'association agencé pour associer plusieurs codes distincts mais fonctionnellement identiques à une même instruction, et un module de sélection agencé pour sélectionner le code à exécuter pour ladite instruction de manière aléatoire.
2. Dispositif selon la revendication 1 , dans lequel les différents codes associés à ladite instruction se distinguent par leur durée d'exécution par le dispositif.
3. Dispositif selon la revendication 1 ou 2, dans lequel les différents codes associés à ladite instruction se distinguent par la consommation électrique ou par le rayonnement électromagnétique qu'ils génèrent lors de leur exécution par le dispositif.
4. Dispositif selon l'une des revendications précédentes, dans lequel la machine virtuelle est agencée pour opérer la sélection aléatoire du code à exécuter pour ladite instruction en s'appuyant sur une mesure de caractéristique physique du dispositif.
5. Dispositif selon l'une des revendications précédentes, dans lequel, deux instructions étant associées chacune à plusieurs codes, l'un au moins des codes associés à la première instruction possède au moins une caractéristique commune avec l'un des codes associés à la deuxième instruction, les caractéristiques communes possibles étant la durée d'exécution du code par le dispositif, ainsi que la consommation électrique et le rayonnement électromagnétique générés lors d'une exécution du code par le dispositif.
6. Dispositif selon l'une des revendications précédentes, dans lequel la machine virtuelle est agencée pour identifier les instructions les plus fréquentes et pour n'utiliser plusieurs codes que pour lesdites instructions les plus fréquentes.
7. Dispositif selon la revendication 6, dans lequel les instructions les plus fréquentes comprennent l'une des instructions parmi les instructions d'addition, de soustraction, de multiplication, de modulo, et de ou exclusif.
8. Dispositif selon l'une des revendications 1 à 5, dans lequel la machine virtuelle est agencée pour identifier les instructions les plus sensibles et pour n'utiliser plusieurs codes que pour lesdites instructions les plus sensibles.
9. Dispositif selon la revendication 8, dans lequel les instructions les plus sensibles comprennent l'une des instructions parmi les instructions mettant en œuvre des algorithmes cryptographiques ainsi que les instructions de contrôle d'accès.
10. Procédé de sécurisation d'un dispositif électronique contre les attaques par canaux cachés, le dispositif électronique étant équipé d'une machine virtuelle reconnaissant les instructions d'une applet et exécutant un code correspondant à chaque instruction, caractérisé en ce que, une instruction étant associée à plusieurs codes distincts mais fonctionnellement identiques, la machine virtuelle sélectionne le code à exécuter pour ladite instruction de manière aléatoire.
1 1 . Procédé selon la revendication 10, dans lequel les différents codes associés à ladite instruction se distinguent par leur durée d'exécution par le dispositif.
12. Procédé selon la revendication 10 ou 1 1 , dans lequel les différents codes associés à ladite instruction se distinguent par la consommation électrique ou par le rayonnement électromagnétique qu'ils génèrent lors de leur exécution par le dispositif.
13. Procédé selon l'une des revendications 10 à 12, dans lequel la machine virtuelle opère la sélection du code à exécuter pour ladite instruction en s'appuyant sur une mesure de caractéristique physique du dispositif.
14. Procédé selon l'une des revendications 10 à 13, dans lequel, deux instructions étant associées chacune à plusieurs codes, l'un au moins des codes associés à la première instruction possède au moins une caractéristique commune avec l'un des codes associés à la deuxième instruction, les caractéristiques communes possibles étant la durée d'exécution du code par le dispositif, ainsi que la consommation électrique et le rayonnement électromagnétique générés lors d'une exécution du code par le dispositif.
15. Procédé selon l'une des revendications 10 à 14, dans lequel la machine virtuelle identifie les instructions les plus fréquentes et n'utilise plusieurs codes que pour lesdites instructions les plus fréquentes.
PCT/FR2011/053160 2010-12-24 2011-12-22 Protection des applets contre les analyses par canaux caches WO2012085482A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
RU2013134481/08A RU2603545C2 (ru) 2010-12-24 2011-12-22 Защита апплетов от анализа скрытых каналов
EP11815528.2A EP2656268A1 (fr) 2010-12-24 2011-12-22 Protection des applets contre les analyses par canaux caches
CN201180066192.0A CN103597490A (zh) 2010-12-24 2011-12-22 保护小应用程序免受隐藏信道分析
US13/997,136 US20130312110A1 (en) 2010-12-24 2011-12-22 Protection of applets against hidden-channel analyses

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1061252A FR2969787B1 (fr) 2010-12-24 2010-12-24 Protection des applets
FR1061252 2010-12-24

Publications (1)

Publication Number Publication Date
WO2012085482A1 true WO2012085482A1 (fr) 2012-06-28

Family

ID=44275914

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2011/053160 WO2012085482A1 (fr) 2010-12-24 2011-12-22 Protection des applets contre les analyses par canaux caches

Country Status (6)

Country Link
US (1) US20130312110A1 (fr)
EP (1) EP2656268A1 (fr)
CN (2) CN103597490A (fr)
FR (1) FR2969787B1 (fr)
RU (1) RU2603545C2 (fr)
WO (1) WO2012085482A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106919833A (zh) * 2015-12-28 2017-07-04 上海华虹集成电路有限责任公司 安全芯片中防止功耗泄露的方法

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2972064B1 (fr) * 2011-02-25 2013-03-15 Inside Secure Procede de cryptographie comprenant une operation d'exponentiation
US9607178B2 (en) 2014-03-20 2017-03-28 Qualcomm Incorporated Protection against key tampering
CN107506623B (zh) * 2017-08-15 2021-07-23 北京奇虎科技有限公司 应用程序的加固方法及装置、计算设备、计算机存储介质
US11308239B2 (en) * 2018-03-30 2022-04-19 Seagate Technology Llc Jitter attack protection circuit
RU2733083C1 (ru) * 2019-11-06 2020-09-29 Акционерное общество "Государственный Рязанский приборный завод" Способ автоматического управления средством активной защиты информации
CN111159660B (zh) * 2019-12-30 2022-07-15 龙芯中科技术股份有限公司 指令执行方法、处理器和电子设备

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002050641A1 (fr) * 2000-12-21 2002-06-27 Cp8 Technologies Procede de securisation d'un operateur logique ou mathematique dans un module electronique a microprocesseur

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5941957A (en) * 1997-10-06 1999-08-24 Ncr Corporation Dependable web page synchronization mechanism
US6681387B1 (en) * 1999-12-01 2004-01-20 Board Of Trustees Of The University Of Illinois Method and apparatus for instruction execution hot spot detection and monitoring in a data processing unit
GB2367651B (en) * 2000-10-05 2004-12-29 Advanced Risc Mach Ltd Hardware instruction translation within a processor pipeline
US7234139B1 (en) * 2000-11-24 2007-06-19 Catharon Productions, Inc. Computer multi-tasking via virtual threading using an interpreter
US9323955B2 (en) * 2000-12-21 2016-04-26 Gemalto Sa Method for protecting a logic or mathematical operator installed in an electronic module with a microprocessor as well as the associated embedded electronic module and the system
US20040249992A1 (en) * 2003-04-30 2004-12-09 Komarla Eshwari P. Methods and apparatus to provide environment-based instruction selection
US7996671B2 (en) * 2003-11-17 2011-08-09 Bluerisc Inc. Security of program executables and microprocessors based on compiler-architecture interaction
FR2903508B1 (fr) * 2006-07-10 2008-10-17 Sagem Defense Securite Protection d'un programme interprete par une machine virtuelle
CN101009554A (zh) * 2007-01-17 2007-08-01 华中科技大学 一种抗功耗攻击的字节替换电路
US8619972B2 (en) * 2007-08-17 2013-12-31 International Business Machines Corporation Method and system for atomicity for elliptic curve cryptosystems
CN102045158B (zh) * 2010-11-26 2012-07-04 中国科学院软件研究所 一种隐蔽信道标识方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002050641A1 (fr) * 2000-12-21 2002-06-27 Cp8 Technologies Procede de securisation d'un operateur logique ou mathematique dans un module electronique a microprocesseur

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106919833A (zh) * 2015-12-28 2017-07-04 上海华虹集成电路有限责任公司 安全芯片中防止功耗泄露的方法

Also Published As

Publication number Publication date
CN103597490A (zh) 2014-02-19
EP2656268A1 (fr) 2013-10-30
RU2603545C2 (ru) 2016-11-27
FR2969787A1 (fr) 2012-06-29
FR2969787B1 (fr) 2013-01-18
US20130312110A1 (en) 2013-11-21
RU2013134481A (ru) 2015-01-27
CN108171021A (zh) 2018-06-15

Similar Documents

Publication Publication Date Title
EP2656268A1 (fr) Protection des applets contre les analyses par canaux caches
EP1702268B1 (fr) Procede de controle d'integrite d'execution de programmes par verification d'empreintes de traces d'execution
FR2989504A1 (fr) Registre protege contre des attaques par injection de fautes
EP2038798B1 (fr) Protection d'un programme interprete par une machine virtuelle
EP2797018B1 (fr) Procede et systeme de simulation des effets d'une attaque sur un code informatique
El Farissi et al. Neural network vs. Bayesian network to detect Java card mutants
EP3284206B1 (fr) Procédé de sécurisation de l' exécution d'un programme
WO2004061622A2 (fr) Procede pour la securisation des systemes informatiques incorporant un module d'interpretation de code.
FR3069993A1 (fr) Dispositifs et procedes de masquage d'operations de chiffrement rsa
EP3295297B1 (fr) Procede de securisation d'une comparaison de donnees lors de l'execution d'un programme
EP1942428B1 (fr) Procédé de vérification de conformité d'une plateforme électronique et/ou d'un programme informatique présent sur cette plateforme, dispositif et programme d'ordinateur correspondants
CA2998780C (fr) Gestion d'un affichage d'une vue d'une application sur un ecran d'un dispositif electronique de saisie de donnees, procede, dispositif et produit programme d'ordinateur correspondants
FR2985337A1 (fr) Procede de calcul cryptographique resilient aux attaques par injection de fautes, produit programme d'ordinateur et composant electronique correspondant.
FR2831739A1 (fr) Procede de mise en oeuvre securisee d'un module fonctionnel, dans un composant electronique et composant correspondant
FR3137988A1 (fr) Procédé et circuit pour la vérification de l’intégrité d’un logiciel
FR2995110A1 (fr) Optimisation memoire cryptographique
EP3100403A1 (fr) Échelle de montgomery déséquilibrée
WO2008096076A2 (fr) Systemes electroniques securises, procedes de securisation et utilisations de tels systemes
WO2012172245A1 (fr) Transfert securise entre memoire non-volatile et memoire volatile
FR3116920A1 (fr) Procédé de traitement d’une opération impliquant des données secrètes, terminal, système et programme d’ordinateur correspondant
Thijssen et al. Side-channel attacks on the IRMA card
EP3242215A1 (fr) Procédé d'optimisation d'écritures en mémoire dans un dispositif
Di Natale Conception et test des circuits et systèmes numériques à haute fiabilité et sécurité
EP1589395A1 (fr) Microprocesseur comprenant des moyens de signature pour détecter une attaque par injection d'erreur
EP1698958A1 (fr) Procédé de sécurisation de l'ecriture en mémoire contre des attaques par rayonnement ou autres

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11815528

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13997136

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2011815528

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2013134481

Country of ref document: RU

Kind code of ref document: A