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 ......................................................................................................................... 1
Introduction ..................................................................................................................... 1
1.

Contexte du stage ............................................................................................... 1

2.

Problématique ..................................................................................................... 1

3.

Principes d’assurer la sécurité pour le consommateur ....................................... 2

4.

Contributions ...................................................................................................... 3

5.

Structure du rapport ............................................................................................ 3

Chapitre II ........................................................................................................................ 4
Techniques principales de PCC....................................................................................... 4
1.

Technique PCC traditionnel ............................................................................... 4
1.1 Architecture du système PCC traditionnel ...................................................... 4
1.2 Protocole de PCC traditionnel......................................................................... 5
1.3 Implémentation du technique PCC traditionnel .............................................. 7
1.4 Contributions du technique PCC traditionnel ...............................................10

2.

Technique OPCC..............................................................................................12
2.1 Architecture du système OPCC ....................................................................12
2.2 Contribution du technique OPCC .................................................................13

3.

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

4.

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
1.

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

2.

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
1.

Conclusion ........................................................................................................34

2.

Perspectives ......................................................................................................35
2.1 Travail pratique .............................................................................................35
2.2 Travail théorique ...........................................................................................35

Appendices ....................................................................................................................37
1.

Outil pour le prouveur de théorème .................................................................37

2.

Utilisation de Frama-C .....................................................................................38

3.

Spécification de sécurité du tas dans la VEP ...................................................39

Références .....................................................................................................................42

-ii-


List des figures
Figure 1. Architecture du système PCC [6] ...................................................................... 5
Figure 2. Représentation des axiomes et règles d’inférence. .......................................... 6
Figure 3. Spécification de la fonction inc. ...................................................................... 6
Figure 4. Une condition de vérification. ......................................................................... 7
Figure 5. La machine abstraite DEC Alpha [9]. ............................................................... 8
Figure 6. Calcule de condition de vérification [9]. ........................................................... 9
Figure 7. Architecture de technique OPCC. ..................................................................12

Figure 8. Architecture de technique FPCC. ..................................................................14
Figure 9. 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
1. 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.

2. 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
1


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 5 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.

3. 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é.

2


Chapitre I - Introduction

4. Contributions
Il y a deux contributions principales dans le cadre du stage :
 Analyser des techniques principales de PCC dans la pointe de vue de
l’utilisateur, ses avantages et aussi des inconvénients dans l’application en
réalité.
 Proposer un changement dans l’algorithme de récupérateur de mémoire de la
machine virtuelle d’EPCC et un prototype pour prouver sa sécurité
automatiquement.

5. Structure du rapport
La suite de ce mémoire se compose de quatre parties
 Chapitre II – Techniques principales de PCC : présenter l’idée principale de
trois techniques de programme accompagné de preuves, leurs forces
et faiblesses, spécialement le cadre EPCC.
 Chapitre III – Vérification de la machine virtuelle d’EPCC : Introduire en détail
l’architecture de la VEP, proposer un algorithme pour le récupérateur de
mémoire et un prototype pour prouver automatiquement la sécurité de VEP.
 Chapitre IV – Conclusion et perspectives : Remarques dans l’application de
technique PCC en réalité et quelques l’extension de recherche.
 Appendice : Informations supplémentaires de l’utilisation d’interface graphique
pour le prouveur de théorème, l’utilisation de Frama-C et un exemple des
spécifications pour prouver une partie de VEP.

3


Chapitre II
Techniques principales de PCC
1. Technique PCC traditionnel
1.1 Architecture du 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 résultat d’analyser statique du programme sous forme d’une condition
de vérification (VC). C’est une formule logique qui représente le respect de la
politique par le code en cours de vérification. Si la formule est vraie alors le code

