WO2005064466A2 - Procede permettant l'interruption sure d'applications dans un systeme informatique distribue comportant un moteur d'execution logiciel - Google Patents

Procede permettant l'interruption sure d'applications dans un systeme informatique distribue comportant un moteur d'execution logiciel Download PDF

Info

Publication number
WO2005064466A2
WO2005064466A2 PCT/FR2004/002995 FR2004002995W WO2005064466A2 WO 2005064466 A2 WO2005064466 A2 WO 2005064466A2 FR 2004002995 W FR2004002995 W FR 2004002995W WO 2005064466 A2 WO2005064466 A2 WO 2005064466A2
Authority
WO
WIPO (PCT)
Prior art keywords
execution
frame
execution engine
unsafe
instructions
Prior art date
Application number
PCT/FR2004/002995
Other languages
English (en)
Other versions
WO2005064466A3 (fr
Inventor
Alexandre Frey
Eduardo Gimenez
Original Assignee
Trusted Logic
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Trusted Logic filed Critical Trusted Logic
Publication of WO2005064466A2 publication Critical patent/WO2005064466A2/fr
Publication of WO2005064466A3 publication Critical patent/WO2005064466A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4482—Procedural
    • G06F9/4484—Executing subprograms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45529—Embedded in an application, e.g. JavaScript in a Web browser

Definitions

  • the present invention relates to a method for the secure integration of applications in a distributed computer system comprising a software execution engine (or virtual machine).
  • Chip cards and small terminals are typical examples of such devices.
  • These devices include basic hardware and software (operating system, memory manager, device managers, etc.) which are collectively referred to as platforms. On these platforms run specific applications (sometimes referred to as "applets").
  • Client-server computer systems can be synchronous or asynchronous.
  • the property that characterizes synchronous systems is that, once the client sends its request to the server, it stops all computation and remains blocked while waiting for its response.
  • the client and the server continue their tasks in parallel, until they decide to take charge of the message sent or received. Each process therefore pursues a different "thread".
  • Asynchronous programming is often a complicated task, which makes program behavior difficult to predict. For this reason, several standards based on the client-server model have chosen to allow only one thread to process the requests that the controller sends to the applet (synchronous programming). At the start of this thread, the controller has the hand and sends a command to the applet. Subsequently, the applet and the controller surrender successively until the complete processing of the request.
  • the only asynchronous events of the system are those related to the management of the I / O devices of the platform (screen and keyboard of a terminal, etc.).
  • the applet has control, it can trigger these events by calling an API method that will trigger a thread parallel to processing the request. It is therefore naturally possible that several events concerning the input / output are being executed at a given time, in parallel with the execution thread of the request.
  • the controller is notified of asynchronous events concerning the devices. If these end before the execution thread of the request, they are saved in a queue and processed by the controller when the request has been fully processed. It was also assumed that these notifications have all the information necessary for their management by the controller.
  • the events linked to the management of inputs / outputs can be of a complex nature (non-atomic execution).
  • the execution engine In order to manage the invocation of methods, the execution engine maintains a stack of data structures called "frames" for the execution thread corresponding to the processing of the request. Each "frame” contains the data necessary for the execution of the methods previously invoked in this thread, and whose execution is not yet finished. In particular, each "frame” contains a reference to the instruction of the method which is being executed. When a method is invoked, a new "frame" is created and installed at the top of the stack.
  • the controller may send the applet a special message asking it to stop.
  • the applet can therefore do whatever is necessary to terminate its execution properly (for example, cleaning its data structures, saving its state on a persistent memory, etc.).
  • the applet can cleanly terminate the various execution threads linked to the devices (closing files, etc.).
  • the controller can also verify that the peripherals have been shut down once the applet returns their hands.
  • the controller must at least ensure that all threads linked to the peripherals stop properly, and that the platform will remain in a safe state. For this, when it receives the notification of an event concerning a device, it will do what is necessary to stop it properly.
  • the invention therefore more particularly aims to solve the following problem: how, in all cases, properly interrupt the execution thread of the applet and the execution threads of the devices so that the platform can return to a safe state, particularly in the context of low-resource platforms such as those previously mentioned (Java Card, "FLNREAD”, “STIP”, “GlobalPlatform”, etc.), and whose security is a concern first class.
  • the light termination method by rewriting the applet code has at least three shortcomings.
  • the previously described solution ensures that any malicious applet will eventually take over, but it allows the applet to continue running until it encounters one of the instructions that could extend his life.
  • the invention therefore more particularly aims to solve these problems and therefore eliminate these drawbacks.
  • the secure codes may be adapted so as to coat any call to an insecure method by an exception handling mechanism so as to properly continue the execution of said secure codes after a call to an insecure method.
  • the separation into secure and non-secure codes may alternatively: • be established permanently and written into the code or the data of the execution engine, • evolve dynamically during the execution of the system, • result from an analysis of '' a register of potentially dangerous events.
  • - Events can be triggered by a hardware mechanism and / or by a software component different from the execution engine and / or by the execution engine itself.
  • the above "obligatory waypoints" can be annotated so that the execution engine can differentiate them from other instructions, in particular by using a different instruction name (opcode) for each type of annotated instruction.
  • the software component that triggers the event may notify this event to the execution engine through a shared data structure which may in particular consist of a simple Boolean variable and / or include additional information, such as, for example, a priority level , methods that are considered unsafe, instructions regarding the shutdown procedure to use.
  • This shared data structure can be consulted by the execution engine systematically after the execution of a certain number of instructions or by the execution engine during the execution of certain instructions annotated by applets (or alternative instructions) .
  • the instructions corresponding to invocations of potentially insecure methods could be replaced by special instructions recognized by the execution engine, which then prevents any stacking of an insecure "frame".
  • the platform may have a second execution engine which is called upon the detection of an event and which prevents any stacking of an "unsafe frame", this second execution engine may include for each of the " "unsafe frames” a timer counting units of time elapsed since the "frame” was stacked and which is used by said engine to interrupt the execution of unsafe "frames".
  • Triggering by hardware interruption This solution consists in processing the events triggered by a system of hardware interrupts. In this case, the detection engine is directly interrupted and no specific mechanism is necessary.
  • Triggering by the execution engine In certain situations, the execution engine can trigger the event itself. In these particular cases, it is therefore the engine which both triggers the event and processes this event. In Java Card for example, any catch of an exception of the class "SecurityException" by an applet can be detected by the virtual machine.
  • Triggering by a software component (which requires a specific event detection mechanism):
  • This solution provides for an asynchronous triggering of the event by another software component of the platform.
  • the component that triggers the error must notify the execution engine of the immediate stop request, for example through a data structure shared with the components that can request a stop.
  • This data structure can be a simple flag (boolean variable) or a more complex structure, containing for example a priority level for the message, the methods which are considered unsafe at the time of interruption, instructions concerning the procedure of stop to use, etc.
  • it is necessary to ensure the detection (and processing) of the event by the execution engine.
  • One way to satisfy this requirement is to program the execution engine so that it regularly checks the state of the flag. This approach can be modulated according to the frequency of consultation of the flag.
  • the detection of events can be carried out by the following mechanisms:
  • An inspection mechanism at regular intervals In its simplest expression, this mechanism includes the programming of the execution engine so as to check the state of the flag systematically after the execution of a certain number of instructions .
  • the flag is maintained as a native data structure, and therefore not accessible by applets.
  • the use of a native structure makes it possible to avoid verifications additional to prove that the applet cannot change the flag value itself.
  • the set of obligatory waypoints can notably result from a static analysis of the applet code. If the analysis is done outside the platform, the instructions to modify can be sent to the platform with the applet code. For example, in a Java Card platform, they can be appended in a specific additional component of the "CAP" file format. In a “GlobalPlatform” platform, they can be part of the data of the "LNSTALL” or "LOAD” commands. In all cases, the method of loading the application code on the platform must also ensure the integrity of this information (for example, using a secure communication channel by the use of a special protocol, like the SCP01 and SCP02 protocols used in "GlobalPlatform").
  • the annotation of the applet instructions is done when installing the applet on the platform, for example, during the linkage phase of the code.
  • the advantage of annotating the bytecode on the card is that it ensures that any applet can be executed on the modified platform so as to recognize the new "opcodes", even if it was designed to be executed on another platform.
  • the action taken by the execution engine when an event is detected can be arbitrarily complex. Just as an example, it can perform. different treatments (or launch different classes of exceptions) depending on the priority level assigned to the event by the component requesting it.
  • a security exception can have an x attribute indicating whether the event has already been caught by the applet. This attribute is initialized when the exception is thrown, depending on the priority level of the stop request.
  • the execution engine checks the attribute value. If the attribute is false, it accepts to execute the code of the catch-up block. Otherwise, the unsafe "frame" at the top of the stack is unstacked and the engine processes the next "frame" (in the stack). The processing of the exception may include the assignment of attribute x.
  • the catch-up exception control allows you to omit a static check to avoid that an applet can never give up using a catch-up block that overlaps itself.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Storage Device Security (AREA)
  • Multi Processors (AREA)

Abstract

L'invention concerne un procédé permettant l'interruption sûre d'applications dans un système informatique distribué comportant un moteur d'exécution de logiciel, ce procédé comprenant - l'attribution aux 'frames' (structures de données empilées lors d'un appel de méthode) d'une annotation permettant de déterminer si la méthode correspondant à la 'frame' est sûre ou pas, - le dépilement systématique, lors d'événements spécifiques, des 'frames' non sûres et, ceci, jusqu'à ce qu'une 'frame' sûre soit atteinte, - la poursuite normale de l'exécution une fois qu'une 'frame' sûre est atteinte, - l'empêchement de tout nouvel empilement de 'frame' non sûre à partir d'une 'frame' sûre dès lors qu'un événement a été détecté.

Description

PROCEDE PERMETTANT L'INTERRUPTION SURE D'APPLICATIONS DANS UN SYSTEME INFORMATIQUE DISTRIBUE COMPORTANT UN MOTEUR D'EXECUTION LOGICIEL.
La présente invention concerne un procédé permettant l'inteπuption sûre d'applications dans un système informatique distribué comportant un moteur d'exécution logiciel (ou machine virtuelle).
Elle s'applique notamment, mais non exclusivement, à des petits dispositifs informatiques disposant de faibles ressources (en mémoire comme en temps d'exécution) et soumis à de fortes contraintes sécuritaires (protection de rinformation, confidentialité, intégrité des données, etc.). Les cartes à puce et petits terminaux (bancaires, téléphoniques, assistants personnels, claviers sécurisés, etc.) sont des exemples typiques de tels dispositifs. Ces dispositifs comportent un matériel et un ensemble de logiciels de base (système opératoire, gestionnaire de mémoire, gestionnaires des périphériques, etc.) qu'on désigne collectivement sous le nom de plates- formes. Sur ces plates- formes s'exécutent des applications spécifiques (parfois désignées sous le nom d'« applets »).
Plusieurs standards décrivant des plates-formes sécuritaires (Java Card, "STIP", "FLNREAD", "GlobalPlatform", etc.) sont basés sur un modèle de calcul distribué du type client-serveur. Dans ce modèle, un contrôleur envoie des requêtes aux applets. Ces applets peuvent faire appel à des services de bas niveau offerts par la plate-forme à travers une interface de programmation, appelée ci-après API. Du point de vue sécuritaire, la plate- forme, le contrôleur et le code des APIs sont considérés sûrs. Par contre, les applets peuvent être potentiellement malicieuses.
Les systèmes informatiques client- serveur peuvent être de type synchrone ou asynchrone. La propriété qui caractérise les systèmes synchrones est que, une fois que le client envoie sa requête au serveur, il arrête tout calcul et reste bloqué en attendant la réponse de celui-ci. En revanche, dans les systèmes asynchrones, une fois la requête envoyée, le client et le serveur poursuivent leurs tâches en parallèle, jusqu'à ce qu'ils décident de prendre en charge le message envoyé ou reçu. Chaque processus poursuit donc un « fil d'exécution » ("thread", en anglais) différent.
La programmation asynchrone est souvent une tâche compliquée, qui rend le comportement des programmes difficile à prévoir. Pour cette raison, plusieurs standards basés sur le modèle client-serveur ont choisi de n'autoriser qu'un seul fil d'exécution pour traiter les requêtes que le contrôleur envoie à l'applet (programmation synchrone). Au début de ce fil d'exécution, le contrôleur a la main et il envoie une commande à l'applet. Par la suite, l'applet et le contrôleur se rendent la main successivement jusqu'au traitement complet de la requête. Dans ce cadre, les seuls événements asynchrones du système sont ceux liés à la gestion des périphériques d'entrée/sortie de la plate-forme (écran et clavier d'un terminal, etc.). Lorsque l'applet a le contrôle, elle peut déclencher ces événements par l'appel d!une méthode de l'API qui déclenchera un fil d'exécution parallèle au traitement de la requête. Il est donc naturellement possible que plusieurs événements concernant l' entrée/sortie soient en cours d'exécution à un moment donné, en parallèle avec le fil d'exécution de la requête.
On a supposé que le contrôleur est notifié des événements asynchrones concernant les périphériques. Si ceux-ci finissent avant le fil d'exécution de la requête, ils sont sauvegardés dans une file d'attente et traités par le contrôleur quand la requête a été entièrement traitée. On a supposé aussi que ces notifications possèdent toute l'information nécessaire à leur gestion par le contrôleur. Les événements liés à la gestion des entrées/sorties peuvent être de nature complexe (exécution non-atomique).
On a supposé aussi que le code embarqué sur la plate- forme (aussi bien celui du client que celui du serveur) n'est pas directement exécutable sur le processeur de la plate- forme, mais qu'il est interprété par un autre programme appelé le moteur d'exécution (ou, de manière équivalente, la machine virtuelle). Afin de gérer l'invocation des méthodes, le moteur d'exécution maintient une pile de structures de données appelées "frames" pour le fil d'exécution correspondant au traitement de la requête. Chaque "frame" contient les données nécessaires à l'exécution des méthodes invoquées précédemment dans ce fil d'exécution, et dont l'exécution n'est pas encore terminée. En particulier, chaque "frame" contient une référence à l'instruction de la méthode qui est en cours d'exécution. Quand une méthode est invoquée, une nouvelle "frame" est créée et installée au sommet de la pile. Quand l'exécution de la méthode en cours finit normalement, la "frame" au sommet de la pile est retirée (ou « dépilée »), et le moteur d'exécution poursuit avec l'instruction qui suit celle référencée dans la nouvelle "frame" au sommet de la pile. Quand l'exécution de la méthode en cours s'arrête avec une exception, les « frames » dans la pile sont retirées l'une après l'autre jusqu'à la rencontre d'une « frame » de méthode dont le code contient un bloc de traitement pour l'exception en question. Dans ce cas, le moteur d'exécution poursuit avec la nouvelle « frame » au sommet de la pile, à partir de l'instruction indiquée dans le bloc de traitement.
Il s'avère que le problème qui se pose avec le plus d'acuité est celui de l'interruption sûre d'applets suite à des événements exceptionnels, comme, par exemple, un comportement anormal de l'applet qui met en cause la sécurité de la plate-forme ou perturbe l'exécution d'autres applets. Dans ce schéma d'exécution, il existe deux moyens d'interrompre l'exécution d'une requête :
1. Si l'applet rend la main au contrôleur normalement, celui-ci peut envoyer à l'applet un message spécial lui demandant de s'arrêter. L'applet peut donc faire le nécessaire pour terminer son exécution proprement (par exemple, nettoyer ses structures de données, sauver son état sur une mémoire persistante, etc.). Dans ce cas, l'applet peut terminer proprement les différents fils d'exécution liés aux périphériques (clôture des fichiers, etc.). Néanmoins, pour des raisons de sécurité, le contrôleur peut vérifier aussi que les périphériques ont bien été arrêtés une fois que l'applet lui rend la main.
2. Si l'applet rend la main au contrôleur avec une exception, alors elle peut ne pas être en mesure de s'arrêter proprement. Dans ce cas, le contrôleur doit au moins assurer que tous les fils d'exécution liés aux périphériques s'arrêtent proprement, et que la plate-forme restera dans un état sûr. Pour cela, lorsqu'il reçoit la notification d'un événement concernant un périphérique, il fera le nécessaire pour l'arrêter proprement.
Par contre, dans ce schéma d'exécution synchrone, il n'est pas possible d'arrêter l'applet et de transiter vers un état sûr du système si elle ne rend pas la main. Or, cela peut être nécessaire dans plusieurs situations, comme par exemple :
• quand une applet malicieuse veut monopoliser les ressources et les rendre indisponibles pour les autres applications ; • quand un processus de surveillance (ou audit) extérieur au fil d'exécution de la requête détecte que l'applet a violé la politique de sécurité (par exemple, dans le cas de Java Card, la plate-forme détecte que l'applet a lancé et rattrapé une exception de sécurité ("SecurityException" en Java) pendant son exécution) ; • quand l'applet est incapable de répondre car elle a déclenché une erreur fatale.
L'invention a donc plus particulièrement pour but de résoudre le problème suivant : comment, dans tous les cas, interrompre proprement le fil d'exécution de l'applet et les fils d'exécution des périphériques afin que la plate-forme puisse revenir à un état sûr et ce, notamment, dans le cadre de plates-formes à faibles ressources telles que celles précédemment mentionnées (Java Card, "FLNREAD", "STIP", "GlobalPlatform", etc.), et dont la sécurité est un souci de premier ordre.
Pour résoudre le problème de l'arrêt sûr d'un fil d'exécution Java, a déjà été proposée une solution développée sous le nom de « terminaison légère » ("soft termination") consistant à classifier les "frames" du fil d'exécution en "sûrs" et "non-sûrs". Quand l'administrateur du système veut arrêter un fil d'exécution, il dépile les "frames" non-sûres, mais laisse poursuivre l'exécution des "frames" sûres sur la pile jusqu'à leur arrêt normal. Le code des applets est alors réécrit en insérant des instructions qui testent l'état d'une variable logique (drapeau), et lancent une exception si la variable a été mise à vrai. Par exemple, si le drapeau est vu comme une variable statique booléenne, et l'instruction b à la position i est un passage obligé, alors b pourrait être remplacée par les instructions suivantes (dans le bytecode du langage Java) :
I : getstatic <drapeau> ifeqO j new java.lang.ThreadDeath dup mvokevir aljava.lang.ThreadDeam<init> athrow i b Pour assurer que la variable sera effectivement testée si la méthode réécrite boucle, on a proposé d'insérer les nouvelles instructions devant des instructions qui pourraient potentiellement prolonger la durée de vie de la méthode, à savoir : • un branchement du flot de contrôle vers l'arrière • le début de chaque méthode • le début de chaque bloc de traitement d'exceptions
Certaines situations qui pourraient empêcher cette solution de fonctionner (existence d'une variable avec le même nom que le drapeau, bloc de traitement d'une exception se recouvrant à lui-même) sont écartées par une analyse préalable du code pendant son chargement. L'analyse recherche ces situations particulières, et refuse de charger le code si elles sont présentes dans le code de l'applet.
La méthode de terminaison légère par réécriture du code des applets présente au moins trois défauts.
D'abord, du fait qu'elle a été conçue dans le cadre de l'utilisation de Java comme langage de programmation d'applications dynamiques (ajoutables à un navigateur d'Internet), la solution précédemment décrite prend en compte la dégradation des performances de l'applet réécrite en temps d'exécution, mais pas en termes d'augmentation de la taille du code. En effet, la réécriture du code des applets fait grossir la taille du code des applets. Or, pour les plates- formes visées dans le contexte de la présente invention, la mémoire est souvent une ressource critique, ce qui peut rendre cette approche inapplicable en pratique.
Deuxièmement, la solution précédemment décrite garantit que toute applet malicieuse finira par rendre la main, mais elle permet à l'applet de poursuivre son exécution jusqu'à ce qu'elle rencontre l'une des instructions qui pourrait prolonger sa vie. Or, dans un contexte de fortes contraintes sécuritaires comme celui adressé par les standards précédemment cités, il est souhaitable de pouvoir arrêter net l'exécution de l'applet, afin d'empêcher qu'elle puisse continuer à faire des dégâts, tout en laissant aux autres applets le temps de s'arrêter correctement.
Il s'avère donc que cette solution pénalise toutes les applications de la même façon : dès que la procédure d'arrêt est engagée à cause d'une action engagée par l'une des applets, toutes les autres applets sont aussi empêchées d'invoquer des méthodes (et finalement arrêtées).
Troisièmement, l'utilisation d'une variable booléenne Java pour communiquer l'arrêt éventuel de l'applet représente un point faible pour la sécurité. En effet, une applet malicieuse pourrait essayer de manipuler elle-même cette variable (en l'affectant à faux) pour éviter les contre-mesures de la plate-forme. Ceci implique en principe de vérifier l'absence de telles manipulations avant la réécriture du code. Pour que les codes des applets restent indépendants de la plate-forme, cette vérification doit être faite sur la plate-forme elle-même. Or, le coût en temps et taille de code de ce genre d'analyse n'est pas négligeable dans des dispositifs à faibles ressources, comme ceux envisagés dans le contexte de la présente invention.
L'invention a donc plus particulièrement pour but de résoudre ces problèmes et donc de supprimer ces inconvénients.
Elle propose, à cet effet, un procédé consistant à adapter le moteur d'exécution du système informatique ainsi que les APIs selon un processus comprenant les étapes suivantes : - l'attribution aux "frames" (structures de données empilées lors d'un appel de méthode) d'une annotation permettant de déterminer si la méthode correspondant à la "frame" est sûre ou pas,
- la consultation d'une structure de données lors de l'exécution d'une instruction appartenant à un ensemble de "points de passage obligés", ledit ensemble étant conçu de manière à ce que, à partir de toute instruction de la méthode, le moteur d'exécution doive finir par atteindre un de ces points de passage obligés,
- le dépilement systématique, lors d'événements spécifiques (simplement appelés « événements » par la suite), enregistrés dans ladite structure de données des "frames" non sûres et, ceci, jusqu'à ce qu'une "frame" sûre soit atteinte,
- la poursuite normale de l'exécution une fois qu'une "frame" sûre est atteinte,
- l'empêchement de tout nouvel empilement d'une nouvelle "frame" non sûre à partir d'une "frame" sûre dès lors qu'un événement a été détecté.
Avantageusement :
- Les codes sûrs pourront être adaptés de manière à enrober tout appel à une méthode non sûre par un mécanisme de traitement des exceptions de façon à poursuivre proprement l'exécution desdits codes sûrs après un appel à une méthode non sûre.
- La séparation en codes sûrs et non sûrs pourra alternativement : • être établie de façon permanente et inscrite dans le code ou les données du moteur d'exécution, • évoluer dynamiquement lors de l'exécution du système, • résulter d'une analyse d'un registre d'événements potentiellement dangereux.
- Les événements pourront être déclenchés par un mécanisme matériel et/ou par un composant logiciel différent du moteur d'exécution et/ou par le moteur d'exécution lui-même. - Les susdits "points de passage obligés" pourront être annotés afin que le moteur d'exécution puisse les différencier des autres instructions, notamment en utilisant un nom d'instruction (opcode) différent pour chaque type d'instruction annotée. - Le composant logiciel qui déclenche l'événement pourra notifier cet événement au moteur d'exécution à travers une structure de données partagées pouvant notamment consister en une simple variable booléenne et/ou comporter des informations complémentaires, comme, par exemple, un niveau de priorité, les méthodes qui sont considérées non sûres, des instructions concernant la procédure d'arrêt à utiliser. Cette structure de données partagée pourra être consultée par le moteur d'exécution systématiquement après l'exécution d'un certain nombre d'instructions ou par le moteur d'exécution lors de l'exécution de certaines instructions annotées des applets (ou instructions alternatives). - Les instructions correspondant à des invocations de méthodes potentiellement non sûres pourront être remplacées par des instructions spéciales reconnues par le moteur d'exécution, qui empêche alors tout empilement d'une "frame" non sûre.
- La plate- forme pourra posséder un second moteur d'exécution qui est appelé lors de la détection d'un événement et qui empêche tout empilement d'une "frame non sûre", ce second moteur d'exécution pouvant comporter pour chacune des "frames" non sûres un chronomètre comptabilisant des unités de temps écoulées depuis que la "frame" a été empilée et qui est utilisée par ledit moteur pour interrompre l'exécution des "frames" non sûres.
Des modes d'exécution de l'invention seront décrits ci-après, à titre d'exemples non limitatifs, concernant les trois phases principales du procédé, à savoir :
- le déclenchement d'un événement et sa détection par le moteur d'exécution, - les traitements effectués par le moteur suite à la détection d'un événement, et - les mécanismes permettant d'éviter l'empilement des "frames" non sûres.
En ce qui concerne le déclenchement et la détection des événements, trois variantes sont envisageables, ces trois variantes pouvant être combinées dans une irnplémentation :
Le déclenchement par interruption matérielle ("Hardware") : Cette solution consiste à traiter les événements déclenchés par un système d'interruptions matériel. Dans ce cas, le moteur détection est interrompu directement et aucun mécanisme spécifique n'est nécessaire.
Le déclenchement par le moteur d'exécution : Dans certaines situations, le moteur d'exécution peut déclencher lui-même l'événement. Dans ces cas particuliers, c'est donc le moteur qui, à la fois, déclenche l'événement et traite cet événement. En Java Card par exemple, tout rattrapage d'une exception de la classe "SecurityException" par une applet peut être détecté par la machine virtuelle.
Le déclenchement par un composant logiciel (qui nécessite un mécanisme spécifique de détection des événements) : Cette solution prévoit un déclenchement de manière asynchrone de l'événement par un autre composant logiciel de la plate-forme. Dans ce cas, le composant qui déclenche l'erreur doit notifier au moteur d'exécution la demande d'arrêt immédiat, par exemple à travers une structure de données partagée avec les composants pouvant demander un arrêt. Cette structure de données peut être un simple drapeau (variable booléenne) ou bien une structure plus complexe, contenant par exemple un niveau de priorité pour le message, les méthodes qui sont considérées non sûres au moment de rinterruption, des instructions concernant la procédure d'arrêt à utiliser, etc. Dans ce cas, il faut assurer la détection (et le traitement) de l'événement par le moteur d'exécution. Un moyen de satisfaire cette exigence est de programmer le moteur d'exécution de façon à ce qu'il consulte régulièrement l'état du drapeau. Cette approche peut être modulée selon la fréquence de consultation du drapeau.
Conformément à l'invention, la détection des événements peut s'effectuer grâce aux mécanismes suivants :
a) Un mécanisme d'inspection à intervalles réguliers : Dans son expression la plus simple, ce mécanisme comprend la programmation du moteur d'exécution de manière à vérifier l'état du drapeau systématiquement après l'exécution d'un certain nombre d'instructions.
b) Un mécanisme de détection du prolongement de vie potentiel : La consultation régulière du drapeau peut ralentir sensiblement l'exécution du code des applets. Une solution alternative consiste à ne consulter le drapeau que pour un sous-ensemble des instructions de l'applet, mais sans faire grossir le code de celle-ci : au lieu de réécrire le code de l'applet, on annote certaines instructions des applets qui constituent un sur-ensemble des points de passage obligés dans leur exécution, à partir de n'importe quelle instruction du code. Ce marquage peut se faire en remplaçant le nom des instructions choisies qui apparaît dans le code de l'applet (appelé "opcode" dans le jargon de Java) par un autre. Lors de l'exécution du code, chaque fois que l'interpréteur trouve une instruction marquée, il teste si un message d'arrêt est arrivé. Si c'est le cas, il déclenche la procédure d'arrêt de l'applet. Sinon, il interprète l'instruction normalement. Pour des raisons de sécurité, il est préférable que le drapeau soit maintenu comme une structure de données native, et donc pas accessible par les applets. L'utilisation d'une structure native permet d'éviter des vérifications additionnelles pour prouver que l'applet ne peut modifier elle-même la valeur du drapeau.
L'ensemble de points de passage obligés peut notamment résulter d'une analyse statique du code de l'applet. Si l'analyse se fait hors de la plateforme, les instructions à modifier peuvent être envoyées sur la plate-forme avec le code de l'applet. Par exemple, dans une plate-forme Java Card, elles peuvent être annexées dans un composant additionnel spécifique du format de fichiers "CAP". Dans une plate-forme "GlobalPlatform", elles peuvent faire partie des données des commandes "LNSTALL" ou "LOAD". Dans tous les cas, le procédé de chargement du code de l'application sur la plate-forme doit aussi assurer l'intégrité de cette information (par exemple, en utilisant un canal de communication sécurisé par l'utilisation d'un protocole spécial, comme les protocoles SCP01 et SCP02 utilisés dans "GlobalPlatform").
Il est préférable que l'annotation des instructions de l'applet se fasse lors de l'installation de l'applet sur la plate-forme, par exemple, pendant la phase d'édition de liens du code. L'avantage d'annoter le bytecode sur la carte est qu'il assure que toute applet peut être exécutée sur la plate-forme modifiée de façon à reconnaître les nouveaux "opcodes", même si elle a été conçue pour être exécutée sur une autre plate-forme.
Le déclenchement mixte : II consiste à combiner les méthodes de déclenchement précédemment décrites dans l'implantation (par exemple, déclenchement par interruption matérielle pour les exceptions de sécurité et déclenchement logiciel pour les autres événements).
En ce qui concerne le traitement des événements : L'action réalisée par le moteur d'exécution au moment de la détection d'un événement peut être arbitrairement complexe. Juste à titre d'exemple, elle peut effectuer . différents traitements (ou lancer différentes classes d'exceptions) en fonction du niveau de priorité attribué à l'événement par le composant qui la demande.
Par exemple, pour des événements de priorité basse, il peut être utile de laisser l'applet faire le nécessaire pour que son état interne reste sûr. Mais si l'applet doit être arrêtée pour des raisons de sécurité, il est préférable de l'empêcher d'exécuter tout autre code. Pour cela, une exception sécuritaire peut posséder un attribut x indiquant si l'événement a déjà été rattrapé par l'applet. Cet attribut est initialisé lors du lancement de l'exception, en fonction du niveau de priorité de la demande d'arrêt. Lors du rattrapage d'une exception sécuritaire, le moteur d'exécution vérifie la valeur de rattribut. Si l'attribut vaut faux, il accepte d'exécuter le code du bloc de rattrapage. Sinon, la "frame" non sûre au sommet de la pile est dépilée et le moteur traite la "frame" suivante (dans la pile). Le traitement de l'exception peut inclure l'affectation à vrai de rattribut x.
Le contrôle du rattrapage des exceptions permet d'omettre une vérification statique pour éviter qu'une applet puisse ne jamais rendre la main en utilisant un bloc de rattrapage qui se recouvre lui-même.

Claims

Revendications
1. Procédé permettant l'interruption sûre d'applications dans un système informatique distribué comportant un moteur d'exécution logiciel (ou machine virtuelle), caractérisé en ce qu'il comprend les étapes suivantes :
- attribution aux "frames" (structures de données empilées lors d'un appel de méthode) d'une annotation permettant de déterminer si la méthode correspondant à la "frame" est sûre ou pas, - la consultation d'une structure de données lors de l'exécution d'une instruction appartenant à un ensemble de "points de passage obligés", ledit ensemble étant conçu de manière à ce que, à partir de toute instruction de la méthode, le moteur d'exécution doit finir par atteindre un de ces "points de passage obligés", - le dépilement systématique, lors d'événements spécifiques, enregistrés dans ladite structure de données, des "frames" non sûres, ceci, jusqu'à ce qu'une "frame" sûre soit atteinte,
- la poursuite normale de l'exécution une fois qu'une "frame" sûre est atteinte,
- l'empêchement de tout nouvel empilement de "frame" non sûre à partir d'une "frame" sûre dès lors qu'un événement a été détecté.
2. Procédé selon la revendication 1, caractérisé en ce que les codes sûrs sont adaptés de manière à enrober tout appel à une méthode non sûre par un mécanisme de traitement des exceptions de façon à poursuivre proprement l'exécution desdits codes sûrs après un appel à une méthode non sûre.
3. Procédé selon la revendication 1, caractérisé en ce que la séparation en codes sûrs et non sûrs est établie de façon permanente et inscrite dans le code ou les données du moteur d'exécution.
4. Procédé selon la revendication 1, caractérisé en ce que la séparation en codes sûrs et non sûrs peut évoluer dynamiquement lors de l'exécution du système.
5. Procédé selon la revendication 4, caractérisé en ce que la séparation en codes sûrs et non sûrs résulte d'une analyse d'un registre d'événements potentiellement dangereux.
6. Procédé selon la revendication 1, caractérisé en ce que lesdits événements sont déclenchés par un mécanisme matériel (interruptions matérielles, par exemple).
7. Procédé selon la revendication 1, caractérisé en ce que lesdits événements sont déclenchés par le moteur d'exécution lui-même.
8. Procédé selon la revendication 1, caractérisé en ce que lesdits événements sont déclenchés par un composant logiciel différent du moteur d'exécution.
9. Procédé selon la revendication 1, caractérisé en ce que lesdits "points de passage obligés" sont annotés afin que le moteur d'exécution puisse les différencier des autres instructions, notamment en utilisant un nom d'instruction (opcode) différent pour chaque type d'instruction annotée.
10. Procédé selon la revendication 1, caractérisé en ce que ladite structure de données est une simple variable booléenne.
11. Procédé selon la revendication 1, caractérisé en ce que ladite structure de données comporte des informations complémentaires, comme par exemple un niveau de priorité, les méthodes qui sont considérées non sûres au moment du déclenchement de la procédure d'arrêt, ou des instructions concernant la procédure d'arrêt à utiliser.
12. Procédé selon la revendication 1, caractérisé en ce que ladite structure de données partagée est consultée par le moteur d'exécution systématiquement après l'exécution d'un certain nombre d'instructions.
13. Procédé selon la revendication 1, caractérisé en ce que ladite structure de données partagée est consultée par le moteur d'exécution lors de l'exécution de certaines instructions annotées des applications (ou instructions alternatives).
14. Procédé selon la revendication 1, caractérisé en ce que différents traitements sont effectués par le moteur d'exécution lors de la détection d'un événement, selon les informations associées à cet événement (priorité par exemple).
15. Procédé selon la revendication 1, caractérisé en ce que les instructions correspondant à des invocations de méthodes potentiellement non sûres pourront être remplacées par des instructions spéciales reconnues par le moteur d'exécution qui empêche alors tout empilement d'une "frame" non sûre.
16. Procédé selon la revendication 1, caractérisé en ce que la plate-forme possède un second moteur d'exécution qui est appelé lors de la détection d'un événement et qui empêche tout empilement d'une "frame" non sûre.
17. Procédé selon la revendication 16, caractérisé en ce que le second moteur d'exécution comporte pour chacune des "frames" non sûres un chronomètre comptabilisant les unités de temps écoulées depuis que la "frame" a été empilée et qui est utilisée par ledit moteur pour interrompre l'exécution desdites "frames" non sûres.
PCT/FR2004/002995 2003-11-28 2004-11-23 Procede permettant l'interruption sure d'applications dans un systeme informatique distribue comportant un moteur d'execution logiciel WO2005064466A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0313969 2003-11-28
FR0313969A FR2863074B1 (fr) 2003-11-28 2003-11-28 Procede permettant l'interrupton sure d'applications dans un systeme informatique distribue comportant un moteur d'execution logiciel.

Publications (2)

Publication Number Publication Date
WO2005064466A2 true WO2005064466A2 (fr) 2005-07-14
WO2005064466A3 WO2005064466A3 (fr) 2006-01-12

Family

ID=34566210

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2004/002995 WO2005064466A2 (fr) 2003-11-28 2004-11-23 Procede permettant l'interruption sure d'applications dans un systeme informatique distribue comportant un moteur d'execution logiciel

Country Status (2)

Country Link
FR (1) FR2863074B1 (fr)
WO (1) WO2005064466A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109271239A (zh) * 2018-08-10 2019-01-25 北京达佳互联信息技术有限公司 数据处理的方法、装置、系统、设备及介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001004743A2 (fr) * 1999-07-13 2001-01-18 Sun Microsystems, Inc. Procedes et appareil de gestion d'une application en fonction d'un cycle de vie d'application
EP1087295A2 (fr) * 1999-09-10 2001-03-28 Sun Microsystems, Inc. Appareil et méthode pour la prévention d'attaques en refus de service

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60032692T2 (de) * 1999-09-10 2007-10-11 Sun Microsystems, Inc., Palo Alto Beendung einer Gruppe verwandter Fäden durch Modifzierung des Programmzählers von ausgewählten Kellerspeicherrahmen
US6910209B2 (en) * 2001-04-30 2005-06-21 Sun Microsystems, Inc. Clean thread termination

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001004743A2 (fr) * 1999-07-13 2001-01-18 Sun Microsystems, Inc. Procedes et appareil de gestion d'une application en fonction d'un cycle de vie d'application
EP1087295A2 (fr) * 1999-09-10 2001-03-28 Sun Microsystems, Inc. Appareil et méthode pour la prévention d'attaques en refus de service

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
CZAJKOWSKI G ET AL: "JRes: a resource accounting interface for Java" PROCEEDINGS OF THE ACM OOPSLA CONFERENCE, 18 octobre 1998 (1998-10-18), pages 21-35, XP002265122 *
FEELEY M: "Polling efficiently on stock hardware" 1993, NEW YORK, NY, USA, ACM, USA, 9 juin 1993 (1993-06-09), pages 179-187, XP002349354 ISBN: 0-89791-595-X *
GREG BOLLELLA, BEN BROSGOL, PETER DIBBLE, STEVE FURR, JAMES GOSLING, DAVID HARDIN, MARK TURNBULL, RUDY BELLIARDI: "The Real-Time Specification for Java" [Online] juin 2000 (2000-06), ADDISON-WESLEY , XP002285373 ISBN: 0201703238 Extrait de l'Internet: URL:http://www.rtj.org/rtsj-V1.0.pdf> [extrait le 2004-06-16] Chapter 9 - "Asynchrony" le document en entier *
NIKANDER P ET AL: "Distributed policy management for JDK 1.2" PROCEEDINGS 1999 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM INTERNET SOC RESTON, VA, USA, 3 février 1999 (1999-02-03), XP002349393 ISBN: 1-891562-04-5 *
RUDYS A ET AL: "Termination in language-based systems" ACM TRANS. INF. SYST. SECUR. (USA), ACM TRANSACTIONS ON INFORMATION AND SYSTEMS SECURITY, MAY 2002, ACM, USA, vol. 5, no. 2, mai 2002 (2002-05), pages 138-168, XP002285372 ISSN: 1094-9224 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109271239A (zh) * 2018-08-10 2019-01-25 北京达佳互联信息技术有限公司 数据处理的方法、装置、系统、设备及介质

Also Published As

Publication number Publication date
FR2863074B1 (fr) 2006-02-24
FR2863074A1 (fr) 2005-06-03
WO2005064466A3 (fr) 2006-01-12

Similar Documents

Publication Publication Date Title
US8161552B1 (en) White list creation in behavior monitoring system
US8931097B2 (en) Method, computer software, and system for providing end to end security protection of an online transaction
US7690033B2 (en) Electronic computer system secured from unauthorized access to and manipulation of data
US7587724B2 (en) Kernel validation layer
US6167520A (en) System and method for protecting a client during runtime from hostile downloadables
AU767894B2 (en) Method and agent for the protection against the unauthorised use of computer resources
US7386859B2 (en) Method and system for effective management of client and server processes
EP3156931B1 (fr) Procédé de détection de vulnerabilités dans un serveur virtuel de production d&#39;un système informatique virtuel ou en nuage
US7979866B2 (en) Monitoring messages in a distributed data processing system
EP1967949A1 (fr) Procédé pour exécuter un programme relatif à plusieurs services, système et dispositif électroniques correspondants
KR20120079847A (ko) 컴퓨터 애플리케이션에서의 데이터 손실을 최소화하기 위한 방법 및 시스템
EP2174252A1 (fr) Protection automatique de systèmes informatiques contre des attaques qui exploitent des vulnérabilités de sécurité
WO2011045119A1 (fr) Gestion de disponibilité d&#39;un composant ayant un espace d&#39;adressage fermé
EP3971751A1 (fr) Procédé et système de détection et de hiérarchisation en temps réel d&#39;actifs de calcul affectés par des vulnérabilités publiquement connues basés sur des données de surveillance topologiques et transactionnelles
EP1960934B1 (fr) Procede pour securiser l&#39;execution d&#39;un code logiciel en langage intermediaire dans un appareil portatif
EP1700218B1 (fr) Procede de determination de caracteristiques operationnelles d&#39;un programme
WO2005064466A2 (fr) Procede permettant l&#39;interruption sure d&#39;applications dans un systeme informatique distribue comportant un moteur d&#39;execution logiciel
FR2737028A1 (fr) Architecture d&#39;habillage d&#39;applications pour une plate-forme informatique
CN115086081B (zh) 一种蜜罐防逃逸方法及系统
Ouffoué et al. Attack tolerance for services-based applications in the cloud
Sudmann TACOMA–fundamental abstractions supporting agent computing in a distributed environment
JP2001125800A (ja) 選択したスタックフレームのプログラムカウンタの変更による関連するスレッドグループの終了
CN116954867A (zh) 一种内核保护系统禁用方法、装置、设备及存储介质
FR3129552A1 (fr) Procédé de contrôle dans un système informatique, système informatique et programme d’ordinateur pour la mise en œuvre du procédé
Refsdal et al. Mandatory and Potential Choice: Comparing Event-B and STAIRS.

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

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

AL Designated countries for regional patents

Kind code of ref document: A2

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

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase