WO2004061622A2 - Procede pour la securisation des systemes informatiques incorporant un module d'interpretation de code. - Google Patents

Procede pour la securisation des systemes informatiques incorporant un module d'interpretation de code. Download PDF

Info

Publication number
WO2004061622A2
WO2004061622A2 PCT/FR2003/003805 FR0303805W WO2004061622A2 WO 2004061622 A2 WO2004061622 A2 WO 2004061622A2 FR 0303805 W FR0303805 W FR 0303805W WO 2004061622 A2 WO2004061622 A2 WO 2004061622A2
Authority
WO
WIPO (PCT)
Prior art keywords
code
derivation
codes
implementations
physical
Prior art date
Application number
PCT/FR2003/003805
Other languages
English (en)
Other versions
WO2004061622A3 (fr
Inventor
Patrice Hameau
Daniel Le Metayer
Original Assignee
Trusted Logic
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 Trusted Logic filed Critical Trusted Logic
Priority to AU2003299355A priority Critical patent/AU2003299355A1/en
Priority to EP03799637A priority patent/EP1576443A2/fr
Priority to US10/540,501 priority patent/US20060048230A1/en
Publication of WO2004061622A2 publication Critical patent/WO2004061622A2/fr
Publication of WO2004061622A3 publication Critical patent/WO2004061622A3/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/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

  • the present invention relates to securing computer systems comprising at least one code interpretation module and memory storage capacities for the code to be interpreted.
  • code interpretation module a code being defined as a structured set of instructions
  • interpreter hardware interpreter: microcontroller, microprocessor or software: virtual machine
  • memory storage capacities of the code to be interpreted or "interpreted code”
  • Said code can be written directly by a programmer, be obtained automatically (what will be called “code generation”) from a "source code” in a language which is generally of a higher level or even result a combination of automatic production and manual intervention.
  • the invention therefore more particularly aims to eliminate these drawbacks.
  • this method essentially involves two types of variants in the execution times of the interpreted codes, in the following manner:
  • this method will make the apparently executed code different on each execution, and will therefore make it more difficult to discover the actual code of the application.
  • This process may involve: • for the first variant:
  • the first mode of introducing "derivation codes” consists of introducing a specific instruction (s), called “derivation” (s) in certain particular places of the code.
  • This introduction can be done either manually or automatically during code generation.
  • the code generator can be guided, to produce these instructions, by annotations inserted by the programmer in the source code and making it possible to designate sensitive portions of code (for example, and in a nonlimiting manner, procedures of encryption or verification of access rights).
  • the execution of a derivation instruction by the interpreter causes a connection to an associated derivation code.
  • This first method can also be improved by attaching different levels of security to the bypass instructions and by associating them with bypass codes that are all the more complex (or defensive against security attacks described above) as their level of security is high.
  • the second mode of introducing "derivation codes” consists in introducing the derivation code into the implementation of the interpreter itself: between the execution of two consecutive instructions of the code, the interpreter executes the derivation code, either systematically, selectively or randomly. It can for example execute this code only when calling certain sensitive methods (typically from libraries, called API "Application Program Interface").
  • the advantage of the first mode is that it makes it possible to selectively introduce derivative code executions, which leads to less penalty in terms of execution time if the number of such derivations is small. It also allows the implementation of so-called “discretionary" security policies, that is to say at the discretion of the applications.
  • the second mode will be more advantageous if the number of derivations desired is significant since the implementation of the method in the interpreter itself can then be optimized. Furthermore, it allows the implementation of security policies called "proxies" where controls are imposed uniformly on all applications.
  • the two preceding methods of introduction require the introduction of a derivation code.
  • the invention provides four modes for achieving these bypass codes so that they introduce variations in execution times and measurable physical footprints.
  • the first embodiment of "derivation codes" with physical footprint and variable duration consists in performing a so-called “superfluous” calculation depending on data known at runtime (which can therefore differ on each runtime). This superfluous calculation must have no effect on the final result of the execution of the interpreter.
  • a simple example of such a calculation is a parity test of dynamic data (known at runtime) which can lead either to an empty action, or to the addition of an element from a stack followed by its immediate removal .
  • the number of possible actions is not necessarily limited to two. A large number of possible actions will lead to significant variability in the execution time and the physical footprint of the derivation code.
  • the second embodiment of "derivation codes” improves the first mode by providing it with a random drawing of additional data during the execution of the superfluous calculation, said additional data being used in the calculation carried out by the code of derivation (for example in a test of said code).
  • This random draw adds a new variable element and makes the execution time and the physical footprint of the derivation code even less predictable.
  • the third embodiment of "derivation codes” improves the efficiency of the two previous ones by replacing the test allowing the decision of the next action by a connection in a so-called indirection table, that is to say containing the addresses of possible actions, to an index calculated from variable elements (dynamic data and / or result of a random draw).
  • the fourth embodiment of "derivation codes” improves the first mode (and therefore the other three) by considering a superfluous calculation which, while remaining without effect on the final result, presents the external characteristics (physical imprint) of a particular sensitive calculation (for example encryption or decryption) unrelated to the actual code of the application.
  • a superfluous calculation makes it possible to deceive an attacker who would try to deduce secrets by measuring the physical effect of the execution of the application.
  • Such a process can be qualified as "software decoy” since its purpose is to mislead attackers by making them believe in the presence of said sensitive calculation in the effective code of the application. This mode can be carried out simply by implementing the sensitive calculation in question without retaining its result.
  • the first mode of introducing "multiple implementations" of certain instructions consists in enriching all of the instructions recognized by the interpreter with a plurality of implementations for a given instruction. These implementations will be carried out so as to have different physical fingerprints and execution times while producing an identical result. Any of these implementations can be used interchangeably in the code. This use can be done either manually, by programming, or automatically during code generation. In the latter case, the code generator can be guided, to produce these instructions, by annotations inserted by the programmer in the source code and making it possible to designate sensitive portions of code (for example, and without limitation, procedures encryption or verification of access rights).
  • This first mode can also be improved by attaching different levels of security to the implementations of instructions and by associating them with implementations which are all the more complex (or defensive with respect to security attacks) as their level of security. is high.
  • the second method of introducing "multiple implementations" of certain instructions consists in including in the implementation the instruction itself implements a connection to a portion of alternative code which will dynamically determine the implementation to be executed.
  • the advantage of the first mode is to minimize the additional cost in terms of execution time since the choice of the implementation of the instruction to be applied is determined before execution. It also allows the implementation of so-called “discretionary" security policies, that is to say at the discretion of the applications.
  • the advantage of the second mode is to further complicate attacks requiring synchronization with the code since two consecutive executions of the same instruction (at the same location in the code) will be likely to take different execution times and offer fingerprints different physical. Furthermore, this second mode allows the implementation of security policies called "proxies" where controls are imposed uniformly on all applications.
  • an implementation can include a multiplicity of implementations for a given instruction, some of them (or all) being implemented by connecting to a portion of alternative code dynamically determining the implementation to execute.
  • the above second mode of the second variant requires the introduction of an alternative code associated with an instruction.
  • the invention proposes three modes for producing this alternative code so that it introduces different implementations into the execution times and the physical footprint measured.
  • the first embodiment of "alternative codes" with physical footprint and variable duration consists in proposing a plurality of different implementations of the instruction and in conditioning the choice of the version executed in a dynamic test, that is to say dependent on data known at runtime.
  • a simple example of such a calculation is a parity test of dynamic data (known at runtime).
  • a large number of implementations will lead to significant variability in the execution time and in the physical footprint of the alternative code.
  • the second embodiment of "alternative codes" improves the first mode by providing it with a random drawing of a data item which is then used for carrying out the test leading to the dynamic choice of the version executed. This random draw adds a new variable element and makes the execution time and the physical footprint of the alternative code even less predictable.
  • the third embodiment of "alternative codes” improves the efficiency of the two preceding ones by replacing the test making it possible to decide on the version chosen by a connection in an indirection table (containing the addresses of the versions available) to an index calculated at from variable elements (dynamic data and / or result of a random draw).

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • Devices For Executing Special Programs (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)

Abstract

Le procédé selon l'invention concerne la sécurisation des systèmes informatiques comportant au moins un module d'interprétation de code et des capacités mémoire de stockage du code à interpréter. Elle propose à cet effet de rendre plus difficiles les attaques reposant sur des mesures physiques et/ou nécessitant une synchronisation avec le code interprété en introduisant des variantes dans les temps d'exécution des codes interprétés et les empreintes physiques mesurables.

Description

PROCEDE POUR LA SECURISATION DES SYSTEMES INFORMATIQUES INCORPORANT UN MODULE D'INTERPRETATION DE CODE.
La présente invention concerne la sécurisation des systèmes informatiques comportant au moins un module d'interprétation de code et des capacités mémoire de stockage du code à interpréter.
Elle a plus particulièrement pour objet de résoudre les problèmes de sécurisation des systèmes informatiques comportant au moins un module d'interprétation de code (un code étant défini comme un ensemble structuré d'instructions) qu'on appellera simplement "interpréteur" par la suite (interpréteur matériel : micro-contrôleur, micro-processeur ou logiciel : machine virtuelle) et des capacités mémoire de stockage du code à interpréter (ou "code interprété").
Ledit code peut être écrit directement par un programmeur, être obtenu de manière automatique (ce qu'on appellera la "génération de code") à partir d'un "code source" dans un langage qui est généralement de plus haut niveau ou encore résulter d'une combinaison de production automatique et d'interventions manuelles.
D'une façon générale, on sait que la plupart des attaques recensées contre de tels systèmes informatiques reposent sur des mesures physiques (émission électromagnétique, etc.) lors de l'exécution et nécessitent la synchronisation avec le code interprété. En d'autres termes, il est nécessaire à l'intrus de déterminer à quel moment l'interpréteur se trouve en train d'exécuter certaines fonctionnalités du code. Parmi ces techniques les plus connues, on peut citer celles développées pour retrouver une clé dans des algorithmes cryptographiques par espionnage passif de l'émission physique d'un circuit : les attaques de type SPA ("Simple Power Analysis") et DPA ("Differential Power Analysis") en particulier ont été utilisées avec succès pour découvrir des clés DES ("Data Encryption Standard"). A titre d'exemple, sur une plateforme Java embarquée ("Java Card", "JEFF", "J2ME", ... ), ces attaques peuvent être utilisées afin d'essayer d'obtenir des informations sur des secrets manipulés par la machine virtuelle Java. Ces secrets peuvent concerner aussi bien les données confidentielles que le code Java lui-même.
L'invention a donc plus particulièrement pour but de supprimer ces inconvénients.
Elle propose, à cet effet, de rendre plus difficiles les attaques reposant sur des mesures physiques et/ou nécessitant une synchronisation avec le code interprété en introduisant des variantes dans les temps d'exécution des codes interprétés et les empreintes physiques (par exemple, et de manière non exclusive, émission électromagnétique, etc.) mesurables.
Selon l'invention, ce procédé fait intervenir essentiellement deux types de variantes dans les temps d'exécution des codes interprétés, de la manière suivante :
- en provoquant à certains endroits d'un code interprété des dérivations vers de nouvelles portions de code (qui n'appartiennent pas au code d'origine) destinées à compliquer la synchronisation et l'empreinte physique de l'exécution, ou - en proposant une pluralité de mises en oeuvre de certaines instructions, chacune réclamant un temps d'exécution différent et/ou présentant une empreinte physique différente et fournissant un résultat identique, en faisant en sorte que deux exécutions de cette instruction au sein d'un même code puissent être réalisées par deux mises en oeuvre différentes.
Ainsi, en introduisant des distorsions dans les temps d'exécution et en modifiant l'effet physique de l'exécution, les deux types de variantes ci-dessus rendront plus difficile toute tentative de corrélation entre les manifestations physiques observées d'un code interprété et ses fonctionnalités.
Avantageusement, ce procédé permettra de rendre le code apparemment exécuté différent à chaque exécution, et rendra donc plus difficile la découverte du code réel de l'application.
Ce procédé pourra faire intervenir : • pour la première variante :
- deux modes d'introduction de "codes de dérivation",
- quatre modes de réalisation de "codes de dérivation", • pour la deuxième variante :
- deux modes d'introduction de "mises en œuvre multiples" de certaines instructions,
- trois modes de réalisation de "codes alternatifs" à empreinte physique et durée variable.
Concernant la première variante, le premier mode d'introduction de "codes de dérivation" consiste à introduire une (ou des) instruction(s) spécifιque(s), dite(s) "de dérivation" à certains endroits particuliers du code. Cette introduction peut être réalisée soit manuellement, soit automatiquement lors de la génération de code. Dans le dernier cas, le générateur de code peut être guidé, pour produire ces instructions, par des annotations insérées par le programmeur dans le code source et permettant de désigner des portions de code sensibles (par exemple, et de manière non limitative, des procédures de chiffrement ou de vérification de droits d'accès). L'exécution d'une instruction de dérivation par l'interpréteur provoque un branchement vers un code de dérivation associé. Ce premier procédé peut également être amélioré en attachant différents niveaux de sécurité aux instructions de dérivation et en leur associant des codes de dérivation d'autant plus complexes (ou défensifs vis à vis d'attaques de sécurité décrites ci-dessus) que leur niveau de sécurité est élevé.
Concernant la première variante, le deuxième mode d'introduction de "codes de dérivation" consiste à introduire le code de dérivation dans la mise en oeuvre de l'interpréteur lui-même: entre l'exécution de deux instructions consécutives du code, l'interpréteur exécute le code de dérivation, soit de manière systématique, soit de manière sélective, soit de manière aléatoire. Il peut par exemple exécuter ce code seulement lors de l'appel de certaines méthodes (typiquement de bibliothèques, dites API "Application Program Interface") sensibles.
L'avantage du premier mode est de permettre d'introduire les exécutions de code de dérivation de manière sélective, ce qui conduit à une moindre pénalisation en terme de temps d'exécution si le nombre de telles dérivations est faible. Il permet également la mise en oeuvre de politiques de sécurité dites "discrétionnaires", c'est à dire à la discrétion des applications.
En revanche, le second mode sera plus avantageux si le nombre de dérivations souhaitées est important car la mise en oeuvre du procédé dans l'interpréteur lui-même pourra alors être optimisée. Par ailleurs, il permet la mise en oeuvre de politiques de sécurité dites "mandataires" où les contrôles sont imposés de manière uniforme à toutes les applications.
Les deux précédents susdits modes d'introduction nécessitent l'introduction d'un code de dérivation. L'invention propose quatre modes pour réaliser ces codes de dérivation de manière à ce qu'ils introduisent des variantes dans les temps d'exécution et les empreintes physiques mesurables.
Concernant la première variante, le premier mode de réalisation de "codes de dérivation" à empreinte physique et durée variable consiste à effectuer un calcul dit "superflu" dépendant de données connues à l'exécution (qui peuvent donc différer à chaque exécution). Ce calcul superflu doit être sans effet sur le résultat final de l'exécution de l'interpréteur. Un exemple simple de tel calcul est un test de parité d'une donnée dynamique (connue à l'exécution) qui peut conduire soit à une action vide, soit à l'ajout d'un élément d'une pile suivi de son retrait immédiat. Il est à noter que le nombre d'actions possibles n'est pas forcément limité à deux. Un nombre d'actions possible important conduira à une variabilité importante dans le temps d'exécution et l'empreinte physique du code de dérivation.
Le deuxième mode de réalisation de "codes de dérivation" améliore le premier mode en le dotant d'un tirage aléatoire d'une donnée supplémentaire lors de l'exécution du calcul superflu, ladite donnée supplémentaire étant utilisée dans le calcul effectué par le code de dérivation (par exemple dans un test dudit code). Ce tirage aléatoire ajoute un nouvel élément variable et rend encore moins prévisible le temps d'exécution et l'empreinte physique du code de dérivation.
Le troisième mode de réalisation de "codes de dérivation" améliore l'efficacité des deux précédents en remplaçant le test permettant de décider de l'action suivante par un branchement dans un tableau dit d'indirection, c'est-à-dire contenant les adresses des actions possibles, à un indice calculé à partir des éléments variables (donnée dynamique et/ou résultat d'un tirage aléatoire).
Le quatrième mode de réalisation de "codes de dérivation" améliore le premier mode (et par conséquent les trois autres) en considérant un calcul superflu qui, tout en restant sans effet sur le résultat final, présente les caractéristiques externes (empreinte physique) d'un calcul sensible particulier (par exemple chiffrage ou déchiffrage) sans rapport avec le code effectif de l'application. Un tel calcul superflu permet de tromper un attaquant qui tenterait de déduire des secrets en mesurant l'effet physique de l'exécution de l'application. Un tel procédé peut être qualifié de "leurre logiciel" puisqu'il a pour objet d'induire en erreur les attaquants en leur faisant croire à la présence dudit calcul sensible dans le code effectif de l'application. Ce mode peut être réalisé simplement en mettant en œuvre le calcul sensible en question sans retenir son résultat.
Concernant la deuxième variante, le premier mode d'introduction de "mises en œuvre multiples" de certaines instructions consiste à enrichir l'ensemble des instructions reconnues par l'interpréteur avec une pluralité de mises en oeuvre pour une instruction donnée. Ces mises en oeuvre seront réalisées de façon à avoir des empreintes physiques et des temps d'exécution différents tout en produisant un résultat identique. N'importe laquelle de ces mises en oeuvre peut être utilisée indifféremment dans le code. Cette utilisation peut être effectuée soit manuellement, par programmation, soit automatiquement lors de la génération de code. Dans ce dernier cas, le générateur de code peut être guidé, pour produire ces instructions, par des annotations insérées par le programmeur dans le code source et permettant de désigner des portions de code sensibles (par exemple, et de manière non limitative, des procédures de chiffrement ou de vérification de droits d'accès). Ce premier mode peut également être amélioré en attachant différents niveaux de sécurité aux mises en oeuvre d'instructions et en leur associant des mises en oeuvre d'autant plus complexes (ou défensives vis à vis d'attaques de sécurité) que leur niveau de sécurité est élevé.
Concernant la deuxième variante, le deuxième mode d'introduction de "mises en œuvre multiples" de certaines instructions consiste à inclure dans la mise en œuvre elle-même de l'instruction un branchement à une portion de code alternatif qui déterminera dynamiquement la mise en oeuvre à exécuter.
L'avantage du premier mode est de minimiser le surcoût en terme de temps d'exécution puisque le choix de la mise en oeuvre d'instruction à appliquer est déterminé préalablement à l'exécution. Il permet également la mise en oeuvre de politiques de sécurité dites "discrétionnaires", c'est à dire à la discrétion des applications.
L'avantage du second mode est de compliquer encore les attaques nécessitant une synchronisation avec le code puisque deux exécutions consécutives de la même instruction (au même emplacement dans le code) seront susceptibles de prendre des temps d'exécution différents et d'offrir des empreintes physiques différentes. Par ailleurs, ce second mode permet la mise en oeuvre de politiques de sécurité dites "mandataires" où les contrôles sont imposés de manière uniforme à toutes les applications.
Les deux modes ne s'excluent pas mutuellement : une réalisation peut inclure une multiplicité de mises en oeuvre pour une instruction donnée, certaines d'entre elles (ou toutes) étant mises en oeuvre par un branchement à une portion de code alternatif déterminant dynamiquement la mise en oeuvre à exécuter.
Le susdit deuxième mode de la deuxième variante nécessite l'introduction d'un code alternatif associé à une instruction. L'invention propose trois modes pour réaliser ce code alternatif de manière à ce qu'il introduise des mises en œuvre différentes dans les temps d'exécution et l'empreinte physique mesurée.
Concernant la deuxième variante, le premier mode de réalisation de "codes alternatifs" à empreinte physique et durée variable consiste à proposer une pluralité de mises en oeuvre différentes de l'instruction et de conditionner le choix de la version exécutée à un test dynamique, c'est à dire dépendant de données connues à l'exécution. Un exemple simple de tel calcul est un test de parité d'une donnée dynamique (connue à l'exécution). Un nombre de mises en oeuvre important conduira à une variabilité importante dans le temps d'exécution et dans l'empreinte physique du code alternatif.
Le deuxième mode de réalisation de "codes alternatifs" améliore le premier mode en le dotant d'un tirage aléatoire d'une donnée qui est ensuite utilisée pour la réalisation du test conduisant au choix dynamique de la version exécutée. Ce tirage aléatoire ajoute un nouvel élément variable et rend encore moins prévisibles le temps d'exécution et l'empreinte physique du code alternatif.
Le troisième mode de réalisation de "codes alternatifs" améliore l'efficacité des deux précédents en remplaçant le test permettant de décider de la version choisie par un branchement dans un tableau d'indirection (contenant les adresses des versions disponibles) à un indice calculé à partir des éléments variables (donnée dynamique et/ou résultat d'un tirage aléatoire).
Ainsi, l'introduction de variantes dans les temps d'exécution des codes interprétés et donc les empreintes physiques permet de rendre plus difficiles les attaques reposant sur les dites empreintes physiques, en faisant en sorte qu'une action codée dans l'implémentation de l'application puisse avoir des signatures électroniques différentes et se produisant à des temps d'exécution variables.
L'implémentation des susdits codes interprétés sera effectuée sur des modules d'interprétation de code logiciel comme des machines virtuelles de la famille JAVA, et sur des modules d'interprétation de code physique du type micro- contrôleur ou micro-processeur.

Claims

REVENDICATIONS
1. Procédé de sécurisation des systèmes informatiques comprenant au moins un module d'interprétation de code et des capacités mémoire de stockage du code interprété présentant des empreintes physiques mesurables, caractérisé en ce que dans le but de rendre plus difficiles les attaques reposant sur des mesures physiques ou nécessitant une synchronisation avec le susdit code interprété, il consiste à introduire des variantes d'exécution du code interprété, lesdites variantes ayant un effet sur les temps d'exécution du code interprété ou ses empreintes physiques mesurables.
2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend des dérivations vers de nouvelles portions de code, dits "codes de dérivation", qui n'appartiennent pas au code d'origine.
3. Procédé selon la revendication 1, caractérisé en ce qu'il comprend une pluralité de mises en œuvre de certaines instructions, chacune réclamant un temps d'exécution différent ou présentant une empreinte physique différente tout en fournissant un résultat identique.
4. Procédé selon la revendication 2, caractérisé en ce qu'il comprend un premier mode d'introduction de "codes de dérivation" consistant à introduire une (ou des) instruction(s) spécifique(s) à certains endroits particuliers du code, soit manuellement soit automatiquement lors de la génération du susdit code.
5. Procédé selon la revendication 4, caractérisé en ce que les instructions de dérivation sont associées à des niveaux de sécurité qui correspondent à des degrés de complexité de leur code de dérivation, les plus complexes étant considérés comme les plus défensifs vis à vis d'attaques de sécurité nécessitant une synchronisation avec le code ou une mesure de son empreinte physique.
6. Procédé selon la revendication 2, caractérisé en ce qu'il comprend un deuxième mode d'introduction de "codes de dérivation" consistant à introduire le code de dérivation dans la mise en oeuvre de interpréteur lui-même.
7. Procédé selon la revendication 6, caractérisé en ce que le code de dérivation introduit dans la mise en œuvre de l'interpréteur est exécuté soit de manière systématique par l'interpréteur, soit de manière sélective, soit de manière aléatoire.
8. Procédé selon la revendication 2, caractérisé en ce qu'il comprend un premier mode de réalisation de "codes de dérivation" consistant à effectuer un calcul dit "superflu" dépendant de données connues à l'exécution.
9. Procédé selon la revendication 2, caractérisé en ce qu'il comprend un deuxième mode de réalisation de "codes de dérivation" consistant à doter le susdit premier mode d'un tirage aléatoire d'une donnée supplémentaire lors de l'exécution du calcul superflu, ladite donnée supplémentaire étant utilisée dans le calcul effectué par le code de dérivation.
10. Procédé selon la revendication 8, caractérisé en ce que le susdit premier mode de réalisation de "codes de dérivation" est amélioré en attachant différents niveaux de sécurité aux mises en œuvre d'instructions et en leur associant des mises en œuvre d'autant plus complexes.
11. Procédé selon la revendication 2, caractérisé en ce qu'il comprend un troisième mode de réalisation de "codes de dérivation" consistant à remplacer dans les susdits premier et deuxième mode le test permettant de décider de l'action suivante par un branchement dans un tableau d'indirection contenant les adresses des actions possibles à un indice calculé à partir des éléments variables (donnée dynamique et/ou résultat d'un tirage aléatoire).
12. Procédé selon la revendication 2, caractérisé en ce qu'il comprend un quatrième mode de réalisation de "codes de dérivation" consistant à effectuer un calcul superflu présentant les caractéristiques externes d'un calcul sensible particulier.
13. Procédé selon la revendication 3, caractérisé en ce qu'il comprend un premier mode d'introduction d'une pluralité de mises en oeuvre de certaines instructions consistant à enrichir l'ensemble des instructions reconnues par l'interpréteur avec une pluralité de mises en œuvre pour une instruction donnée ; les susdites instructions sont effectuées soit manuellement, par programmation, soit automatiquement lors de la génération du code.
14. Procédé selon la revendication 3, caractérisé en ce qu'il comprend un deuxième mode d'introduction de la susdite pluralité de mises en oeuvre de certaines instructions consistant à inclure dans la mise en œuvre elle-même de l'instruction un branchement à une portion d'au moins un code alternatif à empreinte physique ou durée variable qui détermine dynamiquement la mise en oeuvre à exécuter.
15. Procédé selon la revendication 14, caractérisé en ce qu'il comprend un premier mode de réalisation du susdit code alternatif consistant à proposer une pluralité de mises en oeuvre différentes de l'instruction et en conditionnant le choix de la version exécutée à un test dynamique, c'est à dire dépendant de données connues à l'exécution.
16. Procédé selon la revendication 14, caractérisé en ce qu'il comprend un deuxième mode de réalisation du susdit code alternatif consistant à améliorer le susdit premier mode de réalisation de "codes alternatifs" en le dotant d'un tirage aléatoire pour la réalisation du test conduisant au choix dynamique de la version exécutée.
17. Procédé selon la revendication 14, caractérisé en ce qu'il comprend un troisième mode de réalisation du susdit code alternatif consistant à améliorer les susdits premier et deuxième modes de réalisation de "codes alternatifs" consistant à remplacer le test permettant de décider de la version choisie par un branchement dans un tableau d'indirection contenant les adresses des versions disponibles à un indice calculé à partir des éléments variables.
18. Procédé selon la revendication 1, caractérisé en ce qu'il est implémenté sur un module d'interprétation de code logiciel dit machine virtuelle.
19. Procédé selon la revendication 18, caractérisé en ce que ladite machine virtuelle est une plateforme Java.
20. Procédé selon la revendication 1, caractérisé en ce qu'il est implémenté sur un module d'interprétation de code physique.
21. Procédé selon la revendication 1 , caractérisé en ce qu'il est implémenté sur un système embarqué et sur un module d'interprétation du type micro-contrôleur ou micro-processeur.
PCT/FR2003/003805 2002-12-24 2003-12-18 Procede pour la securisation des systemes informatiques incorporant un module d'interpretation de code. WO2004061622A2 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
AU2003299355A AU2003299355A1 (en) 2002-12-24 2003-12-18 Method of securing computer systems comprising a code interpretation module
EP03799637A EP1576443A2 (fr) 2002-12-24 2003-12-18 Procede pour la securisation des systemes informatiques incorporant un module d interpretation de code
US10/540,501 US20060048230A1 (en) 2002-12-24 2003-12-18 Method for securing computer systems incorporating a code interpretation module

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR02/16932 2002-12-24
FR0216932A FR2849232B1 (fr) 2002-12-24 2002-12-24 Procede pour la securisation des systemes informatiques incorporant un module d'interpretation de code

Publications (2)

Publication Number Publication Date
WO2004061622A2 true WO2004061622A2 (fr) 2004-07-22
WO2004061622A3 WO2004061622A3 (fr) 2004-11-11

Family

ID=32406555

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2003/003805 WO2004061622A2 (fr) 2002-12-24 2003-12-18 Procede pour la securisation des systemes informatiques incorporant un module d'interpretation de code.

Country Status (5)

Country Link
US (1) US20060048230A1 (fr)
EP (1) EP1576443A2 (fr)
AU (1) AU2003299355A1 (fr)
FR (1) FR2849232B1 (fr)
WO (1) WO2004061622A2 (fr)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2327911A1 (fr) * 2000-12-08 2002-06-08 Cloakware Corporation Fonctions logicielles d'obscurcissement
US20070226795A1 (en) * 2006-02-09 2007-09-27 Texas Instruments Incorporated Virtual cores and hardware-supported hypervisor integrated circuits, systems, methods and processes of manufacture
US20080091975A1 (en) * 2006-10-17 2008-04-17 Konstantin Kladko Method and system for side-channel testing a computing device and for improving resistance of a computing device to side-channel attacks
EP2071483A1 (fr) * 2007-12-07 2009-06-17 Gemplus Procédé de sécurisation de l'éxécution d'un code par masquage itératifs
FR2935823B1 (fr) * 2008-09-11 2010-10-01 Oberthur Technologies Procede et dispositif de protection d'un microcircuit contre les attaques.
ITTO20111229A1 (it) * 2011-12-29 2013-06-30 Milano Politecnico Procedimento e sistema per proteggere dispositivi elettronici, relativo prodotto informatico
US10063569B2 (en) * 2015-03-24 2018-08-28 Intel Corporation Custom protection against side channel attacks
US11550943B2 (en) 2020-02-18 2023-01-10 BluBracket, Inc. Monitoring code provenance

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0448262A2 (fr) * 1990-03-20 1991-09-25 General Instrument Corporation Of Delaware Evitement de la détermination du temps d'exécution d'une routine prédéterminée en relation avec l'occurrence d'un événement externe observable au préalable
WO1999001815A1 (fr) * 1997-06-09 1999-01-14 Intertrust, Incorporated Techniques d'obscurcissement pour augmenter la securite de logiciels
WO1999064973A1 (fr) * 1998-06-10 1999-12-16 Auckland Uniservices Limited Techniques de marquage de logiciel avec un filigrane
US6334189B1 (en) * 1997-12-05 2001-12-25 Jamama, Llc Use of pseudocode to protect software from unauthorized use
WO2002001334A2 (fr) * 2000-06-27 2002-01-03 Microsoft Corporation Système et procédé pour interfacer une configuration logicielle destinée à sécuriser des organes d'archivage

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5249294A (en) * 1990-03-20 1993-09-28 General Instrument Corporation Determination of time of execution of predetermined data processing routing in relation to occurrence of prior externally observable event
US7587044B2 (en) * 1998-01-02 2009-09-08 Cryptography Research, Inc. Differential power analysis method and apparatus
FR2785422B1 (fr) * 1998-10-29 2000-12-15 Schlumberger Ind Sa Dispositif et procede pour la securisation d'un circuit integre
US7092523B2 (en) * 1999-01-11 2006-08-15 Certicom Corp. Method and apparatus for minimizing differential power attacks on processors
GB2365153A (en) * 2000-01-28 2002-02-13 Simon William Moore Microprocessor resistant to power analysis with an alarm state
US6625737B1 (en) * 2000-09-20 2003-09-23 Mips Technologies Inc. System for prediction and control of power consumption in digital system
GB0023699D0 (en) * 2000-09-27 2000-11-08 Univ Bristol Executing a combined instruction
DE10101956A1 (de) * 2001-01-17 2002-07-25 Infineon Technologies Ag Verfahren zur Erhöhung der Sicherheit einer CPU
US7194633B2 (en) * 2001-11-14 2007-03-20 International Business Machines Corporation Device and method with reduced information leakage
FR2832824A1 (fr) * 2001-11-28 2003-05-30 St Microelectronics Sa Blocage du fonctionnement d'un circuit integre
US7124445B2 (en) * 2002-06-21 2006-10-17 Pace Anti-Piracy, Inc. Protecting software from unauthorized use by converting source code modules to byte codes
US7150003B2 (en) * 2002-11-25 2006-12-12 Matsushita Electric Industrial Co., Ltd. Class coalescence for obfuscation of object-oriented software

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0448262A2 (fr) * 1990-03-20 1991-09-25 General Instrument Corporation Of Delaware Evitement de la détermination du temps d'exécution d'une routine prédéterminée en relation avec l'occurrence d'un événement externe observable au préalable
WO1999001815A1 (fr) * 1997-06-09 1999-01-14 Intertrust, Incorporated Techniques d'obscurcissement pour augmenter la securite de logiciels
US6334189B1 (en) * 1997-12-05 2001-12-25 Jamama, Llc Use of pseudocode to protect software from unauthorized use
WO1999064973A1 (fr) * 1998-06-10 1999-12-16 Auckland Uniservices Limited Techniques de marquage de logiciel avec un filigrane
WO2002001334A2 (fr) * 2000-06-27 2002-01-03 Microsoft Corporation Système et procédé pour interfacer une configuration logicielle destinée à sécuriser des organes d'archivage

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1576443A2 *

Also Published As

Publication number Publication date
WO2004061622A3 (fr) 2004-11-11
US20060048230A1 (en) 2006-03-02
AU2003299355A1 (en) 2004-07-29
EP1576443A2 (fr) 2005-09-21
FR2849232A1 (fr) 2004-06-25
FR2849232B1 (fr) 2005-02-25

Similar Documents

Publication Publication Date Title
EP1596283B1 (fr) Protection d'un branchement dans un programme
EP2614458B1 (fr) Procede d'authentification pour l'acces a un site web
FR2849230A1 (fr) Procede et dispositif de verification de l'integrite d'une application logicielle sans cle de chiffrement/dechiffrement
WO2003003169A2 (fr) Procede et systeme de verification biometrique fiables
WO2009092903A2 (fr) Procede et dispositifs de protection d'un microcircuit contre des attaques visant a decouvrir une donnee secrete
FR2885709A1 (fr) Controle d'integrite d'une memoire externe a un processeur
EP1774484A1 (fr) Enregistrement d'une cle dans un circuit integre
EP3033857B1 (fr) Authentification de code binaire
US8566609B2 (en) Integrity of ciphered data
EP1983436B1 (fr) Contrôle d'intégrité d'une mémoire externe à un processeur
FR2969787A1 (fr) Protection des applets contre les analyses par canaux caches
WO2004061622A2 (fr) Procede pour la securisation des systemes informatiques incorporant un module d'interpretation de code.
FR3055444A1 (fr) Dispositif et procedes de commande de dispositif de cryptage sur courbe elliptique securises
EP1449067B1 (fr) Securisation d'un generateur pseudo-aleatoire
FR2974207A1 (fr) Procede et systeme de securisation d'un logiciel
EP2336931B1 (fr) Procédé de vérification de signature
EP1436792B1 (fr) Protocole d'authentification a verification d'integrite de memoire
EP1591866B1 (fr) Contrôle de l'exécution d'un algorithme par un circuit intégré
FR2867929A1 (fr) Procede d'authentification dynamique de programmes par un objet portable electronique
EP1470663B1 (fr) Procede de generation et de verification de signatures electroniques
EP4057169B1 (fr) Procédé d'exécution d'un code binaire d'un programme d'ordinateur par un microprocesseur
FR3137988A1 (fr) Procédé et circuit pour la vérification de l’intégrité d’un logiciel
FR2831739A1 (fr) Procede de mise en oeuvre securisee d'un module fonctionnel, dans un composant electronique et composant correspondant
FR3020888A1 (fr) Chiffrement d'une cle de protection de secrets protegeant au moins un element sensible d'une application
FR2976697A1 (fr) Transfert securise entre memoire non-volatile et memoire volatile

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

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

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2003799637

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2006048230

Country of ref document: US

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 10540501

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2823/DELNP/2005

Country of ref document: IN

WWP Wipo information: published in national office

Ref document number: 2003799637

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 10540501

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Ref document number: JP