WO2011000722A1 - Procédé de validation distante d'un code exécutable - Google Patents

Procédé de validation distante d'un code exécutable Download PDF

Info

Publication number
WO2011000722A1
WO2011000722A1 PCT/EP2010/058673 EP2010058673W WO2011000722A1 WO 2011000722 A1 WO2011000722 A1 WO 2011000722A1 EP 2010058673 W EP2010058673 W EP 2010058673W WO 2011000722 A1 WO2011000722 A1 WO 2011000722A1
Authority
WO
WIPO (PCT)
Prior art keywords
control program
integrity
code
computer
hpc
Prior art date
Application number
PCT/EP2010/058673
Other languages
English (en)
Inventor
Jacques Fournier
Pierre Girard
Original Assignee
Gemalto Sa
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 Gemalto Sa filed Critical Gemalto Sa
Priority to EP10726074A priority Critical patent/EP2449495A1/fr
Publication of WO2011000722A1 publication Critical patent/WO2011000722A1/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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability

Definitions

  • the invention relates to a method for remote validation of an executable code.
  • the invention relates in particular to remote and secure execution of a computer code.
  • Intelligent Keys have the particularity of having a memory, an electronic intelligence, and access to a secure electronic module.
  • executable computer code one or more software
  • This particular code is commonly called CDROM because in most cases, this code is stored as an 'ISO' image on a 'Read Only' partition that emulates a CD-ROM that will be seen as such (ie in the manner of a "compact disc") by the host electronic device (the computer).
  • the computer detects, recognizes and activates it.
  • the activation phase involves, among other things, mounting on the operating system the different 'discs' presented by the Intelligent Key including the one containing the CD-ROM. Once activated, the Smart Key then sends the contents of the CDROM to the computer running the content.
  • This technology can transport executable code, potentially large, on a non-fixed media, and this through a USB communication interface widely deployed on computers. Indeed, the compact disk, and its subsequent generations can transport such a computer code, but in a static manner.
  • Intelligent Keys offer the possibility to upgrade this computer code, but also a whole set of features related to embedded intelligence and secure electronic module. These features can for example be related to security.
  • these devices make it possible to execute computer applications on a device (called an execution device) with the least possible support for the software resources of this execution device. Most often, only the operating system will be exploited to execute the computer code contained in the smart key.
  • the first solution happens to be unrealistic given the size of the executable code. Indeed, the verification of the integrity of such a computer code, with the electronic resources of an electronic device such as an intelligent key, takes a time incompatible with any usability.
  • the second solution assumes the verification of the integrity of the executable code on the resources of the execution device.
  • smart keys can execute computer code in insecure environments. To entrust the verification of the integrity of the code on the resources of such a device is problematic because it It is not possible to trust the result of such an analysis.
  • the present invention proposes to solve these drawbacks, and thus to guarantee the integrity of the executable code, with performances totally acceptable to the user, without delegating security to the execution device.
  • the present invention is a method for securing the remote execution of an executable computer code, comprising at least one electronic device ST, able to communicate with at least one electronic device HPC, and a secure electronic device SC, the electronic device ST comprising a mass memory in which executable computer code is stored, access to a second executable computer code called a control program, and a communication controller capable of managing the data exchanges with the HPC and SC devices, the computer code executable AP being intended to be executed by the HPC device, this method comprises at least the steps of:
  • control program can for example be recorded in a non-memory volatile of said device SC, or in a non-volatile memory of said device ST.
  • integrity values may have been associated with all or part of the executable code AP.
  • integrity values may have been associated with all or part of the control program.
  • Integrity values can, for example, be Checksums.
  • the verification step of the control program may, for example, be performed by the SC device (13), or by the controller of the device ST.
  • control program may only allow the loading and verify the integrity, only portions of the AP code to execute.
  • control program may allow loading and verify the integrity of the AP code in successive portions.
  • control program may allow the loading of the entire AP code and then check the integrity of the entire AP code.
  • the device SC can be integrated in said device ST, or be integrated in the HPC device, or be an independent electronic device.
  • FIG. 2 represents a mode of implementation of the invention in which the integrity of the control program is guaranteed by its hosting in the secure electronic device SC (13).
  • FIG. 3 represents a mode of implementation of the invention in which the integrity of the control program is validated by the smart key.
  • FIG. 4 represents an embodiment of the invention in which the integrity of the control program is validated by the secure electronic device SC (13).
  • Smart keys often use the USB communication protocol, as shown in Figure 1. This allows them to be easily connected to an individual computer such as Computer 2 in Figure 1, and recognized by it (through software low-level commonly called “drivers” that are present in the majority of operating systems).
  • the most advanced keys contain a security module 3 such as a smart card.
  • controller 6 in the smart keys.
  • This controller illustrated by the box 6 of Figure 1, implies the presence in the key intelligent 1 of at least one computing component
  • microprocessor a working memory (volatile memory), and a non-volatile memory (eg EEPROM, Flash, or ROM).
  • working memory volatile memory
  • non-volatile memory eg EEPROM, Flash, or ROM
  • the key includes a nonvolatile memory 4, called mass memory, which contains executable computer code 5 which we will call "application” in the remainder of this document.
  • the key When connecting the key 1 to the computer 2, the key receives the energy necessary to start it. Therefore, the controller 6 enters into communication with the computer 2.
  • the controller initiates a communication session, this passes, among other things, by identifying the key by its type of electronic device (mass storage unit, multimedia device, etc.).
  • the controller 6 of the key 1 sends the application 5 to the computer 2 which executes it 7.
  • This computer system makes it possible, among other things, the execution of an application 5 on a computer 2 not having it not.
  • the use of the security module 3 allows to restrict the use of the application 5 with the most advanced cryptographic tools. For example, it is possible to associate, with any invasive command for the application, authentication delegated to the security module (for example through the use of a personal code ("PIN code" in English). But nothing protects the computer or its user from a malicious or corrupt application, we are here in the context where the application would have been corrupted, for example by a malicious act or a computer virus.
  • the use of the key 1 can have serious consequences for the resources available to the computer 2 (for example network services, online payment application, etc.), but also for the user who thinks use a reliable application.
  • Figure 2 provides an implementation of the invention that solves this problem.
  • FIG. 2 shows an intelligent key 11, containing a secure module 13, a controller 17, a mass memory 15 itself containing an application 16, connected to a computer 12.
  • This smart key 11 also contains an additional program 14 called a control program.
  • control program 14 will guarantee the integrity of the application 16.
  • the control program 14 is hosted in the smart card 13, itself embedded in the key 11.
  • the fact that the control program is thus kept safe in the secure module 13 guaranteed its integrity. Indeed, the control program thus stored can not be modified from outside the secure module 13, because of the nature of the secure module.
  • the controller informs the computer that it has a program to execute. This can be done by presenting the program as a CDROM. Unlike the prior art, it is not the application 16, but the control program 14 that the controller has the computer 12 execute.
  • control program 14 is integrity. Once executed by the computer 12, it is the only software component of the computer in which the key 11 can fully trust.
  • the system now enters another phase, phase in which the control program will, from the computer 12, load the application 16 present in the mass memory of the key 11.
  • the control program can now check the integrity of the application 16, using the electronic resources of the computer 12.
  • control program can load them at the same time as it loads the application itself.
  • a preferred solution is to record the integrity values in the secure module 13.
  • the control program establishes a connection with the secure module before downloading the application to obtain these integrity values. This communication is generally done through the controller of the key 11 itself.
  • control program In the case where the security module 13 is not integrated in the key 11, the control program must establish a connection with this module before loading the application 16.
  • a solution may also lie in the insertion of the security values in the same code of the control program. Thus, during its execution, the control program already has the integrity values.
  • this integrity value may be a hash of the application code 16, generated from a hash function.
  • a hash function is a function, which, to an element is capable of associating a fingerprint (also called hash) retaining 3 essential characteristics:
  • SHA-I Secure Hash Algorithm 1: 160-bit
  • SHA-2 SHA-256, SHA-384 or SHA-512-bit choice
  • control program 18 contains a means of checking these values. In the majority of cases this implies that the code of the control program contains the necessary algorithm.
  • control program must be able to obtain the integrity values, if necessary, and use them to verify that the application 16 is the one from which these integrity values were generated.
  • the control program authorizes its execution 19 on the computer 12. If the verification of the integrity of the application 16 concludes that the application is not integrates, we will talk about failure of verification. This failure can be due to several parameters: it can be linked to a real alteration of the application 16, but also to an error by example in communications between the computer and the key.
  • control program in case of failure of the verification of the integrity of the application 16, the control program takes note of this failure (for example by updating a counter), and starts over again. loading operation. Several consecutive failures can result in a pure and simple refusal of the execution of the application 16 on the computer 12. In order to guarantee the durability of this information, the control program may record a verification failure in the key 11, even in the secure module 13.
  • control program may cause a reaction at the key 11 or even the secure module 13.
  • reactions may for example consist of a neutralization of all or part of these devices, for example by erasing data.
  • Verification of the integrity of the application 16 can be done at once or in several times. Indeed, in the case where the application 16 is for example very large, or for example in the case where the communication between the key 11 and the computer 12 is limited, it may be wise to load the application 16 by parts, and to independently verify those parts.
  • FIG. 3 illustrates an embodiment of the invention in which the control program 28 is stored in the mass memory 26, with the application 27.
  • the controller 29 obtains, from the secure module 23, at least one integrity value for verifying the integrity of the control program 24. Once the integrity of the control program is ensured, it is loaded and executed on the computer as illustrated in Figure 2.
  • the controller 29 in the case where verification of the integrity of the control program fails, the controller 29 does not propose its loading to the computer.
  • This implementation of the invention involves, in a preliminary step, the creation of integrity values related to the control program, and stored in the security module 23.
  • a variant of implementation of the previous case consists in delegating the verification of the security. integrity of the control program 45 to the security module 43, which has the integrity values related to the control program 45.
  • the mechanisms described above for generating the integrity values related to the application 16, apply mutatis mutandis, the generation of the integrity values related to the control program 23 and 45 as well as the mechanisms described for managing application integrity check failures 16 shall apply mutatis mutandis to the verification of the integrity of the application. the integrity of the control program 23 and 45.
  • the invention applies advantageously to the case where the control program is on an electronic device third party.
  • the controller establishes a communication session with this device to to obtain the control program, and to implement the following process according to the invention.
  • the integrity values related to the control program can also be loaded from a remote electronic slide. This embodiment makes it possible to entrust the management of the control program to a trusted third party.

Abstract

La présente invention propose un procédé de vérification de l'intégrité d'une application informatique stockée sur un dispositif intelligent, et destiné à être exécutée sur un second dispositif. L' invention consiste en l' envoi d'un programme de contrôle dont l'intégrité est garantie, au second dispositif, et ce programme de contrôle va vérifier l'intégrité de l'application avec les ressources électroniques du second dispositif.

Description

Procédé de validation distante d'un code exécutable
L'invention concerne un procédé de validation distante d'un code exécutable.
L'invention porte en particulier sur l'exécution distante et sécurisée, d'un code informatique.
Les dispositifs électroniques mobiles sont en pleine mutation. En effet, leur capacité de stockage évolue, leur puissance de calcul par unité de taille augmente de même que leur encombrement diminue.
Une nouvelle génération de tels dispositifs a permis de développer un nouveau modèle distribué. Ces dispositifs, couramment appelés Clés Intelligentes, ont la particularité de posséder une mémoire, une intelligence électronique, et un accès à un module électronique sécurisé. Dans la mémoire de ces Clés Intelligentes est enregistré un code informatique exécutable (un ou plusieurs logiciels) , qui est destiné à être chargé (à travers l'interface de communication de la Clé Intelligente, souvent USB) sur un autre dispositif électronique hôte.
Ce code particulier est couramment appelé CDROM car dans la majorité des cas, ce code est stocké sous forme d'image 'ISO' sur une partition 'Lecture Seule' qui émule un CD-ROM qui sera vu comme tel (c'est à dire à la manière d'un "compact disque") par le dispositif électronique hôte (l'ordinateur).
En général, lorsque la Clé Intelligente est inséré dans un ordinateur, ce dernier la détecte, la reconnaît et l'active. La phase d'activation consiste, entre autres, à monter sur le système d'exploitation les différents 'disques' présentés par la Clef Intelligente dont celui qui contient le CD-ROM. Une fois activée, la Clé Intelligente envoie alors le contenu du CDROM à l'ordinateur qui exécute ledit contenu.
Cette technologie permet de transporter un code exécutable, potentiellement de grande taille, sur un support non figé, et cela à travers une interface de communication USB largement déployée sur les ordinateurs . En effet, le compact disque, et ses générations ultérieures permettent de transporter un tel code informatique, mais d'une manière statique.
Les Clés Intelligentes offrent la possibilité de faire évoluer ce code informatique, mais également tout un ensemble de fonctionnalités liées à l'intelligence embarquée et au module électronique sécurisé. Ces fonctionnalités peuvent par exemple être liées à la sécurité .
De plus, ces dispositifs permettent d'exécuter des applications informatiques sur un dispositif (appelé dispositif d'exécution) en s' appuyant le moins possible sur les ressources logicielles de ce dispositif d'exécution. Le plus souvent, seul le système d'exploitation sera exploité pour exécuter le code informatique contenu dans la clé intelligente.
Cela permet d'utiliser un logiciel sur un dispositif en ayant une confiance restreinte dans ce dispositif. En effet si une clé intelligente est utilisée dans un environnement non sûr, l'exécution du code informatique qu'elle contient pourra être altérée, pas l'application en elle même.
Afin d'utiliser ce code informatique avec un niveau optimal de sécurité, seule la confiance dans le système d'exploitation est nécessaire. De plus, l'exécution du code informatique contenu dans la clé intelligente se fait sans laisser de trace car le code informatique exécuté n'est pas stocké sur dispositif d'exécution de manière permanente ou persistante.
Cette flexibilité du support ouvre la porte à de nouveaux risques. En effet, il est désormais possible d'altérer le contenu de la mémoire de la Clé Intelligente, et ainsi de corrompre le code informatique qu'elle héberge. Cette altération du code peut soit servir à reconfigurer la Clef Intelligente pour une utilisation autre que celle prévue par son revendeur, soit pour y cacher des virus ou des chevaux de Troie. La vérification de l'intégrité de ce code informatique est possible, et deux méthodes ont été envisagées jusqu'à ce jour : effectuer cette vérification dans la Clé Intelligente, ou effectuer cette vérification dans le dispositif électronique en charge de l'exécution de ce code.
La première solution se trouve être peu réaliste vu la taille du code exécutable. En effet, la vérification de l'intégrité d'un tel code informatique, avec les ressources électroniques d'un dispositif électronique tel qu'une clef intelligente, prend un temps incompatible avec une quelconque convivialité.
La deuxième solution assoit la vérification de l'intégrité du code exécutable sur les ressources du dispositif d'exécution. Nous avons explicité plus haut que les clés intelligentes permettent d'exécuter un code informatique dans des environnements non sécurisés. Confier la vérification de l'intégrité du code sur les ressources d'un tel dispositif est problématique car il n'est pas possible d'avoir confiance dans le résultat d'une telle analyse.
La présente invention propose de résoudre ces inconvénients, et ainsi de garantir l'intégrité du code exécutable, avec des performances totalement acceptables pour l'utilisateur, sans déléguer la sécurité au dispositif d'exécution. La présente invention est un procédé de sécurisation de l'exécution distante d'un code informatique exécutable, comportant au moins un dispositif électronique ST, apte à communiquer avec au moins un dispositif électronique HPC, et un dispositif électronique sécurisé SC, le dispositif électronique ST comportant une mémoire de masse dans laquelle est enregistré un code informatique exécutable, l'accès à un second code informatique exécutable appelé programme de contrôle, et un contrôleur de communication apte à gérer les échanges de données avec les dispositifs HPC et SC, le code informatique exécutable AP étant destiné à être exécuté par le dispositif HPC, ce procédé comprend au moins les étapes de:
• A- chargement et exécution du programme de contrôle sur le dispositif électronique HPC,
• B- le programme de contrôle autorise le chargement de tout ou partie du code AP sur le dispositif HPC, vérifie son intégrité,
• C- exécution du code intègre par le dispositif HPC. Dans une étape préliminaire, l'intégrité dudit programme de contrôle peut être vérifiée.
Selon un mode de réalisation, le programme de contrôle peut par exemple être enregistré dans une mémoire non volatile dudit dispositif SC, ou bien dans une mémoire non volatile dudit dispositif ST.
Dans un mode de réalisation, lors d'une éventuelle étape préalable, des valeurs d'intégrité peuvent avoir été associées à tout ou partie du code exécutable AP.
Dans un mode de réalisation, lors d'une éventuelle étape préalable, des valeurs d'intégrité peuvent avoir été associées à tout ou partie du programme de contrôle.
Les valeurs d'intégrité peuvent, par exemple, être des Checksums .
Dans un mode de réalisation, l'étape de vérification du programme de contrôle peut, par exemple, être réalisée par le dispositif SC (13), ou bien par le contrôleur du dispositif ST.
Selon le mode de réalisation, le programme de contrôle peut ne permettre le chargement et ne vérifie l'intégrité, que de portions du code AP, à exécuter.
Dans un autre mode de réalisation, le programme de contrôle peut permettre le chargement et vérifie l'intégrité du code AP par portions successives.
Dans un autre mode de réalisation, le programme de contrôle peut permettre le chargement de l'intégralité du code AP puis vérifier l'intégrité de l'intégralité du code AP.
Selon le mode de réalisation, le dispositif SC peut être intégré audit dispositif ST, ou bien être intégré au dispositif HPC, ou encore être un dispositif électronique indépendant . D'autres caractéristiques et avantages de l'invention ressortiront clairement de la description qui en est faite ci-après, à titre indicatif et nullement limitatif, en référence aux dessins annexés dans lesquels : - La figure 1 représente l'usage d'une clé intelligente selon le mode de fonctionnement de l'art antérieur.
La figure 2 représente un mode d' implémentat ion de l'invention dans lequel l'intégrité du programme de contrôle est garantie par son hébergement dans le dispositif électronique sécurisé SC (13). - La figure 3 représente un mode d' implémentat ion de l'invention dans lequel l'intégrité du programme de contrôle est validée par la clé intelligente.
La figure 4 représente un mode d' implémentation de l'invention dans lequel l'intégrité du programme de contrôle est validée par le dispositif électronique sécurisé SC (13) .
Les clés intelligentes utilisent souvent le protocole de communication USB, comme illustré dans la figure 1. Cela leur permet d'être aisément connectées à un ordinateur individuel tel que l'ordinateur 2 de la figure 1, et reconnus par lui (à travers des logiciels bas-niveau appelés communément "drivers" qui sont présents dans la majorité des systèmes d'exploitations).
Les clés les plus évoluées contiennent un module de sécurité 3 tels qu'une carte à puce.
Afin de gérer aisément les échanges entre la clé 1, l'ordinateur 2 et éventuellement le module sécurisé 3, il est fréquent d'insérer un contrôleur 6 dans les clés intelligentes. Ce contrôleur, illustré par la boite 6 de la figure 1, sous entend la présence, dans la clé intelligente 1 d' au moins un composant de calcul
(microprocesseur), d'une mémoire de travail (mémoire volatile), et d'une mémoire non volatile (par exemple EEPROM, Flash, ou ROM) .
De plus, la clé comporte une mémoire non volatile 4, dite mémoire de masse, qui contient un code informatique exécutable 5 que nous appellerons « application » dans la suite du présent document.
Lors de la connexion de la clé 1 à l'ordinateur 2, la clé reçoit l'énergie nécessaire à son démarrage. Dès lors, le contrôleur 6 entre en communication avec l'ordinateur 2.
Lors de cette phase, le contrôleur initie une session de communication, cela passe, entre autre, par l'identification de la clé par son type de dispositif électronique (unité de stockage de masse, dispositif multimédia ...) .
S'engage également une communication au cours de laquelle la clé informe l' ordinateur 2 qu'elle contient une application 5, et que cette application doit être exécutée sur les ressources électroniques de l'ordinateur 2. Cette communication peut se faire avantageusement en identifiant l'application comme un CD-ROM auprès de l'ordinateur. En effet, à l'insertion d'un CD-ROM dans un ordinateur, celui-ci s'identifie en tant que tel, et la réponse standard de l'ordinateur (ou plus précisément du système d'exploitation de l'ordinateur) est d'exécuter le contenu, si celui-ci le permet (« démarrage automatique ou autorun en anglais) .
Une fois l'application ainsi déclarée auprès de l'ordinateur 2, le contrôleur 6 de la clé 1 envoie l'application 5 à l'ordinateur 2 qui l'exécute 7.
Ce système informatique permet entre autre, l'exécution d'une application 5 sur un ordinateur 2 ne la possédant pas. De plus l'usage du module de sécurité 3 permet de restreindre l'usage de l'application 5 avec les outils cryptographiques les plus perfectionnés. Il est par exemple, possible d'associer, à toute commande invasive pour l'application, une authentif ication déléguée au module de sécurité (par exemple au travers de l'utilisation d'un code personnel (« PIN code » en anglais) . Mais rien ne protège l'ordinateur 2 ou son utilisateur, d'une application 5 malveillante ou corrompue. Nous nous inscrivons ici dans le cadre ou l'application 5 aurait été corrompue, par exemple par un acte malveillant, ou un virus informatique.
Dans ce contexte l'utilisation de la clé 1 peut entrainer de graves conséquences pour les ressources à disposition de l' ordinateur 2 (par exemple services réseau, application de paiement en ligne, ...) , mais également pour l'utilisateur qui pense utiliser une application 5 fiable.
La figure 2 propose une implémentation de l'invention qui résout ce problème.
Comme dans la figure 1, la figure 2 présente une clé intelligente 11, contenant un module sécurisé 13, une contrôleur 17, une mémoire de masse 15 contenant elle même une application 16, mise en relation avec un ordinateur 12.
Cette clé intelligente 11 contient en outre un programme supplémentaire 14 appelé programme de contrôle.
Ce programme de contrôle va garantir l'intégrité de l'application 16. Dans le mode de réalisation illustré dans la figure 2, le programme de contrôle 14 est hébergé dans la carte à puce 13, elle même embarquée dans la clé 11. Le fait que le programme de contrôle soit ainsi conservé en sécurité dans le module sécurisé 13 garanti son intégrité. En effet, le programme de contrôle ainsi stocké ne peut être modifié depuis l'extérieur du module sécurisé 13, de part la nature du module sécurisé.
Lors du branchement de la clé 11 sur l'ordinateur 12, une fois l'initialisation de la clé réalisée, le contrôleur informe l'ordinateur qu'il possède un programme à exécuter. Cela peut se faire, en présentant le programme comme un CDROM. Contrairement à l'art antérieur, ce n est pas l'application 16, mais le programme de contrôle 14 que le contrôleur fait exécuter par l'ordinateur 12.
En effet, le programme de contrôle 14 est intègre. Une fois exécuté par l'ordinateur 12, c'est le seul composant logiciel de l'ordinateur en lequel la clé 11 peut faire entièrement confiance.
Le système entre désormais dans une autre phase, phase dans laquelle le programme de contrôle va, depuis l'ordinateur 12, charger l'application 16 présente dans la mémoire de masse de la clé 11. Le programme de contrôle peut désormais vérifier l' intégrité de l' application 16, en utilisant les ressources électroniques de l'ordinateur 12.
Cette vérification de l'intégrité de l'application 16 nécessite, dans une étape préalable, l'ajout de valeurs d'intégrités, associées à l'application 16.
Ces valeurs peuvent être enregistrées, avec l'application 16 dans la mémoire de masse 15, auquel cas le programme de contrôle peut les charger en même temps qu'il charge l'application elle même. Une solution préférée consiste à enregistrer les valeurs d'intégrité dans le module sécurisé 13. Dans cette solution, le programme de contrôle établie une connexion avec le module sécurisé avant de télécharger l'application afin d'obtenir ces valeurs d'intégrité. Cette communication se fait généralement au travers du contrôleur de la clé 11 elle-même.
Dans le cas où le module de sécurité 13 n'est pas intégré à la clé 11, le programme de contrôle doit établir une connexion avec ce module avant de charger l'application 16.
Une solution peut également résider dans l'insertion des valeurs de sécurité dans le code même du programme de contrôle. Ainsi lors de son exécution, le programme de contrôle possède déjà les valeurs d'intégrité.
Ces valeurs d'intégrité peuvent prendre différentes formes, l'essentiel est que leur contrôle permette de mettre en évidence une éventuelle modification de l'application 16.
Dans un mode préféré d' implémentat ion de l'invention, cette valeur d'intégrité peu être un haché du code l'application 16, généré a partir d'une fonction de hachage .
Une fonction de hachage est une fonction, qui, à un élément est capable d'associer une empreinte (aussi appelé haché) en conservant 3 caractéristiques essentielles :
- II doit être impossible, en partant du haché, de retrouver l'information qui a servi à le générer.
Il est informatiquement impossible de trouver deux données, quelles qu'elles soient, qui, appliquées à la même fonction de hachage, donnent un même haché .
- A partir d'une donnée et de son haché et d'une fonction de hachage, il est informatiquement impossible de trouver une autre donnée qui ait le même haché .
Les algorithmes SHA-I (Secure Hash Algorithm 1 : 160 bits), et SHA-2 (SHA-256, SHA-384 ou SHA-512 bits au choix) , sont des fonctions de hachage utilisées fréquemment .
L'utilisation de telles fonctions implique que le programme de contrôle 18 contienne un moyen de vérifier ces valeurs. Dans la majorité des cas cela implique que le code du programme de contrôle contienne l'algorithme nécessaire .
D'autres solutions permettant de vérifier l'intégrité de l'application 16, par exemple l'utilisation de checksums, l'utilisation de MACs (Code d' Au t hen t i f i ca t i on de Message, « Message Authenticated Code » en anglais), de bits de parité, l'insertion de balises de repérage, etc..
Dans tous les cas, le programme de contrôle doit être en mesure d'obtenir les valeurs d'intégrités, si elles sont nécessaires, et de les utiliser pour vérifier que l'application 16 est bien celle à partir de laquelle ces valeurs d'intégrité ont été générées.
Une fois l'intégrité de l'application 16 vérifiée, le programme de contrôle autorise son exécution 19 sur l'ordinateur 12. Si la vérification de l'intégrité de l'application 16 aboutit à la conclusion que l'application n'est pas intègre, nous parlerons d'échec de la vérification. Cet échec peut être dû à plusieurs paramètres : elle peut être liée à une réelle altération de l'application 16, mais également à une erreur par exemple dans les communications entre l'ordinateur et la clé .
Dans un mode préféré d' implémentation, en cas d'échec de la vérification de l'intégrité de l'application 16, le programme de contrôle prend acte de cet échec (par exemple en mettant à jour un compteur), et recommence l'opération de chargement. Plusieurs échecs consécutifs peuvent aboutir à un refus pur et simple de l'exécution de l'application 16 sur l'ordinateur 12. Afin de garantir la pérennité de cette information, le programme de contrôle peut enregistre un échec de vérification dans la clé 11, voire même dans le module sécurisé 13.
De la même manière, en réponse à un nombre défini d'échecs de la vérification de l'intégrité, le programme de contrôle peut provoquer une réaction au niveau de la clé 11 voire même du module sécurisé 13. Ces réactions peuvent par exemple consister en une neutralisation de tout ou partie de ces dispositifs, par exemple par effacements de données.
La vérification de l'intégrité de l'application 16 peut se faire en une fois ou bien en plusieurs fois. En effet, dans le cas où l'application 16 est par exemple très volumineuse, ou bien par exemple dans le cas où la communication entre la clé 11 et l'ordinateur 12 est limitée, il peut être judicieux de charger l'application 16 par parties, et de vérifier indépendamment ces parties .
La figure 3 illustre un mode d' implémentation de l'invention dans lequel le programme de contrôle 28 est stocké dans la mémoire de masse 26, avec l'application 27. Afin de garantir l' intégrité de ce programme de contrôle, avant son chargement sur l'ordinateur 22, le contrôleur 29 se procure, auprès du module sécurisé 23, au moins une valeur d'intégrité, permettant de vérifier l' intégrité du programme de contrôle 24. Une fois l'intégrité du programme de contrôle assurée, il est chargé et exécuté sur l'ordinateur comme illustré dans la figure 2.
Dans un mode préféré d' implémentat ion de l'invention, dans le cas où la vérification de l'intégrité du programme de contrôle échoue, le contrôleur 29 ne propose pas son chargement à l'ordinateur.
Cette implémentation de l'invention implique, dans une étape préalable, la création de valeurs d'intégrités liées au programme de contrôle, et stockés dans le module de sécurité 23. Une variante d' implémentation du cas précédent consiste à déléguer la vérification de l'intégrité du programme de control 45 au module de sécurité 43, qui possède les valeurs d'intégrités liées au programme de contrôle 45. Les mécanismes décrits plus hauts pour générer les valeurs d' intégrité liées à l'application 16, s'appliquent mutatis mutandis, à la génération des valeurs d'intégrité liées au programme de contrôle 23 et 45 de même que les mécanismes décrits permettant de gérer les échecs de vérification de l' intégrité de l'application 16 s'appliquent mutatis mutandis, à la vérification de l'intégrité du programme de contrôle 23 et 45. L'invention s'applique avantageusement au cas où le programme de contrôle se trouve sur un dispositif électronique tiers. Dans ce cas, le contrôleur établit une session de communication avec ce dispositif afin d'obtenir le programme de contrôle, et de mettre en œuvre la suite du procédé selon l'invention. Dans un mode de réalisation particulièrement avantageux, les valeurs d' intégrité liées au programme de contrôle peuvent être également chargées depuis un diapositif électronique distant. Ce mode de réalisation permet de confier la gestion du programme de contrôle à un tiers de confiance.