est sécuritaire. L’autre composant, l’examinateur de preuves réalise une teste sur ses
politiques de sécurité avec les preuves fournit par le producteur de code. Si la preuve
garantit que la VC est vraie et donc que le code est sécuritaire, 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 effectuer des opérations sécuritaires et donc qu'il ne
peut pas se permettre d'exécuter du code qui pourrait être dangereux. Il exige donc
que le producteur du code joigne une preuve de sécurité au code qu'il fournit.
Dans la figure 1, le TCB du système contient tous les composants du consommateur
(les objets non-gris). Les composants et les données de producteur de code ne sont pas
dans le TCB du consommateur, ils sont les composants qui n'ont pas à être
sécuritaires. Une caractéristique originale du PCC est que l’on fait confiance au
consommateur du code en utilisant des preuves méfiantes générées par le producteur
de code qui est aussi méfiant.
4


Chapitre II - Techniques principales de PCC

Figure 1. Architecture du système PCC [6]
Dans la section suivante, on analyse en détail les manipulations sur les données et
étapes d’échange des données qui ont utilisés dans PCC.

1.2 Protocole de PCC traditionnel
On peut catégoriser le protocole de PCC dans 5 étapes principales :
Dans 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 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.
Toutes les fonctions provoquées par le consommateur doivent être spécifiées dans la
politique de sécurité, chaque spécification est représentée sous forme d’un triplet de
Hoare [7], {Pre}F{Post}.
{Pre} décrit l’état des variables, des arguments ou des relations (prédicats) entre eux
qui doivent être satisfaits avant l’invocation de la fonction.
{Post} décrit les relations entre les variables, et la valeur retournée par la fonction. Si
la pré-condition est satisfaite alors après l’exécution de la fonction F la post-condition
{Post} doit être respectée.
1. int inc (int x) {
2.

return x+1;
3. }
4. {x:int}inc(x){\result:int Λ \result>x}

Γ ⊢ λ𝑥. 𝑥 + 1: 𝑖𝑛𝑡 → 𝑖𝑛𝑡
Γ ⊢ 𝑥: 𝑖𝑛𝑡
Γ ⊢ λ𝑥. 𝑥 + 1 𝑥 : 𝑖𝑛𝑡 ∧ (λ𝑥. 𝑥 + 1 𝑥) > 𝑥
Figure 3. Spécification de la fonction inc.
La Figure 3 est un exemple d’une fonction qui retour la valeur précédant d’un entier
d’entré. Le triplet de Hoare est représenté sous forme λ-calcul [8].
La deuxième étape est réalisée par le producteur de code avec l’aide d’un compilateur
certifié, le code source est compilé à la forme exécutable avec des annotations (les préconditions, post-conditions de toutes les fonctions, les invariants de chaque boucle). Il
faut que le VCGen à côté de consommateur comprend la représentation des
annotations générées par le compilateur certifié de producteur, sinon le VCGen ne
6


Chapitre II - Techniques principales de PCC
peut pas construire le VC pour le programme, par conséquence le programme sera
refusé d’exécuter sur le consommateur.
∀𝑥. 𝑥: 𝑖𝑛𝑡 → ∀𝑟. 𝑟 = 𝑥 + 1 → 𝑟: 𝑖𝑛𝑡 ∧ 𝑟 > 𝑥
Figure 4. Une condition de vérification.
Dans la troisième étape, le VCGen du consommateur inspecte le programme reçu. Il
réalise un teste sur la syntactique du programme et émet VC qui violent la politique de
sécurité de consommateur.
La quatrième étape, le prouveur de théorème de producteur essais de prouver la VC en
utilisant les axiomes et les règles d’inférence. Dans le cas le prouveur de théorème
n’est pas 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 et les règles d’inférence disponibles. Le protocole PCC ne
spécifie pas précisément la représentation des preuves ni l’algorithme pour les valider
mais il faudra maintenir une indépendance entre cet algorithme et la représentation des
preuves pour que l’implémentation soit réutilisée dans multiple applications. En outre,
l’algorithme de vérification doit être le plus simple possible pour qu’il soit confiant et
assez vite. La VC et les preuves doivent être représentés sous une forme compacte
pour diminuer le volume de données échangées entre deux entités du système PCC.

