Contrôle du flot d'information par des techniques basées sur le langage de programmation

Contrôle du flot d’information par des techniques

basées sur le langage de programmation

Mémoire

Jean Claude Simo

Maîtrise en informatique

Maître ès sciences (M.Sc.)

Québec, Canada

R´

esum´

e

Un programme est dit non interf´erent si les valeurs de ses sorties publiques ne d´ependent pas des valeurs de ses entr´ees secr`etes. Des ´etudes ont montr´e que par l’analyse du flot d’infor-mation, on peut ´etablir et contrˆoler cette propri´et´e ou des propri´et´es qui lui sont ´etroitement li´ees.

Dans ce travail, nous examinons en d´etail les mod`eles d’analyse de flot d’information existants, et esquissons une nouvelle approche dans un paradigme concurrent. La premi`ere partie de ce m´emoire pr´esente les diff´erentes formulations de la non-interf´erence et un survol des grandes familles de m´ecanismes d’analyse de flot d’information. En second lieu, nous pr´esentons en d´etail quelques m´ecanismes r´ecents d’analyse sensibles aux flots, applicables `a la programma-tion s´equentielle. M´ecanismes statiques pour certains, dynamiques ou hybrides pour d’autres. Dans la troisi`eme partie, nous explorons deux mod`eles r´ecents de s´ecurisation des flots d’in-formation dans un programme concurrent. Les deux mod`eles ont en commun la particularit´e de proposer des traitements pour s´ecuriser l’interaction entre les programmes et l’ordonnan-ceur. Nous terminons par une esquisse de notre nouvelle approche, bas´ee sur l’analyse des d´ependances entre les variables d’un programme concurrent.

Abstract

A program is said to be noninterfering if the values of its public (or low) outputs do not depend on the values of its secret (or high) inputs. Various researchers have demonstrated how this property (or closely related properties) can be achieved through information flow analysis. In this work, we present in detail some existing models of information flow analysis, and sketch a new approach of analysis for concurrent programming.

The first part of this thesis presents the different formulations of non-interference, and an overview of the main types of information flow analysis. In the second part, we examine in detail some recent static and dynamic (hybrid) flow-sensitive analysis models, for a simple imperative language. In the third part, we explore two recent models of secure information flow in concurrent programs, which develop a novel treatment of the interaction between threads and the scheduler to prevent undesired interleaving. We end with a sketch of the foundations for another approach, based on the analysis of dependencies between variables of concurrent programs.

Table des mati`

eres

R´esum´e iii

Abstract v

Table des mati`eres vii

Liste des tableaux ix

Liste des figures xi

Remerciements xvii

1 Introduction 1

1.1 Motivation . . . 1

1.2 Probl´ematique . . . 2

1.3 Approche adopt´ee et organisation du m´emoire. . . 3

2 Flot d’information : caract´erisation et m´ecanisme de contrˆole 5 2.1 Introduction. . . 5

2.2 Caract´erisation des flots d’information illicites . . . 5

2.3 Quelques notions de base . . . 13

2.4 Les grandes familles de m´ecanismes de contrˆole du flot d’information . . . 17

3 Contrˆole du flot d’information par analyse sensible aux flots 23 3.1 Introduction. . . 23

3.2 Analyse par typage sensible aux flots . . . 24

3.3 Contrˆole dynamique par monitorage de l’ex´ecution . . . 33

3.4 Contrˆole dynamique par instrumentation du programme . . . 46

3.5 Conclusion . . . 49

4 Contrˆole du flot d’information dans un programme concurrent 51 4.1 Introduction. . . 51

4.2 Quelques notions de base de la programmation concurrente . . . 52

4.3 Fuites sp´ecifiques aux programmes concurrents . . . 56

4.4 Hypoth`eses et exigences . . . 58

4.5 Le mod`ele de Russo et Sabelfeld . . . 60

4.6 Le mod`ele de Mantel et Sudbrock. . . 71

5 Analyse du flot d’information par l’´etude des d´ependances entre variables 83

5.1 Introduction. . . 83

5.2 L’id´ee de base . . . 84

5.3 Quelques exemples de fuites provoqu´ees par la mise en concurrence des pro-grammes dans un contexte sensible aux flots. . . 85

5.4 Condition de s´ecurit´e . . . 88 5.5 Le mod`ele . . . 88 5.6 Analyse de s´ecurit´e . . . 92 5.7 Conclusion . . . 95 6 Conclusion 97 Bibliographie 99

Liste des tableaux

2.1 Langage imp´eratif simple . . . 16

3.1 S´emantique des commandes avec ´ev´enements internes tir´ee de [24] . . . 40

3.2 S´emantique op´erationnelle du moniteur tir´ee de [24] . . . 41

3.3 Comportements possibles du moniteur tir´es de [24] . . . 43

3.4 R`egles de transformation des expressions tir´ees de [8] . . . 47

Liste des figures

2.1 Exemple de structure `a compartiment pour la s´ecurit´e militaire tir´e de [1] . . . 7

3.1 R`egles de typage du mod`ele Desharnais et al. tir´ees de [12] . . . 31

3.2 S´emantique des commandes tir´ee de [24] . . . 34

3.3 R`egles de transformation des commandes tir´ees de [8] . . . 48

4.1 Synchronisation par des s´emaphores tir´ee de [31] . . . 56

4.2 syntaxe des commandes tir´ee de [23] . . . 60

4.3 S´emantique des commandes tir´ee de [23] . . . 61

4.4 S´emantique du bassin des processus tir´ee de [23] . . . 64

4.5 Syst`eme de types de s´ecurit´e tir´e de [23] . . . 67

4.6 syntaxe du langage avec gestion des s´emaphores tir´ee de [23] . . . 69

4.7 Syst`eme de types du mod`ele de Mantel et Sudbrock tir´e de [20] . . . 79

Je d´edie ce travail `a Mireille, mon ´epouse et `a mes enfants ´

Edith Laeticia, Yvan Siegfried, Chanelle et Dylan, pour avoir accept´e tant de sacrifices durant ces derni`eres ann´ees.

La vie, c’est comme une

bicyclette, il faut avancer pour ne pas perdre l’´equilibre.

Albert Einstein ; Math´ematicien, Physicien, Scientifique (1879 -1955)

Remerciements

J’adresse tout particuli`erement ma reconnaissance aux Professeures Nadia Tawbi et Jos´ee Desharnais, pour la direction et respectivement la codirection de ce travail. Elles ont su me faire profiter de leurs nombreuses connaissances et m’ont initi´e `a la rigueur de la r´edaction scientifique. Je remercie aussi les membres du jury, les Professeurs Mohamed Mejri et Thierry Eude, pour avoir accept´e d’examiner ce m´emoire.

Je suis rest´e en emploi tout au long de mon cheminement de maˆıtrise, ´etudiant en temps partiel. Durant cette p´eriode, j’ai eu la chance de travailler avec trois gestionnaires qui m’ont soutenu et encourag´e dans ma d´emarche : M. Judy Bousardo chez Momentum Technologies, M. Michel Dubreuil au Centre des Services Partag´es de Qu´ebec (CSPQ) et Mme Martine Lapierre `a l’Agence de Revenu du Qu´ebec. Madame et messieurs, trouvez ici l’expression de mes sinc`eres remerciements.

J’exprime mes remerciements `a mon ´epouse et `a mes enfants pour leur aide et leur soutien sans lesquels ce travail m’aurait ´et´e impossible.

