FR2849232A1 - 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 PDFInfo
- Publication number
- FR2849232A1 FR2849232A1 FR0216932A FR0216932A FR2849232A1 FR 2849232 A1 FR2849232 A1 FR 2849232A1 FR 0216932 A FR0216932 A FR 0216932A FR 0216932 A FR0216932 A FR 0216932A FR 2849232 A1 FR2849232 A1 FR 2849232A1
- Authority
- FR
- France
- Prior art keywords
- code
- codes
- derivation
- implementations
- introducing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
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
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
TRUSB0014Le 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
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 15 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 20 (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 25 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 30 é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 -2 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: 5 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", "J 2 ME", ), ces attaques peuvent être utilisées afin d'essayer d'obtenir des informations sur des secrets 10 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 20 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 -3 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 cidessus 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 oeuvre multiples" de 20 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 25 dérivation" consiste à introduire une (ou des) instruction(s) spécifique(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 30 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 -4 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 5 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 10 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 15 méthodes (typiquement de bibliothèques, dites A Pl "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 20 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 25 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 5 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 10 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 20 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é 25 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, -6 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 5 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 oeuvre le calcul sensible en question sans retenir son résultat. 10 Concernant la deuxième variante, le premier mode d'introduction de "mises en oeuvre 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 à 15 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 20 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 25 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 30 en oeuvre multiples" de certaines instructions consiste à inclure dans la mise en -7 oeuvre 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 surcot en terme de temps 5 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 15 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 20 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 25 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 oeuvre 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 30 alternatifs" à empreinte physique et durée variable consiste à proposer une pluralité de mises en oeuvre différentes de l'instruction et de conditionner le -8 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 10 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é 15 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 25 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 micro30 contrôleur ou micro-processeur. -9
Claims (15)
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 et/ou nécessitant une synchronisation avec le susdit code interprété, il consiste à introduire des variantes dans les temps d'exécution du codes interprété et de ses empreintes physiques mesurables. 10 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 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. 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 25 lors de la génération du susdit code.
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 30 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 et/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 l'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 oeuvre 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. 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 oeuvre d'instructions et en leur associant des mises en oeuvre d'autant plus 30 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 5 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 oeuvre pour une instruction donnée; les susdites instructions sont effectuées soit manuellement, par programmation, soit automatiquement lors 20 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 à 25 inclure dans la mise en oeuvre elle-même de l'instruction un branchement à une portion d'au moins un code alternatif à empreinte physique et durée variable qui détermine dynamiquement la mise en oeuvre à exécuter.
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 15 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 20 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.
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0216932A FR2849232B1 (fr) | 2002-12-24 | 2002-12-24 | Procede pour la securisation des systemes informatiques incorporant un module d'interpretation de code |
| 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 |
| 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. |
| US10/540,501 US20060048230A1 (en) | 2002-12-24 | 2003-12-18 | Method for securing computer systems incorporating a code interpretation module |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| 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 |
|---|---|
| FR2849232A1 true FR2849232A1 (fr) | 2004-06-25 |
| FR2849232B1 FR2849232B1 (fr) | 2005-02-25 |
Family
ID=32406555
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0216932A Expired - Fee Related FR2849232B1 (fr) | 2002-12-24 | 2002-12-24 | 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) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2009071352A1 (fr) * | 2007-12-07 | 2009-06-11 | Gemalto Sa | Procede de securisation de l'execution d'un code par masquages iteratifs |
Families Citing this family (7)
| 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 |
| 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 |
| US11556642B2 (en) | 2020-02-18 | 2023-01-17 | BluBracket, Inc. | Code monitoring and restricting of egress operations |
Citations (5)
| 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)
| 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 |
-
2002
- 2002-12-24 FR FR0216932A patent/FR2849232B1/fr not_active Expired - Fee Related
-
2003
- 2003-12-18 US US10/540,501 patent/US20060048230A1/en not_active Abandoned
- 2003-12-18 AU AU2003299355A patent/AU2003299355A1/en not_active Abandoned
- 2003-12-18 WO PCT/FR2003/003805 patent/WO2004061622A2/fr not_active Application Discontinuation
- 2003-12-18 EP EP03799637A patent/EP1576443A2/fr not_active Withdrawn
Patent Citations (5)
| 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 |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2009071352A1 (fr) * | 2007-12-07 | 2009-06-11 | Gemalto Sa | Procede de securisation de l'execution d'un code par masquages iteratifs |
| 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 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20060048230A1 (en) | 2006-03-02 |
| AU2003299355A1 (en) | 2004-07-29 |
| WO2004061622A2 (fr) | 2004-07-22 |
| WO2004061622A3 (fr) | 2004-11-11 |
| FR2849232B1 (fr) | 2005-02-25 |
| EP1576443A2 (fr) | 2005-09-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7797549B2 (en) | Secure method and system for biometric verification | |
| EP1596283B1 (fr) | Protection d'un branchement dans un programme | |
| US8332637B2 (en) | Methods and systems for nonce generation in a token | |
| EP2893431B1 (fr) | Protection contre canaux auxiliaires | |
| US7607122B2 (en) | Post build process to record stack and call tree information | |
| FR2849230A1 (fr) | Procede et dispositif de verification de l'integrite d'une application logicielle sans cle de chiffrement/dechiffrement | |
| FR2829331A1 (fr) | Procede de securisation d'une quantite secrete | |
| US8566609B2 (en) | Integrity of ciphered data | |
| FR2849232A1 (fr) | Procede pour la securisation des systemes informatiques incorporant un module d'interpretation de code | |
| FR2969787A1 (fr) | Protection des applets contre les analyses par canaux caches | |
| EP1316874B1 (fr) | Blocage du fonctionnement d'un circuit intégré | |
| EP1489517B1 (fr) | Protection d'un programme en attente d'exécution dans une mémoire utilisée par un microprocesseur | |
| EP1449067B1 (fr) | Securisation d'un generateur pseudo-aleatoire | |
| EP2336931B1 (fr) | Procédé de vérification de signature | |
| CN110535642A (zh) | 一种分散存储密钥的方法、智能终端及存储介质 | |
| EP1436792B1 (fr) | Protocole d'authentification a verification d'integrite de memoire | |
| CN112733126B (zh) | 一种产品许可认证方法和系统 | |
| EP1591866B1 (fr) | Contrôle de l'exécution d'un algorithme par un circuit intégré | |
| EP1470663B1 (fr) | Procede de generation et de verification de signatures electroniques | |
| FR3072477A1 (fr) | Securisation d’instructions de branchement conditionnel compose dans un programme informatique en code intermediaire | |
| JP2019519866A (ja) | 保護されていないハードウェアレジスタへの秘密データの安全なローディング | |
| FR3020888A1 (fr) | Chiffrement d'une cle de protection de secrets protegeant au moins un element sensible d'une application | |
| CN114117363A (zh) | 一种动态生成License验证方式的授权方法及存储介质 | |
| FR3120717A1 (fr) | Procédé d'exécution d'un code binaire d'un programme d'ordinateur par un microprocesseur | |
| FR2928754A1 (fr) | Carte a circuit integre ayant un programme d'exploitation modifiable et procede de modification correspondant |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20110831 |