Technologies des programmes accompagnés de preuves

Technologies des programmes accompagnés de preuves Hoang Minh Tien 13 septembre, 2009 Sous la direction de Professeur Danny Dubé Département d’informatique et de génie logiciel Faculté des sciences et de génie Université Laval Copyright © 2009 Hoang Minh Tien Mot clés : programme accompagné de preuves, condition de vérification, programme accompagné de preuves étendues, programme accompagné de preuves d’oracle, logique de premier ordre, lambda calcul, consommateur de code, producteur de code Keywords: proof carrying code, verification condition, extended proof carrying code, oracle based proof carrying code, foundational proof carrying code, type safe, logical framework, first order logic, lambda calculus, code consumer, code producer Remerciements Je tiens remercier vivement Monsieur Danny Dubé, professeur de l’Université Laval, de m’avoir accueilli au sein de son équipe de recherche, de m’avoir toujours encouragé, de m’avoir donné des suggestions précieuses dans la recherche Je lui en suis très reconnaissant Je tiens remercier également les professeurs et les personnels de l’Institut de la Francophonie pour l’Informatique, des professeurs invités de m’avoir donné des cours de haut qualité et pour leur soutien tout au long de mes études Je voudrais remercier mes amis dans mon laboratoire de recherche, Bui Nguyen Minh, Haythem Kefi, Joseph Assouramou, Marieme Doua, Ishagh Mayouf de m’avoir donnée leurs conseils, leurs commentaires et leurs soutiens pendant le temps j’effectuais ma recherche J’adresse un grande merci ma famille pour leur soutien et leur encouragement de toute l’instance Table des matières List des figures iii Résumé iv Abstract v Chapitre I Introduction 1 Contexte du stage Problématique Principes d’assurer la sécurité pour le consommateur Contributions Structure du rapport Chapitre II Techniques principales de PCC Technique PCC traditionnel 1.1 Architecture du système PCC traditionnel 1.2 Protocole de PCC traditionnel 1.3 Implémentation du technique PCC traditionnel 1.4 Contributions du technique PCC traditionnel .10 Technique OPCC 12 2.1 Architecture du système OPCC 12 2.2 Contribution du technique OPCC 13 Technique FPCC 13 3.1 Architecture du système FPCC .13 3.2 Implémentation de technique FPCC .14 3.3 Contribution de technique FPCC 15 Technique EPCC 16 -i- 4.1 Architecture du technique EPCC 16 4.2 Contribution de technique EPCC 17 Chapitre III 18 Vérification de la sécurité du machine virtuelle d’EPCC .18 Présentation de la machine virtuelle VEP 18 1.1 Brièvement 18 1.2 Gestion de mémoire 19 1.3 Ensemble des instructions de VEP .22 1.4 Assurance la sécurité de VEP .24 Vérification de la sécurité de la VEP .26 2.1 Vérification manuelle de la VEP 26 2.2 Vérification automatique de la VEP .28 Chapitre IV 34 Conclusion et perspectives 34 Conclusion 34 Perspectives 35 2.1 Travail pratique .35 2.2 Travail théorique 35 Appendices 37 Outil pour le prouveur de théorème 37 Utilisation de Frama-C .38 Spécification de sécurité du tas dans la VEP 39 Références .42 -ii- List des figures Figure Architecture du système PCC [6] Figure Représentation des axiomes et règles d’inférence Figure Spécification de la fonction inc Figure Une condition de vérification Figure La machine abstraite DEC Alpha [9] Figure Calcule de condition de vérification [9] Figure Architecture de technique OPCC 12 Figure Architecture de technique FPCC 14 Figure Instructions sont encodées avec un mot 32-bit [16] .14 Figure 10 EPCC pour le PCC traditionnel [2] 16 Figure 11 Architecture de la VEP 18 Figure 12 Représentation de données dans la VEP 19 Figure 13 Stockage des paires dans le tas 20 Figure 14 Algorithme pour récupérer automatiquement la mémoire 20 Figure 15 Problème de référence cyclique [3] 21 Figure 16 Ensemble des instructions de la VEP [19] 22 Figure 17 Sémantiques des instructions de VEP [3] 24 Figure 18 Assurance de sécurité sur la VEP [3] .25 Figure 19 Tests de la sécurité sur la VEP [3] 27 Figure 20 Architecture de Frama-C [20] 28 Figure 21 Catégoriser l’ensemble des instructions de la VEP 29 Figure 22 Vérifier l’instruction BAND 30 Figure 23 Structure du tas .31 Figure 24 Paires libres forment une liste chainée 32 Figure 25 Algorithme non-récursif de récupérateur de mémoire .33 -iii- Résumé La technologie des programmes accompagnés de preuves (Proof Carrying Code, PCC) a été introduite pour la première fois en Novembre 1996 dans le projet de recherche de George Necula et Peter Lee [1] de l’université Carnegie Melon Cette méthode est pour but de vérifier la sécurité d’un programme inéprouvé sur le consommateur de code en utilisant des preuves générées par le producteur de codes Car la vérification entre les codes et les preuves est effectuée une seule fois dès le premier démarrage du programme, sa performance est donc préservée La méthode est connu aussi par sa simplifié, sa flexibilité dans le déploiement Pourtant il existe encore des points faibles qui empêche l’application de PCC en réalité, en basant sur les points de vue différents, les chercheurs ont donné leur façon d’améliorer le modèle primitif comme limiter la taille de l’infrastructure présumée fiable (dans le modèle FPCC [5], Andrew W Appel), réduire la taille des preuves (dans le modèle OPCC[4], Necula) … Ce mémoire vise réaliser une recherche sur les techniques principales de programmes accompagnés de preuves, analyser ses avantages et aussi ses inconvénients On se concentrera sur la méthode programmes accompagnés de preuves étendu (EPCC [2]) proposé par Danny Dubé et Heidar Pirzadeh Tabari de l’Université Laval On discutera également l’architecture d’une machine virtuelle (VEP [3]), le cœur du EPCC, et proposer un prototype pour prouver automatiquement la sécurité de cette machine -iv- Abstract Introduced for the first time in November 1996 by George Necula and Peter Lee from university Carnegie Melon, proof carrying code (PCC) is a promising method for verifying the security of an untrusted program executed on a code consumer by using proofs generated by code producer [1] The verification is performed only for the first run of the program so the performance of program is not affected This technique is also attractive for the simplicity and flexibility in the deployment process However, there are still some disadvantages that make it difficult to apply the model widely in reality Some of them are solved in the research of Andrew W Appel et al (FPCC [5], reducing the trusted computing based), of George Necula (OPCC [4], reducing the size of proof) … This thesis aims to carry out a research on major techniques of proof carrying code, to analyse the advantages and disadvantage of each technique An important part in this thesis concentrates on the framework EPCC (Extended framework for Proof Carrying Code) proposed by Danny Dubé and Heidar Pirzadeh Tabari from University Laval, the architecture of the virtual machine for EPCC (VEP [3]), the heart of EPCC as well as some propositions for proving automatically its security -v- Chapitre I Introduction Contexte du stage Le stage est réalisé au sein de l’équipe LSFM (Langages, Sémantique et Méthodes formelles) de l’Université Laval Le thème du stage est la sécurité informatique, surtout la technique de programme accompagné de preuves et ses variantes Ce sont des méthodes formelles qui permettent de représenter les politiques de sécurité d’un système et le logiciel sous forme d’une formule logique, la satisfaisant de cette formule assure que le logiciel est sécuritaire Dans l’extension EPCC proposée par cette équipe (Danny Dubé et Heidar Pirzadeh[2]), une version d’une machine virtuelle a été développé et prouvé manuellement Pour convaincre l’utilisateur de absolument se fier la sécurité de cette extension il faut que la machine soit automatiquement prouvée Dans le cadre du stage, on propose des changements nécessaires de la machine virtuelle pour que sa sécurité soit automatiquement prouvée Problématique Le rôle important des logiciels dans tous les domaines de la vie est une réalité indéniable On peut voir leur utilisation sur des systèmes de haute capacité sur lesquels on peut appliquer plusieurs politiques de sécurité Dans les années récentes, on les utilise de plus en plus sur divers systèmes de capacité limitée comme le micro contrôleur, la carte puce … On ne peut pas prendre des mesures de sécurité comme dans le grand système, on ne peut non plus le laisser non-vérifié, spécialement dans le cas on fournit une solution complète dans laquelle il y a des coopérations de tous les ensembles mentionnés C’est cause d’une vérité : si la sécurité d’un système est considérée comme une chaine, elle dépende toujours au nœud le plus faible Comment pourrait-on alors construire un cadre pour assurer la sécurité des systèmes de capacité limitée ? Il existe une contradiction, les producteurs de logiciel prétendent toujours que leurs logiciels sont sécuritaires tandis que leurs clients doivent régulièrement mettre jour les correctifs afin de prévenir les failles de sécurité Les géants dans l’industrie de Chapitre I - Introduction logiciel ne sont pas exceptions En effet, le correctif le plus récent de Microsoft (8Sep-2009) corrige 31 failles de sécurité dans lesquelles failles sont classées dans la catégorie des failles critiques Dans l’attente du prochain correctif, comment le client pourrait-il se protéger contre des attaques? Il faudrait par conséquent disposer d'un moyen simple, mais assez forge pour contrer les actions qui violent les politiques de sécurité au niveau du client Avec l’aide de technique programme accompagné des preuves (Proof Carrying Code, PCC) le consommateur peut vérifier est ce que le logiciel fournit par le producteur est conforme sa politique de sécurité ou non D’ailleurs, l’application de PCC ne diminue pas la performance de programme et la consommation de ressources (mémoire, processeur) de PCC sur le consommateur est limitée au maximum En basant sur les principes d’assurer la sécurité, on analysera les points forts, points faibles de chaque technique PCC et leurs applications en réalité et fournit un prototype pour vérifier la sécurité de la machine virtuelle Principes d’assurer la sécurité pour le consommateur Pour le consommateur, en général, on est capable de contrôler la sécurité d’un logiciel avant ou pendant son exécution Pour assurer la sécurité avant l’exécution, on effectue une analyse statique sur le code en utilisant un outil qui décompose le programme sans l’exécuter et analyse tous les comportements possibles pour prouver que le programme soit sécurité Les implémentations en réalité de ce type d’assurance sont le « Model checking » [24], analyser flux de donnée [25], interprétation abstraite [14] Pendant l’exécution, on a l’analyse dynamique, où on fait marcher le programme et utilise un « runtime monitor » pour l’observer, et l’arrêter si dans l’étape suivante, le programme causera une violation Toutes les mesures de sécurité sur le client suivent un principe de base: minimiser l’infrastructure présumée fiable (Trusted Computing Based, TCB [15]), le TCB d'un système est l'ensemble des matériaux, des microprogrammes et des logiciels qui se font confiance entre eux et auxquels le client fait confiance, s’il existe des bugs l'intérieur du TCB, la sécurité du système pourrait être compromise Par contre, les autres composants en dehors du TCB ne pourront jamais toucher sa sécurité Chapitre III - Vérification de la sécurité de la VEP un générateur de condition de vérification, ce générateur crée des prédicats de logique du premier ordre qui sont l’entrés d’un prouveur de théorème Le Frama-C est capable de produit les formules logiques pour plusieurs prouveurs de théorème comme Simplify, CVC, Alt-Ergo, Z3, Coq … 2.2.2 Classification des instructions de VEP Le cadre Frama-C fournit des outils pour prouver la sécurité de mémoire, de type, et de l’exactitude de l’implémentation de la VEP La sécurité de type est automatiquement vérifiée On n’a pas besoin de vérifier l’implémentation de VEP On doit dénoter seulement les spécifications pour la sécurité de mémoire Il y a trois zones de mémoire, la mémoire du code, le tas et la pile Les types de données possibles du tas sont la référence (à une paire) ou le numéro La mémoire du code contient seulement les données de type numériques Le tas contient seulement les paires La nature de données de la pile est semblable avec celle du code, en plus il y a seulement quelques instructions qui manipulent les donnée dans la mémoire de code On peut alors catégoriser l’ensemble d’instructions de la VEP en deux sous ensemble, l’un qui concerne seulement la zone de mémoire du code et la pile, l’autre qui manipule sur les données du tas 𝒮𝒞 LOAD(1 4), LOADI n, PUSH-PC, READC, JUMP, JMPR, LEQ, LTH, ADD, SUB, MUL, DIV, MOD, BAND, BOR, BNOT, BSHIFT, OUTPUT ℋ PEEK, POKE, PEEKI n, POKEI n, POP, JMPRF, JMPRT, EQU, NEQ, CONS, CAR, CDR, ISPAIR 𝜙 HALT, NOP 𝒮𝒞 : Sous ensemble des instructions qui a des effets sur la pile et le mémoire du code ℋ: Sous ensemble des instructions qui a des effets sur le tas 𝜙: Sous ensemble des instructions qui n’a aucune effet sur la mémoire Figure 21 Catégoriser l’ensemble des instructions de la VEP 2.2.3 Vérification des instructions de type 𝓢𝓒 Dans la VEP, soit la pile le tableau vm_s de type vmword (long int), le pointeur de pile vm_sp, MAX_STACK_SIZE la taille maximal de pile La mémoire est sécuritaire si elle est dans l’état normal avant et après l’exécution d’une instruction Pour la pile, il faut que le pointeur de pile soit dans la position 29 Chapitre III - Vérification de la sécurité de la VEP valide (−1 ≤ 𝑣𝑚_𝑠𝑝 < MAX_STACK_SIZE ) et tous les éléments de la pile soient accessibles (\valid_range(𝑣𝑚_𝑠, 0, MAX_STACK_SIZE − 1)) La Figure 22 montre un exemple de spécification pour vérifier la sécurité de l’instruction BAND Cette instruction prend deux opérandes numériques au sommet de la pile, fait la conjonction sur les bits et stocke le résultat au sommet de la pile 10 11 12 13 14 15 16 17 18 19 /*@ requires (ferror==ERR_NO_ERROR) && (-1 check_free(vmheap,ihr,ih); @ } @*/ /*@ predicate form_a_free_chain{L}(vmword vmheap[], integer ihr) = @ (ihr==-1) || @ (valid_heap_ptr(ihr) && @ (\forall integer ih; @ valid_heap_ptr(ih) && check_free(vmheap,ihr,ih) ==> @ (check_free(vmheap,ihr,vmheap[ih]) && @ valid_range_heap_ptr(vmheap[ih])))); @*/ /*@ @ @ @ @ @*/ predicate free_chain_termin{L}(vmword vmheap[], integer ihr) = (ihr==-1) || (valid_heap_ptr(ihr) && (\exists integer ih; valid_heap_ptr(ih) && check_free(vmheap,ihr,ih) && vmheap[ih]==-1)); Figure 24 Paires libres forment une liste chainée Le prédicat form_a_free_chain (lignes 15-22, Figure 24) pour indiquer que toutes les paires libre forment une chaine, pour chaque paire, si elle est libre, la paire pointée par elle doit être également libre Cette liste est terminée par une paire NULL (free_chain_termin, lignes 24-29, Figure 24) L’implémentation des autres es autres conditions se trouve dans l’appendice Dans la version originale de la VEP, le récupérateur de mémoire est implémenté avec un algorithme récursif (Figure 14) Pendant l'exécution de cette fonction, après une 32 Chapitre III - Vérification de la sécurité de la VEP étape récursive, le tas peut être n’est pas dans l’état normal on doit alors propose un algorithme non-récursif pour le récupérateur de mémoire Au lieu d’appeler récursivement le car et le cdr d’une paire, on les met dans une queue et utilise une boucle pour traiter tous les éléments dans la queue void ifpair_reduce(vmword wraped_data) { vmword iqb,iqe,iwd; vmword vm_q[MAX_HEAP_SIZE]; if ((wraped_data&1)==1) { iqb=0;iqe=1; vm_q[iqb]=wraped_data; while (iqb>1; // vm_h[iwd] = vm_h[iwd]-1; // if(vm_h[iwd]==0){ // if ((vm_h[iwd-1] & 1)==1){ vm_q[iqe] = vm_h[iwd-1]; // iqe = iqe + 1; } if ((vm_h[iwd-2] & 1)==1){ vm_q[iqe] = vm_h[iwd-2]; // iqe = iqe + 1; } addtofree(iwd); // } }; } } prendre un élément du queue calculer l’indexe d’élémént dans le tas diminuer le compteur si le compteur égale si car est paire -> metre dans la queue si cdr est paire -> metre dans la queue récupérer la mémoire Figure 25 Algorithme non-récursif de récupérateur de mémoire Une version de vérification de la sécurité de cet algorithme est spécifiée dans l’appendice Cette algorithme est prouvé partiellement en utilisant Frama-C/Jessie/AltErgo, 88/137 buts sont prouvées, les autres on peut prouver manuellement en utilisant les inductions de logiques du premier ordre 33 Chapitre IV Conclusion et perspectives Conclusion Le rapport est pour but de nous familiariser avec PCC et ses variantes, de comprendre les forces et les faiblesses de chacune d'elles, de bien comprendre l'extension EPCC et enfin de proposer une version de la machine virtuelle utilisée dans EPCC qui peut être prouvée automatiquement Pour ce faire, les travaux suivants ont été réalisés:  Lecture de la littérature pertinente des techniques PCC  Recherche d'outils convenable pour la preuve de VEP Quelques outils ont été trouvés, le cadre Frama-C a été sélectionné car sa puissance dans la représentation des conditions (pré-conditions, post-conditions, invariants …) et sa flexibilité dans l’architecture qui permet de changer sans difficulté le prouveur de théorème, un critère important, parce que chaque prouveur de théorème a ses forces ou faiblesses sur un certain groupe des formules logiques  L’adaptation de code source de machine VEP pour qu’il soit prouvé automatiquement  Développement d’une interface graphique pour visualiser et faciliter le processus de prouver la sécurité de VEP  Une bonne partie de la VEP a été prouvé : groupe des instructions de type 𝒮𝒞 qui sont représenté par les instructions logiques Le récupérateur de mémoire (pour le groupe des instructions de type ℋ) est partiellement prouvé par FramaC/Jessie/Alt-Ergo, l’autre partie est prouvé manuellement A partir des travaux réalisés, on peut conclure que : PCC est une technique d’analyser statiquement la sémantique du programme pour assurer sa sécurité avant de le lancer sur le consommateur de code C’est une technique prometteuse mais n’est pas encore tout fait complet Il y a trois grands problèmes qu’on doit résoudre pour appliquer la technique PCC en réalité D’abord c’est la taille grande de TCB cause d’un générateur de VC qui est un programme compliqué Deuxièmement, la taille de preuves qui sont dizaines de fois plus grande que le programme Finalement, des preuves générées ne sont pas toujours facilement 34 Chapitre IV - Conclusions et perspectives prouvé avec le prouveur de théorème Il y a plusieurs recherches pour améliorer les faibles du PCC, mais il n’existe pas encore une solution complète OPCC crée des preuves petites mais agrandit la taille de TCB FPCC enlève le générateur de VC dans son modèle et réduit significativement le TCB, mais le problème est que ses preuves sont élargit de 20% en moyenne en comparaison avec la technique PCC traditionnel PCC peut être appliqué pour une variété des applications, spécialement pour celles qui marchent sur des plates-formes qui ont une limitation de ressource comme la mémoire ou la vitesse de processeur La technique EPCC fait de telle manière que l’application de PCC plus faisable C’est un cadre flexible, son application dans FPCC surmonte deux problèmes de PCC L’utilisation d’une machine virtuelle sur le coté de consommateur aide de diminuer la taille des preuves En plus, en prouvant la sécurité de VEP, le technique EPCC jusqu'à maintenant est le seule technique qui trouve un bon compromis entre la taille de TCB et des preuves Le dé-récursif de l’algorithme de récupérateur de mémoire cause le fonctionnement de la VEP est plus stable et la spécification en Frama-C de la VEP signifie que l’on est capable de prouver automatiquement sa sécurité, un critère très important dans l’application de PCC en réalité Perspectives 2.1 Travail pratique La sécurité de la VEP n’est pas automatiquement prouvée par Alt-Ergo cause de la complication dans sa spécification en Frama-C et également le faible de prouveur de théorème Un raison de la complication est que l’on essais de spécifier l’état normal de mémoire de la VEP indépendamment avant et après l’exécution d’une instruction Alors une solution possible pour le problème est que l’on essais avec la spécification relative, c.a.d, au lieu de spécifier la sécurité pour un état, on spécifie la sécurité pour une transition Une autre solution est que l’on enrichit l’ensemble des axiomes pour le prouveur de théorème ou fournit des lemmes intermédiaires avec ses preuves 2.2 Travail théorique L’utilisation de VEP dans le technique EPCC maintenant prend seulement près de la moitié de sa capacité On peut inventer plus des efforts sur l’amélioration de l’algorithme de reproduire des preuves pour qu’il soit plus proche de la complexité Kolmogorov comme dans l’objective de la conception de la VEP que l’algorithme 35 Chapitre IV - Conclusions et perspectives GUnzip qui est implémenté maintenant pour le constructeur de générateur de preuves dans EPCC L’application d’EPCC dans la technique FPCC diminue significativement le TCB en enlevant le générateur de VC et simplifiant le travail de vérificateur de preuves mais on est capable de réduire encore son TCB en intégrant le programme, le constructeur de générateur de preuves et le vérificateur de preuves Le TCB dans ce cas contient seulement la VEP et le politique de sécurité qui est le plus petit en comparaison avec autres technique de PCC Surement, ce la causera des problèmes dans lesquels celui le plus visible est l’augmentation de taille de preuve mais ce la vaut la peine de faire davantage de recherche sur ce thème Toutes les techniques PCC se concentre simplifier l’architecture de client, ils ont le même problème sur le producteur de code, c’est l’automatisation de la démonstration de théorème il n’y a aucune amélioration pour le prouveur de théorème, même le FPCC cause son travail plus compliqué La customisation du prouveur de théorème pour le PCC donc est une direction de recherche prometteuse 36 Appendices Outil pour le prouveur de théorème Le temps pour vérifier la fonctionnalité d’un programme est varié Il dépende du nombre et de la complexité des conditions vérifié générées par le générateur en WHY L’outil graphique est pour but de visualiser le processus de prouver des théorèmes, chaque moment, on a des informations comme quels sont les théorèmes qui sont prouvés ou ne sont pas prouvés On peut ajouter des axiomes pour augmenter la chance de prouver des théorèmes qui ne sont pas capable de prouvées par Alt-Ergo  Le fichier d’entré généré par générateur de VC  Le fichier d’entré qui contient des axiomes customisées sous forme Alt-Ergo  Le temps maximal en seconds pour prouver un théorème  List des VCs et le résultat  Le détaille d’un VC (qui est en train d’être traité ou sélectionnée dans )  Les axiomes utilisé par l’outil (on peut les sauver dans le fichier )  L’ordre de VC qui est en train d’être traité 37 Appendices Avec cet outil, on peut réaliser une opération de prouver toutes les VCs (presser « Run through ») ou sur un ensemble de VCs sélectionnées dans  (sélectionner les VCs et presser « Run selected ») ou également ignorer le processus de prouver des VCs (presser « Abort ») Utilisation de Frama-C On peut exécuter le Frama-C pour vérifier la sécurité d’un programme par la commande suivante  frama-c -jessie-analysis Le système va réaliser tous les étapes pour produire les VCs et déclencher automatiquement le prouveur de théorème (le prouveur de théorème Simplify est déclenché par défaut) Dans le cas on utilise Alt-Ergo comme le pouveur de théorème, on utilise la commande suivant  frama-c -jessie-analysis –jessie-atp alt-ergo Le système Frama-C va vérifier complètement la fonctionnalité du fichier C entré Si on veut seulement vérifier la sécurité du mémoire (la sécurité des actions qui accèdent une zone de mémoire allouée) on ajoute l’option -jessie-int-model exact  frama-c -jessie-analysis –jessie-int-model exact –jessie-atp alt-ergo Si on ne veut que le débordement des opérations sur les entiers se passe, on ajoute l’option -jessie-int-model bounded frama-c -jessie-analysis –jessie-int-model bounded –jessie-atp alt-ergo 38 Appendices Spécification de sécurité du tas dans la VEP Pour la condition H2 (Vérification des instructions de type 𝓗, p 31) 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 /*@ inductive check_occp{L}(vmword vmheap[], integer ihr, integer ih) { @ case c_occp_refl{L}: @ \forall vmword vmheap[]; @ \forall integer ih; @ valid_heap_ptr(ih) ==> check_occp(vmheap,ih,ih); @ case c_occp_car{L}: @ \forall vmword vmheap[]; @ \forall integer ihr, ih; @ valid_heap_ptr(ihr) && check_pair(vmheap[ihr-1]) && @ check_occp(vmheap,vmheap[ihr-1]/2,ih) ==> check_occp(vmheap,ihr,ih); @ case c_occp_cdr{L}: @ \forall vmword vmheap[]; @ \forall integer ihr, ih; @ valid_heap_ptr(ihr) && check_pair(vmheap[ihr-2]) && @ check_occp(vmheap,vmheap[ihr-2]/2,ih) ==> check_occp(vmheap,ihr,ih); @ } @*/ /*@ predicate valid_occp{L}(vmword vmheap[], @ vmword vmstack[], integer ihr)= @ \forall integer ih; @ valid_heap_ptr(ih) && !check_free(vmheap,ihr,ih) ==> @ (\exists integer ist; valid_stack_ptr(ist) && @ check_pair(vmstack[ist]) ==> check_occp(vmheap,vmstack[ist]/2,ih)) @*/ Pour la condition H3 (Vérification des instructions de type 𝓗, p 31) /*@ predicate stack_safe_valid_pair{L}(vmword vmstack[], @ vmword vmheap[], integer ihr) == @ \forall integer ist; @ valid_stack_ptr(ist) && check_pair(vmstack[ist])==> @ (valid_heap_ptr(vmstack[ist]/2) && @ !check_free(vmheap,ihr,vmstack[ist]/2)); @*/ 39 Appendices Pour la condition H4 (Vérification des instructions de type 𝓗, p 31) 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 /*@ axiomatic ax_count_ref_stack{L} { @ logic integer count_ref_stack{L}(vmword vmheap[], @ vmword vmstack[],integer isp, integer ih); @ axiom cnt_ref_empty{L}: @ \forall vmword heap[], stack[], integer isp, ih; @ isp==0 ==> count_ref_stack(vmheap, vmstack, 0, ih)==0; @ axiom cnt_ref_resc_1{L}: @ \forall vmword heap[], stack[], integer isp, ih; @ check_pair(vmstack[isp]) && (vmstack[isp]/2)==ih ==> @ count_ref_stack(vmheap, vmstack, isp, ih) == @ count_ref_stack(vmheap, vmstack, isp-1, ih)+1; @ axiom cnt_ref_resc_2{L}: @ \forall vmword heap[], stack[], integer isp, ih; @ check_pair(vmstack[isp]) && (vmstack[isp]/2)!=ih ==> @ count_ref_stack(vmheap, vmstack, isp, ih) == @ count_ref_stack(vmheap, vmstack, isp-1, ih); @ axiom cnt_ref_resc_3{L}: @ \forall vmword heap[], stack[], integer isp, ih; @ !check_pair(vmstack[isp]) ==> @ count_ref_stack(vmheap, vmstack, isp, ih) == @ count_ref_stack(vmheap, vmstack, isp-1, ih); @ } @*/ /*@ axiomatic ax_count_ref_heap{L} { @ logic integer count_ref_heap{L}(vmword vmheap[], @ integer ifhr, integer ihr, integer ih); @ axiom cnt_ref_empty{L}: @ \forall vmword heap[], integer ifhr, ihr, ih; @ ihr count_ref_stack(vmheap, ifhr, 0, ih)==0; @ axiom cnt_ref_resc_1{L}: @ \forall vmword heap[], integer ifhr, ihr, ih; @ check_free(vmheap,ifhr,ihr) ==> @ count_ref_heap(vmheap, ifhr, ihr, ih) == @ count_ref_heap(vmheap, ifhr, ihr-3, ih); @ axiom cnt_ref_resc_2{L}: @ \forall vmword heap[], stack[], integer isp, ih; @ !check_free(vmheap,ifhr,ihr) && @ (!check_pair(vmheap[ihr-1]) || @ (check_pair(vmheap[ihr-1]) && (vmheap[ihr-1]/2)!=ih)) && @ (!check_pair(vmheap[ihr-2]) || @ (check_pair(vmheap[ihr-2]) && (vmheap[ihr-2]/2)!=ih)) ==> @ count_ref_heap(vmheap, ifhr, ihr, ih) == @ count_ref_heap(vmheap, ifhr, ihr-3, ih); 40 Appendices 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 @ axiom cnt_ref_resc_3{L}: @ \forall vmword heap[], stack[], integer isp, ih; @ !check_free(vmheap,ifhr,ihr) && @ (!check_pair(vmheap[ihr-1]) || @ (check_pair(vmheap[ihr-1]) && (vmheap[ihr-1]/2)!=ih)) && @ (check_pair(vmheap[ihr-2]) && (vmheap[ihr-2]/2)==ih) ==> @ count_ref_heap(vmheap, ifhr, ihr, ih) == @ count_ref_heap(vmheap, ifhr, ihr-3, ih)+1; @ axiom cnt_ref_resc_4{L}: @ \forall vmword heap[], stack[], integer isp, ih; @ !check_free(vmheap,ifhr,ihr) && @ (check_pair(vmheap[ihr-1]) && (vmheap[ihr-1]/2)==ih) && @ (!check_pair(vmheap[ihr-2]) || @ (check_pair(vmheap[ihr-2]) && (vmheap[ihr-2]/2)!=ih)) ==> @ count_ref_heap(vmheap, ifhr, ihr, ih) == @ count_ref_heap(vmheap, ifhr, ihr-3, ih)+1; @ } @*/ /*@ predicate valid_ref_count{L}(vmword vmheap[], vmword vmstack[], @ integer ihr, integer isp) == @ \forall integer ih; @ valid_heap_ptr(ih) && !check_free(vmheap,ihr,ih) ==> @ vmheap[ih] == ( count_ref_stack(vmheap,vmstack,isp,ih)+ @ count_ref_heap(vmheap,ihr,MAX_HEAP_SIZE-1,ih)); @*/ 41 Références [1] George C Necula and Peter Lee Proof-Carrying Code Technical Report CMUCS-96-165, November 96 [2] Heidar Pirzadeh, Danny Dubé Encoding the program correctness proofs as programs in PCC technology Conference on Privacy, Security and Trust, pp 121-132, Fredericton, New Brunswick, Canada, Octobre 2008 [3] Heidar Pirzadeh, Danny Dubé VEP: a Virtual Machine for Extended ProofCarrying Code Workshop on Virtual Machine Security, Fairfax, Virginie, ÉtatsUnis, octobre 2008 [4] George C Necula, S P Rahul Oracle-Based Checking of Untrusted Software In Proceedings of the 28th ACM Symposium on Principles of Programming Languages (POPL01), London, January 2001 [5] Dinghao Wu, Andrew W Appel, and Aaron Stump Foundational Proof Carrying Code 5th ACM-SIGPLAN International Conference on Principles and Practice of Declarative Programming, pp 264-274, August 2003 [6] George C Necula Compiling with Proofs Carnegie Mellon University, September 1998 [7] C A R Hoare An axiomatic basis for computer programming The Queens University of Belfast, Northern Island, pp 576-583 [8] Raul Rojas A tutorial instruction to lambda calculus FU Berlin, WS-97/98 [9] George C Necula and Peter Lee Efficient Representation and Validation of Logical Proofs Technical Report CMU-CS-97-172, October 97 [10] Christopher Colby , Peter Lee , George C Necula , Fred Blau , Mark Plesko , Kenneth Cline A certifying compiler for Java In Proceedings of the 2000 ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI00), Vancouver, British Columbia, Canada, June 18-21, 2000 [11] George C Necula Proof-Carrying Code, design and implementation Department of Electrical Engineering and Computer Sciences, University of California, Berkeley [12] Michael, Neophytos G., Appel, Andrew W Machine Instruction Syntax and Semantics in Higher Order Logic 17th International Conference on Automated Deduction (CADE-17), pp 7-24, Springer-Verlag (Lecture Notes in Artificial Intelligence), June 2000 42 [13] Appel, Andrew W., Felten, Edward W Models for Security Policies in ProofCarrying Code Authors Princeton University Computer Science TR-636-01, March 2001 [14] Patrick Cousot Interprétation abstraite Département d’informatique, École normale supérieure [15] Trusted computer system evaluation criteria Department of Defense, DoD 5200.28-STD, December l985 [16] Andrew W Appel and Amy P Felty A Semantic Model of Types and Machine Instructions for Proof-Carrying Code 27th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL '00), pp 243-253, January 2000 [17] Simon Peyton John, Erik Meijer A Typed Intemediate Language University of Glasgow and Oregan, May 1997 [18] Greg Morrisett, Karl Crary, Neal Glew, and David Walker Stack-based typed assembly language In ACM Workshop on Types in Compilation, Kyoto, Japan, March 1998 [19] Heidar Pirzardeh Encoding Program Correctness Proof as Programs in PCC Technology 2008 [20] Yannick Moy and Claude Marché Jessie plug-in tutorial June 2009 [21] Patrick Baudin, Jean-Christophe Filliâtre, Claude Marché, Benjamin Monate, Yannick Moy, Virgile Prevost ACSL: ANSI/ISO C Specification Language ANR project (ANR-05-RNTL-0030x), October 2008 [22] Sylvain Conchon, Evelyne Contejean, François Bobot, Stéphane Lescuyer Prouveur de théorème Alt-Ergo [Internet] Available from: http://ergo.lri.fr/ [23] Xavier Leroy, Damien Doligez, Jacques Garrigue, Didier Rémy and Jérôme Vouillon The Objective Caml system Institut National de Recherche en Informatique et en Automatique November 2008 [24] Gerard J Holzmann Software Analysis and Model Checking Bell Laboratories, Lucent Technologies, Murray Hill, New Jersey 07974, USA [25] Markus Mohnen A Graph-Free Approach to Data-Flow Analysis Lehrstuhl für Informatik II, RWTH Aachen, Germany 43 [...]... automatiquement, c.a.d, la génération des preuves n’est pas toujours réalisable, dans ce cas, on doit utiliser le technique de vérification interactif (il faut que l’opérateur du producteur de code ait des expériences pour qu’il puisse fournir des axiomes ou des preuves intermédiaires pour faciliter la génération des preuves) Une autre difficulté de technique PCC est que la taille des preuves est très grand, normalement... capable de générer automatiquement les preuves, il faut que l’on ajoute manuellement des axiomes ou des preuves intermédiaires pour faciliter la génération des preuves Les preuves générées vont être envoyé au consommateur Dans la dernière étape, le consommateur de code effectuer une vérification des VC et les preuves fournis par le producteur Chaque étape d’inférence des preuves sera validée avec les axiomes... système PCC traditionnel De point de vue de fonctionnalité, on a deux acteurs dans un système PCC, le producteur de code et le consommateur de code Le consommateur de code se compose de deux composants principaux : un générateur de condition de vérification (VCGen) et un examinateur de preuves Il définit ses politiques de sécurité Le VCGen s’occupe de représenter la combinaison de ces politiques et le... des preuves, le deuxième composant est assez simple, il y a seulement les opérations de comparer des preuves avec la VC générée Le générateur de VC est plus large et plus compliqué (~23000 lignes de code source en C [10] pour analyser les instructions du programme, les déclarations formelles des pré-conditions, des post-conditions, des invariants) Une erreur dans le VCGen provoquera des fautes quand... le code fournit par le producteur est autorisé d’exécuter sur le consommateur Il y a deux composants à côté de producteur de code : le compilateur certifié pour compiler le code source au format exécutable avec des annotations (pré-condition, post-condition, invariant de la boucle, …) et le prouveur de théorème pour générer des preuves qui ont accompagnés avec le programme Le consommateur de code doit... la première étape, le consommateur de code doit définir un politique de sécurité C’est un ensemble de règles qui assurent que l’exécution de code sur le consommateur ne provoque pas des dangers La politique de sécurité est représentée sous forme d’une logique mathématique, en réalité, c’est un ensemble des expressions et des prédicats en logique du premier ordre des lesquels le satisfaisant provoque... consommateur de code est le plus 15 Chapitre II - Techniques principales de PCC simple au milieu des autres techniques PCC Néanmoins, la taille de preuves générées est augmentée presque 20% en comparaison avec la technique PCC traditionnel qui produit des preuves assez gros La logique d’ordre supérieur simplifie la représentation de politique de sécurité mais cause aussi plus de difficulté dans la génération des. .. une autorisation d’exécution du code L’ensemble des axiomes (premier expression de la Figure 2) et des règles d’inférence (deux autres expressions de la Figure 2) sont utilisés pour prouver la rectitude des prédicats 5 Chapitre II - Techniques principales de PCC Γ ⊢ 1: 𝑖𝑛𝑡 𝑥: 𝑖𝑛𝑡 ∈ Γ 𝑦: 𝑖𝑛𝑡 ∈ Γ Γ ⊢ 𝑥 + 𝑦: 𝑖𝑛𝑡 𝑥: 𝑖𝑛𝑡 ∈ Γ 𝑦: 𝑖𝑛𝑡 ∈ Γ Γ ⊢ 𝑥 − 𝑦: 𝑖𝑛𝑡 Figure 2 Représentation des axiomes et règles d’inférence... assurer qu’après l’exécution de l’instruction, les données sont stockées dans la position valide de la pile  Le débordement de la pile : pour les instructions qui mettent des données dans la pile, il faut qu’elle soit capable de tous stockés  Le débordement du tas : pour les instructions qui mettent des données dans le tas, il faut tester si le tas a assez de l’espace pour stocker des nouvelles paires Tous... une zone de mémoire orpheline qui n’est plus utilisable Pour éviter le problème de référence cyclique, la VEP n’autorise pas les opérations de mutation de paires, donc aucun cycle ne peut être créé, par conséquence le récupérateur de mémoire de la VEP n’est pas vulnérable à cet issue 21 Chapitre III - Vérification de la sécurité de la VEP 1.3 Ensemble des instructions de VEP Figure 16 Ensemble des instructions