EP1337915A1 - Verification formelle notamment d'une machine virtuelle securisee - Google Patents

Verification formelle notamment d'une machine virtuelle securisee

Info

Publication number
EP1337915A1
EP1337915A1 EP01998154A EP01998154A EP1337915A1 EP 1337915 A1 EP1337915 A1 EP 1337915A1 EP 01998154 A EP01998154 A EP 01998154A EP 01998154 A EP01998154 A EP 01998154A EP 1337915 A1 EP1337915 A1 EP 1337915A1
Authority
EP
European Patent Office
Prior art keywords
level language
program
high level
language
virtual machine
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
EP01998154A
Other languages
German (de)
English (en)
Inventor
Pascal Brisset
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.)
Orange SA
Original Assignee
France Telecom 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 France Telecom SA filed Critical France Telecom SA
Publication of EP1337915A1 publication Critical patent/EP1337915A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/44—Encoding
    • G06F8/443—Optimisation
    • 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

  • Formal verification including a secure virtual machine
  • the present invention relates to the verification of a program initially written in a high-level language, when it is carried out in a secure environment and thus linked to security mechanisms controlling possible states of the program.
  • the program is an interpreter or a virtual machine installed in a smart card or a portable radiotelephone terminal.
  • Java registered trademark
  • communications between small local programs and servers The search for increasingly flexible and flexible functionalities, in particular for security, for nomadic objects, such as mobile radiotelephones, payment cards and personal digital assistants, has led to endow the microcontrollers included in smart cards and processing means.
  • analog data relatively complete languages such as Java.
  • Java virtual machine Unlike "bare" processors, whose objective is above all computing performance or low consumption, the Java virtual machine has been designed to provide developers with security functions adapted to sensitive uses notably in the field of electronic banking. and security.
  • security functions whose execution guarantees that the security policy is respected; - to design security mechanisms which are the hardware or software implementation of the security functions.
  • JVM machine complies with the security policy that the nature of the application, for example in the field of electronic banking or mobile radio, requires of operators, such as banks or telecommunications operators.
  • a supplier of the JVM machine supported by a data processing device has an interest in demonstrating that its implementation is in accordance with a security policy that its client, operator or bank, has contractually defined for it, or that that the law or regulations impose.
  • Such verification is based on formal techniques which are a set of tools, software or methodological, guaranteeing certain properties of software.
  • formal techniques which are a set of tools, software or methodological, guaranteeing certain properties of software.
  • these formal techniques use mathematical procedures which provide these guarantees.
  • Many techniques are available, each with its specificities.
  • some of the checks carried out by the virtual machine are static, such as the semantic analysis of a program before its execution.
  • the algorithms involved are complex, it is difficult to design and implement, that is to say to make a virtual machine.
  • the verification that a Java virtual machine respects a desired security policy requires passing, for certain properties, by the joint use of several techniques, formalisms, languages, which structure development.
  • the invention relates to a verification method which guarantees that the specification of a virtual machine is correct and unambiguous, and that its implementation is secure. This involves formally verifying the correction of the static controls and their implementation.
  • the invention aims to optimize the implementation of a high-level language program interpreter, such as a virtual machine whose security mechanisms, comprising for example static controls, have been formally verified in accordance with a security function specification.
  • a method for verifying and optimizing a program initially written in a high level language and implemented in a data processing means during which checks on program states explored by security mechanisms formally prove that a forbidden state defined in high level language is unreachable by the program, is characterized by deleting execution paths leading to the prohibited state in the program, so as to transform the program into an equivalent program written in a low level language. The latter then provides the same security guarantees as the high-level language program.
  • the optimization of the program may further comprise a replacement of unbounded integers of the high-level language, by bounded integers of the language of low level and / or replacement of parameters and function calls in high level language with statically allocated data and imperative control structures in low level language.
  • the verification method according to the invention can be applied to a program of the known virtual machine type comprising whole data, arrays, pointers to the arrays, reusable local variables or registers, exceptions, subroutines, or a stack of operands.
  • the instruction set of the virtual machine includes arithmetic operations, access to variables, access to tables, manipulation of the stack, test, jump, call and return of subroutines, throwing exceptions.
  • Static controls guarantee compliance with operand typing constraints, constraints on the control flow, constraints of non-overflow of the stack of operands, and constraints on the use of local variables.
  • FIG. 1 is a language interpreter algorithm high level with dynamic controls
  • Figure 2 is an optimized low-level language interpreter algorithm
  • FIG. 3 schematically illustrates a method of formal verification of a virtual machine leading to an optimization according to the invention.
  • an interpreter-type program constituting the execution engine of a virtual machine installed in a data processing means, called an execution platform, such as the microcontroller of a mobile radiotelephone terminal, or a smart card such as a payment card or a SIM (Subscriber Identity Module) identity card.
  • the interpreter automatically implemented from formal specifications and written in high level source language to execute an instruction as shown in Figure 1, is to be optimized according to the invention in a low level language shown in Figure 2.
  • the high level source language is a language of the ML family, such as the CAML language developed by INRIA in France, and the low level language is the imperative language C.
  • interpreter in high level language is obtained by an automatic process from formal specifications written in a language based on mathematical logic, which ensures its compliance with these specifications. It has the following control structure:
  • This control structure performs the following functions with reference to steps H1 to H7 in FIG. 1.
  • step H1 when trying to read the current instruction I designated by the ordinal counter (st.pc) in a state (st) for a program (m. Code), the value of the address of execution corresponding to the current instruction is checked (match (nth st.pc m.code)). If the address is invalidated since it does not belong to the program (None) or indicates an incorrect instruction (Some Illegal), the control goes to a "forbidden" state in step H7 where it is stopped. Otherwise, in the next step H2, the current instruction I pointed to by the validated execution address is checked.
  • the instruction validated in step H2 may be the addition instruction (Iadd).
  • the operands to which the addition instruction is applied are checked.
  • the top of the stack of operands contains at least two values (Cons valuel (Cons value2 stack ')) and these two values are of integer type (Vint), that is to say if the addition is consistent
  • the execution continues normally (Continue), by unstacking the values in step H5, by stacking their sum in step H ⁇ , and by incrementing the ordinal counter and recursively calling the interpreter (interp m st ') on a new state (st') so as to return to step Hl.
  • the current instruction is Iadd when the operands are not in sufficient number or are not of the right type, the control goes to the prohibited state and is stopped at step H7.
  • the control structure comprises steps H8 and H9.
  • Step H8 controls the height of the stack of operands and, if the stack is not full, step H9 stacks the value C at the top of the stack.
  • step H7 if the stack is full, the control structure goes to the prohibited state in step H7.
  • control structure comprises three execution paths originating from steps H1, H2 and (H3, H4), or else from steps Hl, H2 and H8, which correspond to control failures and which result in the state prohibited in step H7.
  • the low-level language interpreter C after optimization according to the invention applied to the high-level language interpreter ML now comprises only process steps Bl, B2, B5, B ⁇ and B9 corresponding respectively to steps H1, H2, H5, H ⁇ and H9, without the dynamic control steps H3-H4 and H8 and especially without the forbidden state step H7.
  • conditional analysis instruction is read in step B1 to decode the next instruction (case) associated with the value (pc) in step B2 and designating the addition instruction (IADD) of two whole address values (top + 1) and (top) to be unstacked in step B5.
  • This low-level source code is both efficient since it does not include unnecessary dynamic controls and is safe since it is directly derived from a source code whose correction has been formally proven according to the invention, as we will see below.
  • step H7 the execution paths ending in the prohibited state of step H7 are deleted from the source code of the interpreter in FIG. 2, which corresponds to the following optimizations: removal of control over the execution address in step H1 corresponding to step Bl; - deletion of the check and of the type of arguments to which the addition operation is applied in steps H3 and H4; simplification of the representation of data in machine, their type no longer being represented.
  • the method of the invention includes obtaining formal proof of the effectiveness of the static control mechanisms of the virtual machine. In other words, if these mechanisms have authorized the execution of a given program (code), then the execution of this program by the interpreter (interp) will never result in the prohibited state. This guarantee is obtained during the following steps E1 to E5 shown in FIG. 3.
  • step E1 a logical language for specifying the virtual machine which is a variant of type theory, makes it possible to describe and reason about data structures and algorithms in a program.
  • Predetermined security mechanisms such as static controls (instruction or incorrect execution address; step Hl or H2), are specified as a problem of flow analysis of the states, or possible variants, of execution of the program carrying out the interpreter, in a manner analogous to the analysis of the behaviors of a symbolic object.
  • Security functions typically include typing, data access, operations access, and resource access controls. If certain states attainable by the execution of the program from initial states of these become dangerous, these states are brought back by transitions to a prohibited state (step H7), and the other states are deemed to be safe.
  • step E2 among the predetermined security mechanisms, security mechanisms are obtained by reformulating the flow analysis problem in combination with an abstraction problem and a problem of exhaustive exploration of a state system and transitions. If there is an infinite number of program execution states, this infinite number is reduced to a finite number of attainable abstract states of the program which are explored by static controls. Static checks verify that the abstract "forbidden" state is unreachable by the program thus defined so as to preserve the security properties of the program.
  • Step E3 consists in passing from steps E1 and E2 to a step E4, that is to say in specifying the interpreter of the virtual machine so that it includes assertions, for example the validation of addresses or of 'instructions in steps H1, H2 and the controls in the step of checking whole operands H3-H4.
  • assertions express a security policy, as well as a so-called prohibited state (step H7) which is reached each time an assertion fails.
  • the interpreter and its security mechanisms are implemented in high-level ML type language, for example the CAML language according to the example above and FIG. 1, or the SML language, from specifications of the virtual machine and using a logic-based tool.
  • step E4 includes dynamic controls corresponding to the assertions, which dynamic controls reduce the dangerous states of the program to the prohibited state.
  • step E4 it is proved using the logic-based tool that if the mechanisms have authorized the execution of a program, then its execution by the interpreter will never result in the 'state prohibited.
  • step E5 optimizes the interpreter of the virtual machine by application of the following three local transformations on the source code in ML language. These transformations are carried out manually by a programmer, although in a variant at least some of them can be carried out automatically by suitable programming tools.
  • a first transformation is a suppression of the execution paths, for example between steps H1, H2, H3, H4 and step H7, which certainly lead to the forbidden state. This deletion is guaranteed by the static controls which have ensured that no state reachable by the interpreter is dangerous. In addition, the static controls justify the simplification of the representation of the data in machine, the suppression of tests of overflow of indices, and the suppression of tests on the ordinal instruction counter, as shown by the comparison of FIGS. 1 and 2 .
  • a second transformation is a replacement of the infinite integer types, that is to say unbounded, of the high level language by bounded integer types, that is to say of finite binary integers, in the language of low level C.
  • This replacement is carried out according to a first variant, when it has been formally proven that predetermined limits cannot be reached by whole variables of high level language processed by the interpreter.
  • this replacement is carried out when the operations applied to these integer variables are such that the limits cannot be reached by the integer variables in high-level language before the expiration of a predetermined duration less than the duration of life of the virtual machine; for example, this second variant is applied when the only operations are increments and decrementations relating to a low initial value.
  • a third transformation is a replacement of so-called "recursive terminal" function calls (in English “tail-recursive") and their arguments in high level language by imperative control structures in low level language and allocated data statically.
  • the recursive terminal calls of the interpreter (interp) are replaced by an imperative loop, and its argument (st) representing the state of the program is replaced by statically allocated data, including among others the stack of operands ( stack) and the ordinal counter (pc) in the example in low level language.
  • the application field of the verification method of the invention relates in particular to electronic payment or security access smart cards, and very particularly to downloadable smart cards whose executed code is not known a priori. Smart cards can be included in devices whose programming is accessible to third parties, in particular for mobile radiotelephony applications, and in particular Wap telephone applications combining the two aspects of internet and mobile.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

L'invention concerne la vérification formelle et l'optimisation d'un programme, typiquement une machine virtuelle, initialement écrit dans un langage de haut niveau et implanté par exemple dans une carte à puce. Au cours de la vérification, il est prouvé formellement (E4) que des contrôles sur des états du programme explorés (E1-E2) par des mécanismes de sécurité garantissent qu'un état interdit défini en langage de haut niveau n'est pas atteignable par les programme. L'implantation du programme est alors optimisée notamment en supprimant des chemins d'exécution conduisant à l'état interdit dans le programme, de manière à le transformer en un programme en langage de bas niveau fournissant les mêmes garanties de sécurité que le programme en langage de haut niveau.

Description

Vérification formelle notamment d'une machine virtuelle sécurisée
La présente invention concerne la vérification d'un programme initialement écrit en un langage de haut niveau, lors de sa réalisation dans un milieu sécurisé et ainsi liée à des mécanismes de sécurité contrôlant des états possibles du programme.
Par exemple, le programme est un interpréteur ou une machine virtuelle implantée dans une carte à puce ou un terminal radiotéléphonique portable.
Dans les applications globales liées au réseau Internet, les éditeurs d'outils informatiques, particulièrement de navigateurs, ont été contraints à adopter un langage commun de haut niveau, tel que le langage orienté objet, appelé Java (marque déposée), pour la programmation répartie de communications entre des petits programmes locaux et des serveurs. La recherche de fonctionnalités, notamment de sécurité, de plus en plus nombreuses et souples pour des objets nomades, tels que radiotéléphones mobiles, cartes de paiement et assistants numériques personnels, a conduit à doter les microcontrôleurs inclus dans des cartes à puce et moyens de traitement de données analogues, de langages relativement complets tels que le langage Java.
L'universalité, dans la variété des dispositifs connectés au plus grand des réseaux comme dans celles d'appareils de plus en plus petits, issus d'une multiplicité innombrable de constructeurs, d'architectures matérielles différentes, de systèmes informatiques divers, dans des contraintes très diverses, est un obstacle à un langage unique, interprété sans ambiguïté. Pour ces raisons a été définie une machine virtuelle capable d'exécuter tous les programmes écrits dans le langage Java. Les fournisseurs de matériel notamment de cartes à puce, ou les éditeurs de logiciels notamment de navigateurs Web, ont dû alors développer sur les outils qu'ils fournissent, un logiciel capable de réaliser les fonctions de cette machine virtuelle, appelée habituellement "machine virtuelle Java" JVM, propre à chaque outil logiciel ou matériel. A cause de la faible taille de la mémoire dans les cartes à puce, ce logiciel alors appelé "JavaCard" a été "allégé".
Contrairement aux processeurs "nus", dont l'objectif est avant tout la performance de calcul ou de faible consommation, la machine virtuelle Java a été conçue pour fournir aux développeurs des fonctions de sécurité adaptées à des utilisations sensibles notamment dans le domaine de la monétique et de la sécurité.
Par contre, l'exécution d'un programme Java n'est effectivement totalement sûre que si la machine JVM a été correctement réalisée pour toutes les fonctions critiques de sécurité. Les normes ITSEC (Information Technology Security Evaluation Criteria) de la Commission des Communautés Européennes conseillent pour l'analyse de la sécurité de systèmes informatiques :
- de fixer des objectifs de sécurité ; - d'en déduire une politique de sécurité dont l'application permettra d'atteindre les objectifs de sécurité ;
- de définir des fonctions de sécurité dont l'exécution garantit que la politique de sécurité est respectée ; - de concevoir des mécanismes de sécurité qui sont la réalisation matérielle ou logicielle des fonctions de sécurité.
Il est donc important pour les clients- utilisateurs finaux que la machine JVM soit conforme à la politique de sécurité que la nature de l'application par exemple dans le domaine de la monetique ou de la radiotéléphonie mobile, impose aux opérateurs, tels que banques ou opérateurs de télécommunication.
Dans ce contexte, un fournisseur de la machine JVM supportée par un moyen de traitement de données a intérêt à démontrer que sa réalisation est conforme à une politique de sécurité que son client, opérateur ou banque, lui aura contractuellement définie, ou à celle que la loi ou les règlements imposent.
Il faudra donc vérifier que telle ou telle faille de sécurité n'existe pas, quel que soit le programme Java exécuté par la machine JVM, et quel que soit l'environnement du moyen de traitement de données, tel qu'un processeur, qui exécute la machine JVM. Il s'agit donc d'un processus complexe et délicat, avec des implications économiques fortes.
Une telle vérification repose sur des techniques formelles qui sont un ensemble d'outils, logiciels ou méthodologiques, garantissant de manière certaine des propriétés de logiciels. Au cours du processus de développement d'un programme, par exemple un interpréteur, en l'occurrence une machine virtuelle, ces techniques formelles mettent en oeuvre des démarches mathématiques qui assurent ces garanties. De nombreuses techniques sont disponibles, chacune ayant ses spécificités. Pour des raisons d'efficacité, certains des contrôles effectués par la machine virtuelle sont statiques, comme l'analyse sémantique d'un programme avant son exécution. Comme les algorithmes mis en jeu sont complexes, il est difficile de concevoir et d'implanter, c'est-à-dire réaliser une machine virtuelle. La vérification qu'une machine virtuelle Java respecte bien une politique de sécurité recherchée nécessite de passer, pour certaines propriétés, par l'utilisation conjointe de plusieurs techniques, formalismes, langages, qui structurent le développement .
Plus particulièrement, l'invention concerne un procédé de vérification qui garantit que la spécification d'une machine virtuelle est correcte et non ambiguë, et que son implantation est sûre. Il s'agit de vérifier formellement la correction des contrôles statiques et de leur implantation.
L'invention a pour objectif d'optimiser l'implantation d'un interpréteur de programmes en langage de haut niveau, tel qu'une machine virtuelle dont les mécanismes de sécurité, comportant par exemple des contrôles statiques, ont été vérifiés formellement en conformité avec une spécification de fonction de sécurité.
A cette fin, un procédé pour vérifier et optimiser un programme initialement écrit en un langage de haut niveau et implanté dans un moyen de traitement de données, au cours duquel des contrôles sur des états du programme explorés par des mécanismes de sécurité prouvent formellement qu'un état interdit défini en langage de haut niveau est inatteignable par le programme, est caractérisé par une suppression de chemins d'exécution conduisant à l'état interdit dans le programme, de manière à transformer le programme en un programme équivalent écrit dans un langage de bas niveau. Ce dernier fournit alors les mêmes garanties de sécurité que le programme en langage de haut niveau.
L'implantation en langage de haut niveau est ainsi transformée en une implantation optimisée dans un langage de bas niveau par application manuelle ou automatique de règles de transformation locales sur le code source de haut niveau. La simplicité et le caractère systématique de ces règles garantit semi- formellement ou formellement la correction de l'implantation optimisée en langage de bas niveau par rapport à l'implantation de haut niveau, et par transitivité, par rapport à des spécifications des mécanismes de sécurité.
Selon d'autres caractéristiques de l'invention, l'optimisation du programme, tel qu'interpréteur ou machine virtuelle, peut comprendre, en outre, un remplacement d'entiers non bornés du langage de haut niveau, par des entiers bornés du langage de bas niveau et/ou un remplacement de paramètres et d'appels de fonction en langage de haut niveau par des données allouées statiquement et des structures de contrôles impératives en langage de bas niveau.
Le procédé de vérification selon l'invention peut être appliqué à un programme du type machine virtuelle connue comportant des données entières, des tableaux, des pointeurs sur les tableaux, des variables locales réutilisables ou registres, des exceptions, des sous-routines, ou une pile d'opérandes. Le jeu d'instructions de la machine virtuelle comporte des opérations arithmétiques, d'accès aux variables, d'accès aux tableaux, de manipulation de la pile, de test, de saut, d'appel et retour de sous-routines, de levée d'exceptions.
Les contrôles statiques garantissent le respect de contraintes de typage des opérandes, de contraintes sur le flot de contrôle, de contraintes de non-débordement de la pile d'opérandes, et de contraintes sur l'utilisation de variables locales.
D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs réalisations préférées de l'invention en référence aux dessins annexés correspondants dans lesquels : - la figure 1 est un algorithme d'interpréteur en langage de haut niveau avec contrôles dynamiques ; la figure 2 est un algorithme optimisé d'interpréteur en langage de bas niveau ; et la figure 3 illustre schématiquement un procédé de vérification formelle de machine virtuelle aboutissant à une optimisation selon l'invention.
A titre d'exemple, on se réfère à un programme de type interpréteur constituant le moteur d'exécution d'une machine virtuelle implantée dans un moyen de traitement de données, dite plate-forme d'exécution, tel que le microcontrôleur d'un terminal radiotéléphonique mobile, ou d'une carte à puce telle qu'une carte de paiement ou une carte d'identité SIM (Subscriber Identity Module). L'interpréteur implémenté automatiquement à partir de spécifications formelles et écrit en langage source de haut niveau pour exécuter une instruction comme montré à la figure 1, est à optimiser selon l'invention en un langage de bas niveau montré à la figure 2. Par exemple, le langage source de haut niveau est un langage de la famille ML, tel que le langage CAML développé par l'INRIA en France, et le langage de bas niveau est le langage impératif C.
L'implantation de l'interpréteur (interp) en langage de haut niveau est obtenue par un procédé automatique à partir de spécifications formelles écrites dans un langage à base de logique mathématique, ce qui assure sa conformité à ces spécifications. Elle comporte la structure de contrôle suivante :
let interp m st = match (nth st.pc m. code) with
I one->Interdit
I Sorne Illegal->Interdit
I Some Iadd->
(match st.stack with |Cons(Vint x,Cons(Vint y, stack' ) ) ->Continuer
[...]
!_-> Interdit
Cette structure de contrôle assure les fonctions suivantes en référence aux étapes Hl à H7 de la figure 1.
A l'étape Hl, lors d'une tentative de lecture de l'instruction courante I désignée par le compteur ordinal (st.pc) dans un état (st) pour un programme (m. code), la valeur de l'adresse d'exécution correspondant à l'instruction courante est contrôlée (match (nth st.pc m.code)). Si l'adresse est invalidée puisqu'elle n'appartient pas au programme (None) ou désigne une instruction incorrecte (Some Illégal) , le contrôle passe à un état "interdit" à l'étape H7 où il est arrêté. Sinon, à l'étape suivante H2, l'instruction courante I pointée par l'adresse d'exécution validée est contrôlée. Par exemple, l'instruction validée à l'étape H2 peut être l'instruction d'addition (Iadd) . Dans ce cas, aux étapes suivantes H3 et H4 qui peuvent être réunies, les opérandes auxquels l'instruction d'addition est appliquée sont contrôlés. En l'occurrence, si le sommet de la pile d'opérandes contient au moins deux valeurs (Cons valeurl (Cons valeur2 stack')) et que ces deux valeurs sont de type entier (Vint), c'est-à-dire si l'addition est cohérente, l'exécution se poursuit normalement (Continuer), en dépilant les valeurs à l'étape H5, en empilant leur somme à l'étape Hβ, et en incrémentant le compteur ordinal et appelant récursivement l'interpréteur (interp m st') sur un nouvel état (st') de manière à revenir à l'étape Hl. Par contre, si l'instruction courante est Iadd alors que les opérandes ne sont pas en nombre suffisant ou ne sont pas du bon type, le contrôle passe à l'état interdit et est arrêté à l'étape H7.
Selon une autre variante également montrée à la figure 1, lorsque l'instruction courante est l'instruction d'empilement d'une valeur constante C, la structure de contrôle comporte les étapes H8 et H9. L'étape H8 contrôle la hauteur de la pile d'opérandes et, si la pile n'est pas pleine, l'étape H9 empile la valeur C au sommet de la pile. Par contre, si la pile est pleine, la structure de contrôle va à l'état interdit à l'étape H7.
Dans la figure 1, la structure de contrôle comporte trois chemins d'exécution issus des étapes Hl, H2 et (H3,H4), ou bien des étapes Hl, H2 et H8, qui correspondent à des échecs de contrôles et qui aboutissent à l'état interdit à l'étape H7.
En référence maintenant à la figure 2, l'interpréteur en langage de bas niveau C après optimisation selon l'invention appliquée à l'interpréteur en langage de haut niveau ML, ne comporte plus que des étapes de processus Bl, B2, B5, Bβ et B9 correspondant respectivement aux étapes Hl, H2, H5, Hβ et H9, sans les étapes de contrôle dynamique H3-H4 et H8 et surtout sans l'étape d'état interdit H7.
La structure de contrôle optimisée en langage de bas niveau C s ' écrit :
switch ( code [pc] ) { case IADD : stack [top+1 ] +=stack [top] ; ++toρ; ++pc; break;
}
où l'instruction d'analyse conditionnelle (switch) est lue à l'étape Bl pour décoder l'instruction suivante (case) associée à la valeur (pc) à l'étape B2 et désignant l'instruction d'addition (IADD) de deux valeurs entières d'adresses (top+1) et (top) à dépiler à l'étape B5.
Ce code source de bas niveau est à la fois performant puisqu'il ne comporte pas de contrôles dynamiques inutiles et est sûr puisqu'il est directement dérivé d'un code source dont la correction a été prouvée formellement selon l'invention, comme on le verra ci-après.
Comparativement à la figure 1, les chemins d'exécution aboutissant à l'état interdit de l'étape H7 sont supprimés du code source de l'interpréteur dans la figure 2, ce qui correspond aux optimisations suivantes : suppression de contrôle sur l'adresse d'exécution à l'étape Hl correspondant à l'étape Bl ; - suppression du contrôle et du type des arguments auxquels l'opération d'addition est appliquée aux étapes H3 et H4 ; simplification de la représentation des données en machine, leur type n'étant plus représenté.
Ces optimisations appliquées au code source de haut niveau ci-dessus ML conduisent, par l'application de transformations simples et locales, soit manuellement soit par l'utilisation d'un outil automatique, à un code source optimisé dans un langage de bas niveau, en l'occurrence le langage C.
Le procédé de l'invention comporte l'obtention d'une preuve formelle de l'efficacité des mécanismes de contrôle statique de la machine virtuelle. En d'autres termes, si ces mécanismes ont autorisé l'exécution d'un programme donné (code), alors l'exécution de ce programme par l'interpréteur (interp) n'aboutira jamais à l'état interdit. Cette garantie est obtenue au cours des étapes suivantes El à E5 montrées à la figure 3.
A l'étape El, un langage logique de spécification de la machine virtuelle qui est une variante de la théorie des types, permet de décrire et de raisonner sur des structures de données et des algorithmes dans un programme. Des mécanismes de sécurité prédéterminés, tels que des contrôles statiques (instruction ou adresse d'exécution incorrecte ; étape Hl ou H2), sont spécifiés comme un problème d'analyse de flot des états, ou variantes, possibles d'exécution du programme réalisant l'interpréteur, d'une manière analogue à l'analyse des comportements d'un objet symbolique. Des fonctions de sécurité comportent typiquement des contrôles de typage, d'accès aux données, d'accès aux opérations, et d'accès aux ressources. Si certains états atteignables par l'exécution du programme depuis des états initiaux de ceux-ci deviennent dangereux, ces états sont ramenés par des transitions à un état interdit (étape H7), et les autres états sont réputés sûrs.
A l'étape E2, parmi les mécanismes de sécurité prédéterminés, des mécanismes de sécurité sont obtenus par reformulation du problème d'analyse de flot en la combinaison d'un problème d'abstraction et d'un problème d'exploration exhaustive d'un système à états et transitions. S'il existe un nombre infini d'états d'exécution du programme, ce nombre infini est ramené à un nombre fini d'états abstraits atteignables du programme qui sont explorés par les contrôles statiques. Les contrôles statiques vérifient que l'état abstrait "interdit" est inatteignable par le programme ainsi défini de manière à préserver des propriétés de sécurité du programme.
L'étape E3 consiste à passer des étapes El et E2 à une étape E4, c'est-à-dire à spécifier l'interpréteur de la machine virtuelle pour qu'il comporte des assertions, par exemple les validations d'adresses ou d'instructions aux étapes Hl, H2 et les contrôles à l'étape de contrôle d'opérandes entiers H3-H4. Ces assertions expriment une politique de sécurité, ainsi qu'un état dit interdit (étape H7) qui est atteint chaque fois qu'une assertion échoue. L'interpréteur et ses mécanismes de sécurité sont implantés en langage de haut niveau de type ML, par exemple le langage CAML selon l'exemple ci-dessus et la figure 1, ou le langage SML, à partir de spécifications de la machine virtuelle et à l'aide d'un outil à base de logique. Cette implantation à l'étape E4 comporte des contrôles dynamiques correspondant aux assertions, lesquels contrôles dynamiques ramènent les états dangereux du programme à l'état interdit. Au cours de l'étape E4, il est prouvé à l'aide de l'outil à base de logique que si les mécanismes ont autorisé l'exécution d'un programme, alors son exécution par l'interpréteur n'aboutira jamais à l'état interdit. Puis selon l'invention, l'étape E5 optimise l'interpréteur de la machine virtuelle par application de trois transformations locales suivantes sur le code source en langage ML. Ces transformations sont réalisées manuellement par un programmeur, bien qu'en variante au moins certaines d'entre elles peuvent être réalisées automatiquement par des outils de programmation appropriés.
E51) Une première transformation est une suppression des chemins d'exécution, par exemple entre les étapes Hl, H2, H3, H4 et l'étape H7, qui conduisent de façon certaine à l'état interdit. Cette suppression est garantie par les contrôles statiques qui ont assuré qu'aucun état atteignable par l'interpréteur n'est dangereux. En outre, les contrôles statiques justifient la simplification de la représentation des données en machine, la suppression de tests de débordement d'indices, et la suppression de tests sur le compteur ordinal d'instructions, comme montré par la comparaison des figures 1 et 2. E52) Une deuxième transformation est un remplacement des types entiers infinis, c'est-à-dire non bornés, du langage de haut niveau par des types entiers bornés, c'est-à-dire des entiers binaires finis, dans le langage de bas niveau C. Ce remplacement est effectué selon une première variante, lorsqu'il a été prouvé formellement que des bornes prédéterminées ne peuvent pas être atteintes par des variables entières du langage de haut niveau traitées par l'interpréteur. Selon une deuxième variante, ce remplacement est effectué lorsque les opérations appliquées sur ces variables entières sont telles que les bornes ne peuvent pas être atteintes par les variables entières en langage de haut niveau avant l'expiration d'une durée prédéterminée inférieure à la durée de vie de la machine virtuelle ; par exemple cette deuxième variante est appliquée lorsque les seules opérations sont des incrémentations et des décrémentations relatives à une valeur initiale faible.
E53) Une troisième transformation est un remplacement des appels de fonction dits "récursifs terminaux" (en anglais "tail-recursive" ) et de leurs arguments en langage de haut niveau par des structures de contrôles impératives en langage de bas niveau et des données allouées statiquement . Par exemple, les appels récursifs terminaux de l'interpréteur (interp) sont remplacés par une boucle impérative, et son argument (st) représentant l'état du programme est remplacé par des données allouées statiquement, dont entre autres la pile d'opérandes (stack) et le compteur ordinal (pc) dans l'exemple en langage de bas niveau. Le domaine applicatif du procédé de vérification de l'invention concerne notamment des cartes à puce monétiques ou pour accès sécuritaire, et tout particulièrement des cartes à puce téléchargeables dont le code exécuté n'est pas connu a priori. Les cartes à puce peuvent être incluses dans des dispositifs dont la programmation est accessible à des parties tierces, notamment pour des applications de radiotéléphonie mobile, et tout particulièrement des applications téléphoniques Wap mêlant les deux aspects internet et mobile.

Claims

REVENDICATIONS
1 - Procédé pour vérifier et optimiser un programme initialement écrit en un langage de haut niveau et implanté dans un moyen de traitement de données, au cours duquel des contrôles (Hl, H2, H3- H4) sur des états du programme explorés (E1-E2) par des mécanismes de sécurité prouvent formellement (E4) qu'un état interdit (H7) défini en langage de haut niveau est inatteignable par le programme, caractérisé par une suppression de chemins d'exécution (H1-H7, H2-H7, H3-H4-H7) conduisant à l'état interdit dans le programme, de manière à transformer le programme en un programme équivalent dans un langage de bas niveau.
2 - Procédé conforme à la revendication 1, comprenant un remplacement d'entiers non bornés du langage de haut niveau, par des entiers bornés du langage de bas niveau.
3 - Procédé conforme à la revendication 2, selon lequel ledit remplacement est effectué lorsqu'il a été prouvé formellement que des bornes prédéterminées des entiers du langage de haut niveau ne peuvent pas être atteintes.
4 - Procédé conforme à la revendication 2, selon lequel ledit remplacement est effectué lorsque des bornes prédéterminées ne peuvent pas être atteintes par les entiers en langage de haut niveau avant l'expiration d'une durée prédéterminée.
5 - Procédé conforme à l'une quelconque des revendications 1 à 4, comprenant un remplacement de paramètres et d'appels de fonction en langage de haut niveau par des données allouées statiquement et des structures de contrôles imperatives en langage de bas niveau.
EP01998154A 2000-11-24 2001-11-21 Verification formelle notamment d'une machine virtuelle securisee Withdrawn EP1337915A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0015306A FR2817363B1 (fr) 2000-11-24 2000-11-24 Verification formelle notamment d'une machine virtuelle securisee
FR0015306 2000-11-24
PCT/FR2001/003656 WO2002044898A1 (fr) 2000-11-24 2001-11-21 Verification formelle notamment d'une machine virtuelle securisee

Publications (1)

Publication Number Publication Date
EP1337915A1 true EP1337915A1 (fr) 2003-08-27

Family

ID=8856926

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01998154A Withdrawn EP1337915A1 (fr) 2000-11-24 2001-11-21 Verification formelle notamment d'une machine virtuelle securisee

Country Status (5)

Country Link
US (1) US20040031025A1 (fr)
EP (1) EP1337915A1 (fr)
AU (1) AU2002220813A1 (fr)
FR (1) FR2817363B1 (fr)
WO (1) WO2002044898A1 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2864654B1 (fr) * 2003-12-30 2007-02-23 Trusted Logic Procede de determination de caracteristiques operationnelles d'un programme
US7607011B1 (en) * 2004-07-16 2009-10-20 Rockwell Collins, Inc. System and method for multi-level security on a network
US7730455B2 (en) 2004-11-08 2010-06-01 Ntt Docomo, Inc. Method and apparatus for enforcing safety properties of computer programs by generating and solving constraints
US9501383B2 (en) * 2013-02-26 2016-11-22 Dominique Bolignano Method for securing a program
US9275236B2 (en) * 2013-06-28 2016-03-01 Dominique Bolignano Method for securing a program
US9841972B2 (en) * 2014-12-17 2017-12-12 Cisco Technology, Inc. Securing secret information in source code verification and at runtime

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2002201C (fr) * 1988-12-06 1999-04-27 John Charles Goettelmann Methode de traduction
US5708431A (en) * 1995-11-14 1998-01-13 Lucent Technologies Inc. Method for compression coding of potentially unbounded integers
US6182268B1 (en) * 1998-01-05 2001-01-30 Synplicity, Inc. Methods and apparatuses for automatic extraction of finite state machines
US6434738B1 (en) * 1999-04-22 2002-08-13 David Arnow System and method for testing computer software
US6553514B1 (en) * 1999-09-23 2003-04-22 International Business Machines Corporation Digital circuit verification
US6467075B1 (en) * 2000-03-24 2002-10-15 Nec Corporation Resolution of dynamic memory allocation/deallocation and pointers

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
WO2002044898A1 (fr) 2002-06-06
FR2817363B1 (fr) 2002-12-27
AU2002220813A1 (en) 2002-06-11
FR2817363A1 (fr) 2002-05-31
US20040031025A1 (en) 2004-02-12

Similar Documents

Publication Publication Date Title
US7975257B2 (en) Iterative static and dynamic software analysis
CN107041158B (zh) 用于模块化反射的限制性访问控制
CN107924326B (zh) 对经更新的类型的迁移方法进行覆盖
CN107526625B (zh) 一种基于字节码检查的Java智能合约安全检测方法
US10459708B2 (en) Composing a module system and a non-module system
US10078497B2 (en) Bridging a module system and a non-module system
US20070250825A1 (en) Compiling Alternative Source Code Based on a Metafunction
US20180373515A1 (en) Differentiated static analysis for dynamic code optimization
Fourtounis et al. Static analysis of java dynamic proxies
US20070240120A1 (en) Adaptive Compiled Code
CN110609687A (zh) 一种编译方法、装置、电子设备和存储介质
US9652358B1 (en) Type widening for source code analysis
US10409567B2 (en) Trimming unused dependencies using package graph and module graph
He et al. Accelerating object-sensitive pointer analysis by exploiting object containment and reachability
US20220188126A1 (en) Systems and methods for running applications associated with browser-based user interfaces within multi-developer computing platforms
Arzt et al. Towards cross-platform cross-language analysis with soot
EP1337915A1 (fr) Verification formelle notamment d'une machine virtuelle securisee
US9672020B2 (en) Selectively loading precompiled header(s) and/or portion(s) thereof
US9720807B2 (en) Using core files to develop diagnostic programs
US20210303283A1 (en) Generating compilable machine code programs from dynamic language code
US20200174763A1 (en) Compile-time folding of assumed constant values
CN114090128A (zh) 一种程序运行方法、装置、设备和可读介质
CN115543486B (zh) 面向无服务器计算的冷启动延迟优化方法、装置和设备
US20240111518A1 (en) Embedding code from modules across versioning boundaries
EP3164800B1 (fr) Pontage d'un système à modules et d'un système sans modules

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: 20030502

AK Designated contracting states

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

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

RIN1 Information on inventor provided before grant (corrected)

Inventor name: BRISSET, PASCAL

17Q First examination report despatched

Effective date: 20071109

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

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20100531