Pour terminer, j’adresse toute ma reconnaissance `a mes coll`egues du groupe de recherche. Nous avons partag´e d’agr´eables heures de discussion, souvent tr`es anim´ees, au cours de nos r´eunions hebdomadaires sous la supervision de nos deux directrices de recherche.

Chapitre 1

Introduction

1.1

Motivation

L’information num´erique joue un rˆole grandissant dans notre vie de tous les jours. Pour s’informer et pour s’orienter, les individus souscrivent aux nouvelles parutions des journaux sur Internet, consultent les cartes et autres outils de navigation, cherchent les horaires de d´epart des transports, les informations sur les contacts, sur les organisations, sur les produits et les services. Pour se divertir, les gens se tournent davantage vers des expressions artistiques sous forme num´erique comme les romans, la musique, les films et les jeux. Sur les r´eseaux sociaux et professionnels, les gens ´echangent et discutent des id´ees, des opinions, des anecdotes sur eux-mˆemes et sur les autres. Dans l’enseignement, les derni`eres recherches et les nouvelles id´ees doivent parvenir plus rapidement dans les salles de cours pour r´epondre au besoin croissant en terme de progr`es technologique et d’am´elioration de la qualit´e de vie.

L’information se retrouve partout instantan´ement grˆace aux r´eseaux num´eriques mondiaux toujours plus fiables et accessibles, avec une bande passante en croissance continue. `A travers la t´el´ephonie, le service du courriel, le service bancaire, le commerce ´electronique, le vote ´ elec-tronique, les r´eseaux sociaux et professionnels ; le num´erique s’est d´efinitivement install´e dans notre quotidien. Ce contexte rend particuli`erement difficile la pr´eservation de la confidentia-lit´e et de l’int´egrit´e des donn´ees qui circulent. La confidentialit´e est l’exigence que seules les personnes autoris´ees aient acc`es aux informations qui leur sont destin´ees et que tout acc`es ind´esirable soit empˆech´e. L’int´egrit´e est l’exigence que les donn´ees soient toujours celles que l’on s’attend `a ce qu’elles soient, sans ˆetre alt´er´ees de fa¸con fortuite ou volontaire. La situation de la confidentialit´e des renseignements personnels, c’est-`a-dire la vie priv´ee, m´erite qu’on s’y attarde un instant. Une divulgation non d´esirable de renseignements personnels peut avoir de graves cons´equences sur le plan financier, professionnel et social d’un individu. Par exemple, on apprend r´eguli`erement que des individus mal intentionn´es ont utilis´e les informations de la carte de cr´edit d’une autre personne pour payer des achats sur Internet, que les donn´ees d’authentification d’une personne `a un service en ligne ont ´et´e utilis´ees frauduleusement pour

faire des retraits sur son compte bancaire, pour voter en son nom, pour abuser de sa cr´ e-dibilit´e via son compte courriel ou son profil sur un r´eseau social ou professionnel. De la mˆeme fa¸con, des informations personnelles sur l’historique de cr´edit, sur l’´etat de sant´e, sur l’activit´e professionnelle, sur les opinions politiques et religieuses ou sur l’orientation sexuelle sont souvent utilis´ees frauduleusement par des personnes de mauvaise foi au d´etriment de la personne `a qui elles appartiennent. `A titre d’illustration, le rapport 2014 de Javelin1 sur la fraude d’identit´e2indiquait que le nombre de victimes des fraudes de l’identit´e aux ´Etats-Unis a atteint un chiffre record de 13,1 millions en 2013. Ceci repr´esente une augmentation de plus de 500.000 sur un an.

Dans un contexte politico-militaire, une fuite d’information peut avoir de graves cons´equences sur la vie politique d’un pays, sur les relations diplomatiques avec d’autres pays ou encore sur la s´ecurit´e des personnes et des biens.

Pour ce qui est de l’int´egrit´e des donn´ees, certaines compagnies ont un mod`ele d’affaires bas´e sur la vente d’informations issues d’une collecte des donn´ees. Par exemple, les donn´ees sur les habitudes des consommateurs de produits et services sont souvent collect´ees et analys´ees, et les r´esultats sont utilis´es pour optimiser les strat´egies de vente. De telles organisations peuvent subir d’importantes pertes financi`eres si l’int´egrit´e des donn´ees collect´ees est compromise. La s´ecurisation des syst`emes informatiques modernes s’impose comme un d´efi constant, et les techniques doivent ´evoluer rapidement pour s’adapter au rythme des changements technolo-giques.

1.2

Probl´

ematique

Les r´eseaux num´eriques mondiaux sont soutenus par des infrastructures mat´erielles et logi-cielles. La s´ecurisation de l’information qui y circule doit ˆetre envisag´ee `a ces deux niveaux d’infrastructures. Du cˆot´e logiciel, il existe plusieurs m´ethodes de limitation de la divulgation des informations par un programme. On peut citer les listes de contrˆole d’acc`es, les pare-feux, la cryptographie et le contrˆole du flot d’information. Les trois premi`eres imposent des limites `

a l’acc`es aux informations, mais ne fournissent aucun contrˆole sur la propagation de l’informa-tion. Par exemple, les listes de contrˆole d’acc`es des fichiers syst`emes empˆechent des acc`es non autoris´es aux fichiers, mais ne permettent pas de contrˆoler comment l’information contenue

1. Javelin Strategy & Research est une firme am´ericaine sp´ecialis´ee dans les ´etudes et la recherche pour identifier les risques et les opportunit´es dans quatre domaines pratiques : les services financiers, les paiements ´electroniques, la fraude et la s´ecurit´e, et le mobile. Javelin produit de fa¸con ind´ependante depuis onze ann´ees cons´ecutives une analyse compl`ete des tendances et des ´evolutions sur la fraude d’identit´e. Ses r´esultats sont publi´es sous la forme d’un rapport annuel qui permet de maintenir une base de connaissance approfondie sur le vol et l’usurpation d’identit´e. Ses recommandations font autorit´e aux ´Etats-Unis et dans le monde aupr`es des consommateurs et des entreprises.

2. La fraude d’identit´e constitue l’usage trompeur des renseignements identificateurs d’une personne (vivante ou non) en relation `a diff´erentes fraudes. Les criminels obtiennent le profil de victimes potentielles par des m´ethodes raffin´ees grˆace `a la technologie et en g´en´eral sur Internet.

dans le fichier est utilis´ee par la suite. De mˆeme, la cryptographie fournit un moyen d’´ echan-ger les informations priv´ees `a travers un canal non s´ecuris´e, mais on n’a aucune garantie de confidentialit´e des donn´ees une fois qu’elles sont d´ecrypt´ees. Le contrˆole du flot d’information offre une approche prometteuse, avec pour objectif de contrˆoler la circulation de l’information dans un programme, afin de permettre seulement les flux souhait´es et empˆecher les flux non d´esirables.

Nous explorons dans ce travail la probl´ematique de la s´ecurisation du flot d’information dans un programme. Plusieurs mod`eles de contrˆole de flot d’information dans un programme existent, notamment pour les programmes s´equentiels. Certains de ces mod`eles sont d’ailleurs impl´ement´es et disponibles sous forme de compilateur comme Jif ou Flow Calm. Du cˆot´e de la programmation concurrente, peu d’´etudes ont ´et´e faites et les quelques approches qui ont ´

et´e propos´ees r´ecemment ne sont pas encore au point pour ˆetre impl´ement´ees.

1.3

Approche adopt´

ee et organisation du m´

emoire

Notre d´emarche consiste `a pr´esenter un expos´e de l’´etat de l’art sur le th`eme de la s´ecurisation du flot d’information par le langage de programmation. Pour ce faire, nous explorons des mod`eles de s´ecurisation du flot d’information parmi les plus r´ecents, dans les programmes s´equentiels d’une part, et dans les programmes concurrents d’autre part. Nous nous efforcerons dans la pr´esentation des mod`eles, de faire ressortir les id´ees sous-jacentes derri`ere l’approche. Nous proposons aussi une ´ebauche pour une nouvelle approche dans un paradigme concurrent. Le reste du m´emoire s’organise comme suit : Dans le chapitre 2, nous caract´erisons les flots d’informations illicites, examinons quelques formulations de la non-interf´erence et ses exten-sions, propri´et´e de s´ecurit´e de base du flot d’information, et passons en revue quelques grandes familles de m´ecanismes de contrˆole du flot d’information dans un programme. Le chapitre 3

explore en d´etail trois mod`eles de s´ecurisation du flot d’information dans un programme s´equentiel. Dans le chapitre 4, on s’int´eresse aux fuites provoqu´ees par une mise en concur-rence des programmes. Quelques exemples sont examin´es et deux mod`eles de s´ecurisation applicables `a la programmation concurrente sont explor´es en d´etail. Dans le chapitre5, nous pr´esentons l’´ebauche de notre nouvelle approche qui s’appuie sur l’´etude des d´ependances entre les variables d’un programme concurrent pour ´etendre l’analyse sensible aux flots aux programmes concurrents.

Chapitre 2

Flot d’information : caract´

erisation

et m´

ecanisme de contrˆ

ole

2.1

Introduction

Dans un programme, le transfert de l’information d’une entit´e `a une autre est connu sous le nom de flot d’information. Ce flot d’information devient illicite lorsqu’il peut provoquer une fuite de l’information vers l’ext´erieur du programme. Comment caract´eriser un flot d’infor-mation illicite ? Quelles sont les propri´et´es de s´ecurit´e bas´ees sur le flot d’information ? Quels sont les m´ecanismes existants pour contrˆoler le flot d’information ?

Nous essayerons d’apporter quelques ´el´ements de r´eponse `a ces questions dans ce chapitre. Nous commen¸cons la discussion par une pr´esentation sur les caract´erisations du flot d’in-formation et sa propri´et´e de s´ecurit´e de base : la non-interf´erence. Ensuite, nous d´efinissons certains termes g´en´eraux et introduisons quelques notions math´ematiques de base, n´ecessaires pour la compr´ehension de la suite. Enfin, nous pr´esentons sommairement les grandes familles de m´ecanismes de contrˆole du flot d’information bas´es sur le langage de programmation.

2.2

Caract´

erisation des flots d’information illicites

2.2.1 Du contrˆole d’acc`es au contrˆole de flot d’information

Le contrˆole d’acc`es constitue le mod`ele principal pour la s´ecurit´e dans un grand nombre de syst`emes informatiques. On classifie les contrˆoles d’acc`es en deux groupes : les contrˆoles d’acc`es optionnels ou `a discr´etion et les contrˆoles d’acc`es obligatoires.

Dans le contrˆole d’acc`es `a discr´etion, chaque usager peut d´ecider de sa politique de s´ecurit´e, par exemple, le propri´etaire d’un fichier peut d´ecider de le partager avec un autre usager, et quel type de privil`ege ce dernier peut avoir sur le fichier (lecture ou ´ecriture). Les limitations