1.3 Implémentation du technique PCC traditionnel
Necula et al ont implémenté le protocole PCC [9] sur une machine abstraire. Le
langage utilisé est un sous ensemble du DEC Alpha Assembleur. Les instructions sont
ADD, SUB, LD, ST, BEQ, BNE, RET. Toutes les instructions du processeur de DEC
Alpha est de type 64bit.
Suppose que rm est le registre qui contient l’état de mémoire dans la computation,
(ρ,pc) représente l’état de la machine où ρ est l’état de registre, pc est le compteur
ordinal, ρ(ri) est la valeur de registre i dans l’état ρ, ρ(rm)(a) est la valeur de mémoire
à l’adresse a, ρ[ri ← v] est le nouvel état de registre obtenu en assignant ri par v,
sel(rm,e) est la valeur pointé par e dans la mémoire (équivalant à ρ(rm)( ρ(e))),
7


Chapitre II - Techniques principales de PCC
upd(rm,e1,e2) représente la nouvel état de mémoire où on écrit la valeur du registre
calculé par e2 au location calculé par e1. On a le diagramme de changement de l’état de
la machine abstraite après l’exécution d’une commande comme dans la figure suivant.

Figure 5. La machine abstraite DEC Alpha [9].
Le calcul est réalisé sur un programme simple (de ligne 1 à ligne 6 et la ligne L 1), au

début, r0 contient la valeur du tag, r0+8 est l’adresse de donnée. Si le tag égale à 0,
alors après l’exécution du programme, r0 égale à 1 plus la valeur pointée par r0+8,
sinon r0 contient la donnée pointée par r0+8. On a le codage en langage intermédiaire

On a la pré-condition

Et la post-condition
Post = r1 : ro_addr

8


Chapitre II - Techniques principales de PCC
Dans l’implémentation de Necula et al, la condition de vérification est calculée
inversement, le détail est spécifié dans la figure 6.

Figure 6. Calcule de condition de vérification [9].
On a la VC comme suivante

9


Chapitre II - Techniques principales de PCC
Les preuves accompagnées avec le programme

1.4 Contributions du technique PCC traditionnel
Le technique PCC assure non seulement la sûreté de typage, la sécurité de la mémoire
mais aussi des autres caractéristiques dès qu’on peut les représenter sous forme d’une
10

Chapitre II - Techniques principales de PCC
logique du premier ordre. La plupart du travail (génération des preuves) est réalise sur
le producteur de code avec l’aide de prouveur de théorème, on n’a pas besoin d’un
infrastructure spéciale au consommateur, la vitesse de vérification est alors assurée.
De plus, la vérification est effectuée une seule fois, donc la performance du
programme sur le consommateur est préservée. Dans l’architecture du système PCC,
le TCB se compose seulement des composants de consommateur, le PCC alors ne relie
pas à une relation de confiance entre le producteur et le consommateur. Le PCC peut
être utilisé pour le langage machine, d'une certaine façon, le PCC est indépendant de
langage de programmation.
Cependant, il y a quelques inconvenances qu’il faut faire attention dans le PCC. Le
TCB du système contient un générateur de VC et le vérificateur 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 prouvant un programme.
D’ailleurs, ce n’est pas facile à prouver un théorème 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 égale à 2.5 ou 5 fois la taille du
programme [11], c’est un problème avec les consommateurs qui ont la ressource faible
comme les téléphones portables, les PDA ...
Malgré il existe encore des inconvénients le PCC est une technique prometteuse car on
sépare des travaux les plus durs sur le serveur (le producteur de code), on a besoin de
déployer un infrastructure assez simple sur le client (le consommateur de code). Pour
appliquer le technique PCC en réalité, plusieurs améliorations ont été effectuées. On

les verra dans les parties suivantes.

11


Chapitre II - Techniques principales de PCC

2. Technique OPCC
2.1 Architecture du système OPCC
Une limitation de technique PCC est que la taille de preuves soit très grande, Necula et
al ont inventé la méthode PCC d’oracle [4] (Oracle based Proof Carrying Code, OPCC)
ils ont changé un peut d’architecture du système PCC traditionnel.

Figure 7. Architecture de technique OPCC.

12


Chapitre II - Techniques principales de PCC
Sur consommateur de code, le vérificateur de preuves est remplacé par un interpréteur
non-déterministe, le client alors ne fait plus la comparaison simple entre la VC et les
preuves mais il doit prouver la VC générés par le VCGen en utilisant cet interpréteur.
Le producteur de code ne transfère directement les preuves mais une chaine (on
l’appelle chaine d’oracle) pour guider l’interpréteur non-déterministe du client de
prouver la VC. Les composants du système OPCC est décrit dans la figure 7.

2.2 Contribution du technique OPCC
Le remplacement de vérificateur de preuves par l’interpréteur non-déterministe au
consommateur qui rend plus compliqué son infrastructure. Mais avec l’aide de chaine
d’oracle, le travail réalisé par l’interpréteur est assez simple. Le technique OPCC alors

a tous les avantages de technique PCC traditionnelle. De plus, au lieu de transférer
tous les preuves, le producteur transfère seulement une chaine pour guider
l’interpréteur de consommateur prouver lui-même son VC, la taille de données
échangées donc diminue significativement, 30 fois plus petit [4] que les preuves, égale
à 12% la taille du programme. C’est une amélioration remarquable à partir du modèle
original de PCC.

3. Technique FPCC
3.1 Architecture du système FPCC
Une des points faibles de PCC est que son TCB contient le générateur de VC qui est
un grand programme et vulnérable. Une faute du VCGen causera facilement la malfonction du consommateur. Adrew W. Appel et al a construit le technique FPCC [5]
(Foundational Proof Carrying Code) dans lequel générateur de VC est enlevé et
intégré au politique de sécurité. Pour qu’il soit réalité, les code et les preuves fournir
par le producteur doit être capable de prouver eux-mêmes. En outre, au lieu d’intègre
les règles d’inférence de typage dans la politique de sécurité sur le consommateur, le
producteur de code définit lui-même le système de typage et prouve les règles de
typage comme des lemmes et utilise la logique d’ordre supérieur au lieu de logique du
premier ordre pour simplifier la représentation de politique de sécurité.

13


Chapitre II - Techniques principales de PCC

Figure 8. Architecture de technique FPCC.

3.2 Implémentation de technique FPCC
Dans la représentation du FPCC, le programme est considéré comme une séquence des
entiers (chaque entier représente un instruction) [5] [16]. A chaque moment, l’état du
système est représenté par la paire (r,m) dans laquelle r est l’état de l’ensemble des

registres et m est l’état de la mémoire, après chaque instruction, la machine passe à un
nouvel état (r’,m’).

Figure 9. Instructions sont encodées avec un mot 32-bit [16].

14


Chapitre II - Techniques principales de PCC
Chaque instruction est définit en logique comme une fonction lambda, par exemple
pour l’instruction d’ajouter deux entier (add)
(r,m) ↦ (r’,m’) ≡
add(i,j,k) = λr,m,r’,m’ . r’(i) = r(j)+r(k) Λ (forall x≠i . r’(x)=r(x)) Λ (m’ = m)
Le décodage d’instruction
decode(w,instr) ≡
(∃i,j,k. 0 ≤ 𝑖 ≤ 25 Λ 0 ≤ 𝑗 ≤ 25 Λ 0 ≤ 𝑘 ≤ 25 Λ
w = 3 × 226 + i × 221 + j × 216 + k × 20 Λ instr = add(i,j,k)) V
(∃i,j,k. 0 ≤ 𝑖 ≤ 25 Λ 0 ≤ 𝑗 ≤ 25 Λ 0 ≤ 𝑐 ≤ 216 Λ
w = 12 × 226 + i × 221 + j × 216 + 𝑐 × 20 Λ instr = load(i,j,c)) V
…

