FR2840428A1 - Procede securise de deploiement d'un programme informatique sur des supports d'informations distincts - Google Patents
Procede securise de deploiement d'un programme informatique sur des supports d'informations distincts Download PDFInfo
- Publication number
- FR2840428A1 FR2840428A1 FR0206592A FR0206592A FR2840428A1 FR 2840428 A1 FR2840428 A1 FR 2840428A1 FR 0206592 A FR0206592 A FR 0206592A FR 0206592 A FR0206592 A FR 0206592A FR 2840428 A1 FR2840428 A1 FR 2840428A1
- Authority
- FR
- France
- Prior art keywords
- program
- diversification
- version
- diversifying
- deploying
- 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
- 238000000034 method Methods 0.000 title claims abstract description 22
- 238000004590 computer program Methods 0.000 title description 7
- 230000006870 function Effects 0.000 claims description 11
- 230000015654 memory Effects 0.000 claims description 9
- 239000000969 carrier Substances 0.000 claims description 7
- 230000006399 behavior Effects 0.000 claims description 4
- 230000003936 working memory Effects 0.000 claims description 4
- 230000009466 transformation Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 230000005670 electromagnetic radiation Effects 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 230000004224 protection Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
-
- 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/121—Restricting unauthorised execution of programs
- G06F21/125—Restricting unauthorised execution of programs by manipulating the program code, e.g. source code, compiled code, interpreted code, machine code
-
- 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
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/355—Personalisation of cards for use
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Business, Economics & Management (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Accounting & Taxation (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Computer Networks & Wireless Communication (AREA)
- Microelectronics & Electronic Packaging (AREA)
- General Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Technology Law (AREA)
- Mathematical Physics (AREA)
- Storage Device Security (AREA)
Abstract
L'invention concerne un procédé sécurisé de déploiement d'un programme Po consistant à fournir N versions diversifiées (Po1, Po2, PoN) de ce programme Po et à charger des versions différentes sur des supports d'informations distincts (C1,..., CN) Avantageusement, la diversification est réalisée par un programme de compilation et un programme éditeur de liens (Ced) qui introduisent une ou plusieurs variantes à chaque opération de compilation. L'invention s'applique au déploiement sécurisé des programmes sur des supports d'informations distincts tels que des dispositifs portables de type cartes à puce.
Description
<Desc/Clms Page number 1>
PROCEDE SECURISE DE DEPLOIEMENT D'UN PROGRAMME INFORMATIQUE SUR DES SUPPORTS D'INFORMATIONS DISTINCTS.
L'invention concerne un procédé sécurisé de déploiement d'un programme informatique sur des supports d'informations distincts. Elle concerne également un procédé de diversification de programmes informatiques. L'invention s'applique à la sécurisation de dispositifs électroniques contenant un ou plusieurs programmes informatiques et plus particulièrement à la sécurisation des dispositifs portables de type cartes à puce.
Le problème posé concerne d'une manière générale la sécurité des programmes d'ordinateurs contre les attaques qui permettent d'extraire des informations sensibles lorsque ces programmes sont susceptibles de traiter des données confidentielles. Ce problème concerne en particulier la sécurité contre la fraude de dispositifs portables de type cartes à puce, lesquels sont par nature, utilisés pour stocker et exploiter des données secrètes.
On constate malheureusement que ces dispositifs sont sujets à de nombreuses attaques malveillantes de nature diverses. Ces attaques ont été répertoriées et analysées et leurs principes vont être rappelés cidessous :
Une première attaque dite side channel consiste à étudier la consommation électrique, la radiation électromagnétique ou toute autre modification de l'environnement du composant électronique lorsqu'il participe à l'exécution d'un programme informatique. A partir de l'observation de cette consommation, il devient possible de déduire l'instant de traitement des
Une première attaque dite side channel consiste à étudier la consommation électrique, la radiation électromagnétique ou toute autre modification de l'environnement du composant électronique lorsqu'il participe à l'exécution d'un programme informatique. A partir de l'observation de cette consommation, il devient possible de déduire l'instant de traitement des
<Desc/Clms Page number 2>
données confidentielles ainsi que les données ellesmemes.
Une deuxième attaque consiste à modifier l'environnement physique du composant électronique (température, lumière ...) de manière à modifier le déroulement normal du programme qui est exécuté; il est alors possible de déterminer puis d'intervenir au moment précis du traitement des données confidentielles. Par exemple, une influence physique externe au moment du traitement d'un code confidentiel peut amener le programme à accepter un mauvais code.
Une troisième attaque possible consiste en une intrusion physique au sein des composants électroniques afin d'espionner ou de modifier les informations qui transitent sur des bus de données par exemple. Il est ainsi possible de déterminer l'instant précis où les données confidentielles sont manipulées afin de les intercepter.
Pour lutter contre ces fraudes, les solutions de sécurité de l'art antérieur consistent à prévoir des protections et contre-mesures qui repoussent au maximum ces attaques.
Globalement les solutions connues à ce jour ont pour but de rajouter des obstacles logiques ou physiques à toute tentatives de fraude. En pratique, ces obstacles augmentent le temps nécessaire et la complexité pour décoder le déroulement du programme.
Malheureusement une fois que le déroulement du programme est connu, il est possible d'appliquer facilement cette connaissance sur tous les dispositifs contenant le même programme afin de récupérer les données confidentielles qu'ils peuvent détenir.
L'invention a donc pour but de remédier à ces inconvénients.
<Desc/Clms Page number 3>
Elle a pour objet un procédé sécurisé de déploiement d'un programme Po principalement caractérisé en ce qu'il consiste à fournir N versions diversifiées de ce programme Po et à charger des versions différentes sur des supports d'informations distincts.
Les différentes versions d'un même programme réalisent les mêmes fonctions essentielles, donnent le même résultat mais ont un comportement légèrement différent lors de leur exécution.
Avantageusement, les N versions différentes du programme Po sont obtenues de la manière suivante : le programme Po est écrit dans un langage quelconque, le programme est ensuite traduit N fois par un programme de diversification.
Selon un mode de réalisation, le programme de diversification est un programme de compilation et un programme éditeur de liens qui introduisent une ou plusieurs variantes à chaque opération de compilation.
Les supports prévus peuvent être X dispositifs portables de type cartes à puce, les N versions étant réparties sur les X dispositifs, X étant supérieur ou égal à N.
L'invention a également pour objet un procédé de diversification d'un programme Po principalement caractérisé en ce qu'il consiste à prévoir un programme de diversification apte à introduire des variantes dans le programme Po de manière à obtenir N versions différentes dudit programme.
Selon un mode de réalisation, le programme de diversification est réalisé par un programme compilateur et un programme éditeur de liens, la
<Desc/Clms Page number 4>
diversification se faisant durant la compilation et/ou l'édition de liens dudit programme Po.
Une première variante introduite durant la compilation et l'édition de liens consiste à modifier, d'une version à l'autre, les adresses des fonctions ou sous-programmes dudit programme Po, de la mémoire de programmes dans laquelle il sera enregistré.
Une deuxième variante introduite consiste à modifier, d'une version à l'autre, les adresses des registres tampons et des variables de la mémoire de travail.
Une troisième variante consiste à modifier au moins un paramètre dudit programme ou une instruction par une instruction équivalente, ou un sous-ensemble d'instructions par un autre sous-ensemble d'instructions fonctionnellement équivalent ou ajouter des opérations inutiles d'une version à l'autre dudit programme.
Le procédé de diversification d'un programme Po, est avantageusement utilisé pour la mise en #uvre du déploiement sécurisé dudit programme Po sur des supports d'informations distincts tels que des dispositifs portables de type cartes à puce.
L'invention concerne en outre un procédé de personnalisation de supports d'informations de type cartes à puce principalement caractérisé en ce qu'il consiste à utiliser le procédé de déploiement sécurisé d'un programme Po énoncé ci-dessus.
D'autres particularités et avantages de l'invention apparaîtront clairement dans la description suivante, présentée à titre d'exemple non limitatif en regard des figures annexées qui représentent :
<Desc/Clms Page number 5>
- la figure 1, un schéma classique illustrant la transformation classique d'un programme écrit en langage quelconque en un programme exécutable, - la figure 2, illustre le principe de la présente invention permettant d'avoir plusieurs versions d'un même programme, - la figure 3, illustre un premier exemple de diversification, - la figure 4, illustre un deuxième exemple de diversification, - la figure 5, illustre un troisième exemple de diversification.
- la figure 6, illustre le déploiement d'un programme sur des cartes à puces.
On rappelle pour mieux comprendre la suite qu'un programme principal Po écrit en langage de programmation fait l'objet d'une compilation réalisée par un programme de compilation pour pouvoir être compris par l'unité de traitement du dispositif support qui exécute le programme. Une unité de traitement comprend, et cela de manière classique, un processeur (ou microprocesseur ou microcontrôleur) et des mémoires volatiles et non volatiles. L'unité de traitement peut être installée soit dans un microordinateur soit dans tout autre dispositif électronique à base d'un microprocesseur.
Lorsque le programme principal Po fait appel à un ou plusieurs sous-programmes SP1, SP2, SP3, un autre programme appelé éditeur de liens ed, intègre les différents sous-programmes dans le programme principal Po compilé pour le rendre exécutable. Cette transformation est schématisée par le bloc Ced de la figure 1.
<Desc/Clms Page number 6>
Afin de simplifier la description qui va suivre on désignera par FI, F2, F3, des fonctions ou des sous programmes du programme principal Po.
Selon l'invention, il est donc proposé de déployer le programme Po sous différentes versions Pol, Po2, PoN de manière à assurer une sécurité contre la fraude.
La transformation réalisée est illustrée par le schéma de la figure 2.
Ce déploiement est réalisé par diversification du programme Po.
Plusieurs solutions de diversification vont être décrites dans la suite. Ces solutions peuvent être bien évidemment combinées c'est-à-dire qu'une même version présentera plusieurs variantes par rapport à une autre version. Ceci contribue à renforcer encore plus la sécurité apportée par la diversification.
Les N versions peuvent être obtenues bien entendu par une programmation individuelle de chacune d'elle ou au moyen d'un programme de diversification.
De façon avantageuse, il est prévu que cette diversification soit mise en #uvre par un programme compilateur réalisé à cet effet et/ ou par un programme éditeur de liens comme cela va être détaillé à travers les différents exemples donnés dans la suite.
Comme cela est illustré sur la figure 2, un programme Po unique écrit dans un langage quelconque (C par exemple), va donc pouvoir être fourni en N versions Pol, Po2..., PoN, grâce aux opérations de compilation et d'édition de liens Ced. Les différentes versions assurent les mêmes fonctions que le programme Po tout en présentant des caractéristiques différentes qui font que la connaissante du comportement d'un programme ne permettra pas d'en retirer des informations utiles pour une autre version de ce même programme.
<Desc/Clms Page number 7>
Une première solution proposée consiste à diversifier les adresses aux quelles se trouvent les fonctions ou sous-programmes nécessaires lors de l'exécution du programme Po, dans la mémoire de programme MP (mémoire électriquement programmable de type EEPROM ou Flash/EEPROM). Ces adresses sont donc modifiées par le compilateur (s'il s'agit de fonctions du programme) ou par l'éditeur de lien lorsqu'il s'agit de sous-programmes appelés. Cette solution est illustrée sur la figure 3.
On suppose, pour illustrer le propos que le programme Po fait appel aux trois fonctions et/ou sousprogrammes F1, F2, F3, tel que cela est illustré sur la figure 2. Ces fonctions se trouvent classiquement à des adresses fixées de la mémoire de programme MP . Grâce à la transformation opérée par le compilateur, les fonctions vont se trouver à des adresses distinctes sur chaque version du programme. Sur la version Pol, FI se trouve aux adresses adl-adp ; F2 se trouve aux adresses adr-ads et F3 se trouve aux adresses ads-adn. Sur la version Po2, F1 se trouve aux adresses ado-ad4, F2 se trouve aux adresses ad4-adp et F3 se trouve aux adresses adp-adq. Sur la version PoN, F1 se trouve aux adresses ado-ad4, F2 se trouve aux adresses adp-adq et F3 se trouve aux adresses adq-adr.
Une autre solution consiste à effectuer ce même type de diversification d'adresse mais cette fois ci pour la mémoire de travail MT (mémoire volatile RAM).
On rappelle que classiquement et à titre d'exemple, pour exécuter une opération arithmétique par exemple C=A+B, l'unité arithmétique et logique du dispositif support utilise deux registres RI et R2. Le compilateur charge la valeur A qui est à l'adresse AD1 de la mémoire de travail dans le registre R1 et charge la
<Desc/Clms Page number 8>
valeur B qui est à l'adresse AD2 de cette mémoire dans le registre R2. Le résultat C est stocké à l'adresse AD3 (les instructions de chargement et de transfert sont utilisées pour la mise en #uvre de cette opération.)
Selon l'invention, il peut être prévu que le chargement du contenu de ces deux registres se fasse à des adresses différentes pour chaque version de programme Po.
Selon l'invention, il peut être prévu que le chargement du contenu de ces deux registres se fasse à des adresses différentes pour chaque version de programme Po.
De manière plus générale, pour une instruction I donnée, l'adresse de chargement du contenu des registres peut être modifiée par le compilateur. Un exemple pratique est illustré sur la figure 4, pour la mise en #uvre de l'opération C=A+B.
Une autre solution consiste à réaliser une diversification des paramètres du programme ou des instructions elles-mêmes.
Plusieurs exemples vont illustrer cette solution dans la suite :
Il peut être prévu par exemple d'exécuter une instruction d'une manière différente sans rien changer au résultat soit en rajoutant des opérations inutiles soit en changeant une instruction par une instruction équivalente.
Il peut être prévu par exemple d'exécuter une instruction d'une manière différente sans rien changer au résultat soit en rajoutant des opérations inutiles soit en changeant une instruction par une instruction équivalente.
Par exemple, une opération arithmétique telle que A+B peut être modifiée par le compilateur en A+C+B-C.
Les valeurs de C seront différentes d'une version à l'autre.
Une opération de transfert A#B peut être modifiée en A#C#B.
Une opération conditionnelle : si A+B alors F sinon G, peut être modifiée par l'opération conditionnelle : si AB alors G sinon F.
<Desc/Clms Page number 9>
Ces différents exemples sont illustrés par le schéma de la figure 5.
Comme cela a été dit, l'invention s'applique tout particulièrement au déploiement de programmes contenant des données sensibles pour des dispositifs portables tels que les cartes à puce ou autres objets équivalents. Le ou les programmes déployés seront chargés en mémoire électriquement programmable de type EEPROM ou Flash/EEPROM.
Si un programme est modifié de manière à se trouver sous forme de 100 versions distinctes, ces 100 versions seront déployées de manière aléatoire pour équiper l'ensemble du parc de carte à puce prévu. Il est bien évident que si ce parc représente 1 million de cartes à puce distribuées sur tout un territoire géographique (qui peut être très étendu), des lots de cartes à puce posséderont une même version dudit programme. Cependant le nombre de carte à puce par lot sera insuffisant pour pouvoir retirer des caractéristiques intéressantes pour un fraudeur, d'autant plus que le déploiement géographique des cartes va empêcher pratiquement la reconstitution d'un même lot pour tout fraudeur.
La figure 6, illustre le déploiement des versions Pol, ...PoN, PoN+1 du programme Po sur des cartes à puce Cl,... CN, CN+1 .
Une version donnée d'un programme peut être chargée à tout moment dans une carte à puce, soit avant sa distribution aux organismes de personnalisation soit pendant la personnalisation soit après c'est-à-dire lorsqu'un utilisateur possède cette carte.
Les programmes pouvant faire l'objet d'une telle diversification peuvent être des programmes d'application mais aussi le programme du système d'exploitation (OS) du dispositif portable.
Claims (11)
1. Procédé de déploiement d'un programme Po, caractérisé en ce qu'il consiste à fournir N versions diversifiées de ce programme Po et à charger des versions différentes sur des supports d'informations distincts assurant ainsi une sécurité contre la fraude par analyse des caractéristiques dudit programme.
2. Procédé de déploiement d'un programme selon la revendication 1, caractérisé en ce que les N versions différentes du programme Po sont obtenues de la manière suivante : le programme Po est écrit dans un langage quelconque, le programme est ensuite traduit N fois par un programme de diversification.
3. Procédé de déploiement d'un programme selon la revendication 2, caractérisé en ce que le programme de diversification est un programme de compilation et un programme éditeur de liens qui introduisent une ou plusieurs variantes à chaque opération de compilation.
4. Procédé de déploiement d'un programme selon l'une quelconque des revendications précédentes, caractérisé en ce que les supports prévus sont X dispositifs portables de type cartes à puce, les N versions étant réparties sur les X dispositifs, X étant supérieur ou égal à N.
5. Procédé de diversification d'un programme Po, caractérisé en ce qu'il consiste à prévoir un programme de diversification apte à introduire des variantes dans
<Desc/Clms Page number 11>
le programme Po de manière à obtenir N versions différentes de ce programme Po, assurant les mêmes fonctions que celui-ci tout en ayant des caractéristiques de comportement différentes, la connaissance du comportement d' une version de programme ne permettant pas de retirer des informations utiles pour une autre version.
6. Procédé de diversification d'un programme Po selon la revendication 5, caractérisé en ce que le programme de diversification est réalisé par un programme compilateur et un programme éditeur de liens, la diversification se faisant durant la compilation et/ou l'édition de liens dudit programme Po.
7. Procédé de diversification d'un programme Po selon la revendication 5 ou 6, caractérisé en ce qu'une première variante introduite durant la compilation et l'édition de liens consiste à modifier, d'une version à l'autre, les adresses de chargement des fonctions ou sous-programmes dudit programme Po, de la mémoire de programmes dans laquelle il sera enregistré.
8. Procédé de diversification d'un programme Po, selon les revendications 5,6 ou 7, caractérisé en ce qu'une deuxième variante introduite consiste à modifier, d'une version à l'autre, les adresses des registres tampons et des variables de la mémoire de travail utilisée pendant l'exécution dudit programme Po.
9. Procédé de diversification d'un programme Po, selon l'une quelconque des revendications 5 à 8, caractérisé qu'une troisième variante consiste à
<Desc/Clms Page number 12>
modifier au moins un paramètre dudit programme ou une instruction par une instruction équivalente, ou un sous-ensemble d'instructions par un autre sous-ensemble d'instructions fonctionnellement équivalent ou ajouter des opérations inutiles d'une version à l'autre dudit programme.
10. Procédé de diversification d'un programme Po, selon l'une quelconque des revendications 5 à 9, caractérisé en ce qu'il est mis en #uvre pour réaliser un déploiement dudit programme Po sur des supports d'informations distincts tels que des dispositifs portables de type cartes à puce et assurer ainsi une sécurité contre la fraude par analyse des caractéristiques dudit programme.
11. Procédé de personnalisation de supports d'informations de type cartes à puce, caractérisé en ce qu'il comprend le chargement d'un programme Po, ce chargement étant mis en #uvre le procédé de déploiement selon la revendication 1.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0206592A FR2840428B1 (fr) | 2002-05-30 | 2002-05-30 | Procede securise de deploiement d'un programme informatique sur des supports d'informations distincts |
| AU2003253057A AU2003253057A1 (en) | 2002-05-30 | 2003-05-28 | Secured method for deploying a computer programme on discrete data supports |
| PCT/FR2003/001627 WO2003102883A1 (fr) | 2002-05-30 | 2003-05-28 | Procede securise de deploiement d'un programme informatique sur des supports d'informations distincts |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0206592A FR2840428B1 (fr) | 2002-05-30 | 2002-05-30 | Procede securise de deploiement d'un programme informatique sur des supports d'informations distincts |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2840428A1 true FR2840428A1 (fr) | 2003-12-05 |
| FR2840428B1 FR2840428B1 (fr) | 2004-08-20 |
Family
ID=29558825
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0206592A Expired - Lifetime FR2840428B1 (fr) | 2002-05-30 | 2002-05-30 | Procede securise de deploiement d'un programme informatique sur des supports d'informations distincts |
Country Status (3)
| Country | Link |
|---|---|
| AU (1) | AU2003253057A1 (fr) |
| FR (1) | FR2840428B1 (fr) |
| WO (1) | WO2003102883A1 (fr) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2980600B1 (fr) * | 2011-09-23 | 2013-10-25 | Oberthur Technologies | Procede et systeme de securisation d'une application logicielle comprenant une instruction conditionnelle basee sur une variable booleenne |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1996028795A1 (fr) * | 1995-03-10 | 1996-09-19 | Siemens Aktiengesellschaft | Carte a puce avec systeme d'exploitation protege |
| US5559884A (en) * | 1994-06-30 | 1996-09-24 | Microsoft Corporation | Method and system for generating and auditing a signature for a computer program |
| FR2809847A1 (fr) * | 2000-06-06 | 2001-12-07 | Gemplus Card Int | Procede de personnalisation electrique de carte a puce |
-
2002
- 2002-05-30 FR FR0206592A patent/FR2840428B1/fr not_active Expired - Lifetime
-
2003
- 2003-05-28 WO PCT/FR2003/001627 patent/WO2003102883A1/fr not_active Application Discontinuation
- 2003-05-28 AU AU2003253057A patent/AU2003253057A1/en not_active Abandoned
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5559884A (en) * | 1994-06-30 | 1996-09-24 | Microsoft Corporation | Method and system for generating and auditing a signature for a computer program |
| WO1996028795A1 (fr) * | 1995-03-10 | 1996-09-19 | Siemens Aktiengesellschaft | Carte a puce avec systeme d'exploitation protege |
| FR2809847A1 (fr) * | 2000-06-06 | 2001-12-07 | Gemplus Card Int | Procede de personnalisation electrique de carte a puce |
Non-Patent Citations (1)
| Title |
|---|
| COHEN F B: "OPERATING SYSTEM PROTECTION THROUGH PROGRAM EVOLUTION", COMPUTERS & SECURITY. INTERNATIONAL JOURNAL DEVOTED TO THE STUDY OF TECHNICAL AND FINANCIAL ASPECTS OF COMPUTER SECURITY, ELSEVIER SCIENCE PUBLISHERS. AMSTERDAM, NL, vol. 12, no. 6, 1 October 1993 (1993-10-01), pages 565 - 584, XP000415701, ISSN: 0167-4048 * |
Also Published As
| Publication number | Publication date |
|---|---|
| AU2003253057A1 (en) | 2003-12-19 |
| FR2840428B1 (fr) | 2004-08-20 |
| WO2003102883A1 (fr) | 2003-12-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0475837B1 (fr) | Procédé de gestion d'un programme d'application chargé dans un support à microcircuit | |
| FR2681165A1 (fr) | Procede de transmission d'information confidentielle entre deux cartes a puces. | |
| FR2667171A1 (fr) | Support portable a micro-circuit facilement programmable et procede de programmation de ce micro-circuit. | |
| EP0720098B1 (fr) | Dispositif de sécurisation de systèmes d'information organisés autour de microprocesseurs | |
| EP1960934B1 (fr) | Procede pour securiser l'execution d'un code logiciel en langage intermediaire dans un appareil portatif | |
| FR2888960A1 (fr) | Detection d'une faute par perturbation longue | |
| FR2872309A1 (fr) | Procede de gestion d'une carte a puce multi-applicative | |
| FR2840428A1 (fr) | Procede securise de deploiement d'un programme informatique sur des supports d'informations distincts | |
| FR2823330A1 (fr) | Procede et systeme de gestion de donnees destinees a etre stockees dans une memoire, par exemple du code d'une application charge dans une carte a puce programmable | |
| FR2889005A1 (fr) | Integrite materielle permanente des donnees | |
| FR2824648A1 (fr) | Procede de protection d'un circuit logique contre des attaques exterieures, et unite logique contenant un circuit logique a proteger contre des attaques exterieures | |
| FR2786901A1 (fr) | Dispositif et procede d'initialisation d'un programme applicatif d'une carte a circuit integre | |
| EP2901291B1 (fr) | Procédé de gestion des ressources mémoire d'un dispositif de sécurité, tel qu'une carte à puce, et dispositif de sécurité mettant en oeuvre ledit procédé. | |
| EP2912640A1 (fr) | Procede de gestion d'identifiants dans une carte a circuit integre et carte a circuit integre correspondante | |
| EP3470999B1 (fr) | Sécurisation d'instructions de branchement conditionnel composé dans un programme informatique en code intermédiaire | |
| FR2689662A1 (fr) | Procédé de protection d'une carte à puce contre la perte d'information. | |
| FR2974919A1 (fr) | Protection d'une memoire volatile contre des virus par changement d'instructions | |
| EP3350745B1 (fr) | Gestion d'un affichage d'une vue d'une application sur un écran d'un dispositif électronique de saisie de données, procédé, dispositif et produit programme d'ordinateur correspondants | |
| 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 | |
| FR2888369A1 (fr) | Protection contre les attaques par generation de fautes sur les instructions de saut | |
| FR3056787A1 (fr) | Methode de protection d’un programme logiciel par offuscation par virtualisation | |
| FR2890485A1 (fr) | Circuit integre ayant une memoire de donnees protegee contre l'effacement uv | |
| WO2005050343A2 (fr) | Procede pour l'amelioration de l'efficacite et de la consommation memoire d'un systeme informatique | |
| WO2003071733A1 (fr) | Procede de generation de cles securisees pour un algorithme cryptographique | |
| EP3242215A1 (fr) | Procédé d'optimisation d'écritures en mémoire dans un dispositif |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| CD | Change of name or company name | ||
| TP | Transmission of property | ||
| PLFP | Fee payment |
Year of fee payment: 15 |
|
| PLFP | Fee payment |
Year of fee payment: 16 |
|
| PLFP | Fee payment |
Year of fee payment: 17 |
|
| PLFP | Fee payment |
Year of fee payment: 18 |
|
| PLFP | Fee payment |
Year of fee payment: 19 |
|
| PLFP | Fee payment |
Year of fee payment: 20 |