de ce mod`ele sont directement li´ees au fait qu’il est difficile de garantir des propri´et´es de s´ecurit´e globales pour un syst`eme dans lequel chaque acteur est ind´ependant. Il est ´etabli que le contrˆole d’acc`es pour les programmes est encore plus difficile surtout dans le cas des programmes qui interagissent [25]. Cette difficult´e est encore plus accentu´ee pour le contrˆole d’acc`es `a discr´etion, ceci d’autant plus que chaque composante du syst`eme a une vision locale et limit´ee de l’ensemble du syst`eme.

Dans le contrˆole d’acc`es obligatoire, on tente de fournir des garanties de s´ecurit´e aux syst`emes, ind´ependamment des actions de chaque acteur. L’id´ee de base est de donner des attributs et des ´etiquettes aux ressources, appel´es objets dans le mod`ele, et aux sources des requˆetes sur les objets identifi´ees dans le mod`ele par le terme principaux. Les principaux peuvent ˆetre des usagers, des ordinateurs ou des processus. Par exemple, on peut distinguer les objets de travail des objets de jeu, et les principaux de confiance des principaux visiteurs. On peut ensuite mettre au niveau des acc`es des contraintes qui s’ajoutent `a celles des usagers `a discr´etion. Par exemple, on peut d´ecider que les principaux qui sont ´etiquet´es comme des visiteurs ne doivent pas modifier les objets de travail.

Comme dans cet exemple, les contrˆoles d’acc`es obligatoires utilisent souvent les niveaux de s´ecurit´e. Ces niveaux peuvent d´ecrire des propri´et´es d’int´egrit´e ou de secret. Ils sont parfois organis´es en ordre lin´eaire, parfois en ordres plus riches comme des ordres partiels avec des propri´et´es math´ematiques int´eressantes. Dans ce cas, ils peuvent en partie refl´eter une struc-ture en compartiment. La s´ecurit´e militaire est un bel exemple de structure de compartiment pour un ordre partiel. Comme on peut voir sur la figure2.1, on peut avoir des donn´ees non classifi´ees (publiques), des donn´ees secr`etes et des donn´ees top secr`etes (beaucoup plus sen-sible que les donn´ees secr`etes). Les compartiments correspondent aux activit´es du domaine militaire, par exemple un compartiment pour l’arm´ee de terre et un autre pour la marine. Au sommet, on garde les informations les plus sensibles communes aux deux activit´es. Au second niveau on a les informations top-secr`etes pour la marine et pour l’arm´ee de terre. Au troisi`eme niveau, on a les secrets de chaque activit´e. Les secrets de la marine ne sont pas comparables avec les secrets de l’arm´ee de terre et inversement. La base est occup´ee par les donn´ees non class´ees.

Dans les syst`emes d’acc`es obligatoire, il est fr´equent de rencontrer deux conditions appel´ees les conditions de Bell-LaPadula, du nom des deux auteurs qui les ont ´enonc´ees pour la premi`ere fois :

Condition 1 : « No read-up » un principal ne peut lire un objet qui a un niveau de s´ecurit´e au-dessus du sien.

Condition 2 : « No write-down » Un principal ne peut ´ecrire sur un objet `a un niveau de s´ecurit´e plus bas que le sien.

La motivation pour cette deuxi`eme condition est de prot´eger les syst`emes contre les chevaux de Troie. Il s’agit d’un programme mauvais ou d’un principal qui travaillerait `a un niveau de

Figure 2.1 – Exemple de structure `a compartiment pour la s´ecurit´e militaire tir´e de [1]

s´ecurit´e haut et tenterait de faire fuir les informations vers les niveaux de s´ecurit´e plus bas, o`u les alli´es peuvent ensuite les faire diffuser plus largement.

Le contrˆole d’acc`es obligatoire et le contrˆole du flot d’information ont historiquement certains ´