Claims

REVENDICATIONS
1. Procédé de sécurisation de l'exécution distante d'un code informatique exécutable, comportant au moins un premier dispositif électronique ST (11), apte à communiquer avec au moins un deuxième dispositif électronique HPC (12), et un dispositif électronique sécurisé SC (13), ledit dispositif électronique ST (11) comportant une mémoire de masse dans laquelle est enregistré un code informatique exécutable, l'accès à un second code informatique exécutable appelé programme de contrôle (14), et un contrôleur de communication apte à gérer les échanges de données avec les dispositifs HPC
(12) et SC (13), ledit code informatique exécutable AP
(16) étant destiné à être exécuté par ledit dispositif
HPC (12),
caractérisé en ce que le procédé comprend au moins les étapes de:
• A- chargement et exécution dudit programme de contrôle (14) sur ledit dispositif électronique HPC (12),
• B- ledit programme de contrôle (14) autorise le chargement de tout ou partie dudit code AP (16) sur ledit dispositif HPC (12), vérifie son intégrité,
• C- exécution dudit code intègre par ledit dispositif HPC (12) .
2. Procédé selon la revendication 1, caractérisé en ce que, dans une étape préliminaire, l'intégrité dudit programme de contrôle (14) est vérifiée.
3. Procédé selon l'une quelconque des revendications 1 à 2, caractérisé en ce que ledit programme de contrôle (14) est enregistré dans une mémoire non volatile dudit dispositif SC (13) .
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit programme de contrôle (14) est enregistré dans une mémoire non volatile dudit dispositif ST (11) .
5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que, dans une étape préalable, des valeurs d' intégrité ont été associées à tout ou partie dudit code exécutable AP (16) .
6. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que, dans une étape préalable, des valeurs d' intégrité ont été associées à tout ou partie dudit programme de contrôle (14) .
7. Procédé selon l'une quelconque des revendications 5 ou 6, caractérisé en ce que lesdits valeurs d' intégrité sont des CheckSums .
8. Procédé selon l'une quelconque des revendications 2 à 7, caractérisé en ce que ladite étape de vérification dudit programme de contrôle (14) est faite par ledit dispositif SC (13)
9. Procédé selon l'une quelconque des revendications 2 à 7, caractérisé en ce que ladite étape de vérification dudit programme de contrôle (14) est faite par ledit contrôleur dudit dispositif ST (11).
10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que lors de ladite étape B, le programme de contrôle (14) ne permet le chargement et ne vérifie l'intégrité que des portions dudit code AP (16) à exécuter.
11. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que lors de ladite étape B, le programme de contrôle (14) permet le chargement et vérifie l'intégrité dudit code AP (16) par portions successives .
12. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que lors de ladite étape B, le programme de contrôle (14) permet le chargement de l'intégralité dudit code AP (16) puis vérifie l'intégrité de l'intégralité dudit code AP (16).
13. Procédé selon l'une quelconque des revendications 1 à 12, caractérisé en ce que ledit dispositif SC (13) est intégré audit dispositif ST (11).
14. Procédé selon l'une quelconque des revendications 1 à 12, caractérisé en ce que ledit dispositif SC (13) est intégré audit dispositif HPC (12) .
15. Procédé selon l'une quelconque des revendications 1 à 12, caractérisé en ce que ledit dispositif SC (13) est un dispositif électronique indépendant.
PCT/EP2010/058673 2009-07-03 2010-06-18 Procédé de validation distante d'un code exécutable WO2011000722A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP10726074A EP2449495A1 (fr) 2009-07-03 2010-06-18 Procédé de validation distante d'un code exécutable

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP09305645.5 2009-07-03
EP09305645 2009-07-03