A chaque moment donné, la sécurité de l’état de la machine est définit par la logique
suivant
safe-state(𝑟, 𝑚) = ∀𝑟 ′ , 𝑚′ . 𝑟, 𝑚 ↦∗ 𝑟 ′ , 𝑚′ ⇒ ∃𝑟", m". 𝑟 ′ , 𝑚′ ↦ 𝑟", m"
Un programme p est mis en mémoire m avec le point d’entré start
loaded(p,m,start) = ∀𝑖 ∈ dom 𝑝 . 𝑚 𝑖 + 𝑠𝑡𝑎𝑟𝑡 = 𝑝(𝑖)
Un programme est sécuritaire si son mis en mémoire avec n’import quel point d’entré
on a l’état sécurité de la machine
safe(p) = ∀𝑟, 𝑚, 𝑠𝑡𝑎𝑟𝑡. loaded(p,m,start) Λ r(pc)=start ⇒safe-state(r,m)
Avec cette représentation, on n’a pas besoin d’un générateur de VC à consommateur

de code et le vérificateur de preuves seulement fait le décodage de chaque instruction,
comparer les preuves avec les paramètres des instructions et l’état du client pour
autoriser l’exécution de programme.

3.3 Contribution de technique FPCC
En enlevant le générateur de VC, la technologie FPCC diminue significativement le
TCB (~26000 lignes de code source en OPCC et ~2700 lignes de code source en
FPCC). Par conséquence, le modèle FPCC est plus sécurité du modèle OPCC ou PCC
traditionnel, dans ce modèle, l’infrastructure du 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
preuves. Ces inconvénients eux-mêmes rendent l’impossibilité d’appliquer largement
la technique FPCC en réalité.

4. Technique EPCC
4.1 Architecture du technique EPCC

Figure 10. EPCC pour le PCC traditionnel [2].
16


Chapitre II - Techniques principales de PCC
EPCC (Extended Proof Carrying Code) n’est pas attaché avec une certain modèle
PCC. On peut appliquer l’idée pour toutes les techniques basées sur le PCC. La Figure

10 décrit une étude de cas où on applique l’EPCC pour le PCC traditionnel.
En général, on ajoute un composant qui fait la compression sur les preuves (dans
FPCC et PCC traditionnel) ou le chaine d’oracle (dans OPCC). En suite, on emballe
les preuves compressées avec le décompresseur pour créer un générateur de preuves,
un programme spécial destiné à être exécuté du côté du consommateur. Ce générateur
de preuves est accompagné avec le programme et transféré à consommateur. Le
consommateur est équipé avec une machine virtuelle (VEP) où on fait marcher le
générateur de preuves envoyé par le producteur de code et reconstruire les données
originales des preuves ou le chaine d’oracle pour l’entrée de vérificateur de preuves ou
l’interpréteur non-déterministe correspondant.

4.2 Contribution de technique EPCC
L’apparaître de VEP dans le TCB du EPCC ne signifie pas que le technique EPCC est
plus vulnérable en comparaison avec autres techniques qui basent sur le PCC parce
que la taille de VEP est très petit (~300 lignes de code source en C) et on peut alors
vérifier sa sécurité en main. L’application d’EPCC dans le modèle PCC traditionnel
diminue la taille de preuves mais la taille de générateur créé est encore plus grande
que la chaine d’oracle dans le modèle OPCC. Cette direction donc n’a pas beaucoup
de bénéfice. L’application d’EPCC dans OPCC n’a pas beaucoup d’avantage parce
que la taille de chaine d’oracle est petite en comparaison avec les preuves, de plus
cette chaine est également optimisée.
L’extension d’EPCC dans le FPCC est une combinaison parfaite. La machine VEP et
le générateur de preuves est une réponse pour le problème de la taille grosse des
preuves dans FPCC. D’autre part, la taille petite de TCB qui est un grand avantage de
FPCC est conservée à cause de la simplicité de machine VEP.

17