el´ements en commun, notamment l’utilisation des niveaux de s´ecurit´e, et la conformit´e aux conditions de Bell-LaPadula. Mais chacun des deux mod`eles requiert des d´efinitions et des techniques bien sp´ecifiques. Dans le mod`ele de s´ecurit´e `a base de contrˆole d’acc`es, la s´ecurit´e est garantie en termes des principaux, des objets et des requˆetes pr´ed´efinis. Toute autre entit´e non consid´er´ee est en dehors de la port´ee de ce mod`ele. Imaginons un syst`eme dans lequel on veut ˆetre capable d’empˆecher que certaines sorties (qui pourraient ˆetre publiques) ne d´ependent de certaines entr´ees (qui pourraient ˆetre secr`etes) ou que des donn´ees qui ont une haute int´egrit´e ne d´ependent des donn´ees auxquelles on ne fait pas confiance. Dans les assertions de ce type, on impose des exigences sur des entr´ees et des sorties du syst`eme, sans n´ecessairement imposer un fonctionnement au syst`eme. Il est difficile de les int´egrer au mod`ele de contrˆole d’acc`es. Par contre, en assurant une circulation judicieuse de l’information `

a l’int´erieur du syst`eme, il est tout `a fait possible de combler de telles exigences. C’est le contrˆole du flot d’information.

Martin Abadi [1] pr´esente plus formellement la notion du flot d’information en consid´erant un syst`eme avec des entr´ees x1, ..., xm et des sorties y1, ..., yn. On suppose pour simplifier que

chaque yj est une fonction des variables x1, ..., xm, c’est-`a-dire qu’il existe une fonction fj

telle que yj = fj(x1, ..., xm). On dit que yj ne d´epend pas de l’entr´ee xi si pour toutes valeurs

effective vi du ieme` param`etre par v0i, et ce pour toute valeur vi et vi0. Autrement dit :

∀vi, vi0 : yj = fj(v1, ..., vi−1, vi, vi+1, ..., vm) = fj(v1, ..., vi−1, vi0, vi+1, ..., vm)

Cette assertion peut exprimer les propri´et´es de secret, car elle dit que la valeur de yj,

po-tentiellement publique, ne r´ev`ele aucune information qui serait contenue dans la variable xi,

potentiellement secr`ete. Elle peut aussi exprimer les propri´et´es d’int´egrit´e puisque qu’elle veut que la variable yj ne soit pas affect´ee par des corruptions ´eventuelles de xi.

Pour aller dans le sens de Denning [11], nous s´eparons les flots d’information en deux classes : les flots directs et les flots indirects. Les flots indirects sont tout simplement les flots transitifs. Par exemple, si on a un flot qui part de x vers y et un autre qui part de y vers z, les deux flots induisent un flot indirect de x vers z. Les flots directs sont aussi divis´es en deux :

– Les flots explicites arrivent par une affectation ou l’application d’une fonction. Par exemple, l’affectation x := y + z cause un flot explicite de y et de z vers x. De mˆeme, l’application de la fonction f (x) `a la variable y cause un flot explicite de y vers la variable li´ee x, en ce sens qu’un attaquant qui connaˆıt la sp´ecification de la fonction f peut deviner la valeur de y `a partir de celle de x.

– Les flots implicites arrivent lorsque la valeur d’une variable influence la valeur assign´ee `

a une autre variable en passant par le flot de contrˆole. Clark et al. [9] s´eparent encore les flots implicites en deux :

(a) Les flots locaux viennent des blocs conditionnels ou des boucles : if x then y := z else y := w;

Ici, on a un flot d’information implicite local de x vers y en plus des deux flots explicites de z et de w vers y.

x := y; (while w do x := z);

Ici, on a un flot d’information implicite local de w vers x en plus du flot explicite de z et de x.

(b) Les flots implicites globaux viennent des boucles : x := y; (while w do x := z);

Ici, on a un flot global implicite de w `a tous les points subs´equents du programme, car atteindre ces points v´ehicule l’information selon laquelle la boucle s’est termi-n´ee. Dans l’exemple, la terminaison du programme transmet l’information sur le contenu de la variable w.

Quelques exemples de flots illicites

Dans les exemples qui suivent, l’entr´ee x1 et la sortie y1 ont le mˆeme niveau qui est public et

l’entr´ee x2 et la sortie y2 ont le niveau secret :

– l’affectation y1 := x1 est accept´ee comme s´ecuritaire, car x1 et y1 sont sur le mˆeme

niveau.

– l’affectation y1 := x2 n’est pas accept´ee. C’est un flot d’information dangereux parce

qu’elle transf`ere directement l’information d’une variable secr`ete vers une variable pu-blique. C’est un exemple de flot d’information explicite.

– Dans le programme if x2 is odd then y1 := 1 else y1 := 0; la valeur de la sortie y1

d´epend de celle de l’entr´ee x2 car, si x2 est pair y1 sera ´egal `a 1 `a la fin du traitement.

Sinon y1 sera ´egal `a 0. C’est donc un flot dangereux. C’est un exemple de flot

d’infor-mation implicite.

Remarquons que tous les traitements conditionnels ne provoquent pas toujours des flots d’information dangereux. Dans l’exemple if x2 is odd then y1 := 1 else y1 := 1, la

valeur de y1 ne d´epend pas de celle de x2.

2.2.2 Propri´et´e de non-interf´erence

La non-interf´erence est la propri´et´e de s´ecurit´e de base pour le flot d’information. Elle a ´et´e d´efinie pour la premi`ere fois en 1982 par Goguen et Meseguer [15]. On dira qu’un syst`eme a la propri´et´e de non-interf´erence si une sortie peut d´ependre des entr´ees qui sont du mˆeme niveau ou d’un niveau plus bas, mais pas d’un niveau plus haut. Consid´erons par exemple un syst`eme avec deux niveaux de s´ecurit´e, secret et public. Supposons qu’il existe une relation d’ordre ≤ entre les niveaux de s´ecurit´e, avec public ≤ secret. La propri´et´e de non-interf´erence dit que des sorties au niveau public ne doivent pas d´ependre des entr´ees de niveau secret. Les propri´et´es de confidentialit´e et d’int´egrit´e sont des cas particuliers de non-interf´erence. La confidentialit´e est obtenue en consid´erant les donn´ees publiques comme de niveau bas et les donn´ees secr`etes de niveau haut. Dans le mod`ele d’int´egrit´e, pour appliquer la non-interf´erence telle que nous l’avons pr´esent´ee, on est souvent amen´e `a inverser l’ordre partiel, pour que la donn´ee la plus int`egre soit `a la base de la structure de l’ordre partiel et la moins int`egre soit au sommet. Ainsi, la non-interf´erence veut qu’une sortie int`egre (la plus basse dans la structure de l’ordre partiel) ne soit pas influenc´ee par une entr´ee douteuse (au-dessus de la base dans la structure de l’ordre partiel).

Les exemples pr´ec´edents concernent les secrets (la confidentialit´e), mais des exemples simi-laires peuvent ˆetre donn´es pour l’int´egrit´e.

Expression de la non-interf´erence par une relation d’´equivalence

Simonet [29], exprime rigoureusement la d´efinition de la non-interf´erence en utilisant les ou-tils habituels de la s´emantique des langages de programmation. Il consid`ere un langage de programmation arbitraire dont les programmes sont ex´ecut´es par une machine dont les ´etats sont les ´el´ements d’un ensemble S. Dans ce mod`ele, l’ex´ecution d’un programme e qui d´ebute avec un ´etat s ∈ S peut soit produire un ´etat s0, soit diverger. Sa s´emantique peut donc ˆetre

d´ecrite par une fonction [[ e ]] de S dans S, `a condition de disposer d’un ´etat distingu´e pour repr´esenter la non-terminaison. La distinction entre les parties basses et hautes des ´etats est donn´ee par une relation suppos´ee r´eflexive et sym´etrique d´efinie par : s1 ≈ s2 si et seulement

si s1 et s2 co¨ıncident sur leur partie basse. On dit que s1 et s2 sont indiscernables. La relation

correspond alors au pouvoir d’observation d’un attaquant de niveau « bas », c’est-`a-dire `a sa vision (partielle) de l’´egalit´e entre ´etats. On dit alors que le programme e v´erifie la propri´et´e de non-interf´erence pour ≈ si et seulement si :

∀s₁; s2∈ S s1≈ s2 ⇒ [[ e ]](s1) ≈ [[ e ]](s2)

C’est-`a-dire que deux ex´ecutions ind´ependantes du programme ayant des ´etats initiaux indis-cernables se terminent avec deux ´etats finaux ´egalement indiscernables.

2.2.3 Quelques extensions de la non-interf´erence

Non-interf´erence sensible `a la terminaison

La formulation de la non-interf´erence de la section pr´ec´edente s’appuie sur la comparaison des ´etats initiaux du programme et de ses ´etats finaux. On ne peut pas se prononcer sur cette propri´et´e pour un programme qui ne se termine pas, car son ´etat final ne pourra pas ˆetre connu. On parle alors de non-interf´erence non sensible `a la terminaison. Cette formulation s’av`ere insuffisante pour ´etablir le caract`ere s´ecuritaire d’un programme qui pourrait tourner en boucle pour certaines de ses ex´ecutions, `a l’exemple d’un programme de surveillance des acc`es ou d’un serveur d’impression. Volpano et Smith [33] ont propos´e un syst`eme de types pour un langage imp´eratif, qui permet d’empˆecher la fuite par le comportement de terminaison d’une ex´ecution d’un programme s´equentiel. D’autres ´etudes plus r´ecentes [3, 21] ont aussi abord´e cette forme de non-interf´erence.

Non-interf´erence possibiliste

La formulation standard de la non-interf´erence s’appuie aussi sur l’hypoth`ese que le langage est d´eterministe. C’est-`a-dire que le programme ne fait pas de choix arbitraire dans la s´equence de son d´eroulement. Cette formulation perd son sens en pr´esence d’un langage non d´eterministe. Une analyse de s´ecurit´e avec une d´efinition de flot d’information s´ecuritaire qui ne tient pas compte du non-d´eterminisme a une probabilit´e ´elev´ee de rejeter un programme parfaitement

s´ecuritaire qui est ´ecrit avec un langage non d´eterministe [18]. De ce constat est n´ee la non-interf´erence possibiliste qui s’´enonce comme suit : « Deux ex´ecutions qui commencent avec des entr´ees publiques identiques auront possiblement des sorties publiques identiques » [18]. Le non-d´eterminisme peut ˆetre induit par le langage de programmation ou par la planification des traitements dans un environnement concurrent.

La non-interf´erence possibiliste fait naˆıtre d’autres formes de fuites. Elle n’exige pas pour les deux sorties publiques d’avoir la mˆeme probabilit´e d’occurrence dans les deux ex´ecutions. L’auteur d’une attaque qui connaˆıt les probabilit´es d’occurrence des diff´erentes sorties pos-sibles peut potentiellement d´eduire la valeur d’une entr´ee secr`ete en fonction d’une sortie publique, en ex´ecutant plusieurs fois le mˆeme programme. Les attaques de cette nature sont connues dans la litt´erature sous le nom d’« attaques probabilistes ». Une nouvelle formulation de la non-interf´erence dite « probabiliste » permet de sp´ecifier et d’analyser de telles attaques.

Non-interf´erence probabiliste

La non-interf´erence probabiliste ajoute `a la non-interf´erence possibiliste la condition suivante : chaque sortie publique possible doit avoir la mˆeme probabilit´e d’occurrence dans toutes les ex´ecutions ayant la mˆeme entr´ee publique. Plusieurs ´etudes, dont celle de Sabelfeld et Sand [27], ont abord´e la non-interf´erence dans les programmes non d´eterministes. Nous reviendrons plus en d´etail dans le chapitre4sur cette formulation de la non-interf´erence, en particulier dans le cas o`u le non-d´eterminisme est introduit par la planification des processus d’un programme concurrent.

Pour terminer cette section sur la caract´erisation des flots d’information illicites, mentionnons que, mˆeme en s´ecurisant tous les flots explicites et implicites dans un programme, on n’est pas toujours `a l’abri d’une fuite d’information `a travers des canaux dont le mod`ele de s´ecurit´e n’a pas tenu compte. Ce sont des canaux cach´es. Dans la section qui suit, nous faisons une parenth`ese sur ces types de fuite.

2.2.4 Les canaux cach´es

En informatique, les m´ecanismes pour transf´erer l’information au travers d’un syst`eme sont d´esign´es par les canaux. Certains canaux sont con¸cus pour effectivement v´ehiculer les infor-mations. Ce sont les canaux dits « l´egitimes ». D’autres canaux apparaissent, pas toujours pr´evus pour la communication, mais utilis´es frauduleusement comme tel, toujours plus ing´ e-nieux et surprenants les uns que les autres. Ce sont les canaux dits « cach´es ». Commen¸cons par cet exemple de canal cach´e r´ev´el´e dans un article dans lequel Schlegel et al. [28] explorent certaines failles de s´ecurit´e dans les t´el´ephones intelligents dot´es du syst`eme android1_{. Les}

1. Android est un syst`eme d’exploitation mobile pour t´el´ephon´es intelligents, tablettes tactiles et terminaux mobiles. C’est un syst`eme « open source » qui utilise le noyau Linux. Il a ´et´e lanc´e par une start-up du mˆeme nom et rachet´ee par Google en 2005.

auteurs de cet article pr´esentent un programme malveillant capable de se servir des para-m`etres de vibration du t´el´ephone intelligent pour collecter des informations priv´ees `a partir des communications de l’usager et les faire fuir vers l’ext´erieur. Ils sont parvenus ainsi avec leur prototype `a extraire et `a transmettre discr`etement et avec une certaine facilit´e un nu-m´ero de carte de cr´edit de 16 chiffres sur le r´eseau. Les param`etres de vibration du t´el´ephone repr´esentent dans ce cas un canal cach´e.

La notion de canaux cach´es a ´et´e introduite pour la premi`ere fois par Lampson, dans un article [17] dans lequel il restreint son utilisation `a une sous-classe particuli`ere de canaux de fuite. Lampson d´efinit un canal cach´e comme une m´ethode de transmission de l’information qui utilise un support qui n’´etait pas initialement con¸cu pour la communication. On cite par exemple l’utilisation de la consommation des ressources de l’ordinateur en terme de cache, de temps de calcul ou d’espace m´emoire, pour v´ehiculer une information. Cependant, la d´efinition la plus largement accept´ee d’un canal cach´e est celle du « Department of Defense Trusted Computer System Evaluation Criteria »2, qui le d´efinit comme « tout canal de communication qui peut ˆetre exploit´e par un processus pour transmettre l’information de mani`ere `a violer la politique de s´ecurit´e du syst`eme. » Sabelfeld et Myers [25] classifient les canaux cach´es en plusieurs cat´egories, en fonction de ce que l’auteur d’une attaque peut observer du syst`eme.

– Les canaux de terminaison : l’information est signal´ee `a travers la terminaison ou la non-terminaison d’un traitement.

– Les canaux de chronom´etrage (« timing channels » en anglais) : l’information est signal´ee `

a travers l’instant exact o`u une action se produit, plutˆot que par les donn´ees associ´ees `

a l’action. L’action ici peut aussi ˆetre la terminaison d’un programme, c’est-`a-dire que l’information sensible peut ˆetre obtenue par le temps total d’ex´ecution d’un programme. – Les canaux probabilistes : l’information est signal´ee par un changement `a la distribution de probabilit´e des donn´ees observ´ees. Ces canaux sont particuli`erement dangereux si l’auteur de l’attaque peut ex´ecuter un programme `a r´ep´etition et observer et analyser les diff´erentes sorties.

– Les canaux d’´epuisement des ressources : l’information est signal´ee par un possible ´

epuisement d’une ressource partag´ee finie, telle que la m´emoire ou l’espace disque. – Les canaux de puissance : l’information est v´ehicul´ee par la puissance consomm´ee par

l’ordinateur pour effectuer le traitement, en supposant que l’auteur de l’attaque est capable de mesurer cette puissance.

Depuis Lampson, plusieurs ´etudes ont ´et´e faites sur les canaux cach´es. On a r´eussi `a les

2. Les « Trusted Computer System Evaluation Criteria », expression abr´eg´ee en TCSEC, sont un ensemble de crit`eres ´enonc´es par le d´epartement de la D´efense des ´Etats-Unis qui permettent d’´evaluer la fiabilit´e de syst`emes informatiques centralis´es. Il s’agit d’un cahier des charges d´efinissant quatre degr´es de s´ecurit´e, de A `

caract´eriser et `a limiter leurs effets n´efastes, sans pour autant les ´eliminer. Avec l’´evolution de la technologie, des canaux de plus en plus ing´enieux sont utilis´es, notamment par les auteurs d’attaques sur le r´eseau Internet.

2.3

Quelques notions de base

Nous revenons dans cette section sur quelques pr´eliminaires math´ematiques n´ecessaires `a la compr´ehension de certaines analyses. La plupart des termes ´etant adapt´es de l’s, nous pr´ecisons aussi dans cette section, pour quelques-uns de ces termes, le sens que nous leur accordons dans la suite de ce m´emoire.

2.3.1 Notions sur les treillis

Les notions math´ematiques pr´esent´ees dans cette section sont tir´ees de [6].

Pr´e-ordre

Un pr´e-ordre sur un ensemble S, not´e v, est une relation sur S, (i.e., v ⊆ S × S), qui v´erifie les propri´et´es suivantes :

– R´eflexivit´e : ∀x ∈ S.x v x.

– Transitivit´e : ∀x, y, z ∈ S.x v y ∧ y v z =⇒ x v z.

Exemple : L’ensemble N des entiers naturels muni de la relation d’ordre ≤ est un pr´e-ordre.

Ordre partiel

Un ordre partiel sur un ensemble S est un pr´e-ordre qui est antisym´etrique. C’est-`a-dire :

∀x, y ∈ S.(x v y ∧ y v x) =⇒ x = y.

Majorant, borne sup´erieure

Soit v un ordre partiel d´efini sur un ensemble S, un ´el´ement u ∈ S est dit majorant d’un ensemble X ⊆ S si ∀x ∈ X.x v u. Soit u le plus petit des majorants de X, u est par d´efinition la borne sup´erieure de X et on ´ecrit u = tX. Plus formellement :

Minorant, borne inf´erieure

Soit v un ordre partiel d´efini sur un ensemble S. Un ´el´ement v ∈ S est dit minorant d’un ensemble X ⊆ S si ∀x ∈ X.v v x.

Soit v le plus grand des minorants de X, v est par d´efinition la borne inf´erieure de X et on ´ecrit v = uX. Plus formellement :

v = uX ⇐⇒ (∀x ∈ X.v v x) ∧ (∀v0∈ S, (∀x ∈ X.v0 v x) =⇒ v0v v). Treillis

Un treillis est un couple (L, v), o`u L est un ensemble partiellement ordonn´e par la relation v, et tel que toute paire d’´el´ements admet une borne inf´erieure et une borne sup´erieure. Treillis complet

Un treillis complet est un 6-uplets (L, v, ⊥, >, t, u), o`u L est un ensemble partiellement ordonn´e par la relation v, et tel que tout sous-ensemble (fini ou infini) X de L a une borne inf´erieure et une borne sup´erieure, c’est-`a-dire :

∀X ⊆ L. tX et uX existent.

En particulier, en prenant X = L ⊆ L, on a par d´efinition : – tL = >

– uL = ⊥ .

Propri´et´e 1. Tout treillis sur un ensemble L fini est un treillis complet.

Dans la suite, nous repr´esenterons le treillis tout simplement par le couple (L, v). Le treillis de s´ecurit´e et l’analyse du flot d’information

Nous avons vu dans la section2.2.1que dans les mod`eles de contrˆole d’acc`es obligatoires, on attribue des ´etiquettes de s´ecurit´e aux objets et aux principaux. Dans les mod`eles de contrˆole du flot d’information par le langage, on associe aussi des ´etiquettes de s´ecurit´e `a certaines entit´es du programme. Dans certains mod`eles, ces ´etiquettes sont associ´ees aux variables du programme. Dans d’autres, elles sont associ´ees seulement aux canaux d’entr´ee et de sortie. Dans d’autres encore, elles sont ´egalement associ´ees aux commandes. Une relation d’ordre

est ensuite d´efinie sur l’ensemble des ´etiquettes. L’ensemble des ´etiquettes muni de cette relation poss`ede souvent les propri´et´es d’un ordre partiel et parfois celles d’un treillis. Dans ce dernier cas, le plus petit ´el´ement du treillis (⊥) correspond `a l’´etiquette du plus bas niveau de s´ecurit´e et le plus grand ´el´ement du treillis de s´ecurit´e (>) correspond `a l’´etiquette du plus haut niveau de s´ecurit´e. Pour assurer la confidentialit´e, on ne doit pas permettre un flot d’information d’une entit´e sur un niveau donn´e vers une autre entit´e sur un niveau plus bas. D’autre part, pour assurer l’int´egrit´e, les flots d’informations vers les entit´es de haut niveau doivent ˆetre limit´es.

La non-interf´erence pr´esent´ee dans la section 2.2.2introduit une dichotomie entre niveau bas et niveau haut, ce qui revient `a effectuer une partition du treillis L en deux ensembles L et H respectivement, tous deux stables par les op´erations u et t. Il serait possible de formuler une notion plus g´en´erale, s´eparant les niveaux en un nombre quelconque de classes. Cependant, cette propri´et´e ´etendue pourrait ˆetre vue comme la superposition de plusieurs instances de la forme simple, chacune d’entre elles exprimant l’absence de flot d’information entre une paire d’un ´emetteur et d’un receveur. `A la lumi`ere de ce constat, nous allons souvent consid´erer dans la suite un treillis de s´ecurit´e `a deux niveaux, avec L pour le bas niveau et H pour le haut niveau o`u L v H et H 6v L.

2.3.2 Sensibilit´e aux flots et insensibilit´e aux flots

Par rapport au traitement des variables, une des particularit´es de presque toutes les analyses du flot d’information parmi les plus r´ecentes est qu’elles sont insensibles aux flots, c’est-`

a-dire que l’ordre d’ex´ecution des instructions n’est pas pris en compte. C’est le cas de la technique d’analyse pr´esent´ee par Denning et Denning [10]. Une intuition simple de cette notion est qu’une analyse est insensible aux flots si le r´esultat de l’analyse de la s´equence C1; C2 est le mˆeme que celui de l’analyse de C2; C1. En particulier, l’insensibilit´e aux flots

dans un syst`eme de types signifie que si un programme est typ´e comme s´ecuritaire, alors tous ses sous-programmes doivent ˆetre aussi typ´es comme s´ecuritaires. Par exemple, le programme l := h; l := 0 o`u h contient un secret et que la valeur finale de l est observable par le public, est consid´er´e comme non s´ecuritaire parce que le sous-programme l := h est non s´ecuritaire. Plus g´en´eralement, une analyse insensible aux flots utilise une abstraction simple (dans notre cas le niveau de s´ecurit´e) pour repr´esenter chaque variable du programme. Une analyse sensible aux flots am´eliore la pr´ecision en fournissant une abstraction diff´erente `a chaque point du programme. Le niveau de s´ecurit´e attribu´e `a chaque variable du programme n’est pas fixe, mais se met `a jour au fur et `a mesure qu’on avance dans le programme. Nous reviendrons plus en d´etail sur les m´ecanismes de contrˆole de flot d’information sensible aux flots au chapitre3.

(Expressions) e ::= v | x | e ⊕ e

(Commandes) c ::= skip | x := e | c; c | if e then c else c | while e do c | stop | end

Table 2.1 – Langage imp´eratif simple

2.3.3 Syntaxe et s´emantique des programmes

Dans ce m´emoire, nous appliquerons souvent nos mod`eles sur des programmes ´ecrits avec un langage imp´eratif simple. Nous introduisons ce langage dans cette section, en nous ap-puyant sur la pr´esentation de Volpano et al. [32]. Dans la suite de ce m´emoire, certaines nouvelles primitives vont ˆetre ajout´ees `a cette version de base, notamment pour traiter de la communication avec l’ext´erieur ou de la concurrence.

Le langage est constitu´e d’expressions et de commandes comme on peut voir dans la table2.1. Une expression e peut ˆetre un entier v, une variable x ou une composition d’expressions de la forme e ⊕ e, o`u ⊕ est une op´eration binaire. Une commande c est une instruction imp´erative standard : l’inaction (skip), l’affectation, la composition s´equentielle, la conditionnelle (if then) et la boucle (while). Le langage inclut aussi deux autres commandes, stop et end, g´en´er´ees par le syst`eme dans certains mod`eles pour marquer la fin d’une ex´ecution pour la premi`ere, et la sortie d’un bloc conditionnel ou d’une boucle pour le second.

2.3.4 Autres d´efinitions

Les termes « coh´erence » et « permissivit´e » sont utilis´es dans plusieurs articles sans d´efinition formelle. Voici la signification que nous leur donnons.

D´efinition 2. Coh´erence

Un m´ecanisme statique de contrˆole de flot d’information est dit coh´erent, « sound » en an-glais3_{, s’il rejette tout programme non s´ecuritaire. Un m´ecanisme de contrˆole dynamique est}

coh´erent s’il bloque toute ex´ecution non s´ecuritaire.

D´efinition 3. Permissivit´e

Le terme permissif est utilis´e pour comparer deux m´ecanismes diff´erents de contrˆole de flot d’information. Un m´ecanisme est plus permissif qu’un autre si le premier accepte un plus grand nombre de programmes s´ecuritaires que le second.

3. Dans le domaine de la logique, « sound » est utilis´e dans la litt´erature anglaise pour qualifier un m´ecanisme solidement bˆati, dont la coh´erence est d´emontr´ee.

2.4

Les grandes familles de m´

ecanismes de contrˆ

ole du flot

d’information

La mise en œuvre des m´ecanismes de contrˆoles du flot d’information peut s’appuyer sur le contrˆole d’acc`es. Par exemple, il se pourrait que certaines entr´ees du programme soient gard´ees dans des fichiers du syst`eme sur lesquels s’appliquent des contrˆoles d’acc`es. La mise en œuvre peut aussi s’appuyer sur des techniques autres que le contrˆole d’acc`es, notamment en consid´erant les effets de chaque instruction du programme. Ce sont des techniques qui s’appuient sur des notions propres aux langages de programmation. En particulier, elles se servent de la s´emantique et de l’analyse du programme pour sp´ecifier et appliquer les politiques de s´ecurit´e pour la confidentialit´e ou pour l’int´egrit´e des donn´ees. Nous faisons dans cette section, un survol de ces diff´erents m´ecanismes.

Les m´ecanismes de contrˆole de flot d’information par le langage peuvent partitionn´es en deux groupes, les m´ecanismes bas´es sur une analyse statique du programme d’une part, et les m´ecanismes bas´es sur une approche dynamique de l’autre. Cependant, certains m´ecanismes dynamiques utilisent les r´esultats de l’analyse statique lors de l’examen du code. Ces derniers sont souvent appel´es des m´ecanismes hybrides.

2.4.1 Contrˆole de flot d’information par l’analyse statique

Analyser statiquement un programme consiste `a extraire des informations relatives `a l’ex´ e-cution du code sans l’ex´ecuter effectivement. Les informations sont valables pour toutes les ex´ecutions possibles. Une telle analyse permet d’´etablir un mod`ele du comportement du pro-gramme. Les informations peuvent ˆetre utilis´ees pour optimiser, mettre au point, comprendre, maintenir ou v´erifier le code. Dans le cas du contrˆole du flot d’information, les m´ethodes sta-tiques analysent le programme avant son ex´ecution, et d´eterminent si toutes les ex´ecutions possibles sont s´ecuritaires. Denning et Denning furent les premiers `a utiliser l’analyse statique pour s’attaquer au probl`eme de s´ecurisation du flot d’information dans un programme [10]. Ils proposent de mod´eliser toute politique de flot d’information par un mod`ele en treillis. Cela consiste `a attribuer dans un premier temps `a chaque variable une ´etiquette qui correspond `

a son niveau de s´ecurit´e. Ensuite on munit l’ensemble des classes de s´ecurit´e obtenu d’une relation d’ordre partiel (v), qui en fait une structure de treillis de classes de s´ecurit´e. Enfin, en se servant des propri´et´es du treillis, on peut incorporer le processus de certification du pro-gramme dans la phase d’analyse du compilateur. Par exemple, chaque affectation est v´erifi´ee pour la propri´et´e suivante : la variable affect´ee doit ˆetre de haut niveau si la variable `a droite de l’affectation est de haut niveau (d´etection des flots explicites) ou si l’affectation a lieu dans une instruction conditionnelle ou une boucle de haut niveau. Leur m´ecanisme garantit qu’au-cun traitement de bas niveau n’est effectu´e dans un contexte de haut niveau. `A la suite de Denning et Denning, plusieurs autres travaux ont suivi dans le mˆeme sens. Ces m´ecanismes

ont l’avantage de ne pas augmenter la charge du programme `a l’ex´ecution. On s´epare souvent les m´ecanismes statiques en deux groupes : les m´ecanismes bas´es sur le syst`eme de types d’une part et les m´ecanismes non bas´es sur le syst`eme de types d’autre part.

Analyse bas´ee sur un syst`eme de types

Volpano et al. [32] furent les premiers `a utiliser un syst`eme de types pour analyser la s´ecurit´e du flot d’information. Leur mod`ele s’applique `a un langage imp´eratif simple. Plusieurs ´etudes ont suivi dans le mˆeme sens avec pour certaines une extension au niveau du langage et pour d’autres, une extension au niveau de la propri´et´e de non-interf´erence. Certaines approches, notamment les plus anciennes comme celle de Volpano et al. [32] sont insensibles aux flots au sens de2.3.2. Plus r´ecemment, Hunt et Sands ont propos´e pour la premi`ere fois un syst`eme de types sensible aux flots. D’autres travaux ont suivi dans le mˆeme sens, parmi lesquels ceux de Desharnais et al. [12]. Nous reviendrons plus en d´etails sur ces deux derni`eres approches dans le prochain chapitre.

Dans l’analyse bas´ee sur un syst`eme de types, la s´emantique statique du programme est repr´esent´ee par un ensemble de r`egles de d´eduction appel´e syst`eme de types.

Les r`egles permettent de d´eduire le type d’une expression et se pr´esentent sous la forme suivante :

P 1...P n

Q .

Une telle r`egle stipule que si P1, ..., Pnsont tous vrais, alors Q l’est aussi. Le num´erateur est

constitu´e de pr´emisses (Pi) alors que le d´enominateur contient la conclusion Q. Une r`egle qui

ne poss`ede pas de pr´emisses est un axiome. Un axiome Q est g´en´eralement repr´esent´e par : 

Q ou tout simplement

Q . Le symbole  signifie qu’il n’y a pas de pr´emisses.

Chaque pr´emisse ou conclusion peut utiliser un jugement de la forme :

Γ ` e : τ

– Γ est une mappe qui associe `a chaque variable du programme un ´el´ement du treillis de s´ecurit´e L. Cette mappe sera souvent appel´ee environnement de d´efinition des types ou tout simplement environnement de typage.

– e est une expression

– τ est un ´el´ement du treillis de s´ecurit´e L.

Ce jugement signifie que, sous un environnement de typage Γ, l’expression e est de type τ . Un environnement de d´efinition des types pour les constantes sert souvent de point de d´epart pour l’application des r`egles d’inf´erence et un algorithme d’inf´erence de types sert `a calculer les informations utiles.

Analyse statique non bas´ee sur un syst`eme de types

Comme le fait remarquer Le Guernic [18], toutes les techniques d’analyse statique de la s´ecurit´e du flot d’information ne sont pas bas´ees sur un syst`eme de types. La technique utilis´ee par Denning [11] avant Volpano, est similaire au syst`eme de types, mais n’est pas d´efinie comme telle. Denning d´ecrit un syst`eme dans lequel les variables et les commandes ont un niveau de s´ecurit´e. Ces niveaux sont ordonn´es et forment une structure de treillis. Denning d´efinit un ensemble de r`egles qui font le lien entre les structures du programme et le niveau de s´ecurit´e appropri´e de l’entit´e du programme impliqu´e dans ces structures. Elle sugg`ere deux pistes. La premi`ere consiste `a attribuer le niveau de s´ecurit´e aux variables et instructions et utiliser les r`egles pour v´erifier si les niveaux sont appropri´es. La seconde consiste `a assigner des niveaux de s´ecurit´e seulement aux variables d’entr´ee et utiliser les r`egles pour calculer le niveau de s´ecurit´e des autres entit´es du programme.

D’autres m´ethodes d’analyse non bas´ees sur le syst`eme de types existent, parmi lesquelles l’analyse par interpr´etation abstraite et l’approche bas´ee sur les contraintes.

Analyse par utilisation de l’interpr´etation abstraite

L’interpr´etation abstraite est une technique permettant de d´eriver une analyse statique, `a partir d’une s´emantique instrument´ee du programme. L’id´ee de base de l’interpr´etation abs-traite est l’approximation de la s´emantique des programmes. Elle peut ˆetre d´efinie comme une ex´ecution partielle d’un programme pour obtenir des informations sur sa s´emantique (par exemple, sa structure de contrˆole, son flot de donn´ees) sans avoir `a en faire le traitement complet. Pour s´ecuriser le flot d’information, l’instrumentation de la s´emantique consiste ha-bituellement `a ajouter aux valeurs une ´etiquette qui doit refl´eter l’ensemble des entr´ees qui ont influenc´e la valeur ´etiquet´ee. Toutefois, comme le remarque Le Guernic [18], il reste que la coh´erence de l’analyse r´eside dans la coh´erence du choix de la s´emantique instrument´ee. Autrement dit, si le calcul des ´etiquettes de s´ecurit´e par la s´emantique instrument´ee n’est pas coh´erent, il n’y aura aucune garantie de fiabilit´e pour l’analyse d´eriv´ee.

Analyse bas´ee sur les contraintes

Les m´ethodes d’analyse bas´ee sur les contraintes sont aussi utilis´ees pour v´erifier statiquement la s´ecurit´e du flot d’information. Ces m´ecanismes se d´eroulent g´en´eralement en deux ´etapes : – La premi`ere ´etape consiste `a g´en´erer un ensemble de contraintes qui doivent ˆetre v´erifi´ees pour un programme qui respecte la propri´et´e de non-interf´erence. On peut aussi se limiter `a la production d’une liste de contraintes qui doivent ˆetre respect´ees par une ex´ecution s´ecuritaire du programme.

– La seconde ´etape consiste `a r´esoudre le probl`eme en utilisant par exemple un prouveur de th´eor`emes4 ou un v´erificateur de mod`ele.5 On peut aussi le transformer en une instance d’un probl`eme de satisfaction de contraintes6 et la soumettre `a un solveur de contraintes.7

Habituellement, pour l’analyse de la s´ecurit´e du flot d’information, le probl`eme de r´esolution de contraintes concerne l’affectation des ´etiquettes de s´ecurit´e aux variables, de sorte qu’`a chaque ´etape de l’ex´ecution, l’information circule vers des variables avec un niveau de s´ecurit´e plus ´elev´e ou ´egal `a celui de l’origine du flot. L’autre approche, qui n’utilise pas les ´etiquettes de s´ecurit´e, consiste `a d´emontrer directement que pour deux ex´ecutions quelconques, les valeurs des sorties publiques ne sont pas diff´erentes si celles des entr´ees publiques sont identiques.

2.4.2 Contrˆole de flot d’information par analyse dynamique

Le contrˆole du flot d’information peut se faire dynamiquement, c’est-`a-dire pendant l’ex´ ecu-tion du programme. Par rapport `a l’analyse statique, les m´ethodes dynamiques sont souvent plus pr´ecises. Par contre, ce sont des m´ecanismes qui peuvent ajouter une grande surcharge de travail `a l’ex´ecution du programme. S´ecuriser le programme par analyse dynamique est une id´ee plutˆot ancienne, qui remonte aux ann´ees 1970, au travail de Fenton [14] tout au moins, mais qui est toujours d’actualit´e. D’ailleurs, plusieurs travaux r´ecents ont ´etudi´e la possibilit´e d’incorporer des m´ecanismes dynamiques de contrˆole du flot d’information dans les

4. La d´emonstration de th´eor`emes est une approche de v´erification des programmes, qui est de plus en plus automatis´ee et assist´ee par ordinateur. Elle consiste `a ´enoncer des propositions et `a les d´emontrer dans un syst`eme de d´eduction de la logique math´ematique, en particulier dans le calcul des pr´edicats. L’objectif est de raisonner rigoureusement sur des programmes informatiques afin de d´emontrer leur validit´e par rapport `a une certaine sp´ecification. Le prouveur de th´eor`eme est l’outil informatique utilis´e.

5. Un v´erificateur de mod`ele, « model checker » en anglais, analyse exhaustivement l’´evolution du syst`eme lors de ses ex´ecutions possibles. Par exemple, pour d´emontrer l’absence d’erreurs `a l’ex´ecution, on pourra tester l’absence d’´etats d’erreur dans l’ensemble des ´etats accessibles du syst`eme. En g´en´eral, il n’est pas possible d’analyser directement le syst`eme, mais on en analyse plutˆot un mod`ele, plus ou moins abstrait par rapport `a la r´ealit´e.

6. Les probl`emes de satisfaction de contraintes, ou CSP en anglais pour « Constraints Satisfaction Problems

», sont des probl`emes math´ematiques o`u l’on cherche des ´etats ou des objets satisfaisant un certain nombre de contraintes ou de crit`eres.

7. En g´en´eral, on s´epare la mod´elisation d’un probl`eme CSP de sa r´esolution. Le solveur de contraintes est l’outil informatique qui est utilis´e dans la phase de r´esolution du probl`eme.

navigateurs web avec le langage JavaScript [13]. On regroupe g´en´eralement les m´ecanismes dynamiques en trois groupes :

(a) Le monitorage, qui consiste `a faire surveiller l’ex´ecution du programme par un autre programme appel´e moniteur.

(b) L’instrumentation, qui consiste `a transformer le programme, en y ajoutant des com-mandes pour contrˆoler le flot d’information.

(c) Une nouvelle approche bas´ee sur l’ex´ecution multiple du programme.

Le monitorage de l’ex´ecution

Un moniteur est un programme qui observe, r´egule et contrˆole ou v´erifie les op´erations d’un syst`eme de traitement des donn´ees. Dans le cadre de la s´ecurisation du flot d’information, le moniteur a pour objectif de contrˆoler l’ex´ecution des autres programmes pour pr´evenir tout flot d’information illicite. Des caract´eristiques pr´ecises des politiques de s´ecurit´e applicables par monitorage des programmes ont ´et´e ´etudi´ees dans la litt´erature. La non-interf´erence a ´

et´e pr´esent´ee comme un exemple de politique qui ne peut ˆetre appliqu´ee avec pr´ecision par des m´ecanismes dynamiques. Cependant, des travaux comme celui de Russo et Sabelfeld [24] ont rigoureusement d´emontr´e qu’il est possible d’utiliser un moniteur pour appliquer une certaine politique de s´ecurit´e qui est une approximation de la non-interf´erence et qui garantit la non-interf´erence dans les programmes qu’ils acceptent.

Le monitorage d’un programme est potentiellement plus permissif qu’une simple v´erification de type (analyse purement statique). En fait, le monitorage peut autoriser les ex´ecutions s´ecuritaires mˆeme si le programme contient des fragments non s´ecuritaires, dans les branches non prises d’un bloc conditionnel par exemple. De plus, la d´etermination des instructions s´ecuritaires se fait sur la base des informations pr´ecises `a l’ex´ecution par opposition `a des approximations de l’analyse statique. Mais, en g´en´eral, le moniteur ne peut voir que la partie d´ej`a ex´ecut´ee de la trace d’ex´ecution, `a moins qu’il ne soit dot´e des moyens lui permettant d’utiliser d’autres informations provenant de l’analyse statique.

Des travaux r´ecents sur le monitorage du flot d’information portent sur des langages interpr´ e-t´es comme JavaScript. Dans la pratique, le moniteur est souvent int´egr´e `a la machine virtuelle Java par une modification du code source de cette derni`ere. Cette possibilit´e est due au fait que cette machine virtuelle est impliqu´ee dans tous les ´ev`enements du flot de contrˆole et du flot des donn´ees `a l’ex´ecution des programmes. Nous appellerons dans la suite un tel moniteur « moniteur MV ». Un exemple de moniteur MV est celui de Russo et Sabelfeld [24] que nous d´ecrivons plus en d´etail au chapitre suivant.

L’instrumentation du code

Chudnov et Naumann affirment [8] qu’un moniteur MV est peu pratique dans certains cas. L’une des raisons ´evoqu´ees est l’utilisation de nouvelles techniques de compilation comme le JIT (Just In Time). Cette technique de plus en plus r´epandue associe la traduction en bytecode et la compilation dynamique. La machine virtuelle n’a plus tout le contrˆole sur les petites ´etapes des flots de contrˆole et de donn´ees, notamment pour la partie du code qui est d´ej`a traduite en langage natif. L’autre solution, qui aura `a quelque chose pr`es le mˆeme r´esultat que le moniteur est la transformation du code source du programme, c’est-`a-dire l’instrumentation. Dans le cas du contrˆole du flot d’information, elle consiste `a ajouter au programme des variables qui refl`etent le niveau de s´ecurit´e de ses variables originales. Des tests sur ces nouvelles variables sont aussi ins´er´es, dans le but d’appliquer dynamiquement la non-interf´erence. Il sera alors suffisant de montrer que chaque programme ainsi transform´e est non interf´erent. Plusieurs ´etudes proposent de telles transformations pour un langage proc´edural simple et d´eterministe. Nous pr´esentons en d´etail dans le prochain chapitre un de ces m´ecanismes assez r´ecent, ´elabor´e par Chudnov et Naumann [8], qui a la particularit´e d’ˆetre bas´e sur une analyse sensible aux flots telle que d´efinie dans la section 2.3.2.

L’ex´ecution multiple

L’id´ee principale derri`ere l’approche par ex´ecution multiple consiste `a ex´ecuter un programme `

a plusieurs reprises, une fois pour chaque niveau de s´ecurit´e, en utilisant des r`egles sp´eciales pour s´ecuriser le flot d’information au niveau des op´erations d’entr´ee/sortie. Contrairement aux autres approches dynamiques et `a l’analyse statique par typage, l’ex´ecution multiple ne requiert pas que l’ensemble du code de l’application soit inspect´e (seulement les instructions d’entr´ee/sortie). C’est une id´ee qui a ´et´e explor´ee plus r´ecemment, `a la fin des ann´ees 90. Des articles r´ecents [4,13] proposent des techniques d’analyse bas´ees sur cette approche. Les difficult´es inh´erentes `a cette approche r´esident, d’une part dans le choix des valeurs d’entr´ees de haut niveau `a tester et, d’autre part dans le partage de la charge de test `a travers les diff´erentes copies de l’ex´ecution de la fonction avec des entr´ees diff´erentes. De plus, si le programme fait des choix non d´eterministes, il devient particuli`erement difficile d’analyser les valeurs obtenues pour les sorties de bas niveau. Dans ce cas, il faut g´en´eraliser ou adapter la technique pour en tenir compte.

Chapitre 3

Contrˆ

ole du flot d’information par

analyse sensible aux flots

3.1

Introduction

Nous examinons dans ce chapitre quelques m´ecanismes de contrˆole de flot d’information parmi les plus r´ecents, tous bas´es sur une analyse sensible aux flots des donn´ees.

Pour bien comprendre la diff´erence entre une analyse sensible aux flots et une qui ne l’est pas, consid´erons le programme suivant :

secret := 0; if secret then public := 1

Une analyse insensible aux flots rejette ce programme parce qu’il a un sous-programme non s´ecuris´e, en l’occurrence, l’affectation `a une variable publique dans un bloc conditionnel avec une garde impliquant une variable secr`ete. D’un autre cˆot´e, le programme est accept´e par une analyse sensible aux flots, parce que la variable secret en recevant par affectation la constante 0 se comporte dans la suite comme une variable publique. On note que les constantes sont consid´er´ees comme publiques puisqu’elles ne transmettent aucune information sur un autre objet [10]. La garde du bloc conditionnel ´etant devenue publique, la mise `a jour de la variable public ne repr´esente plus de danger. Comme nous allons le voir, les approches sensibles aux flots permettent d’accepter un plus grand nombre de programmes s´ecuritaires que celles qui ne le sont pas.

Dans tout ce chapitre, nous supposons que dans notre syst`eme, les secrets sont conserv´es dans les variables des programmes. Les niveaux de s´ecurit´e sont associ´es aux variables et d´ecrivent la s´ecurit´e voulue pour leur contenu. La plus simple instance d’un tel probl`eme implique deux niveaux de s´ecurit´e : H pour haut niveau de s´ecurit´e qui d´enote la partie secr`ete de l’information et L pour bas niveau qui d´enote la partie publique. Une relation d’ordre partiel

L v H indique que les seuls flots permis sont ceux de L vers H. Le probl`eme de s´ecurit´e est de v´erifier qu’il n’y a pas de d´ependance entre la valeur initiale d’une variable de niveau H (contenant le secret dont le programme a acc`es) et la valeur finale d’une variable de niveau L (la sortie qui est visible par le public).

