EP1880282A2 - Procede de verification de pseudo-code charge dans un systeme embarque, notamment une carte a puce - Google Patents

Procede de verification de pseudo-code charge dans un systeme embarque, notamment une carte a puce

Info

Publication number
EP1880282A2
EP1880282A2 EP06725034A EP06725034A EP1880282A2 EP 1880282 A2 EP1880282 A2 EP 1880282A2 EP 06725034 A EP06725034 A EP 06725034A EP 06725034 A EP06725034 A EP 06725034A EP 1880282 A2 EP1880282 A2 EP 1880282A2
Authority
EP
European Patent Office
Prior art keywords
verification
code
context
dictionary
application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP06725034A
Other languages
German (de)
English (en)
Inventor
Laurent Gauteron
Alexandre Terrasses du Derby Bât. A1 BENOIT
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales DIS France SA
Original Assignee
Gemplus Card International SA
Gemplus 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 Gemplus Card International SA, Gemplus SA filed Critical Gemplus Card International SA
Publication of EP1880282A2 publication Critical patent/EP1880282A2/fr
Withdrawn legal-status Critical Current

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/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44589—Program code verification, e.g. Java bytecode verification, proof-carrying code

Definitions

  • the present invention relates to a method of checking code coherence for an embedded system.
  • the invention relates more particularly, but not exclusively, to the field of applications in interpreted bytecode type (pseudo-code), loaded on a smart card.
  • embedded system in the broad sense is considered, especially as a system for any portable electronic device, for example a smart card, whose processing and storage resources are relatively limited.
  • an interpreted language is an uncompiled language whose execution of lines of code requires the presence of auxiliary means to interpret this code.
  • An example of such a language is the Java language
  • Java application (trademark) widely used in application solutions for smart cards.
  • the Java application or “applet” is interpreted by an associated Java virtual machine.
  • hardware solutions for example a dedicated chip, that implement the equivalent of the virtual machine.
  • virtual machine will refer indifferently to auxiliary means of software or hardware type for interpreting an associated interpreted language.
  • the pseudo-code (bytecode) verification for example and not exclusively Java (registered trademark), is an element key in the security of Java platforms (registered trademark).
  • This check consists in particular of ensuring the integrity and the conformity of a bytecode program to properties, for example the typing of the variables of the code, this bytecode program being interpreted by a virtual machine, that is to say say a stack machine (access memory stacking and depilating) and registers (indexed access memory boxes).
  • These verification operations are relatively complex and resource-intensive (RAM, processing time).
  • Java registered trademark
  • Java registered trademark
  • new applications for example Java (registered trademark) applets
  • Java registered trademark
  • These applets can be corrupted or tampered with and can make calls to unauthorized memory areas creating malfunctions on the virtual machine.
  • this verification has become extremely complicated in all embedded systems due to the limited resources available.
  • FIG. 1 provides an example code presenting a subroutine (B7 to RET) with a call to this subroutine (line 4: JSR B7).
  • a RET instruction is executed, the virtual machine executes the bytecode following the JSR having called the subroutine.
  • the address of this latter is stored on the stack of the virtual machine, but without any typing instance of this information: it is a numerical value in the stack that depends on the flow of execution.
  • the problem with this registration is that standard verifiers work on the basis of typing and do not have access to the numerical values themselves. It is therefore not possible to statically determine the parts of code calling the subroutine.
  • the pseudo-code verification ensures that no illegal manipulation on the typing of the elements used by the bytecode is performed.
  • Two properties are to be checked: - for each bytecode the height of the stack is always the same whatever the execution path,
  • integrity checking requires the storage of a lot of information. It has been shown then that it is sufficient to perform this memorization only for the jump targets.
  • the algorithm needs to store additional information like the instruction pointer or "program counter" (pointer on the line of code at the current verification point), the worklist (list of lines of codes to be checked later) and the current frame (set of typings of the registers and the stack at the point which is being examined, stored in the device's RAM).
  • Verification with a Proof Carrying Code is also known.
  • a proof component is calculated off map and then added to the program when it is transmitted on the map. This is to insert typing info into the code.
  • the verification on the card is greatly facilitated and requires very little RAM (Random Access Memory).
  • the disadvantage of this solution lies in the need for off-card pretreatment: the calculation of the proof; and in the larger size of the data
  • the Trusted Logic (registered trademark) verifier protected by patent FR 2 815 434 is also known.
  • the registers used by the virtual machine are exploded in a monomorphic manner, that is to say that each register has a unique variable typing. The RAM requirements are thus reduced.
  • the disadvantage of this solution is that you need to perform an off-board calculation to modify the methods to verify the two additional properties required.
  • the present invention intends to overcome the disadvantages of the prior art by proposing a code coherence verification method for an embedded system limiting the RAM consumed during processing.
  • the invention also does not require any pretreatment outside the portable electronic device, for example the smart card, and without adding elements in the application code.
  • the invention also aims at optimizing this management of the random access memory (RAM) during the verification phase.
  • the invention realizes bytecode verification by context (polyvariant) with a particular management of the current frames in order to consume less RAM.
  • context polyvariant
  • One is made to find himself, during a verification in sub-program, in the situation of a check in method. To do this, we proceed to a context change, saving the state of the current data (including including the stack frame jump targets, the current frame and the worklist).
  • the current frame of the routine subroutine is unified with the frame corresponding to the successor of the calling bytecode (JSR for example) of the preceding context, and then the previous context is restored.
  • JSR calling bytecode
  • the invention optimizes the memory consumption during the backup of the frames to the jump targets by establishing, over the water, a dictionary of stack frames (for example, the current frames to the jump targets that are stored when the context) to which these safeguards point.
  • a dictionary of stack frames for example, the current frames to the jump targets that are stored when the context
  • This mass of information is not compatible with the memory size available in the majority of portable electronic devices.
  • the advantage of the dictionary is not to unnecessarily multiply the number of identical stack frames saved in the memory and thus provides a good compression rate because of the properties of bytecodes and compilers. interest of the dictionary is to hold the memory consumed in the portable electronic devices with limited resources, and in the case of objects with large RAM memory, to allow the use of a portable electronic object having a smaller RAM memory and thereby generating a cost saving.
  • the invention easily integrates with existing solutions in order to improve performance by appropriate management of RAM.
  • the invention relates in its most general sense to a method for verifying an application that can be interpreted by a virtual machine, said application being loaded into a portable electronic device comprising at least one processor and a random access memory, the method consisting in carrying out, after the loading of said application in the device and before its validation, checks on the code of said application by a processing implemented by the processor characterized in that it comprises: during a call to a subroutine, a step of saving the current verification context in the RAM, a step of creating and activating a new verification context dedicated to the subroutine, at the end of the subroutine, a step of restoring the verification context previously saved.
  • the new verification context is initialized, for example only with the current frame.
  • the method further comprises immediately executing the checks on the code of the called routine when the call to it has been detected. More particularly, the method does not include a preliminary step of code demarcation.
  • the method does not involve recourse to resources external to said device with the exception of the power supply.
  • the context includes a worklist for navigating the application code tree.
  • the method further comprises, when checking a line of code of the application, a step of updating said working list with the possible successors of said line of code.
  • the context includes an instruction pointer and a current frame.
  • all or part of the identical frames are saved under a single address in a zone of the random access memory called a dictionary.
  • the identical frames are saved under a single address and a dictionary containing the frames to be saved is created. More precisely, for each new frame to be saved in the RAM, it is checked whether all or part of the new frame is present in the dictionary, and if it is the case, we use the pointer
  • the dictionary is decomposed into sections corresponding to homogeneous portions of the frames.
  • one of the homogeneous parts of the dictionary corresponds to the registers.
  • one of the homogeneous parts of the dictionary corresponds to the stack.
  • one of the homogeneous parts of the dictionary corresponds to non-variable registers in bytecode type.
  • the invention also relates to a smart card and a Java card comprising at least one Java virtual machine and an "applet" in Java interpretable language whose consistency must be verified, for the implementation of this verification method.
  • FIG. 1 represents an example of bytecodes including a subroutine
  • FIG. 2 represents an example of Java card architecture (registered trademark) for the implementation of the present invention
  • FIG. 3 illustrates the verification method according to the present invention
  • FIGS. 4 to 7 illustrate the evolution of the random access memory during the implementation of the verification method of the invention.
  • FIG. 8 illustrates the use of a dictionary to optimize the management of RAM.
  • the card module 1 comprises a microprocessor 2 driving a nonvolatile memory 3, for example of the flash type, a ROM 4 and a RAM RAM 5.
  • the ROM 4 stores the computer programs verifiers 41 of bytecode and the virtual machine 42 allowing the execution of the bytecode.
  • a virtual machine is understood to mean a machine which, when executing bytecodes, manages in RAM 5 a stack 51 and registers 52.
  • the stack 51 is a top-access memory in which the data is stacked and unstacked. .
  • the registers 52 are index access or free access memory boxes: one can access any information from the registers.
  • a program or application 31 to be verified is stored as a file in the non-volatile memory 3.
  • This program is in the form of pseudo-code or bytecodes whose invention proposes to check the integrity with respect to the virtual machine. 42.
  • the file 31 is a CAP (Converted APplet) file which is the file loaded by the virtual machine 42.
  • This file may contain several methods in the Java (registered trademark) sense, in which case the verification of the bytecode is method by method. If a method M2 is invoked in method M1, M1 being checked, the verifier considers M2 already checked or to check later, and proceeds to the next bytecode.
  • FIG. 1 Illustrated in Figure 1, an example of a bytecode of a method M is provided.
  • This bytecode includes a JSR subroutine jump in line 4 and an online RET return 11.
  • the subroutine called by the JSR extends from B7 to RET.
  • the bytecode verifier starts checking the method M.
  • the first bytecode B1 is taken 102. Since it is a traditional bytecode to be checked 104, a verification of the integrity criteria (typing) is done 106 on the bytecode in comparison with the registers and the stack of the current frame and this current frame is updated according to the bytecode (change of typing, new variable, ).
  • the current frame is the set of typings of the registers and stack of the virtual machine at the point that is being examined. Since it is the first bytecode, the current frame data 200 can be stored in memory as illustrated in FIG. 4. Additional data, for example the "worklist" 202 are also saved in memory; the working list
  • worklist includes the list of the following bytecode (s) to be checked and this is set to "line 2" to indicate that the next bytecode to be processed is that of line 2.
  • the worklist allows you to browse the code tree and cover all the scenarios of this journey by taking into account the multiple successors that can present each line of code.
  • "Multiple successors" of a line of code means the other lines of code that can be reached from that line.
  • the set of data of the current frame and complementary data (for example the worklist 202, the dictionary 203, the list 201 of the stack frames to the jump targets) constitute the current context.
  • the memory pointer pi of the current frame is stored, among other things, in the memory 204, the pointers p2 to p4 complementary data (working list, ...) and the end of context pointer p5.
  • the term "stack frame” or “frame” refers to the current frame at the jump target, that is at the moment when it is saved.
  • the context saved consists of all the data and structure 204 RAM data useful for checking a method: worklist 202, stack frame 200, in particular.
  • the verification algorithm can then resume, with the worklist set to "line 7" at the beginning of the subroutine.
  • the verification algorithm then applies to bytecodes B7, B8 and B9, the context data in memory being updated.
  • a unification is made with the successor of the corresponding JSR and the next item to be checked is searched for in the working list of the current context.
  • the subroutine is then complete and the previous context is restored 114, as shown in FIG.
  • a verification of the parameters of the method is carried out to ensure the integrity of the current typings with those of the called method.
  • the verification of this method is carried out independently of the method M as previously specified.
  • a dictionary of stack frames is used. Indeed, in many cases, the evolution of stack frames is slow and many of them have the same content.
  • the code includes three calls to subprograms.
  • the current frame can be saved in a part of the RAM 5 which is called the dictionary.
  • saving the current context in the RAM 5 then uses the pointer ptrl referencing the current frame.
  • the ptrl pointer associated with the stack frame of the dictionary identical to the current frame at the time of the jump is used for the backup of the current context.
  • the dictionary of unused stack frames (that is, when the associated pointer is not used in any context backup) is refined as subprograms are taken out. .
  • the dictionary can be built with partial stack-frame entries that are recurrent in order to optimally optimize the compression and the RAM memory gain.
  • this dictionary is not limited to stack frames and can contain any type of entries that are used when saving contexts, to minimize the size of these backups.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Debugging And Monitoring (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention concerne la vérification d'applications en langage interprété de type bytecode (pseudo-code) chargées sur des dispositifs électroniques portables, notamment une carte à puce. La présente invention se rapporte à un procédé de vérification d'une application (31) interprétable par une machine virtuelle (42), ladite application étant chargée dans un dispositif électronique portable (1) comprenant au moins un processeur (2) et une mémoire vive (5), le procédé consistant à procéder, après le chargement de ladite application dans le dispositif et avant sa validation, à des contrôles sur le code de ladite application par un traitement mis en œuvre par le processeur (2) caractérisé en ce qu'il comporte : lors d'un appel à un sous-programme, une étape de sauvegarde du contexte courant de vérification (200 à 203) dans la mémoire vive (5) , une étape de création et d' activation d'un nouveau contexte de vérification (206 à 209) dédié au sous- programme, lors de la fin du sous-programme, une étape de restauration du contexte de vérification (200 à 203) précédemment sauvegardé.

Description

PROCEDE DE VERIFICATION DE PSEUDO-CODE CHARGÉ DANS UN SYSTÈME EMBARQUÉ, NOTAMMENT UNE CARTE À PUCE
La présente invention concerne un procédé de vérification de cohérence de codes destinés à un système embarqué .
L'invention se rapporte plus particulièrement, mais non exclusivement, au domaine des applications en langage interprété de type bytecode (pseudo-code) , chargées sur une carte à puce .
On considère, par la suite, le terme « système embarqué » au sens large, notamment comme système destiné à tout dispositif électronique portable, par exemple une carte à puce, dont les ressources de traitement et de mémorisation sont relativement limitées .
De même, un langage interprété est un langage non compilé dont l'exécution des lignes de code nécessite la présence de moyens auxiliaires permettant d' interpréter ce code. Un exemple d'un tel langage est le langage Java
(marque déposée) largement répandu dans les solutions applicatives pour cartes à puce. L'application Java ou « applet » est interprétée par une machine virtuelle Java associée. Il existe également des solutions matérielles, par exemple une puce dédiée, qui implémentent l'équivalent de la machine virtuelle. Par la suite, le terme « machine virtuelle » référera indifféremment à des moyens auxiliaires de type logiciel ou matériel permettant d'interpréter un langage interprété associé.
La vérification de pseudo-code (bytecode) , par exemple et non exclusivement Java (marque déposée) , est un élément clé dans la sécurité des plateformes Java (marque déposée) . Cette vérification consiste notamment à s'assurer de l'intégrité et de la conformité d'un programme bytecode à des propriétés, par exemple le typage des variables du code, ce programme bytecode étant interprété par une machine virtuelle, c'est-à-dire une machine à pile (mémoire à accès empilant et dépilant) et à registres (cases mémoires à accès indexé) . Ces opérations de vérification sont relativement complexes et gourmandes en ressources (mémoire vive, temps de traitement) .
Avec le développement des cartes à puce, des solutions Java (marque déposée) ont été intégrées dans celles-ci. Au cours de la vie de la carte à puce, de nouvelles applications, par exemple des applets Java (marque déposée) , sont chargées dans cette carte afin d'être exploitées. Ces applets peuvent être corrompues ou trafiquées et peuvent réaliser des appels à des zones mémoires non autorisées créant des dysfonctionnements sur la machine virtuelle. Avec l'apparition des cartes à puce et l'intégration de programmes dans ces cartes, cette vérification est devenue extrêmement compliquée dans tous les systèmes embarqués eut égard au peu de ressources disponibles.
II est fréquent que des programmes de type bytecode mettent en oeuvre des appels à d'autres programmes ou à des sous-programmes. Une distinction peut être faite entre les appels à des programmes partageant le même contexte d'exécution que le programme appelant et les appels à des programmes d'autres méthodes présentant un contexte d'exécution dédié spécifique. Dans le cadre de l'invention, on s'intéresse particulièrement au cas des appels à des programmes ou sous-programmes partageant le même contexte d'exécution que le programme appelant. On utilisera par la suite le terme de « sous-programme » pour définir les parties de code qui peuvent être atteintes depuis d'autres parties de code partageant le même contexte d'exécution qu'il s'agisse indifféremment d'un programme appelé ou d'un sous-programme appelé (ensemble de lignes de code en commun avec le programme appelant) . De tels appels peuvent être mis en œuvre dans des fonctions du type « Goto », « If » ou lors d'appels à des macros.
On notera, à titre d'exemple, en langage Java (marque déposée) l'existence d'un couple d'instructions JSR (Jump to Sub-Routine - saut de sous-routine) et RET (return from subroutine - retour de sous-routine) mettant en œuvre des sous- routines ou sous-programmes. La figure 1 propose un exemple de code présentant un sous-programme (B7 à RET) avec un appel à ce sous-programme (ligne 4 : JSR B7) . Lorsqu'en fin de sous-programme, on exécute une instruction RET, la machine virtuelle exécute le bytecode suivant le JSR ayant appelé le sous-programme. Pour mémoriser l'information du JSR appelant, l'adresse de celui-ci est enregistrée sur la pile de la machine virtuelle, mais sans instance de typage de cette information : il s'agit d'une valeur numérique dans la pile qui dépend du flot d'exécution. Le problème de cet enregistrement réside dans le fait que les vérifieurs standard travaillent sur la base des typages et n'ont pas accès aux valeurs numériques à proprement parler. Il n'est donc pas possible de déterminer statiquement les parties de code appelant le sous-programme.
En effet, ces algorithmes de vérification appliquent l'algorithme d'unification pour chaque bytecode, algorithme dont le principe est le suivant : dans un bytecode, à un point de convergence d'une même variable avec deux typages différents (provenant de deux sauts de sous-programmes différents, par exemple) , la variable prend le typage du premier ancêtre commun aux deux typages (cette notion d'ancêtre commun découle des principes d'héritage du langage orienté objet type Java (marque déposée) ) . Et en cas d'incompatibilité de typage, un type appelé « TOP » est affecté à la variable. Puis lors de la modélisation du bytecode, si le typage attendu par le bytecode n'est pas compatible avec celui reçu, le code est rejeté.
Dans le cas des sous-progammes, deux appels différents au même sous-programme peuvent être réalisés alors même qu'une variable n'a pas le même typage. Ainsi il peut y avoir une erreur de vérification (typages incompatibles) alors qu'il n'y a pas de problème de typage (s' agissant de deux contextes différents, les deux typages ne pourront interférer pendant l'exécution du code par la machine virtuelle) .
Pour les cartes Java (marque déposée) , la vérification de pseudo-codes assure qu'aucune manipulation illégale sur le typage des éléments utilisés par le bytecode n'est réalisée. Deux propriétés sont à vérifier : - pour chaque bytecode la hauteur de la pile est toujours la même quelque soit le chemin d'exécution,
- pour chaque bytecode, il existe un typage des variables (registres) et des étages de pile qui est compatible avec le bytecode quel que soit le chemin d'exécution.
Pour ce faire, on explore tous les chemins d'exécution possibles de façon statique. Il s'agit d'une exécution abstraite du bytecode.
Pour chaque ligne de bytecode, la vérification de l'intégrité requiert la mémorisation de beaucoup d'informations. Il a été montré alors qu'il suffit d'effectuer cette mémorisation uniquement pour les cibles de sauts. De plus, l'algorithme a besoin de stocker des informations complémentaires comme le pointeur d' instruction ou « program counter » (pointeur sur la ligne de code au point de vérification courant) , la worklist (liste des lignes de codes à vérifier par la suite) et la frame courante (ensemble des typages des registres et de la pile au point qui est en train d'être examiné, enregistrés dans la mémoire vive du dispositif) .
On connaît des solutions de vérification externes - comme la solution de SUN MICROSYSTEMS (marque déposée) dans lesquelles le bytecode est initialement vérifié lors d'un traitement hors carte. Une fois qu'il est validé, il est chargé sur la carte à puce. L'inconvénient de ces solutions réside en ce qu'entre la vérification du bytecode et le chargement dans la carte, il existe une possibilité de trafiquer le code. Ces solutions ne garantissent donc pas l'intégrité entre le code initial et le code finalement chargé sur la carte puis exécuté.
On connaît également le vérifieur SUN MICROSYSTEMS (marque déposée) où la vérification est faite hors carte en milieu sécurisé et qui permet de signer le programme. La carte n'a plus qu'à vérifier la signature à la réception du programme .
Le portage de cette solution dans la carte présente des inconvénients, notamment une trop forte consommation de RAM.
On connaît également la vérification avec un composant de preuve (Proof Carrying Code) . Un composant de preuve est calculé hors carte puis rajouté au programme lors de sa transmission sur la carte. Il s'agit d'insérer des infos de typage dans le code. De ce fait, la vérification sur la carte est grandement facilitée et ne requiert que très peu de mémoire vive RAM (Random Access Memory) . L'inconvénient de cette solution réside dans la nécessité d'un prétraitement hors carte : le calcul de la preuve ; et dans la taille plus importante des données
(bytecode et preuves) à transmettre et à stocker : allongement des temps de transmission, augmentation de la consommation de bande passante.
On connaît également le vérifieur Trusted Logic (marque déposée) protégé par le brevet FR 2 815 434. Les registres utilisés par la machine virtuelle sont éclatés de façon monomorphe, c'est-à-dire que chaque registre a un unique typage de variable. Les besoins en RAM en sont ainsi réduits. L'inconvénient de cette solution est qu'il faut effectuer un calcul hors carte afin de modifier les méthodes pour qu'elles vérifient les deux propriétés supplémentaires requises .
La littérature tend à indiquer que certaines vérifications embarquées de bytecode sont infaisables. Notamment la publication « Java bytecode vérification : algorithme and formalisations » (http://pauillac.inria.fr /~xleroy/publi/bytecode-verification-JAR.pdf) précise que les algorithmes de vérification conventionnels polyvariants ne peuvent être mis en œuvre sur des équipements à faibles capacités de traitement comme les cartes Java (marque déposée) .
La présente invention entend remédier aux inconvénients de l'art antérieur en proposant un procédé de vérification de cohérence de codes destinés à un système embarqué limitant la mémoire vive consommée lors des traitements. L'invention ne requiert également aucun prétraitement à l'extérieur du dispositif électronique portable, par exemple la carte à puce, et sans ajout d'éléments dans le code de l'application. L'invention vise également à optimiser cette gestion de la mémoire vive (RAM) pendant la phase de vérification.
L'invention réalise une vérification de bytecode par contexte (polyvariant) avec une gestion particulière des frames courantes afin de consommer moins de mémoire vive. On fait en sorte de se trouver, lors d'une vérification en sous-programme, dans la situation d'une vérification en méthode. Pour ce faire, on procède à un changement de contexte, en sauvegardant l'état des données courantes (comprenant notamment la stack frame aux cibles de saut, la frame courante et la worklist) . En sortie de sous-programme, on unifie la frame courante du contexte courant du sous- programme avec la frame correspondant au successeur du bytecode appelant (JSR par exemple) du contexte précédent, puis on restaure le contexte précédent. L'objectif de cette réalisation est de pouvoir gérer les appels à des sous- programmes, par exemple JSR/RET, ceux-ci pouvant être imbriqués . Également, l'invention optimise la consommation mémoire lors de la sauvegarde des frames aux cibles de saut en établissant au fil de l'eau un dictionnaire de stack frames (par exemple, les frames courantes aux cibles de saut qui est mémorisé lors du changement de contexte) sur lesquelles pointent ces sauvegardes. Dans l'utilisation classique, un grand nombre d'informations supplémentaires et parfois redondantes doit être stocké pour gérer ces appels à des sauts. Cette masse d'informations n'est pas compatible avec la taille mémoire disponible dans la majorité des dispositifs électroniques portables. L'avantage du dictionnaire est de ne pas multiplier inutilement le nombre de stack frames identiques sauvegardées dans la mémoire et permet ainsi d'obtenir un bon taux de compression en raison des propriétés des bytecodes et des compilateurs. L'intérêt du dictionnaire est de faire tenir la mémoire consommée dans les dispositifs électroniques portables à ressources limitées, et dans le cas des objets disposant de large mémoire RAM, de permettre l'utilisation d'un objet électronique portable ayant une mémoire RAM plus réduite et d'engendrer ainsi un gain sur les coûts.
L'invention s'intègre facilement à des solutions déjà existantes afin d'en améliorer les performances par une gestion appropriée de la mémoire vive.
À cet effet, l'invention concerne dans son acception la plus générale, un procédé de vérification d'une application interprétable par une machine virtuelle, ladite application étant chargée dans un dispositif électronique portable comprenant au moins un processeur et une mémoire vive, le procédé consistant à procéder, après le chargement de ladite application dans le dispositif et avant sa validation, à des contrôles sur le code de ladite application par un traitement mis en œuvre par le processeur caractérisé en ce qu'il comporte : lors d'un appel à un sous-programme, une étape de sauvegarde du contexte courant de vérification dans la mémoire vive, une étape de création et d' activation d'un nouveau contexte de vérification dédié au sous-programme, lors de la fin du sous-programme, une étape de restauration du contexte de vérification précédemment sauvegardé .
Dans un mode de réalisation, lors de ladite étape de création et d' activation, le nouveau contexte de vérification est initialisé, par exemple uniquement avec la frame courante . Dans un mode de réalisation particulier, le procédé comprend, en outre, l'exécution immédiate des contrôles sur le code du sous-programme appelé lorsque l'appel à celui-ci a été détecté. Plus particulièrement, le procédé ne comporte pas d'étape de bornage préalable du code.
Dans un mode de réalisation, le procédé ne comporte pas de recours à des ressources extérieures audit dispositif à l'exception de l'alimentation électrique.
Dans un mode de réalisation, le contexte comprend une liste de travail permettant de parcourir l'arborescence du code de l'application. Le procédé comprend, en outre, lors du contrôle d'une ligne de code de l'application, une étape de mise à jour de ladite liste de travail avec les successeurs possibles de ladite ligne de code.
Particulièrement, le contexte comprend un pointeur d'instruction et une frame courante.
Dans un mode de réalisation, on sauvegarde tout ou partie des frames identiques sous une adresse unique dans une zone de la mémoire vive appelée dictionnaire.
Dans un mode de réalisation particulier, on sauvegarde les frames identiques sous une adresse unique et l'on crée un dictionnaire contenant les frames à sauvegarder. Plus précisément, pour chaque nouvelle frame à sauvegarder dans la mémoire vive, on vérifie si tout ou partie de la nouvelle frame est présente dans le dictionnaire, et si c'est le cas, on utilise le pointeur
(ptrl) associé, si ce n'est pas le cas, on l'enregistre dans le dictionnaire et on utilise le pointeur (ptr2) associé à ce nouvel enregistrement.
Dans un mode de réalisation, le dictionnaire est décomposé en sections correspondant à des parties homogènes des frames. Particulièrement, l'une des parties homogènes du dictionnaire correspond aux registres. Dans une variante, l'une des parties homogènes du dictionnaire correspond à la pile. Selon une autre variante, l'une des parties homogènes du dictionnaire correspond à des registres non variables en type de bytecode.
L'invention concerne également une carte à puce et une carte Java comprenant au moins une machine virtuelle Java et une « applet » en langage interprétable Java dont la cohérence doit être vérifiée, pour la mise en œuvre de ce procédé de vérification.
On comprendra mieux l'invention à l'aide de la description, faite ci-après à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux figures annexées où :
- la figure 1 représente un exemple de bytecodes comportant un sous-programme ;
- la figure 2 représente un exemple d'architecture de carte Java (marque déposée) pour la mise en œuvre de la présente invention ;
- la figure 3 illustre le procédé de vérification selon la présente invention ;
- les figures 4 à 7 illustrent l'évolution de la mémoire vive lors de la mise en œuvre du procédé de vérification de l'invention ; et
- la figure 8 illustre l'utilisation d'un dictionnaire pour optimiser la gestion de la mémoire vive.
Dans les modes de réalisation fournis ci-après à titre d'exemple, les sous-routines Java (marque déposée) appelées par des JSR ne sont qu'un exemple de sous-programmes pouvant être appelés de façon générale et sur lesquels l'invention porte . En référence à la figure 2, le module de carte 1 comprend un microprocesseur 2 pilotant une mémoire non- volatile 3 par exemple de type flash, une mémoire morte ROM 4 et une mémoire vive RAM 5. La mémoire ROM 4 stocke les programmes informatiques vérifieurs 41 de bytecode et la machine virtuelle 42 permettant l'exécution du bytecode. On entend par machine virtuelle une machine qui, lors de l'exécution de bytecodes, gère en mémoire vive 5 une pile 51 et des registres 52. La pile 51 est une mémoire à accès par le haut dans laquelle on empile et on dépile les données. Les registres 52 sont des cases mémoires à accès indexé ou accès libre : on peut accéder à n'importe quelle information des registres.
Un programme ou application 31 à vérifier est stocké sous forme de fichier dans la mémoire non-volatile 3. Ce programme se présente sous la forme de pseudo-code ou bytecodes dont l'invention propose de vérifier l'intégrité par rapport à la machine virtuelle 42.
Le fichier 31 est un fichier CAP (Converted APplet) qui est le fichier chargé par la machine virtuelle 42. Ce fichier peut contenir plusieurs méthodes au sens Java (marque déposée) , auquel cas la vérification du bytecode se fait méthode par méthode. Si une méthode M2 est invoquée dans la méthode Ml, Ml étant en train d'être vérifiée, le vérifieur considère M2 déjà vérifiée ou à vérifier plus tard, et passe au bytecode suivant.
Illustré par la figure 1, un exemple de bytecode d'une méthode M est fourni. Ce bytecode comprend un saut de sous- routine JSR en ligne 4 et un retour RET en ligne 11. La sous-routine appelée par le JSR s'étend de B7 à RET. En référence à la figure 3, le vérifieur de bytecode entame 100 la vérification de la méthode M. Le premier bytecode Bl est prélevé 102. Puisqu'il s'agit d'un bytecode traditionnel à vérifier 104, une vérification des critères d'intégrité (typage) est effectuée 106 sur le bytecode en comparaison avec les registres et la pile de la frame courante et cette frame courante est mise à jour en fonction du bytecode (changement de typage, nouvelle variable, ...) . La frame courante est l'ensemble des typages des registres et de la pile de la machine virtuelle au point qui et en train d'être examiné. Comme il s'agit du premier bytecode, les données frame courante 200 peuvent être enregistrées en mémoire comme illustrées par la figure 4. Des données complémentaires par exemple la « liste de travail » 202 sont également sauvées en mémoire ; la liste de travail
(worklist) comprend la liste du ou des bytecodes suivants à vérifier et celle-ci est mise à « ligne 2 » pour indiquer que le prochain bytecode à traiter est celui de la ligne 2.
La worklist permet de parcourir l'arborescence du code et de couvrir tous les cas de figures de ce parcours en prenant en compte les successeurs multiples que peut présenter chaque ligne de code. On entend par « successeurs multiples » d'une ligne de code, les autres lignes du code qui peuvent être atteintes depuis cette ligne. L'ensemble des données de la frame courante et des données complémentaires (par exemple la liste de travail 202, le dictionnaire 203, la liste 201 des stack frames aux cibles de saut) constituent le contexte courant .
Puis l'opération de vérification est reproduite pour les bytecodes B2 et B3 avec la mise à jour en mémoire RAM des données de contexte, notamment la liste de travail passe successivement à « ligne 3 » puis à « ligne 4 ». Lorsque le vérifieur rencontre 108 le saut de sous- routine JSR en ligne 4, la liste de travail est mise à jour à « ligne 5 ». Puis l'adresse de la JSR ou pointeur d'instruction, soit « ligne 4 » est stockée sur la pile de la frame ; c'est elle qui permet de « mémoriser » l'endroit depuis lequel le saut a eu lieu. Le vérifieur sauvegarde 110 alors le contexte courant dans la mémoire vive 5. La figure 5 illustre un mode de réalisation de la sauvegarde du contexte : on mémorise, entre autres, dans la mémoire 204 le pointeur pi de la frame courante, les pointeurs p2 à p4 des données complémentaires (liste de travail, ...) et le pointeur p5 de fin de contexte. Le terme « stack frame » ou « frame » correspond à la frame courante à la cible de saut, c'est-à- dire au moment où celle-ci est sauvegardée. Le contexte sauvegardé se compose de l'ensemble des données et structure 204 de données RAM utiles à la vérification d'une méthode : liste de travail 202, stack frame 200, notamment.
Un nouveau contexte de vérification est alors créé et activé 112. Illustrées par la figure 6, une nouvelle frame
206 et des données complémentaires 207 à 209 sont créées dans la mémoire RAM libre avec des pointeurs p' 1 à p'5 correspondants. Lors de cette création, la nouvelle frame courante 206 est initialisée à l'identique de la stack frame courante 200 au moment du saut de sous-routine. On a donc, à cet instant, des registres et une pile conformes au contexte d'où l'on vient, mais dans un nouveau contexte.
L'algorithme de vérification peut alors reprendre, la liste de travail étant mise à « ligne 7 » au début de la sous-routine.
L'algorithme de vérification s'applique alors sur les bytecodes B7, B8 et B9, les données de contexte en mémoire étant mises à jour. Lorsque le vérifieur rencontre le bytecode RET de la ligne 10, on fait une unification avec le successeur du JSR correspondant et on va chercher le prochain élément à vérifier dans la liste de travail du contexte en cours.
Lorsque la liste de travail est rendue vide, le problème de bornage des sous-routines qui est omniprésent dans les solutions de vérification de bytecode est, ici, naturellement réalisé par l'algorithme général de vérification : la liste de travail du nouveau contexte est vide signifiant la fin de la sous-routine.
La sous-routine est alors terminée et le contexte précédent est restauré 114, comme illustré par la figure 7.
Enfin, lorsqu'il n'y a plus de bytecode à vérifier, la vérification de la méthode M prend fin 116.
Dans le cas où une méthode est invoquée dans la méthode M, une vérification des paramètres de la méthode est réalisée pour s'assurer de l'intégrité des typages courants avec ceux de la méthode appelée. La vérification de cette méthode est réalisée indépendamment de la méthode M comme cela a été précisé précédemment.
Dans un mode de réalisation de l'invention, un dictionnaire des stack frames est utilisé. En effet, dans de nombreux cas, l'évolution des stack frames est lente et beaucoup d' entre-elles ont le même contenu.
En référence à la figure 8, le code comprend trois appels à des sous-programmes.
Lors de l'appel à un sous-programme en B2 , la frame courante peut être sauvegardée dans une partie de la mémoire RAM 5 que l'on appelle le dictionnaire. Dans ce cas, la sauvegarde du contexte courant dans la mémoire vive 5 utilise alors le pointeur ptrl référant la frame courante.
Lors d'un appel suivant à un sous-programme en B6, on utilise pour la sauvegarde du contexte courant le pointeur ptrl associé à la stack frame du dictionnaire identique à la frame courante au moment du saut.
Lorsqu'une telle stack frame n'est pas présente dans le dictionnaire 53, on crée une nouvelle entrée ptr2 dans le dictionnaire (cas de l'appel Bt de sous-programme).
Dans un mode de réalisation, on épure le dictionnaire des stack frames non utilisées (c'est-à-dire lorsque le pointeur associé n'est utilisé dans aucune sauvegarde de contexte) au fur et à mesure qu'on sort des sous-programmes.
Éventuellement, le dictionnaire peut être construit avec des entrées de stack frames partielles qui sont récurrentes afin s'optimiser au mieux la compression et le gain de mémoire RAM. À titre d'exemples, on peut séparer dans le dictionnaire les registres et la pile, ou séparer les registres en ensembles, particulièrement les registres non variables en « type de bytecode » (les variables globales déclarées en début de méthode du source Java ainsi que les paramètres et qui ne changent pas de typage au cours de la méthode) peuvent constituer un ensemble sur lequel chaque contexte dans la méthode pointera.
Il est entendu que ce dictionnaire ne se limite pas aux stack frames et peut contenir tout type d'entrées qui sont utilisées lors de la sauvegarde des contextes, afin de minimiser la taille de ces sauvegardes.

Claims

REVENDICATIONS
1. Procédé de vérification d'une application (31) interprétable par une machine virtuelle (42), ladite application étant chargée dans un dispositif électronique portable (1) comprenant au moins un processeur (2) et une mémoire vive (5) , le procédé consistant à procéder, après le chargement de ladite application dans le dispositif et avant sa validation, à des contrôles sur le code de ladite application par un traitement mis en œuvre par le processeur (2) caractérisé en ce qu'il comporte : lors d'un appel à un sous-programme, une étape de sauvegarde du contexte courant de vérification (200 à 203) dans la mémoire vive (5) , - une étape de création et d' activation d'un nouveau contexte de vérification (206 à 209) dédié au sous- programme, lors de la fin du sous-programme, une étape de restauration du contexte de vérification (200 à 203) précédemment sauvegardé.
2. Procédé de vérification selon la revendication 1, caractérisé en ce que, lors de ladite étape de création et d' activation, le nouveau contexte de vérification (206 à 209) est initialisé.
3. Procédé de vérification selon la revendication 1, caractérisé en ce qu'il comprend, en outre, l'exécution immédiate des contrôles sur le code du sous-programme appelé lorsque l'appel à celui-ci a été détecté.
4. Procédé de vérification selon la revendication 1, caractérisé en ce qu'il ne comporte pas d'étape de bornage préalable du code.
5. Procédé de vérification selon la revendication 1, caractérisé en ce qu'il ne comporte pas de recours à des ressources extérieures audit dispositif à l'exception de l'alimentation électrique.
6. Procédé de vérification selon la revendication 1, caractérisé en ce que le contexte comprend une liste de travail (202) permettant de parcourir l'arborescence du code de l'application (31) .
7. Procédé de vérification selon la revendication précédente, caractérisé en ce qu'il comprend, en outre, lors du contrôle d'une ligne de code de l'application, une étape de mise à jour de ladite liste de travail (202) avec les successeurs possibles de ladite ligne de code.
8. Procédé de vérification selon la revendication 1, caractérisé en ce que le contexte comprend un pointeur d'instruction et une frame courante.
9. Procédé selon la revendication 1, caractérisé en ce qu'on sauvegarde tout ou partie des frames identiques sous une adresse unique dans une zone de la mémoire vive (5) appelée dictionnaire (53) .
10. Procédé selon la revendication précédente, caractérisé en ce que pour chaque nouvelle frame à sauvegarder dans la mémoire vive (5) , on vérifie si tout ou partie de la nouvelle frame est présente dans le dictionnaire (53), et si c'est le cas, on utilise le pointeur (prtl) associé, si ce n'est pas le cas, on l'enregistre dans le dictionnaire (53) et on utilise le pointeur (ptr2) associé à ce nouvel enregistrement.
11. Procédé de vérification selon la revendication 9, caractérisé en ce que le dictionnaire (53) est décomposé en sections correspondant à des parties homogènes des frames.
12. Procédé de vérification selon la revendication 11, caractérisé en ce que l'une des parties homogènes du dictionnaire (53) correspond aux registres (52).
13. Procédé de vérification selon la revendication 11, caractérisé en ce que l'une des parties homogènes du dictionnaire (53) correspond à la pile (51) .
14. Procédé de vérification selon la revendication 11, caractérisé en ce que l'une des parties homogènes du dictionnaire (53) correspond à des registres (52) non variables en type de bytecode.
15. Carte à puce comprenant au moins une mémoire vive (5) et un processeur (2) pour la mise en œuvre du procédé selon l'une quelconque des revendications précédentes.
16. Carte Java de type carte à puce, comprenant une mémoire vive (5), un processeur (2), une machine virtuelle Java (42) et au moins une « applet » Java (31) dont la cohérence du code interprétable par la machine virtuelle doit être vérifiée, pour la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 14.
EP06725034A 2005-04-22 2006-03-14 Procede de verification de pseudo-code charge dans un systeme embarque, notamment une carte a puce Withdrawn EP1880282A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0551036A FR2884994A1 (fr) 2005-04-22 2005-04-22 Procede de verification de pseudo-code charge dans un systeme embarque, notamment une carte a puce
PCT/EP2006/060676 WO2006111441A2 (fr) 2005-04-22 2006-03-14 Procede de verification de pseudo-code charge dans un systeme embarque, notamment une carte a puce

Publications (1)

Publication Number Publication Date
EP1880282A2 true EP1880282A2 (fr) 2008-01-23

Family

ID=35229912

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06725034A Withdrawn EP1880282A2 (fr) 2005-04-22 2006-03-14 Procede de verification de pseudo-code charge dans un systeme embarque, notamment une carte a puce

Country Status (5)

Country Link
US (1) US7991953B2 (fr)
EP (1) EP1880282A2 (fr)
JP (1) JP5225071B2 (fr)
FR (1) FR2884994A1 (fr)
WO (1) WO2006111441A2 (fr)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2938091B1 (fr) * 2008-10-30 2010-12-31 Caps Entpr Procede de realisation d'un appel d'une instance d'une fonction, dispositif, programme d'ordinateur correspondant
US8626919B1 (en) 2008-11-07 2014-01-07 Google Inc. Installer-free applications using native code modules and persistent local storage
US20120159449A1 (en) * 2010-12-15 2012-06-21 International Business Machines Corporation Call Stack Inspection For A Thread Of Execution
EP2782006B1 (fr) * 2013-03-19 2018-06-13 Nxp B.V. Procédé et système permettant de vérifier un programme informatique sur une carte à puce
KR101583133B1 (ko) * 2014-03-26 2016-01-07 단국대학교 산학협력단 스택 기반 소프트웨어 유사도 평가 방법 및 장치
CN106845225A (zh) * 2016-12-20 2017-06-13 北京中电华大电子设计有限责任公司 一种java卡帧的边界检查方法
CN109144775A (zh) * 2018-06-30 2019-01-04 深圳市文鼎创数据科技有限公司 智能卡的应用数据备份恢复方法、电子设备及存储介质
RU2720254C1 (ru) * 2019-12-05 2020-04-28 Акционерное общество "Актив-софт" (АО "Актив-софт") Способ восстановления и обновления программного обеспечения на смарт-карте

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6092147A (en) * 1997-04-15 2000-07-18 Sun Microsystems, Inc. Virtual machine with securely distributed bytecode verification
FR2797963B1 (fr) * 1999-08-23 2002-11-29 Trusted Logic Protocole de gestion, procede de verification et de transformation d'un fragment de programme telecharge et systemes correspondants
US7120572B1 (en) * 2000-01-06 2006-10-10 Sun Microsystems, Inc. Memory efficient program pre-execution verifier and method
FR2840084A1 (fr) * 2002-05-27 2003-11-28 Gemplus Card Int Procede de verification de codes pour microcircuits a ressources limitees
US20040153709A1 (en) * 2002-07-03 2004-08-05 Burton-Krahn Noel Morgen Method and apparatus for providing transparent fault tolerance within an application server environment
US20050277432A1 (en) * 2003-11-26 2005-12-15 Viana Rodrigo B D Dynamic display generation for mobile communication devices

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
JP5225071B2 (ja) 2013-07-03
FR2884994A1 (fr) 2006-10-27
WO2006111441A2 (fr) 2006-10-26
US7991953B2 (en) 2011-08-02
WO2006111441A3 (fr) 2007-12-21
US20090049258A1 (en) 2009-02-19
JP2008537240A (ja) 2008-09-11

Similar Documents

Publication Publication Date Title
EP1880282A2 (fr) Procede de verification de pseudo-code charge dans un systeme embarque, notamment une carte a puce
FR2801118A1 (fr) Procede de chargement d'applications dans un systeme embarque multi-application, systeme embarque correspondant, et procede d'execution d'une application du systeme embarque
WO2001014958A2 (fr) Protocole de gestion, procede de verification et de transformation d'un fragment de programme telecharge et systemes correspondants
FR2667171A1 (fr) Support portable a micro-circuit facilement programmable et procede de programmation de ce micro-circuit.
EP1527387A2 (fr) Logiciel de generation de code d application informatique et langage de description de logiciel
EP1960934B1 (fr) Procede pour securiser l'execution d'un code logiciel en langage intermediaire dans un appareil portatif
WO2001088705A1 (fr) Procede de securisation d'un langage du type a donnees typees, notamment dans un systeme embarque et systeme embarque de mise en oeuvre du procede
EP2453356B1 (fr) Procédé, programme d'ordinateur et dispositif de sécurisation de code intermédiaire de programmation pour son exécution par une machine virtuelle
FR2686171A1 (fr) Carte a memoire de masse pour microordinateur avec facilites d'execution de programmes internes.
EP1649363B1 (fr) Procede de gestion des composants logiciels integres dans un systeme embarque
FR2642544A1 (fr) Systeme de traitement de donnees a programme de securite
EP1728354A1 (fr) Procede d'authentification dynamique de programmes par un objet portable electronique
WO2005073860A2 (fr) Procede de determination de caracteristiques operationnelles d'un programme
EP1112536A1 (fr) Procede de verification de transformateurs de codes pour un systeme embarque, notamment sur une carte a puce
WO2002084610A1 (fr) Procede et systeme de gestion de donnes destinees a etre stockees dans une carte a puce programmable
EP0838053B1 (fr) Procede et dispositif permettant a un programme fige de pouvoir evoluer
WO2008125479A1 (fr) Procédé d'exécution sécurisée d'une application
FR2864650A1 (fr) Procede de mise a jour d'applications pour carte a puce
WO2003027851A1 (fr) Procede et dispositif de verifieur de code optimise
FR2936327A1 (fr) Procede de telechargement d'un programme .net et dispositif pour celui-ci
FR2931567A1 (fr) Methode de recherche de classe et de fonction basee basee sur une carte .net et carte .net correspondante.
EP2252978B1 (fr) Carte a circuit integre ayant un programme d'exploitation modifiable et procede de modification correspondant
FR3010814A1 (fr) Procede et systeme de securisation d'un environnement d'execution informatique contre les attaques par confusion de type
EP3203405B1 (fr) Procede d'execution d'instructions d'applications orientees objet par un interpreteur
EP1760614B1 (fr) Mise à jour synchronisée de fichiers de données

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

R17D Deferred search report published (corrected)

Effective date: 20071221

DAX Request for extension of the european patent (deleted)
17P Request for examination filed

Effective date: 20080623

RBV Designated contracting states (corrected)

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

REG Reference to a national code

Ref country code: DE

Ref legal event code: 8566

17Q First examination report despatched

Effective date: 20090423

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: GEMALTO SA

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20160720

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20161201

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN