EP1112536A1 - Procede de verification de transformateurs de codes pour un systeme embarque, notamment sur une carte a puce - Google Patents

Procede de verification de transformateurs de codes pour un systeme embarque, notamment sur une carte a puce

Info

Publication number
EP1112536A1
EP1112536A1 EP00946037A EP00946037A EP1112536A1 EP 1112536 A1 EP1112536 A1 EP 1112536A1 EP 00946037 A EP00946037 A EP 00946037A EP 00946037 A EP00946037 A EP 00946037A EP 1112536 A1 EP1112536 A1 EP 1112536A1
Authority
EP
European Patent Office
Prior art keywords
code
transformed
source
codes
auxiliary functions
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.)
Ceased
Application number
EP00946037A
Other languages
German (de)
English (en)
Inventor
Christian Goire
Thomas Jensen
Pascal Fradet
Daniel Le Metayer
Ewen Denney
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.)
CP8 Technologies SA
Original Assignee
Centre National de la Recherche Scientifique CNRS
CP8 Technologies SA
Institut National de Recherche en Informatique et en Automatique INRIA
Bull CP8 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 Centre National de la Recherche Scientifique CNRS, CP8 Technologies SA, Institut National de Recherche en Informatique et en Automatique INRIA, Bull CP8 SA filed Critical Centre National de la Recherche Scientifique CNRS
Publication of EP1112536A1 publication Critical patent/EP1112536A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/52—Binary to binary
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 invention relates to a method for verifying code transformers for an on-board system.
  • the invention also relates to the application of such a method to a transformer for generating a code intended for a smart card.
  • the term "on-board system” must be considered in its most general sense II relates in particular to systems intended for a smart card, which constitutes the preferred application of the invention, but also to any system intended for a portable or mobile device comprising its own means for processing computerized data which will be referred to below. after "processing resources"
  • Modern embedded systems are equipped with data processing resources that allow them to fulfill increasingly complex and increasing functions.
  • data processing resources that allow them to fulfill increasingly complex and increasing functions.
  • a distinctive characteristic on-board systems compared to conventional computer systems (microcomputer, workstation, etc.), relate to the limitations they impose in terms of resources (memory size and power of microprocessors in particular)
  • resources memory size and power of microprocessors in particular
  • the so-called “transformed” code is obtained from the “source code” using a code transformer, generally external to the on-board system but which can also be resident in it. It is therefore necessary to show the equivalence between source code and transformed code
  • the method according to the invention makes it possible to systematically and modularly check the correction of code transformations
  • the method for verifying code transformers consists in specifying the meaning of two codes using a common virtual machine configured by functions that will be called "auxiliary functions".
  • auxiliary functions The differences between the two codes are expressed and grouped in the aforementioned auxiliary functions.
  • Each auxiliary function has two versions: a version in the source code and a version in the transformed code.
  • the first modules being identical, since they are common to both codes, there is no need to check if they are equivalent.
  • auxiliary functions considered two by two, are equivalent.
  • the subject of the invention is therefore a method of verifying a so-called source code transformer into a so-called transformed code intended for an on-board system, said source and transformed codes being associated with virtual machines, characterized in that it comprises minus the following steps: - the determination, for each of said source and transformed codes, of a first common subset, constituting a single virtual machine factoring the behavior of these two codes; determining, for each of said source and transformed codes, a second subset consisting of a plurality of so-called auxiliary functions, said auxiliary functions representing residual differences between said source and transformed codes; pairwise association of said auxiliary functions, a first auxiliary function of each pair belonging to said second subset associated with said source code and a second auxiliary function of each pair belonging to said second subset associated with said transformed code; verifying a property of correspondence determined between said auxiliary functions of all said pairs; and
  • Another subject of the invention is the application of such a method to a transformer for the generation of a code intended to be recorded in a smart card.
  • FIG. 1 schematically illustrates the process of transforming a source code into a final transformed code
  • FIGS. 2A and 2B schematically illustrate one of the essential characteristics of the method according to the invention
  • - Figure 3 schematically illustrates the application of the method according to the invention to a smart card
  • FIG. 1 schematically illustrates the process of transforming a code 1, which will be called “source code”, in the sense of original or initial code, into a final code 3, called “transformed code”, using of a code transformer 2.
  • This last organ can be a computer means or a specific piece of software.
  • the transformed code is intended to be resident in the on-board system 4 (solid line).
  • the transformer 2 can also be resident or downloaded in the on-board system: reference 4 '(in dotted lines).
  • the transformed code 3 After loading or recording in the on-board system 4-4 ', the transformed code 3 allows the execution of one or more tasks as needed, represented under the unique reference 5. It is assumed that the on-board system 4 has resources classical autonomous computing (not shown). A priori, the code transformation is carried out once and for all by a given transformer 2 or on rare occasions modification of version of the original code or source code 1, for example
  • first and second subsets An essential characteristic of the method according to the invention will consist in finding for each of the two codes two subsets, which will be called first and second subsets.
  • the first subsets form a virtual machine common to the two codes, source and transformed Therefore, it is therefore not necessary to check the equivalence of the first subsets
  • the second subsets made up of auxiliary functions, are however distinct from one code to another
  • the determination of the equivalence of the codes, source and transformed, is then reduced to the determination of the equivalence of all the pairs of auxiliary functions of the second subsets
  • the residual complexity of the auxiliary functions can be very reduced It follows that the above-mentioned equivalence determination becomes possible
  • FIGS. 2A and 2B very schematically illustrate the method according to the invention
  • the first subsets of the source code 1 and of the transformed code 3 form a common virtual machine 13
  • the second subsets, 10 and 30, each consist of a series of so-called auxiliary functions, whose equivalence must be checked
  • These auxiliary functions, 10 and 30, configure the common virtual machine 13
  • the equivalence of the two codes, source 1 and transformed 2 is therefore reduced to checking the equivalence of the auxiliary functions, 10 and 30, taken two by two, as will be shown below with reference to FIG. 2B.
  • the source and transformed codes are associated with first and second so-called virtual machines, respectively.
  • the first step consists in the definition of a single virtual machine (or operational semantics) allowing to factorize the behavior of the source code and the transformed code.
  • the differences between the two codes then appear through auxiliary functions which will be interpreted or implemented differently in the two codes.
  • a virtual machine can be represented by a set of rules of the form:
  • Premises are either conditions for applying a rule, that is to say Boolean expressions, or assignments to variables used to express a change of state. Premises use auxiliary functions to extract information from the state or express conditions.
  • Each rule indicates how the state of the machine evolves when the premises are checked and the instruction "Instructionl" is encountered.
  • One or more rules of this form are defined for each type of instruction in the code.
  • the second step consists in defining the types or data structures used in the two codes. We define basic types such as for example
  • the third step consists of the interpretation of types, references ⁇ , used in virtual machines
  • For each type ⁇ we define an interpretation for the source code [[#]] ,, and an ⁇ interpretation for the transformed code, , plus a relation R ⁇ between the two interpretations [[]] 5 and
  • the logical relations must be the relation "identity" for the observable types, ie of the types for which one wants to show that the two codes make the same result
  • These are usually printable and / or displayable types on a computer screen
  • These can be basic types, but also structured types representing, for example, a stack or variables of a given program
  • the fourth step consists in the interpretation of the auxiliary functions used in virtual machines For each auxiliary function f, we give its definition for the source code, noted Q /]] 5 , and its definition for the transformed code, noted [[/]] -.
  • the last step consists in showing that there exists a transformer r (figure 1 2) which satisfies the logical relations This can be done by checking that a given transformer r S ⁇ T satisfies the logical relation associated with the type of its argument, with S source code (figure 1 1) and T transformed code (figure 1 3) To do this it is necessary that it obey the following relation
  • the method according to the invention therefore has an important advantage because it allows great mechanization of the verification process, and above all allows it to be carried out successfully, since this verification is carried out on less complex sub-assemblies.
  • auxiliary functions 10 and 30, as illustrated in FIG. 2B, using a component 6, hardware or software. It has been assumed that there are n auxiliary functions, referenced 10 a , 10rise, ..., 10 practice ..., 10 ,,. ,, 10 inconvenienceand 20 a , 20 ⁇ , ..., 20 supplement. ..20 n-7 , 20 spirits, respectively. If the member 6 is material, it comprises as many checking circuits, 60 a , 60 / ,, ..., 60 ,, ..., 60 ⁇ - r, 60 fibre(represented arbitrarily in FIG.
  • the method according to the invention can be used both a posteriori, that is to say to verify an existing transformer, and a priori, as an aid to the development of a new transformer. It allows in particular, in the latter case, to determine its characteristics, so that it functions correctly, in other words so that the transformed code which will be generated by this transformer from the source code satisfies the requirement of above equivalence.
  • FIG. 3 schematically illustrates the architecture of a smart card, referenced 7 This figure shows only the elements essential for a good understanding of the process according to the invention
  • the smart card 7 notably comprises an input-output member 70 allowing communications with the outside world, a first memory member 71, fixed or programmable (of the "ROM”, “PROM”, “EPROM” or “EEPROM type "), and a random access memory member 72
  • the smart card 7 finally comprises a microprocessor or a microcontroller 73 interacting via bus with the other components of the smart card 7
  • the software architecture of such a smart card 7 obeys the ISO 7816-3 standard, resulting in a protocol layer ranging from the lowest layers associated with the input-output members 70, up to the highest layers associated with software applications stored in the smart card 7
  • These standards provide that transmissions are made in serial mode
  • the source code 1, once transformed by the code transformer 2, is transmitted to the smart card 7 to be recorded there , generally in the memory member 71, fixed or "semi-fixed", via the input-output member 70
  • the software application or applications processed by the smart card 7 can be permanently saved in the smart card 7, that is to say in the memory member 71, or transiently in the random access memory 72 In the latter case, the applications are downloaded via the input-output member 70
  • the card to chip 7 is of a multi-application, even multi-user type II It has therefore also been assumed that the smart card 7 processes m software applications, A ⁇ to A m , written in the transformed language 3
  • a class file is a unit of compilation and representation of the object code of a "Java” program
  • a CAP file groups together all the classes of the same “Java Card package” and only includes a single "constant pool”
  • a "Java Card package” is a "Java” construction for grouping classes and creating namespaces
  • a "constant pool” is a table associated with each class file for "Java” and with each "CAP” file for "Java Card” This table groups constants (character strings, integers,) It is used in the virtual machines of "Java” and “Java Card”
  • the transformation is non-trivial and global it replaces all the names (of packages, classes, fields, methods) by entities called “tokens", c is whole numbers of 7 or 8 bits These "tokens" serve as an index to access tables
  • the transformation groups all the class files of the same package into a CAP
  • the "Java Card” language is especially intended to be used on bank smart cards. It is therefore imperative to verify the correction of the transformation of a program (or "byte code") written in the virtual machine of the "Java” language. in a program written in the Java Card language virtual machine, that is to say to provide proof of the equivalence of these two programs
  • the first step consists in defining an operational semantics
  • One or more semantic rules are associated with each instruction of the "byte code".
  • the "byte code” is a portable assembler code.
  • object code for "Java” or “Java Card” virtual machines For example, the semantic rule associated with one of the instructions in this code, the "getfield” instruction can be described as follows:
  • the report consists of the code executed with the current instruction at the head (getfield / ' ; bc), a stack of operands (r :: ops), local variables (/), d 'a reference to the current class (c) and the heap (h).
  • the rule specifies the operations carried out during the execution of getfield /: -
  • the auxiliary function "constant_pool” uses the index / to obtain the reference f_ref of the field (a signature or a "token", depending on whether it is source or transformed code) in the appropriate "constant pool".
  • the reference ⁇ to the object whose field is to be read is found at the top of the stack. This reference makes it possible to find in the heap (h (r)) the dynamic class of the object c_ref (a qualified name or a pair of tokens depending on whether it is the source or transformed code) and the list of fields of subject
  • the getfield instruction changes the state by replacing the reference to the object with the value of the field and execution continues with the rest of the code (bc).
  • the second step is to define the types.
  • the Word type In the case of the "Java Card” language, we define the Word type to represent the storage unit:
  • Word Objectj-ef + Null + Boolean + Byte + Short (10), As an example of a constructed type, the type of a constant pool is
  • Constant_pool CPjndex ⁇ CPjnf o (11),
  • a "constant pool” is seen as a function taking an index (the CPjndex type is considered as basic) and making an entry (here a reference to a class, a method or a field)
  • the "byte" type code "is
  • the "byte code” is a sequence of instructions
  • the Instruction type lists all the instructions used in the "byte code” of "Java Card”
  • the third step is to interpret the types
  • CP index ame Class_name x Index (14)
  • a "constant pool” index consists of a class name (to indicate the "constant pool” to which we refer) and an index.
  • a “constant pool” index consists of a “package” "token” (in the example described, there is a “constant pool” unique by “package” or CAP file) and an index.
  • R C p_index is defined as a bijection such that: (16)
  • the name of the "package" of the class containing the "constant pool” referred to in the name-based model must be related to the "token" of the "package” containing the "constant pool” to which it is made reference in the model based on “tokens”.
  • the only constraint on the indices / and ' is that R c p jndex must be a bijection (the entries of the "constant pools” can therefore be grouped and reordered).
  • the fourth step consists of the interpretation of the auxiliary functions
  • auxiliary function "constantjpool" for the name-based model is:
  • the packjname function takes a class name and returns a "package" name and the envjname function takes a package name and a class name and finds the structure representing the designated class file in the class hierarchy.
  • the constant pool is extracted from the class file.
  • the "constant pool” is found in the environment (ie CAP files) using the env ok function and the package token.
  • the fifth step consists in proving that the auxiliary functions respect logical relations.
  • the sixth and last step of the method consists in determining a transformer such that the transformation of the code and of the data by this converter respects certain logical relationships.
  • references to "packages” are either names or “tokens” depending on the model.
  • the associated logical relation R paCk age_ r ef is defined simply as a bijection between the names of "package” and the “tokens” of "package”. It suffices to verify that the function of the converter carrying out the transformation of package names into "tokens" is indeed a bijection. On reading the above, it is easy to see that the invention achieves the goals it has set for itself.
  • the invention can find application whenever the device involved has only relatively limited computer resources, in particular with regard to the memory capacity (live or fixed) and / or the computing power of the processor used Mention may be made, by way of example, of electronic books, for example of the so-called “e-book” type, intended for downloading and storing data from websites, pocket calculators, for example so-called “organize” type, some mobile phones can be connected to the Internet, etc. In all these cases, it is necessary to have an optimized language to make the best use of the integrated IT resources.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Devices For Executing Special Programs (AREA)
  • Debugging And Monitoring (AREA)
  • Hardware Redundancy (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un procédé de vérification d'un transformateur de code source en un code transformé destiné à un système embarqué (7). Le procédé comprend au moins les étapes de détermination d'une machine virtuelle unique factorisant le comportement de ces deux codes (1, 3), la détermination, pour chacun desdits codes source (1) et transformé (3), d'une pluralité de fonctions dites auxiliaires représentant des différences résiduelles entre lesdits codes source (1) et transformé (3) et une étape consistant à vérifier une propriété de correspondance entre les fonctions auxiliaires, la vérification du transformateur de code (2) étant obtenue à partir de cette dernière étape. Application notamment aux cartes à puce (7).

Description

PROCÉDÉ DE VÉRIFICATION DE TRANSFORMATEURS DE CODES POUR UN SYSTÈME EMBARQUÉ, NOTAMMENT SUR UNE CARTE À PUCE
L'invention concerne un procédé de vérification de transformateurs de codes pour un système embarqué
L'invention concerne aussi l'application d'un tel procédé à un transformateur pour générer un code destiné à une carte à puce Dans le cadre de l'invention, le terme "système embarqué" doit être considéré dans son acception la plus générale II concerne notamment des systèmes destinés à une carte à puce, ce qui constitue l'application préférée de l'invention, mais également tout système destiné à un dispositif portable ou mobile comportant des moyens propres de traitement de données informatisés que l'on appellera ci-après "ressources de traitement"
Les systèmes embarqués modernes sont munis de ressources de traitement des données permettent de remplir des fonctions de plus en plus complexes et de plus en plus nombreuses Cependant, malgré la mise sur le marché de technologies et de composants de plus en plus performants, une caractéristique distinctive des systèmes embarqués, par rapport à des systèmes informatiques conventionnels (micro-ordinateur, station de travail, etc ), concerne les limitations qu'ils imposent en matière de ressources (taille mémoire et puissance des microprocesseurs notamment) Pour satisfaire ces contraintes, il est nécessaire de transformer le code destiné à être exécuté sur un système embarqué Les transformations ont pour but de produire un code plus efficace et plus économe en ressources
Pour fixer les idées, et à titre d'exemple non limitatif de code, on considérera dans ce qui suit un programme écrit dans la machine virtuelle du langage "JAVA" (marque déposée par SUN MICROSYSTEMS) qui présente l'intérêt de pouvoir être exécuté dans de nombreux environnements Les domaines d'application de ce langage se sont en effet multipliés notamment avec le développement important du réseau Internet De nombreuses applications logicielles de petite taille, dites "applets", sont écrites dans ce langage et exécutables par un navigateur de type "WEB" On se placera également dans le cadre de l'application préférée de l'invention, à savoir l'exécution d'un code de ce type par les ressources informatiques propres d'une carte à puce Comme il a été rappelé ci-dessus, malgré des progrès technologiques importants, la capacité mémoire de la carte à puce, ainsi que la puissance du microprocesseur qui l'équipe restent relativement limités II est également important que le code soit résident dans la carte à puce, car les transmissions entre celle-ci et un terminal hôte, quel qu'il soit, s'effectuent à basse vitesse Les standards actuels ne prévoient que des transmissions de type série Le besoin se fait donc sentir de disposer d'un code que l'on pourrait qualifier "d'allégé", en tout cas optimisé pour cet usage Pour ce faire, il a été proposé d'utiliser un langage dérivé de "JAVA", se présentant sous la forme d'une restriction de ce langage, à savoir le langage "JAVA CARD" " (marque déposée également par SUN MICROSYSTEMS)
Une complication supplémentaire vient du fait que les systèmes em- barques sont généralement utilisés dans des environnements qui requièrent les plus hautes garanties en matière, à la fois de fiabilité et de sécurité On peut citer à titre d'exemple les nouvelles versions de cartes à puce sur lesquelles on souhaite installer des applications logicielles multiples qui doivent coopérer harmonieusement sans révéler d'informations confidentielles En effet, a priori, ces multiples applications peuvent concerner des utilisateurs distincts Malgré la coopération précitée, on doit conserver un cloisonnement rigoureux, pour que les informations concernant un utilisateur donné restent confidentielles, pour le moins ne puissent pas être mises à la disposition d'un utilisateur non habilité à les connaître (lecture) et/ou à les manipuler (écriture et opérations connexes effacement, modification) En dehors de l'aspect "confidentialité", d'autres exigences sont à prendre en compte, notamment l'exigence dite "d'intégrité" pertes de données, modifications non conformes etc
Si on considère le code "source", dans le sens de "code initial", tel que par exemple le "byte code" du langage "JAVA" précité, ce dernier présente toutes les garanties nécessaires et remplit les exigences précitées, le "byte code" étant un programme écrit dans la machine virtuelle du langage "JAVA" En effet, de nombreux tests ont pu être effectués, ce pendant de longues périodes de temps
Le code dit "transformé" est obtenu à partir du "code source" à l'aide d'un transformateur de code, généralement extérieur au système embarque mais qui peut également être résident dans celui-ci II est donc nécessaire de montrer l'équivalence entre le code source et le code transformé
Cela peut s'effectuer en garantissant que les transformations effectuées sur le code ne changent en rien son comportement (d'un point de vue externe) et n'introduisent pas de failles de sécurité En d'autres termes, le code initial (avant transformation) doit être d'un point de vue logique équivalent au code résultant (après transformation)
Il est particulièrement difficile de garantir cette propriété en général, car les transformations ont un effet global sur le code et sur les représentations des données qu'il manipule De façon pratique, la complexité impliquée par cette opération ne permet pas une mise en œuvre dans des conditions économiques et/ou technologiques réalistes En outre, on doit bien comprendre que de tels besoins ne sont apparus que très récemment, notamment en conjonction avec le développement des technologies précitées de cartes à puce multi-apphcations et/ou multi-utilisateurs L'invention vise à répondre à ces besoins, sans nécessiter des procédures extrêmement longues et coûteuses
Le procédé selon l'invention permet de vérifier de manière systématique et modulaire la correction des transformations de codes
Dans le cadre de l'invention, deux formalismes, bien connus en soi seront utilisés de façon essentielle les sémantiques opérationnelles et les relations logiques Pour une description plus détaillée de ces formalismes, on se reportera avec profit, pour le premier, au livre de H R Nielson, et F Nielson, intitulé "Semantics with Applications A formai Introduction" Wι\ey, 1992, et, pour le second, au livre de J Mitchell "Foundations for Programming Languages", MIT Press, 1996
Selon une caractéristique essentielle de l'invention, le procédé de vérification des transformateurs de codes consiste à spécifier le sens de deux codes à l'aide d'une machine virtuelle commune paramétrée par des fonctions que l'on appellera "fonctions auxiliaires". Les différences entre les deux codes sont exprimées et regroupées dans les fonctions auxiliaires précitées. Chaque fonction auxiliaire possède deux versions : une version dans le code source et une version dans le code transformé. Les premiers modules étant identiques, puisque communs aux deux codes, il n'y a pas lieu de vérifier s'ils sont équivalents. Pour montrer l'équivalence des deux codes, il suffit donc de montrer que les fonctions dites auxiliaires, considérées deux à deux, sont équivalentes. Ces deux sous-ensembles peuvent être rendus beaucoup moins complexes que les deux ensembles représentés par les deux codes, source et transformé, considérés dans leur intégralité. Il s'ensuit que, selon le procédé de l'invention, la difficulté inhérente au processus de vérification est très fortement réduite, et de façon corrélative, le processus de vérification devient économiquement et technologiquement réalisable. L'invention a donc pour objet un procédé de vérification d'un transformateur de code dit source en un code dit transformé destiné à un système embarqué, lesdits codes source et transformé étant associés à des machines virtuelles, caractérisé en ce qu'il comprend au moins les étapes suivantes : - la détermination, pour chacun desdits codes source et transformé, d'un premier sous-ensemble commun, constituant une machine virtuelle unique factorisant le comportement de ces deux codes ; la détermination, pour chacun desdits codes source et transformé, d'un second sous-ensemble constitué d'une pluralité de fonctions dites auxiliaires, lesdites fonctions auxiliaires représentant des différences résiduelles entre lesdits codes source et transformé ; l'association par paire desdites fonctions auxiliaires, une première fonction auxiliaire de chaque paire appartenant audit second sous-ensemble associé audit code source et une seconde fonction auxiliaire de chaque paire appartenant audit second sous-ensemble associé audit code transformé ; la vérification d'une propriété de correspondance déterminée entre lesdites fonctions auxiliaires de toutes lesdites paires ; et la vérification que ladite transformation du code source en code transformé par ledit convertisseur respecte ladite propriété de correspondance déterminée.
L'invention a encore pour objet l'application d'un tel procédé à un transformateur pour la génération d'un code destiné à être enregistré dans une carte à puce.
L'invention va maintenant être décrite de façon plus détaillée en se référant aux dessins annexés, parmi lesquels : la figure 1 illustre schématiquement le processus de transformation d'un code source en un code transformé final ; les figures 2A et 2B illustrent schématiquement une des caractéristiques essentielles du procédé selon l'invention ; et - la figure 3 illustre schématiquement l'application du procédé selon l'invention à une carte à puce ;
On va maintenant décrire de façon détaillée le procédé de vérification de transformateurs de codes selon l'invention.
La figure 1 illustre schématiquement le processus de transformation d'un code 1 , que l'on appellera "code source", dans le sens de code origine ou initial, en un code final 3, dit "code transformé", à l'aide d'un transformateur de code 2. Ce dernier organe peut être un moyen informatique ou une pièce de logiciel spécifique. De façon habituelle, le code transformé est destiné à être résident dans le système embarqué 4 (en trait plein). Le transformateur 2 peut également être résident ou téléchargé dans le système embarqué : référence 4' (en traits pointillés).
Après chargement ou enregistrement dans le système embarqué 4-4', le code transformé 3 permet l'exécution d'une ou plusieurs tâches en tant que de besoin, représentées sous la référence unique 5. On suppose que le système embarqué 4 dispose de ressources informatiques autonomes classiques (non représentées). A priori, la transformation de code est effectuée une fois pour toutes par un transformateur donné 2 ou dans de rares occasions modification de version du code d'origine ou code source 1 , par exemple
Il est donc nécessaire que l'on puisse établir la preuve formelle que le code transformé 3 est équivalent au code source 1 Ce processus permet de vérifier si le transformateur 2 fonctionne de façon correcte
Cependant, comme il a été rappelé, si on considère, dans leur globalité, les deux ensembles formés par les codes, source et transformé, la théorie montre qu'une telle détermination n'est généralement pas possible de façon réaliste
Une caractéristique essentielle du procédé selon l'invention va consister à trouver pour chacun des deux codes deux sous-ensembles, que l'on appellera premier et second sous-ensembles Selon une caractéristique importante du procédé selon l'invention, les premiers sous-ensembles forment une machine virtuelle commune aux deux codes, source et transformé De ce fait, il n'est donc pas nécessaire de vérifier l'équivalence des premiers sous- ensembles
Les seconds sous-ensembles, constitués des fonctions auxiliaires, sont par contre distincts d'un code à l'autre La détermination de l'équivalence des codes, source et transformé, se réduit alors à la détermination de l'équivalence de toutes les paires de fonctions auxiliaires des seconds sous- ensembles Or, la complexité résiduelle des fonctions auxiliaires peut être très réduite II s'ensuit que la détermination d'équivalence précitée devient possible
Les figures 2A et 2B illustrent très schématiquement le procédé selon l'invention
Comme le montre plus particulièrement la figure 2A, les premiers sous-ensembles du code source 1 et du code transformé 3 forment une machine virtuelle commune 13 Les seconds sous-ensembles, 10 et 30, sont constitués chacun par une série de fonctions dites auxiliaires, dont l'équivalence devra être vérifiée Ces fonctions auxiliaires, 10 et 30, paramétrent la machine virtuelle commune 13 L'équivalence des deux codes, source 1 et transformé 2, se réduit donc à vérifier l'équivalence des fonctions auxiliaires, 10 et 30, prises deux à deux, comme il le sera montré ci-après en regard de la figure 2B.
Les étapes du procédé vont maintenant être décrites de façon plus détaillée.
Les codes source et transformé sont associés à des première et seconde machines dites virtuelles, respectivement.
La première étape consiste en la définition d'une machine virtuelle (ou sémantique opérationnelle) unique permettant de factoriser le comportement du code source et du code transformé. Les différences entre les deux codes apparaissent alors à travers des fonctions auxiliaires qui seront interprétées ou mises en oeuvre différemment dans les deux codes.
Une machine virtuelle peut se représenter par un ensemble de règles de la forme :
prémisse 1
prémisse n
étatl [Instruction ] => état2 (1 ).
Les prémisses sont, soit des conditions d'application d'une règle, c'est- à-dire des expressions booléennes, soit des affectations à des variables utilisées pour exprimer un changement d'état. Les prémisses font appel à des fonctions auxiliaires pour extraire des informations de l'état ou exprimer des conditions. Chaque règle indique comment l'état de la machine évolue lorsque les prémisses sont vérifiées et l'instruction "Instructionl" est rencontrée. On définit une ou plusieurs règles de cette forme pour chaque type d'instruction du code. La seconde étape consiste en la définition de types ou structures de données utilisés dans les deux codes On définit des types basiques comme par exemple
Basique = Nat | Bool | Nom (2),
et des types construits comme, par exemple
Environnement = Nom → Valeur Instructions = Instruction 1 I lnstructιon2 I (3),
La troisième étape consiste en l'interprétation de types, références θ, utilisés dans les machines virtuelles Pour chaque type < , on définit une interprétation pour le code source [[#]],, et unΘ interprétation pour le code transformé, , plus une relation Rθ entre les deux interprétations [[]]5 et
[[]]j Ces relations, appelées relations logiques, respectent la structure des types Pour des types simples, elles doivent être définies explicitement , pour des types structurés, elles sont déduites des types des composants de la structure Par exemple, pour les paires
(a, b) RΘ βι (a b') > a Rθ1 a' Λ b Rθ2b' (4),
relation dans laquelle &\ et 62 sont des types et a, b, a' et b' des éléments de type
Il en est de même pour les fonctions
f Rθ1→θ2 f' <=> Va, a' a Rθ1 a' z=> f a Rθ2 f a' (5)
Les relations logiques doivent être la relation "identité" pour les types observables, c'est à dire des types pour lesquels on veut montrer que les deux codes rendent le même résultat II s'agit habituellement de types imprimables et/ou affichables sur un écran informatique Cela peut être des types basiques, mais également des types structurés représentant, par exemple, une pile ou des variables d'un programme donné La quatrième étape consiste en l'interprétation des fonctions auxiliaires utilisées dans les machines virtuelles Pour chaque fonction auxiliaire f, on donne sa définition pour le code source, notée Q/]]5 , et sa définition pour le code transformé, notée [[/]]-.
La détermination de l'équivalence consiste à montrer que les définitions des fonctions auxiliaires respectent les relations logiques Plus précisément, pour chaque fonction auxiliaire f θ→ &, on montre
II s'ensuit que les deux machines virtuelles sont en relation, c'est-à- dire que
Rtype- tat (7)
Comme les relations sont l'identité pour les types observables, les codes source et transformé sont observationellement identiques
La dernière étape consiste à montrer qu'il existe un transformateur r (figure 1 2) qui satisfait les relations logiques Cela peut être fait en vérifiant qu'un transformateur donné r S → T satisfait la relation logique associée au type de son argument, avec S code source (figure 1 1 ) et T code transformé (figure 1 3) Pour ce faire il est nécessaire qu'il obéisse à la relation suivante
II vient d'être montré que les relations logiques spécifient un ensemble de contraintes On peut donc en extraire un transformateur 2 correct par construction, en appliquant des techniques de raffinement ou d'extraction, en faisant appel à un des assistants de preuve appropriés..
Le procédé selon l'invention présente donc un avantage important car il permet une grande mécanisation du processus de vérification, et surtout permet de le conduire à bien, car cette vérification est menée sur des sous- ensembles moins complexes.
Si la transformation du code source 1 peut se décrire comme une succession de transformations plus simples, cette méthode peut s'appliquer pour montrer chaque transformation indépendamment. Il s'ensuit qu'elle présente un grand avantage de modularité.
La vérification ne doit être effectuée que sur les sous-ensembles de fonctions auxiliaires 10 et 30, comme illustré par la figure 2B, à l'aide d'un organe 6, matériel ou logiciel. On a supposé qu'il existe n fonctions auxiliaires, référencées 10a, 10„, ... , 10„ ... , 10,,.,, 10„ et 20a, 20ύ, ... , 20„ ...20n-7, 20„, respectivement. Si l'organe 6 est matériel, il comporte autant de circuits vérificateurs, 60a, 60/,, ... , 60,, ... , 60π-r, 60„ (représentés arbitrairement sur la figure 2B par le symbole d'un comparateur), que de paires de fonctions auxiliaires à vérifier, par exemple le circuit vérificateur 60, pour la paire de fonctions 10, et 30,. La ou les sortιe(s) de cet organe 6, sous la référence unique 61 , indique(nt) que la relation logique entre toutes les paires possibles de fonctions auxiliaires correspondantes des codes source 1 et transformé 3 est satisfaite. Cette série d'opérations est suffisante pour apporter la preuve formelle de l'équivalence des deux codes, dans leur globalité.
Il est à noter que le procédé selon l'invention est utilisable aussi bien, a posteriori, c'est-à-dire pour vérifier un transformateur existant, qu'a priori, comme une aide au développement d'un nouveau transformateur. Elle permet notamment, dans ce dernier cas, d'en déterminer les caractéristiques, pour qu'il fonctionne correctement, en d'autres termes pour que le code transformé qui sera généré par ce transformateur à partir du code source satisfasse l'exigence d'équivalence précitée.
On va maintenant se placer dans le cadre des cartes à puce. La figure 3 illustre schématiquement l'architecture d'une carte à puce, référencée 7 On n'a représenté sur cette figure que les éléments essentiels à la bonne compréhension du procédé selon l'invention
La carte à puce 7 comprend notamment un organe d'entrée-sortie 70 permettant des communications avec le monde extérieur, un premier organe de mémoire 71 , fixe ou programmable (de type "ROM", "PROM", "EPROM" ou "EEPROM"), et un organe de mémoire vive 72 La carte à puce 7 comprend enfin un microprocesseur ou un microcontrôleur 73 dialoguant par l'intermédiaire de bus avec les autres composants de la carte à puce 7
L'architecture logicielle d'une telle carte à puce 7 obéit à la norme ISO 7816-3, se traduisant par une couche protocolaire allant des couches les plus basses associées aux organes d'entrée-sortie 70, jusqu'aux couches les plus hautes associées aux applications logicielles enregistrées dans la carte a puce 7 Ces normes prévoient que les transmissions s'effectuent en mode série Le code source 1 , une fois transformé par le transformateur de code 2, est transmis à la carte à puce 7 pour y être enregistré, généralement dans l'organe de mémoire 71 , fixe ou "semi-fixe", via l'organe d'entrée-sortie 70 La ou les applications logicielles traitées par la carte à puce 7 peuvent être enregistrées à demeure dans la carte à puce 7, c'est-à-dire dans l'organe de mémoire 71 , ou de façon transitoire dans la mémoire vive 72 Dans ce dernier cas les applications sont téléchargées via l'organe d'entrée-sortie 70 Dans l'exemple décrit, il a été supposé que la carte à puce 7 est d'un type multi- applications, voire multi-utilisateurs II a donc été également supposé que la carte à puce 7 traite m applications logicielles, A\ à Am, écrites dans le langage transformé 3
Un des langages couramment utilisés pour les cartes à puce est, comme il a été rappelé, le langage "Java Card" Il s'agit d'un langage dédié à la programmation des cartes à puce, langage qui constitue une restriction du langage "Java" La carte 7 peut également stocker un convertisseur supplémentaire effectuant des conversions in situ au chargement sur des parties de codes Les étapes du procédé selon l'invention qui viennent d'être décrites dans un cadre général, vont être illustrées plus particulièrement dans ce cadre d'application préférée
Comme il est connu, une implantation du langage "Java Card" fait appel à un convertisseur qui transforme des fichiers dits "de classes" en fichiers "CAP" Un fichier de classe est une unité de compilation et de représentation du code objet d'un programme "Java" Un fichier CAP regroupe toutes les classes d'un même "package Java Card" et ne comporte qu'un unique "constant pool" Un "package Java Card" est une construction "Java' pour regrouper des classes et créer des espaces de noms Pour sa part, un "constant pool" est une table associée à chaque fichier de classe pour "Java" et à chaque fichier "CAP" pour "Java Card" Cette table regroupe des constantes (chaînes de caractères, entiers, ) Elle est utilisée dans les machines virtuelles de "Java" et "Java Card" La transformation est non triviale et globale elle remplace tous les noms (de packages, de classes, de champs, de méthodes) par des entités appelées "tokens", c'est-à-dire des nombres entiers de 7 ou 8 bits Ces "tokens" servent d'index pour accéder à des tables De plus, la transformation regroupe tous les fichiers de classes d'un même package en un fichier CAP (avec fusion des "constant pools" et réorganisation des tables de méthodes)
Le langage "Java Card" est notamment destiné à être utilisé sur des cartes à puce bancaires II est donc impératif de vérifier la correction de la transformation d'un programme (ou "byte code") écrit dans la machine virtuelle du langage "Java" en un programme écrit dans la machine virtuelle du langage "Java Card", c'est-à-dire d'apporter la preuve de l'équivalence de ces deux programmes
Cette preuve formelle va être apportée en exécutant les étapes du procédé selon l'invention
La première étape consiste en la définition d'une sémantique opérationnelle
On associe à chaque instruction du "byte code" une ou plusieurs règles sémantiques Le "byte code" est un code assembleur portable C'est le code objet pour les machines virtuelles "Java" ou "Java Card" Par exemple, la règle sémantique associée à l'une des instructions de ce code, l'instruction "getfield" peut se décrire ainsi:
f_ref - constant_pool (c)(i)
(c_ref, iv) := h(τ) v := iv(f_ref)
("getfield /; bc, r :: ops, I, c, h> =z> (bc, v :: ops, 1, c, h) (9).
Dans l'exemple, l'état se compose du code exécuté avec l'instruction courante en tête (getfield /'; bc), d'une pile d'opérandes (r :: ops) , des variables locales (/), d'une référence à la classe courante (c) et du tas (h). La règle spécifie les opérations effectuées lors de l'exécution de getfield / : - La fonction auxiliaire "constant_pool" utilise l'index / pour obtenir la référence f_ref du champ (une signature ou un "token", selon qu'il s'agit du code source ou transformé) dans le "constant pool" approprié.
La référence τ à l'objet dont le champ doit être lu est trouvée en sommet de pile. Cette référence permet de trouver dans le tas (h(r)) la classe dynamique de l'objet c_ref (un nom qualifié ou une paire de tokens selon qu'il s'agit du code source ou transformé) et la liste des champs de l'objet
(iv).
En utilisant la référence précédemment calculée et la liste des champs, le champ est lu (v := iv(f_ref)). - L'instruction getfield change l'état en replaçant la référence à l'objet par la valeur du champ et l'exécution se poursuit avec la suite du code (bc). La deuxième étape consiste en la définition des types. Dans le cas du langage "Java Card", on définit le type Word pour représenter l'unité de stockage :
Word = Objectj-ef + Null + Boolean + Byte + Short (10), Comme exemple de type construit, le type d'un constant pool est
Constant_pool = CPjndex →CPjnf o (11 ),
avec
CP nfo = Class_ref + Method_ref + Fιeld_ref (12)
Dans l'exemple, un "constant pool" est vu comme une fonction prenant un index (le type CPjndex est considéré comme basique) et rendant une entrée (ici une référence à une classe, une méthode ou un champ) Le type du "byte code" est
Bytecode = Instruction + Bytecode, Bytecode Instruction = getfieldCPjndex + Invokevirtual Cpjndex + (13)
Le "byte code" est une séquence d'instructions Le type Instruction énumère toutes les instructions utilisées dans le "byte code" de "Java Card"
La troisième étape consiste en l'interprétation des types
Dans le cas de "Java Card", l'interprétation pour le code source, sous la forme de fichiers de classe (qui utilise des noms), est notée ™».* et l'interprétation pour le code transformé sous la forme de fichiers CAP (qui utilise des "tokens") est notée [[]]toA. A titre d'exemple, le type [[CP index ame est vérifié pour le code source
[[CP index ame = Class_name x Index (14) Dans le modèle à base de noms, un index de "constant pool" est constitué d'un nom de classe (pour indiquer le "constant pool" auquel on fait référence) et d'un index.
Le type [[CP index ]];oA. est vérifié pour le code transformé :
[[CP index J]toAr = Package_token x Index (15).
Un index de "constant pool" est constitué d'un "token" de "package" (dans l'exemple décrit, il existe un "constant pool" unique par "package" ou fichier CAP) et d'un index.
La relation RCp_index est définie comme une bijection telle que : (16)
(c_name,i) RCp_index (pjtok, i') => pack_name(c_name) RpaCkage_rei pjtok
Le nom du "package" de la classe contenant le "constant pool" auquel il est fait référence dans le modèle à base de noms doit être en relation avec le "token" du "package" contenant le "constant pool" auquel il est fait référence dans le modèle à base de "tokens". La seule contrainte sur les index / et ' est que Rcpjndex doit être une bijection (les entrées des "constant pools" peuvent donc être regroupées et réordonnées).
La quatrième étape consiste en l'interprétation des fonctions auxiliaires
Par exemple, la version de la fonction auxiliaire "constantjpool" pour le modèle à base de noms est :
[constant oolL = cpjπame (17),
avec
cp_name c = let (..., cp, ...) = env_name(pack_name(c))(c) (18). in cp
La fonction packjname prend un nom de classe et rend un nom de "package" et la fonction envjname prend un nom de package et un nom de classe et trouve dans la hiérarchie de classes la structure représentant le fichier de classe désigné. Le constant pool est extrait du fichier de classe.
Pour le modèle à base de "tokens", la version de la fonction auxiliaire []constant_pool]]toJt est :
[[constant _pool]]toAr = cp_tok (1 9),
avec :
cp_tok c = let (..., cp, ...) = envj;ok(p) (20) in cp
Le "constant pool" est trouvé dans l'environnent (c'est-à-dire les fichiers CAP) à l'aide de la fonction env ok et du token de package.
La cinquième étape consiste à prouver que les fonctions auxiliaires respectent des relations logiques.
Si on se reporte de nouveau à l'exemple de la fonction d'accès au "constant pool", il est nécessaire de déterminer que :
[constant oolJL Rc Jndex → cp_,nfo [[constant oolL (21 )
La relation Rcp_ιndex → cp_mfo est complètement définie en fonction des relations RCp_ιnde et Rcpjnfo- En se servant de cette définition, on montre qu'il suffit de vérifier que :
/(c_name, i)(p_tok, i') tels que (c_name, i) RCp_,ndex (p_tok, i') cp(i) RcP nfo cp'(i') (22), avec :
(..., cp, ...) = env_name(pack_name(c_name))(c_name) (..., cp', ...) = env ok(p ok) (23).
La preuve se fonde sur la définition de Rcpjnto et la propriété rappelée ci-dessus : (24)
(c_name, i) Rcpjndex (pj k, i') ==> pack_name(c_name) Rpackage_ref p _tok
La sixième et dernière étape du procédé consiste à déterminer un transformateur tel que la transformation du code et des données par ce convertisseur respecte des relations logiques déterminées. Par exemple, les références à des "packages" sont, soit des noms, soit des "tokens" suivant le modèle. La relation logique associée RpaCkage_ref est définie simplement comme une bijection entre les noms de "package" et les "tokens" de "package". Il suffit de vérifier que la fonction du convertisseur réalisant la transformation des noms de package en "tokens" est effectivement une bijection. A la lecture de ce qui précède, on constate aisément que l'invention atteint bien les buts qu'elle s'est fixés.
Il doit être clair cependant que l'invention n'est pas limitée aux seuls exemples de réalisations explicitement décrits, notamment en relation avec les figures 2 et 3. Enfin, bien que le procédé ait été décrit de façon détaillée dans le cas de la transformation d'un programme de la machine virtuelle du langage "Java" en un programme de la machine virtuelle du langage "Java Card", particulièrement intéressant pour les applications de type carte à puce ou similaire, l'invention n'est en aucun cas limité à cette application particulière. L'invention peut trouver application à chaque fois que le dispositif impliqué ne dispose que de ressources informatiques relativement limitées, notamment en ce qui concerne la capacité mémoire (vive ou fixe) et/ou la puissance de calcul du processeur utilisé On peut citer à titre d'exemple des livres électroniques, par exemple du type dit "e-book", destinés à télécharger et stocker des données en provenance de sites Internet, des calculateurs de poche, par exemple du type dit "organiser", certains téléphones mobiles pouvant être connectés au réseau Internet, etc. Dans tous ces cas, il est nécessaire de disposer d'un langage optimisé pour utiliser au mieux les ressources informatiques intégrées.

Claims

REVENDICATIONS
1. Procédé de vérification d'un transformateur de code dit source en un code dit transformé destiné à un système embarqué, lesdits codes source et transformé étant associés à des machines virtuelles, caractérisé en ce qu'il comprend au moins les étapes suivantes :
- la détermination, pour chacun desdits codes source (1 ) et transformé (3), d'un premier sous-ensemble (13) commun constituant une machine virtuelle unique factorisant le comportement de ces deux codes (1 , 3) ;
- la détermination, pour chacun desdits codes source (1 ) et transformé (3), d'un second sous-ensemble (10, 30) constitué d'une pluralité de fonctions dites auxiliaires (10, - 30,) utilisées par ladite machine virtuelle unique, lesdites fonctions auxiliaires (10, - 30,) représentant des différences résiduelles entre lesdits codes source (1 ) et transformé (3) ; - l'association par paire desdites fonctions auxiliaires, une première fonction auxiliaire (10,) de chaque paire appartenant audit second sous-ensemble (10) associé audit code source (1 ) et une seconde fonction auxiliaire (30,) de chaque paire appartenant audit second sous-ensemble (30) associé audit code transformé (3) ; - la vérification (6) d'une propriété de correspondance déterminée entre lesdites fonctions auxiliaires de toutes lesdites paires (10, - 30,) ; et
- la vérification que ladite transformation du code source (1 ) en code transformé (3) par ledit convertisseur (2) respecte ladite propriété de correspondance déterminée.
2. Procédé selon la revendication 1 , caractérisé en ce que ladite propriété de correspondance est une relation logique, de manière à ce que lesdites fonctions auxiliaires de chacune desdites paires (10, - 30,), lors de leur exécution, génèrent des résultats liés par ladite relation logique, et en ce que cette relation est la relation identité pour des entités dites observables de chacun desdits codes, source et transformé, pour toute paire de fonctions auxiliaires, de manière à ce que les fonctionnalités dudit code source (1 ) soient préservées lors de ladite transformation dans ledit code transformé (3), et ladite vérification de transformateur de code (2) réalisée.
3. Application du procédé de vérification selon l'une des revendications 1 ou 2 à un transformateur de code (2) générant, à partir dudit code source (1 ) un code transformé (3) destiné à être enregistré dans des moyens de mémoire (71 ) d'une carte à puce (7).
4. Application selon la revendication 3, caractérisé en ce que, ledit code transformé étant un programme écrit dans la machine virtuelle d'un langage informatique déterminé, ladite carte à puce (7) est une carte à puce enregistrant une pluralité d'applications logicielles At à An) écrites dans ce code transformé (3).
5. Application selon les revendications 3 ou 4, caractérisé en ce que ledit code source (1 ) est un programme écrit dans la machine virtuelle du langage
"JAVA" (marque déposée) et ledit code transformé (3) est un programme écrit dans la machine virtuelle du langage "JAVA CARD" (marque déposée)
EP00946037A 1999-07-01 2000-06-28 Procede de verification de transformateurs de codes pour un systeme embarque, notamment sur une carte a puce Ceased EP1112536A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR9908460 1999-07-01
FR9908460A FR2795835B1 (fr) 1999-07-01 1999-07-01 Procede de verification de transformateurs de codes pour un systeme embarque, notamment sur une carte a puce
PCT/FR2000/001815 WO2001002955A1 (fr) 1999-07-01 2000-06-28 Procede de verification de transformateurs de codes pour un systeme embarque, notamment sur une carte a puce

Publications (1)

Publication Number Publication Date
EP1112536A1 true EP1112536A1 (fr) 2001-07-04

Family

ID=9547574

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00946037A Ceased EP1112536A1 (fr) 1999-07-01 2000-06-28 Procede de verification de transformateurs de codes pour un systeme embarque, notamment sur une carte a puce

Country Status (9)

Country Link
US (1) US7020872B1 (fr)
EP (1) EP1112536A1 (fr)
JP (2) JP2003525482A (fr)
CN (1) CN1231838C (fr)
BR (1) BR0006883A (fr)
CA (1) CA2342322C (fr)
FR (1) FR2795835B1 (fr)
HK (1) HK1040304B (fr)
WO (1) WO2001002955A1 (fr)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2840084A1 (fr) * 2002-05-27 2003-11-28 Gemplus Card Int Procede de verification de codes pour microcircuits a ressources limitees
EP1768263B1 (fr) * 2004-05-26 2015-01-21 NEC Corporation Méthode de détection de signal mulitplexé spatialement et décodeur itératif d'espace temps l'utilisant
KR100804207B1 (ko) 2006-08-01 2008-02-18 성인환 인삼씨를 재료로 하는 인삼차의 제조방법
US7810073B2 (en) * 2006-09-05 2010-10-05 International Business Machines Corporation Method of translating n to n instructions employing an enhanced extended translation facility
CN101458638B (zh) * 2007-12-13 2010-09-01 安凯(广州)微电子技术有限公司 一种用于嵌入式系统的大规模数据验证方法
US8793757B2 (en) * 2008-05-27 2014-07-29 Open Invention Network, Llc User-directed privacy control in a user-centric identity management system
CN101382892B (zh) * 2008-09-24 2012-04-18 飞天诚信科技股份有限公司 下载.Net程序的方法和装置
US20120054501A1 (en) * 2010-08-25 2012-03-01 Toshiba Tec Kabushiki Kaisha Image processing apparatus
US8789033B2 (en) * 2012-02-03 2014-07-22 International Business Machines Corporation Reducing application startup time by optimizing spatial locality of instructions in executables
CN106201896A (zh) * 2016-07-26 2016-12-07 华中科技大学 一种嵌入式环境下基于检查点的调试方法、系统及装置
DE102018122920A1 (de) * 2018-09-19 2020-03-19 Endress+Hauser Conducta Gmbh+Co. Kg Verfahren zur Installation eines Programms auf einem eingebetteten System, ein eingebettetes System für ein derartiges Verfahren sowie ein Verfahren zur Erstellung einer Zusatzinformation

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4736320A (en) * 1985-10-08 1988-04-05 Foxboro Company Computer language structure for process control applications, and translator therefor
DE3731736A1 (de) * 1986-09-27 1988-04-07 Toshiba Kawasaki Kk Verarbeitungssystem fuer tragbare elektronische vorrichtung
WO1993010509A1 (fr) * 1991-11-12 1993-05-27 Security Domain Pty. Ltd. Procede et systeme de personnalisation securisee et decentralisee de cartes a memoire
US5293424A (en) * 1992-10-14 1994-03-08 Bull Hn Information Systems Inc. Secure memory card
GB9307623D0 (en) * 1993-04-13 1993-06-02 Jonhig Ltd Data writing to eeprom
EP0795844A1 (fr) * 1996-03-11 1997-09-17 Koninklijke KPN N.V. Méthode pour modifier avec sécurité des données d'une carte à puce
US5889941A (en) * 1996-04-15 1999-03-30 Ubiq Inc. System and apparatus for smart card personalization
US5923884A (en) * 1996-08-30 1999-07-13 Gemplus S.C.A. System and method for loading applications onto a smart card
BR9713267A (pt) * 1996-10-25 2004-06-15 Schlumberger Systems & Service Cartão de circuito integrado para uso com um terminal, processo para uso com o mesmo, microcontrolador e processo para sua programação
FR2757970B1 (fr) * 1996-12-30 1999-03-26 Gemplus Card Int Procede de chargement d'un programme d'utilisation dans un support a puce
EP1021801B1 (fr) * 1997-03-24 2004-11-03 Visa International Service Association Procede et dispositif de carte a puce multi-application permettant de telecharger une application sur la carte posterieurement a son emission
JPH1165832A (ja) * 1997-08-21 1999-03-09 Sony Corp ソースコード変換方法及び記録媒体
US5987256A (en) * 1997-09-03 1999-11-16 Enreach Technology, Inc. System and process for object rendering on thin client platforms
US6128774A (en) * 1997-10-28 2000-10-03 Necula; George C. Safe to execute verification of software
US6253370B1 (en) * 1997-12-01 2001-06-26 Compaq Computer Corporation Method and apparatus for annotating a computer program to facilitate subsequent processing of the program
US6324685B1 (en) * 1998-03-18 2001-11-27 Becomm Corporation Applet server that provides applets in various forms
US5999732A (en) * 1998-03-23 1999-12-07 Sun Microsystems, Inc. Techniques for reducing the cost of dynamic class initialization checks in compiled code
US6216227B1 (en) * 1998-06-29 2001-04-10 Sun Microsystems, Inc. Multi-venue ticketing using smart cards
US6591229B1 (en) * 1998-10-09 2003-07-08 Schlumberger Industries, Sa Metrology device with programmable smart card
WO2000025278A1 (fr) * 1998-10-27 2000-05-04 Visa International Service Association Delegation de gestion pour applications de cartes a puce
EP0997815A3 (fr) * 1998-10-29 2004-05-26 Texas Instruments Incorporated Système interactif et méthode interactive de traduction
US6115719A (en) * 1998-11-20 2000-09-05 Revsoft Corporation Java compatible object oriented component data structure
JP3173728B2 (ja) * 1998-12-07 2001-06-04 日本電気株式会社 半導体装置
US6390374B1 (en) * 1999-01-15 2002-05-21 Todd Carper System and method for installing/de-installing an application on a smart card
US6256690B1 (en) * 1999-01-15 2001-07-03 Todd Carper System and method for facilitating multiple applications on a smart card
US6581206B2 (en) * 1999-11-12 2003-06-17 Sun Microsystems, Inc. Computer program language subset validation
FR2794543B1 (fr) * 1999-06-04 2001-08-24 Gemplus Card Int Migration de differents langages sources vers un support d'execution

Non-Patent Citations (8)

* Cited by examiner, † Cited by third party
Title
A. PNUELI AND O. SHTRICHMAN AND M. SIEGEL: "The Code Validation Tool (CVT) - Automatic verification of a compilation process", INTERNATIONAL JOURNAL ON SOFTWARE TOOLS FOR TECHNOLOGY TRANSFER, vol. 2, no. 2, December 1998 (1998-12-01), pages 192 - 201, XP007911453 *
CIMATTI, A., GIUNCHIGLIA, F., PECCHIARI, P., PIETRA, B., PROFETA, J., ROMANO, D., TRAVERSO, P., AND YU, B.: "A Provably Correct Embedded Verifier for the Certification of Safety Critical Software", PROCEEDINGS OF THE 9TH INTERNATIONAL CONFERENCE ON COMPUTER AIDED VERIFICATION (JUNE 22 - 25, 1997), LNCS, vol. 1254, 25 June 1997 (1997-06-25), Springer-Verlag, pages 202 - 213 *
CORNELIA PUSCH: "Proving the Soundness of a Java Bytecode Verifier Specification in Isabelle/HOL", PROCEEDINGS OF THE 5TH INTERNATIONAL CONFERENCE ON TOOLS AND ALGORITHMS FOR CONSTRUCTION AND ANALYSIS OF SYSTEMS, TACAS'99, MARCH 22-28, AMSTERDAM, THE NETHERLANDS, vol. 1579, 28 March 1999 (1999-03-28), Springer-Verlag, pages 89 - 103, XP007911447 *
JEAN-LOUIS LANET AND ANTOINE REQUET: "Formal Proof of Smart Card Applets Correctness", PROCEEDINGS OF CARDIS'98, 14-16 SEPTEMBER 1998, LOUVAIN-LA-NEUVE, BELGIUM, LNCS, vol. 1820, 14 September 1998 (1998-09-14), Springer, Berlin, pages 85 - 97, XP019048920 *
PETER BERTELSEN: "Semantics of Java Byte Code", TECHNICAL REPORT, TECHNICAL UNIVERSITY OF DENMARK, 31 March 1997 (1997-03-31), pages 1 - 69, XP007911452 *
PIERRE GIRARD AND JEAN-LOUIS LANET: "Java Card or How to Cope with the New Security Issues Raised by Open Cards?", GEMPLUS DEVELOPER CONFERENCE 99, JUNE 21-22 1999, PARIS, FRANCE, 22 June 1999 (1999-06-22), pages 1 - 11, XP007911446 *
PNUELI A., SIEGEL M., AND SINGERMAN E.: "Translation Validation", PROCEEDINGS OF THE 4TH INTERNATIONAL CONFERENCE ON TOOLS AND ALGORITHMS FOR CONSTRUCTION AND ANALYSIS OF SYSTEMS (MARCH 28 - APRIL 04, 1998), LECTURE NOTES IN COMPUTER SCIENCE, vol. 1384, 4 April 1998 (1998-04-04), Springer-Verlag, pages 151 - 166, XP007911448 *
See also references of WO0102955A1 *

Also Published As

Publication number Publication date
JP2003525482A (ja) 2003-08-26
FR2795835B1 (fr) 2001-10-05
CA2342322A1 (fr) 2001-01-11
CN1231838C (zh) 2005-12-14
HK1040304B (zh) 2006-03-10
FR2795835A1 (fr) 2001-01-05
HK1040304A1 (en) 2002-05-31
BR0006883A (pt) 2001-06-12
JP2012027936A (ja) 2012-02-09
WO2001002955A1 (fr) 2001-01-11
US7020872B1 (en) 2006-03-28
CN1316073A (zh) 2001-10-03
CA2342322C (fr) 2011-10-18

Similar Documents

Publication Publication Date Title
EP1212678B1 (fr) Protocole de gestion, procede de verification et de transformation d&#39;un fragment de programme telecharge et systemes correspondants
FR2809200A1 (fr) Procede de securisation d&#39;un langage du type a donnees typees, notamment dans un systeme embarque et systeme embarque de mise en oeuvre du procede
EP1147467A1 (fr) Procede de chargement d&#39;applications dans un systeme embarque multi-application muni de ressources de traitement de donnees, systeme, et procede d&#39;execution correspondants
FR2824160A1 (fr) Conteneur generique configurable de facon dynamique
WO2010009996A1 (fr) Procede de compilation de programme informatique
CN113434582B (zh) 业务数据处理方法、装置、计算机设备和存储介质
EP1112536A1 (fr) Procede de verification de transformateurs de codes pour un systeme embarque, notamment sur une carte a puce
EP4728413A1 (fr) Recommandation d&#39;invite sécurisée à l&#39;aide d&#39;invites de sécurité à ingénierie inverse
FR2826748A1 (fr) Description d&#39;une interface applicable a un objet informatique
WO2006136565A1 (fr) Procede de traitement de donnees compatible avec un formalisme de modelisation d&#39;objets
EP1782191B1 (fr) Procede de chargement d&#39;un logiciel en langage intermediaire oriente objet dans un appareil portatif
CN111090425B (zh) 一种程序封装方法、装置及电子设备
EP1141903B1 (fr) Dispositif et procede d&#39;initialisation d&#39;un programme applicatif d&#39;une carte a circuit integre
EP1960934B1 (fr) Procede pour securiser l&#39;execution d&#39;un code logiciel en langage intermediaire dans un appareil portatif
EP1442370A1 (fr) Installation de programme compile notamment dans une carte a puce
FR2835628A1 (fr) Gestion de la mise a jour d&#39;informations encodees en memoire
WO2006111441A2 (fr) Procede de verification de pseudo-code charge dans un systeme embarque, notamment une carte a puce
EP1337915A1 (fr) Verification formelle notamment d&#39;une machine virtuelle securisee
Meroño Peñuela Development of modules for the GNU PDF project
Greanier Java foundations
FR2797962A1 (fr) Procede de conversion de types de variables codees dans un programme informatique et systeme de traduction de programme informatique correspondant
CN111368263A (zh) 一种客户授权方法
EP1295203A1 (fr) Procede de structuration, de transfert et d&#39;interpretation d&#39;un ensemble d&#39;informations destinees a la conception d&#39;interfaces graphiques
FR2795535A1 (fr) Procede d&#39;execution a distance d&#39;une fonction sur un objet informatique dans un reseau de communication
McManus et al. Visual Basic. Net Developer's Guide to Asp. Net, Xml, and Ado. Net

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

17P Request for examination filed

Effective date: 20010313

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

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

Owner name: CP8 TECHNOLOGIES

17Q First examination report despatched

Effective date: 20070827

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

Owner name: CP8 TECHNOLOGIES

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

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

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20141026