Dans la suite du chapitre, nous pr´esentons dans la premi`ere partie deux m´ecanismes d’analyse statique bas´es sur le typage. Il s’agit du mod`ele de Hunt et Sands [16] compl´et´e par Russo et Sabelfeld [24] pour le premier, et du mod`ele de Desharnais et al. [12] pour le second. Dans la seconde partie, on examine deux m´ecanismes hybrides de contrˆole dynamique de flot d’information, qui font appel aux r´esultats de l’analyse statique. Le premier m´ecanisme, tir´e des travaux de Russo et Sabelfeld [24], est bas´e sur un moniteur de programme. Le second m´ecanisme, bas´e sur la transformation du programme sur la base du fonctionnement du moniteur de Russo et Sabelfeld, est tir´e des travaux de Chudnov et Naumann [8].

3.2

Analyse par typage sensible aux flots

3.2.1 Le syst`eme de types de Hunt et Sands

Introduction

C’est en 1996 que Volpano propose pour la premi`ere fois un syst`eme de types pour l’analyse de la s´ecurit´e du flot d’information [32]. Dix ans plus tard, Hunt et Sands [16] proposent un nouveau syst`eme de types pour l’analyse de la s´ecurit´e du flot d’information. La nouveaut´e de ce dernier par rapport `a celui de Volpano r´eside dans la prise en compte de la sensibilit´e aux flots dans l’analyse. Le syst`eme de types est d´efini pour un langage imp´eratif simple, puis ´etendu `a un langage avec la commande output par Russo et Sabelfeld.

