Génération automatique des preuves par Jakarta

Nous pr´esentons dans cette section l’utilisation de Jakarta pour la construction de mani`ere automatique de preuves n´ecessaires `a l’instanciation de notre mod`ele de v´erificateur de code octet. L’int´egration des techniques pr´esent´ees ci-dessous `a l’outil Jakarta a ´et´e r´ealis´ee par Pierre Courtieu [10].

Concernant les preuves de validation crois´ee des machines virtuelles, on peut remarquer que, pour une fonction d’abstractionα, une fonctionf et sa version abstraite ˆf, celles-ci ont la forme :

∀x_i.(P rec_fˆ−→x_i) ⇒ (R (α(f −→x_i)) ˆf (α −→x_i))

o`uRest une relation binaire (par exemple l’´egalit´e ou une relation de sous-typage) et P rec<sub>fˆ</sub> une conjonction de pr´emisses restreignant la conclusion aux seuls cas o`u elle est vraie. Dans le cas de la preuve de commutation des machines virtuelles d´efensive et abstraite par exemple, on ne consid´erera pas les cas o`u l’instruction d´efensive lance une exception puisqu’il n’y a pas d’´equivalent abstrait.

Jakarta fournit un m´ecanisme pour g´en´erer automatiquement les pr´ e-misses du lemme, et sa preuve. Les pr´emisses sont calcul´ees `a partir des directives d’abstractions destin´ees `a construire la machine virtuelle. Il appa-raˆıt important que ces pr´emisses soient correctes : trop restrictives elles em-pˆecheraient de prouver la correction globale de la machine virtuelle comme une cons´equence du lemme prouv´e ; trop permissives elles empˆecheraient de prouver le lemme lui-mˆeme.

Consid´erons par exemple les commandes d’abstraction suivantes : Suppression d’une conclusion. Appliqu´ee `a une r`egle de la forme :

l1 →r1. . . ln→rn⇒(f −→xi)→(...t...)

la commandedelete t, destin´ee `a enlever une r`egle contenant tdans la conclusion, ajoute la pr´emisse suivante `a P rec_fˆ:

¬(f −→x_i) = (...t...)

Par exemple, dans le cas l’abstraction de types,P rec_fˆcontiendra une condition de la forme (f x_i)6= (ThrowException e).

Suppression d’une pr´emisse. Appliqu´ee `a une r`egle de la forme : l1→r1. . .(...t...)→ri. . . ln→rn⇒g→d

la commande delete t, destin´ee `a enlever une pr´emisse contenant t dans la conclusion, ajoute la pr´emisse suivante `aP rec_fˆ:

¬(l₁ =r1∧ · · · ∧ln=rn)

Propagation des pr´emisses. De la mˆeme mani`ere que l’abstraction d’une fonctionf en ˆf se r´ealise en abstrayant les fonctions auxiliaires dont f d´epend, les pr´emisses n´ecessaires `a ´etablir la preuve pour ces fonc-tions auxiliaires sont ajout´ees aux pr´emisses pourf. Plus pr´ecis´ement,

pour chaque fonctionh apparaissant dans une r`egle (non enlev´ee par l’abstraction) de la forme :

l1 →r1, . . . ,li →ri,(...(h −→xj)...)→ri+1, · · · ⇒g→d la pr´emisse suivante est ajout´ee `a P rec_fˆ:

(l₁ =r₁∧ · · · ∧l_i =r_i)→(P rec_ˆh −→x_j)

Un script de preuve Coq par d´efaut est donn´e par l’utilisateur et ap-pliqu´e `a chaque fonction. Il fait appel `a la tactique Analyze d´ecrite `a la section 6.4 pour un raisonnement par cas, il recherche les contradictions dans les hypoth`eses et fait appel sinon `a de la r´e´ecriture avec les lemmes g´en´er´es pour prouver les buts restants. En cas d’´echec du script par d´efaut (pour les cas o`u la preuve du fait de sa complexit´e ne peut ˆetre automatis´ee), l’utilisateur peut fournir lui-mˆeme la preuve dans le fichierCoqg´en´er´e pour l’instruction. Il sera conserv´e si l’abstraction est r´ealis´ee `a nouveau.

La d´emarche d´etaill´ee ci-dessus apparaˆıt la plus efficace pour l’automa-tisation des preuves, principalement parce que les informations sur l’abs-traction r´ealis´ee sont disponibles. Cela permet ainsi de construire automa-tiquement les ´enonc´es des lemmes `a prouver et des sous-lemmes dont ils d´ependent avec les hypoth`eses n´ecessaires. Appliqu´ee aux preuves de valida-tion crois´ee de la section 6.3.2, cette technique a permis de d´echarger pr`es de 90 % des preuves.

Notons enfin qu’une partie des m´ecanismes pr´esent´es ici peuvent ˆetre utilis´es pour prouver d’autres types de propri´et´es. Concernant les invariants portant sur une machine virtuelle par exemple, Jakarta permet alors de g´en´erer automatiquement les ´enonc´es des lemmes `a partir d’un mod`ele `a fournir et de placer un script de preuve par d´efaut ´egalement `a fournir.

Des r´esultats tr`es concluants ont ´egalement ´et´e obtenus pour des propri´et´es simples comme la formation des contextes d’ex´ecution (cf section 6.3.1).

6.7 Conclusion

Notre mod`ele de v´erificateur de code octet nous permet de d´elimiter clairement les propri´et´es n´ecessaires sur les machines virtuelles sans se pr´ e-occuper des m´ecanismes de la v´erification. Les propri´et´es les plus complexes

`

a apporter concernent la valid´ee crois´ee des machines virtuelles et la mo-notonie de la fonction ex´ecution abstraite. Les autres preuves, l’ordre sur les ´etats ou des invariants triviaux des machines virtuelles posent moins de difficult´es.

Lorsque l’int´egralit´e du jeu d’instructions de la machine virtuelle Java Card est consid´er´e, les sch´emas de preuves utilis´es par les autres cadres for-mels sur la v´erification de code octet posent des probl`emes de passage `a l’´echelle. Nous avons r´esolu ces probl`emes par le d´eveloppement d’outils vi-sant `a l’automatisation des preuves sur les machines virtuelles. Les premiers r´esultats obtenus par l’utilisation de ces outils pour la construction d’un v´erificateur de la sˆuret´e du typage sont particuli`erement encourageants et laissent entrevoir une application facilit´ee de ces techniques pour la v´ erifica-tion d’autres propri´et´es de s´ecurit´e de la plate-forme.

Notre instanciation du v´erificateur de code octet comporte encore quelques invariants triviaux sur la machine virtuelle `a d´emontrer. L’ach` eve-ment r´ecent des fonctionnalit´es deJakarta pour la r´esolution de ces preuves nous permettra de compl´eter rapidement les preuves manquantes.

Conclusion