Publications (1)

Publication Number Publication Date
WO2011000722A1 true WO2011000722A1 (fr) 2011-01-06

Family

ID=42727535

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2010/058673 WO2011000722A1 (fr) 2009-07-03 2010-06-18 Procédé de validation distante d'un code exécutable

Country Status (2)

Country Link
EP (1) EP2449495A1 (fr)
WO (1) WO2011000722A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113168462A (zh) * 2018-11-29 2021-07-23 日本电信电话株式会社 应用程序动作控制装置、应用程序动作控制方法以及应用程序动作控制程序

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060107320A1 (en) * 2004-11-15 2006-05-18 Intel Corporation Secure boot scheme from external memory using internal memory
EP1714684A1 (fr) * 2005-04-19 2006-10-25 Aruze Corporation Machine de jeu, authentification de l'information concernant le jeu et dispositif de chargement de l'information concernant le jeu
FR2901038A1 (fr) * 2006-05-15 2007-11-16 France Telecom Procede et dispositif de configuration securisee d'un terminal au moyen d'un dispositif de stockage de donnees de demarrage

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060107320A1 (en) * 2004-11-15 2006-05-18 Intel Corporation Secure boot scheme from external memory using internal memory
EP1714684A1 (fr) * 2005-04-19 2006-10-25 Aruze Corporation Machine de jeu, authentification de l'information concernant le jeu et dispositif de chargement de l'information concernant le jeu
FR2901038A1 (fr) * 2006-05-15 2007-11-16 France Telecom Procede et dispositif de configuration securisee d'un terminal au moyen d'un dispositif de stockage de donnees de demarrage

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113168462A (zh) * 2018-11-29 2021-07-23 日本电信电话株式会社 应用程序动作控制装置、应用程序动作控制方法以及应用程序动作控制程序