L’approche en bref

On suppose que le programme est ´ecrit dans le langage d´ecrit dans le paragraphe 2.3.3. Soit Var l’ensemble fini des variables du programme, on attribue initialement `a chaque ´el´ement de Var un type qui est une ´etiquette correspondant `a son niveau de s´ecurit´e, ce qui d´efinit une fonction entre l’ensemble des variables du programme et l’ensemble des niveaux de s´ecurit´e not´ee Γ. On note L l’ensemble des niveaux de s´ecurit´e et on d´efinit sur L une relation d’ordre partiel not´ee v. On montre que le couple (L, v) poss`ede les propri´et´es d’un treillis telles que d´ecrites dans2.3.1. Ce sera dans la suite notre treillis de s´ecurit´e.

Rappelons que dans un syst`eme de types insensible aux flots comme celui de Volpano et Smith [32], on attribue aussi des niveaux de s´ecurit´e aux variables du programme et, lorsqu’on affecte une expression `a une variable sous la forme x := Exp, toutes les variables de Exp doivent avoir un niveau de s´ecurit´e plus bas ou ´egal `a celui de x. De plus, si l’affectation a lieu dans une branche d’un bloc conditionnel ou dans une boucle, le niveau de x doit ˆetre au moins

aussi haut que celui de toutes les variables des expressions de garde. L’id´ee derri`ere le mod`ele de Hunt et Sands est de ne pas bloquer un flot (implicite ou explicite) d’une variable de haut niveau vers une autre variable dont le niveau est plus bas. Ils proposent de laisser aller le flot, mais de s’assurer que le contenu de la variable nouvellement affect´ee ne sera pas r´ev´el´e par la suite. Pour ce faire, ils modifient le niveau de s´ecurit´e de cette derni`ere variable, pour le mettre `a la hauteur du secret qu’elle contient. Afin de tenir compte de la sensibilit´e aux flots dans un bloc conditionnel ou une boucle, Hunt et Sands introduisent une nouvelle variable pc, qui garde en tout temps le niveau de s´ecurit´e du contexte. Ceci va permettre de bien contrˆoler les changements des niveaux de s´ecurit´e du contexte pour ´eviter les flots implicites ill´egaux. Par exemple, consid´erons le treillis de s´ecurit´e `a deux points {L v H}. Lorsqu’on affecte une expression `a une variable x := y + x, si x est de type L avant l’affectation, et y de type H, alors apr`es l’affectation x doit prendre le type H. Plus g´en´eralement, si l’affectation x := Exp se fait dans un contexte de niveau pc, le niveau de la variable affect´ee x devient la borne sup´erieure de pc et du niveau de l’expression affect´ee.

Le syst`eme de types

Le syst`eme de types d´efinit les jugements de la forme : pc ` Γ {C} Γ0, o`u pc est le niveau de s´ecurit´e du contexte, Γ et Γ0 sont des fonctions d´efinies de l’ensemble des variables vers le treillis de s´ecurit´e. Le jugement stipule que le niveau de s´ecurit´e des variables est d´etermin´e par Γ avant l’ex´ecution de la commande C, et Γ0 apr`es son ex´ecution. Ces jugements utilisent une extension de Γ aux expressions, d´efinie pour une expression e par : Γ(e) est ´egale `a la borne sup´erieure des Γ(x), pour toutes les variables x impliqu´ees dans la d´efinition de e. Ces jugements utilisent aussi la variable pc. Au d´ebut du processus de typage d’un programme, la variable pc est initialis´ee avec le plus petit ´el´ement du treillis de s´ecurit´e. Son contenu change de valeur d`es qu’on entre ou sort d’un bloc conditionnel ou d’une boucle. `A l’entr´ee, la nouvelle valeur de pc devient la borne sup´erieure de son ancienne valeur et du niveau de s´ecurit´e de l’expression de garde. `A la sortie, la variable pc reprend la valeur qu’elle avait avant l’entr´ee dans ledit bloc.

Les r`egles de typage des commandes s’´enoncent comme suit :

skip, end et stop

Les commandes skip, end et stop ne modifient pas l’environnement de typage. On a :

(skip)

Γ{skip}Γ (ST OP ) Γ{stop}Γ (EN D) Γ{end}Γ

L’affectation