Also Published As

Publication number Publication date
EP2449495A1 (fr) 2012-05-09

Similar Documents

Publication Publication Date Title
US8887295B2 (en) Method and system for enabling enterprises to use detachable memory devices that contain data and executable files in controlled and secure way
EP2110742B1 (fr) Dispositif portable et procédé de démarrage externe d'une installation informatique
EP1987653B1 (fr) Procede et dispositif de configuration securisee d'un terminal
EP2688010A1 (fr) Mise à jour d'un système d'exploitation pour elément sécurisé
EP2741466B1 (fr) Procédé et système de gestion d'un élément sécurisé intégré ese
FR2989799A1 (fr) Procede de transfert d'un dispositif a un autre de droits d'acces a un service
EP1687717A1 (fr) Demarrage securise d'un appareil electronique a architecture smp
EP2614458A2 (fr) Procede d'authentification pour l'acces a un site web
EP2077515B1 (fr) Dispositif, systèmes et procédé de démarrage sécurisé d'une installation informatique
EP3586258B1 (fr) Système d'authentification à clé segmentée
EP1728354A1 (fr) Procede d'authentification dynamique de programmes par un objet portable electronique
EP3531729B1 (fr) Configuration d'un module d'identité de souscripteur embarqué
WO2019129937A1 (fr) Contrôle d'intégrité d'un dispositif électronique
EP2048576B2 (fr) Procédé de mise à jour sécurisée d'un programme à lancement automatique et entité électronique portable le mettant en oeuvre
WO2011000722A1 (fr) Procédé de validation distante d'un code exécutable
EP2813962A1 (fr) Méthode de contrôle d'accès à un type de services spécifique et dispositif d'authentification pour le contrôle de l'accès à un tel type de services.
WO2011003722A1 (fr) Module logiciel de securisation utilisant le chiffrement du hache d ' un mot de passe concatene avec une graine
EP3166252B1 (fr) Procédé d'enregistrement sécurisé de données, dispositif et programme correspondants
EP3765984A1 (fr) Traitement sécurisé de données
EP3179400B1 (fr) Procédé de chargement d'une ressource informatique au sein d'un dispositif électronique, module électronique et programme d'ordinateur correspondant
EP1494461B1 (fr) Procédé et dispositif d'authentification de données numériques à partir d'un module d'extension d'authentification
WO2020193583A1 (fr) Procédé d'exécution de code sécurisé, dispositifs, système et programmes correspondants
EP2933767A1 (fr) Procédé de désactivation d'un module de paiement, produit programme d'ordinateur, medium de stockage et module de paiement correspondants
EP2302518B1 (fr) Procédé et dispositif d'installation d'une application MIFARE dans une mémoire MIFARE
CA3179748A1 (fr) Proced de verrouillage d'une memoire non-volatile reinscriptible et dispositif electronique mettant en oeuvre ledit procede

Legal Events

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

Ref document number: 10726074

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010726074

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE