Visitez http://liliasfaxi.wix.com/liliasfaxi !

1. Dr. Lilia SFAXI
Sécurité des
Systèmes Répartis
Partie 1I :
Contrôle de Flux D’Information
et
Non-Interférence
Doctorants ETIC, Ecole Polytechnique deTunisie 2014

2. Rappel
Mécanismes de Sécurité Usuels
Contrôle d’accès
Vérifier l’authentification et l’autorisation
Définir une matrice de contrôle d’accès
Primitives Cryptographiques
Hachage :Assurer l’intégrité du message
Chiffrement :Assurer la confidentialité du message
Signature :Assurer l’intégrité et la non répudiation
Certificat :Assurer l’authentification
Délégation
Délégation des droits et permissions à un sujet tierce
Optimisation du nombre d’identités stockées
2

3. Problème …
Mécanisme de sécurité ponctuels
Ne garantissent pas une sécurité de bout en bout
è Nécessité du contrôle de la propagation de
l’information
3

4. Notions de Base
Donnée, Information
Donnée
Élément brut, sans interprétation ni contexte
Exemple: String mdp = « azerty » è Donnée
Information
Donnée interprétée, mise en contexte
Crée une valeur ajoutée pour son intercepteur
Exemple: la variable mdp entrée comme mot de passe pour accéder à une
application en fait une information, qui peut être dangereuse si elle est
divulguée
4

5. Notions de Base
Flux d’Information
Flux d’Information
Acheminement d’une information d’une donnée à une
autre
Suivi du flux d’information: permet de voir quelles entités
ont eu accès à une information
Exemple: String mdpModif = mdp + « ! »
è Flux d’information de mdp
vers mdpModif
Suivi du Flux d’Information
Trouver toutes les données/entités ayant eu accès à une information
Exemple: mdp et mdpModif ont eu accès à l’information « mot de passe »
5

6. Suivi du Flux d’Information
L’information circule dans un système:
Entre les données
Entre les modules et composants (logiciels et matériels)
Entre les acteurs / sujets
Assurer les propriétés d’authentification, de
confidentialité et d’intégrité ne garantit pas
toujours que les données circulent de manière
autorisée par leurs propriétaires
6

7. A!
B!
C!
Suivi du Flux d’Information
7

8. LA NON-INTERFÉRENCE :
CONCEPT ET DÉFINITIONS
Contrôle de Flux D’Information et Non-Interférence
8

9. Non-Interférence
Modèle de Contrôle de Flux d’Information (CFI)
Définie par Goguen et Meseguer en 1982
Mais implémentée récemment
Objectif :
S’assurer que les données sensibles n’affectent pas le
comportement publiquement visible du système
Permet :
Le suivi de l’information dans le système
L’application de la confidentialité et de l’intégrité de bout en
bout
9

10. NI : Définition Informelle
Si un attaquant peut observer des données jusqu’à un
niveau de sécurité o , alors une modification d’une variable
de niveau de sécurité plus haut que o est indiscernable
pour cet attaquant
10
Les sorties observables à un niveau o doivent être
indépendantes des entrées à des niveaux plus restrictifs que o

11. NI : Définition Informelle
Si un attaquant peut observer des données jusqu’à un
niveau de sécurité o , alors une modification d’une variable
de niveau de sécurité plus haut que o est indiscernable
pour cet attaquant
11
Les sorties observables à un niveau o doivent être
indépendantes des entrées à des niveaux plus restrictifs que o

12. Niveaux de Sécurité : Étiquettes
Données sont classifiées selon leur niveau de
sécurité
Pour définir un niveau de sécurité, on associe à la
donnée une étiquette (label)
Étiquette de sécurité : Paire de :
Niveau de confidentialité (S pour Secrecy)
Niveau d’intégrité (I pour Integrity)
Notée { S ; I }
12

13. Niveaux de Sécurité : Étiquettes
Les étiquettes de sécurité sont classées par ordre de
restriction
Une étiquette de sécurité e1 est au plus aussi restrictive
qu’une étiquette e2 si le niveau de sécurité de e1 est
moins haut ou égal à celui de e2
Notée : e1 ⊆ e2
13

14. Treillis de Sécurité
La relation ⊆ détermine le sens de circulation d’une
information
Restriction de non-interférence :
Quand l’information circule dans le système, les
étiquettes deviennent uniquement plus restrictives
Les étiquettes du système, régies pas la relation de
restriction, permettent de définir un treillis de sécurité
14

15. Treillis de Sécurité
Treillis : ordonne les étiquettes du système de la
moins restrictive (en bas du treillis) vers la plus
restrictive (en haut du treillis)
Exemple de treillis :
15
e1
e2
e3
e4
e4 ⊆ e2 ⊆ e1
e4 ⊆ e3 ⊆ e1
e2 et e3 sont incomparables
Circulation de
l’Information

16. NI : Définition Formelle
Plusieurs définitions formelles de la non-interférence
dans la littérature
[Goguen82, Rushby92, Malecha10, Myers06]
Nous avons opté pour la définition de [Malecha10]
La plus récente
Applicable aussi bien pour un programme que pour des
composants interconnectés (notre cas)
[Malecha10] ramène le problème de la non-interférence
à un problème d’indiscernabilité (indistinguishability)
entre plusieurs états de la mémoire
16

17. NI : Définition Formelle (1/3)
Soit le vocabulaire suivant
s
:
programme
L
:
ensemble de niveaux de sécurité dans le programme
⊆L:
ordre partiel sur L, définit les informations pouvant
circuler entre deux niveaux de sécurité
Φ
= (L , ⊆L )
: la politique de sécurité
UL
:
Opérateur de jointure :
Pour les niveaux de sécurité p et q, il existe p UL q ∈ L qui a pour
limite supérieure à la fois p et q.
σ = [x ⟼ v] : mémoire. Représente une configuration
associant une variable x à une valeur v.
17

18. NI : Définition Formelle (2/3)
Soit le vocabulaire suivant
Γ : environnement de variables. Représente un sous ensemble de
variables, dont un observateur à un niveau de sécurité o ∈ L
peut observer les valeurs
• Γ ⊢ σ1 ≈o σ2
σ1 et σ2 sont indiscernables par rapport à o dans Γ
Pour toutes les variables x que le niveau de sécurité o peut observer, on a :
σ1(x) = σ2(x)
• On dit aussi que « Γ protège x au niveau o » si x n’est observable à
aucun niveau de sécurité moins restrictif que o
Φ ⊢ s, σ →* v, σ’
• Fermeture transitive de la sémantique opérationnelle à petits pas
• Pour la politique de sécurité Φ et avec la configuration σ, le
programme s est évalué à la valeur v et à la mémoire σ’
18

19. NI : Définition Formelle (3/3)
Un programme s satisfait la propriété de non-interférence
pour un niveau de sécurité o sous l’environnement Γ si,
• pour toutes les politiques de sécurité Φ,
• pour toutes les configurations σ,
• pour toutes les variables h telles que Γ protège h à un
niveau o’ avec o ⊈L o’ , et
• pour toutes les valeurs v1 et v2 du même type :
Si Φ ⊢ s, σ [h ⟼v1] →* v’1 , σ’1 et Φ ⊢ s, σ [h ⟼v2] →* v’2 , σ’2
alors
Γ ⊢ σ’1 ≈o σ’2 et v’1 = v’2
19

20. Pour Résumer…
Si un attaquant peut observer des données jusqu’à
un niveau de sécurité o, alors une modification
d’une variable de niveau de sécurité plus haut est
indiscernable pour cet attaquant.
Les résultats ou sorties observables à un niveau o
doivent être indépendants des entrées à des
niveaux plus restrictifs que o.
20

21. Interférences dans le Code
Interférence Explicite
Affectation :
21
class NI {
boolean secretVar;
boolean publicVar;
public void start(){
secretVar = publicVar;
publicVar = ! secretVar;
}
}
INTERFERENCE!
Flux d’information d’une donnée secrète
vers une donnée publique!

22. Interférences dans le Code
Interférence Implicite
Bloc de Contrôle :
22
class NI {
boolean secretVar;
boolean publicVar;
public void start(){
if (secretVar){
publicVar = true;
} else{
publicVar = false;
}
}
}
INTERFERENCE!
Équivalent à publicVar = secretVar !
Modification d’une donnée dans un
contexte plus restrictif

23. Interférences dans le Code
Interférence Implicite
Appel de Méthode :
23
class NI {
boolean secretVar;
boolean publicVar = false;
public void start(){
if (secretVar){
modif();
}
}
public void modif(){
publicVar = true;
}
}
INTERFERENCE!
Appel d’une méthode, modifiant une
variable publique, dans un contexte
plus restrictif

24. Interférences dans le Code
Référencement
Cas des langages orientés objet
Référencement (aliasing) des objets peut créer une
interférence
Un même objet peut être référencé par plusieurs
variables de niveau de sécurité différents
24

25. Interférences dans le Code
Référencement
25
class MyClass { int pa = 0;}
class NI {
MyClass p1= new MyClass(); MyClass p2= new MyClass();
MyClass s1;
int s2;
public void start(){
if (s20) {
s1= p1;
} else {
s1= p2;
}
s1.pa= 40;
}
}
Pas d’Interférence dans le bloc de contrôle
La variable modifiée dans un contexte
restrictif est une variable privée
INTERFERENCE!
En observant p1.pa et p2.pa, je peux savoir
si s20 ou non

26. Pour Avoir un Code
Non-Interférent :
• Il ne faut pas faire d’affectation directe d’une
variable privée vers une variable publique
• Il ne faut pas modifier une variable dans un
contexte plus restrictif
• Attention aux blocs de contrôle, surtout imbriqués!
• Attention aux appels de méthodes!
• Il ne faut pas modifier les attributs publics d’un
objet à partir d’une référence privée
26

27. Sans oublier…
Les exceptions
Les threads
Les canaux temporels
Les ressources partagées
…
27

28. Cependant…
TOUS les systèmes sont interférents!
Il est impossible, voire même indésirable, d’obtenir un système
complètement non-interférent
L’interférence la plus connue, et la plus inévitable : La
vérification du mot de passe
Variable secrète : mot de passe
Variable publique : la réponse du serveur (mot de passe valide ou
pas)
⇒ La modification de la variable secrète entraîne celle de la
variable publique
Même minime, c’est une interférence, qui peut fragiliser le
système si l’attaquant utilise un script pour essayer les
combinaisons possibles du mot de passe
28

29. Mais également…
Autre interférence célèbre et inévitable :
Le Chiffrement!
La variable publique (le cryptogramme) dépend de la valeur de
la variable privée (le message secret à chiffrer)
Mais, comme on peut le remarquer, certaines interférences
peuvent être tolérées, mais surveillées de près:
Interdire plusieurs essais de mots de passes pas la même personne
Les questions de sécurité (pour vérifier qu’on est un être humain)
Algorithmes de chiffrement complexes impossibles à déchiffrer
…
29

30. Rétrogradation
Il faut donc un mécanisme pour permettre de relaxer le
niveau de sécurité d’une donnée, et autoriser ainsi une
interférence, sous certaines conditions
Mécanisme de Rétrogradation (Downgrading)
Une rétrogradation peut être possible :
Pour un acteur particulier, après qu’il ait payé pour obtenir
l’information
Après une certaine période de temps
Si la quantité d’information révélée est trop mince pour être
une menace (login, chiffrement…)
30

31. MODÈLES DES ÉTIQUETTES DE SÉCURITÉ
Contrôle de Flux D’Information et Non-Interférence
31

32. Étiquettes de Sécurité
Attribuent un niveau de sécurité aux données
Étiquette d’une donnée d dans l’ensemble
d’étiquettes L est noté : l (d )
Si le contenu d’une donnée d1 affecte celui d’une
autre donnée d2, c’est qu’il existe un flux
d’information de d1 vers d2.
Le flux est non-interférent ssi :
l (d1 ) ⊆ l (d2 )
Il existe plusieurs modèles dans la littérature…
32

33. Modèle d’Étiquettes Décentralisé
DLM : Decentralized Label Model [Myers00]
Modèle décentralisé : la politique de sécurité n’est pas
définie par une autorité centrale, mais contrôlée par
les différents acteurs du système
Le système doit ensuite faire en sorte de respecter cette
politique
Définition de la notion de propriété d’une étiquette
Un participant peut rétrograder le niveau de sécurité de ses
étiquettes, mais pas celle des autres
Entités principales :Autorités et Étiquettes
33

34. Modèle d’Étiquettes Décentralisé
Autorités
Autorités ou Principals : Entités qui possèdent, modifient
et publient les informations
Représentent les utilisateurs, groupes ou rôles
Quelques autorités ont le droit d’agir pour d’autres
A peut agir pour A’ ⇒ A possède tous les pouvoirs et
privilèges de A’
Agit pour : relation réflexive et transitive ⇒ définition d’une
hiérarchie ou ordre partiel entre les autorités
A agit pour B est notée : A ≽ B
Tous les pouvoirs de B sont délégués à A
34

35. Modèle d’Étiquettes Décentralisé
Étiquettes
Une étiquette (label) est composée de deux parties:
Une étiquette de confidentialité
Une étiquette d’intégrité
Chacune des étiquettes contient un ensemble
d’éléments d’étiquette : expriment les besoins de
sécurité définis par les autorités
Élément d’étiquette a deux parties :
Propriétaire :Acteur propriétaire de l’élément
Lecteurs (confidentialité) ou Écrivains (intégrité)
Objectif de l’élément d’étiquette :
Protéger les données privées de son propriétaire
Représente la politique d’utilisation de la donnée
35

36. Modèle d’Étiquettes Décentralisé
Étiquettes de Confidentialité
Exprime le niveau de secret désiré par le propriétaire
d’une donnée
Cite la liste des lecteurs potentiels de la donnée
Ce sont les autorités auxquelles l’élément d’étiquette permet
de consulter la donnée
Propriétaire
=
Source de la donnée
Lecteurs
=
Destinataires possibles
Les autorités qui ne sont pas listées comme lecteurs ne
peuvent pas consulter la donnée
Toutes les politiques d’une étiquette doivent être
respectées
Une information étiquetée ne doit être divulguée que
suite à un consensus entre toutes ses politiques
36

37. Seuls les utilisateurs dont les autorités peuvent agir pour r2 peuvent lire les
données étiquetées par lC
Modèle d’Étiquettes Décentralisé
Étiquettes de Confidentialité
Exemple :
lC = { o1 → r1, r2 ; o2 → r2, r3}
• o1, o2, r1, r2 et r3 : autorités
• Le « ; » sépare deux éléments (politiques) de l’étiquette
• o1 et o2 représentent respectivement les propriétaires des deux
politiques de sécurité, r1, r2 et r3 en représentent les lecteurs
Un utilisateur peut lire les données seulement si l’autorité représentant cet
utilisateur peut agir pour un lecteur de chaque politique de l’étiquette
37

38. Modèle d’Étiquettes Décentralisé
Étiquettes de Confidentialité
Relation d’ordre : au plus aussi restrictive que
Soit
lC1 = { o1 → r1, r2 ; o2 → r2, r3}
et
lC2 = { o1 → r1 ; o2 → r2, r3}
On dit que :
lC1 ⊆ lC2
Car :
• Du point de vue de o1 , lC1 autorise plus de lecteurs que lC2
• Une donnée étiquetée lC1 est donc moins restrictive, car plus
publique
lC3 = { o1 → r1 ; o2 → r2, r3,r4}
Est incomparable avec lC1, car :
{ o1 → r1, r2 } ⊆{ o1 → r1 } et {o2 → r2, r3,r4} ⊆ {o2 → r2, r3}
38

39. Modèle d’Étiquettes Décentralisé
Étiquettes d’Intégrité
Duales aux étiquettes de confidentialité
Politique d’intégrité protège les données contre les
modifications inappropriées
Étiquette d’intégrité garde la trace de toutes les sources qui
ont affecté la valeur de sa donnée, même indirectement
Même structure qu’une politique de confidentialité, sauf qu’elle
définit un ensemble d’écrivains : autorités autorisées à
modifier la donnée
Plusieurs politiques d’intégrité représentent des garanties
indépendantes de qualité de la part de leurs propriétaires
39

40. Modèle d’Étiquettes Décentralisé
Étiquettes d’Intégrité
Exemple :
lI = { o1 ← w1, w2 ; o2 ← w2, w3}
• o1 et o2 représentent respectivement les propriétaires
des deux politiques de sécurité, w1, w2 et w3 en
représentent les écrivains
• o1 ← w1, w2 : garantie fournie par l’autorité o1 que seuls
w1 et w2 sont capables de modifier la valeur de la
donnée
• L’étiquette d’intégrité la plus restrictive est celle qui ne
contient aucune politique : {}
Elle ne fournit aucune garantie sur le contenu de la valeur
Peut être utilisée comme valeur d’entrée uniquement quand le
destinataire n’impose aucune exigence d’intégrité
40

41. Modèle d’Étiquettes Décentralisé
Étiquettes d’Intégrité
Relation d’ordre : au plus aussi restrictive que
Soit
lI1 = { o1 ← w1, w2}
et
lI2 = { o1 ← w1 }
On dit que :
lI2 ⊆ lI1
Car :
• Une variable d’étiquette lI2 a été affectée uniquement par w1
• lI1 autorise w1 et w2 à la modifier
lI3 = { o1 ← w1, w3} ⊈ lI1
w3 n’est pas autorisé par lI1 à modifier la donnée
lI4 = { o1 ← w1 ; o2 ← w3} ⊆ lI1
Du point de vue de o1, la relation est respectée
L’ajout de o2représente une garantie supplémentaire, indépendante
pour lI4
41

42. Modèle d’Étiquettes à base de Jetons
Inspiré de [Krohn07, Zeldovich06]
Une étiquette est un couple de niveaux de
confidentialité et d’intégrité
Un niveau est un ensemble de jetons (tags)
Jeton : terme opaque qui, sorti de son contexte, n’a pas de
signification précise, mais dans une étiquette, permet
d’attribuer aux données une catégorie de confidentialité ou
d’intégrité
l = {S ; I} avec S: niveau de confidentialité et I: niveau
d’intégrité
42

43. Modèle d’Étiquettes à base de Jetons
Confidentialité
Associer un jeton j de confidentialité (j ∈ S) à une
donnée d :
d contient une information privée de niveau de
confidentialité j
Pour révéler le contenu de d, le système doit obtenir
l’accord pour chacun des jetons de confidentialité qui
l’ornent
43

44. Modèle d’Étiquettes à base de Jetons
Intégrité
Associer un jeton i d’intégrité (i ∈ I) à une donnée d :
i attribue une garantie d’authenticité de l’information dans d
i permet au destinataire de s’assurer que d n’a pas été
modifiée par des parties non fiables
i est une garantie supplémentaire pour la donnée
44

45. Modèle d’Étiquettes à base de Jetons
Relation d’ordre
Relation d’ordre partielle : peut circuler vers ⊆
Ordonne les étiquettes de la moins restrictive vers la
plus restrictive
Décomposée en deux sous-relations :
⊆C : ordonne les niveaux de confidentialité
⊆I : ordonne les niveaux d’intégrité
Soient l1 ={ S1; I1 } et l2 = { S2; I2 }
l1 ⊆ l2
ssi
S1 ⊆C S2 et I1 ⊆I I2
45

46. Modèle d’Étiquettes à base de Jetons
Relation d’ordre
Confidentialité
S1 ⊆C S2 ssi ∀j1 ∈ S1, ∃ j2 ∈ S2, tel que j1 = j2
Intégrité
I1 ⊆I I2 ssi ∀i2 ∈ I2, ∃ i1 ∈ I1, tel que i1 = i2
Réunion
Soient deux étiquettes l1 ={ S1; I1 } et l2 = { S2; I2 }.
l ={ S; I } est la réunion de l1 et l2 ssi:
S = S1 U S2 et I = I1 ∩ I2
Corollaire
∀l, l1, l2 ∈ L, si l ⊆ l1 et l ⊆ l2 alors l ⊆ l1 U l2
46

47. Modèle d’Étiquettes à base de Jetons
Relation d’ordre
Transitivité
si l 1 ⊆ l2 et l2 ⊆ l3 alors l1 ⊆ l3
Réflexivité
∀l ∈ L, l ⊆ l
Antisymétrie
l 1 ⊆ l2 et l2 ⊆ l1 ⇔ l1 = l2
47

48. Modèle d’Étiquettes à base de Jetons
Treillis de Sécurité
Ordonne l’ensemble des
étiquettes d’un système de
la moins restrictive vers la
plus restrictive
Montre l’acheminement
a u t o r i s é d ’ u n fl u x
d’information : du bas vers
le haut du treillis
Exemple de treillis avec deux
jetons de confidentialité j1 et
j2 et un jeton d’intégrité i :
48
{ j1,j2 ; }
{ j2 ; }
{ j1 ; }
{ j1,j2 ; i }
{ }
{ j2 ; i }
{ j1 ; i }
{ ; i }

49. ETAT DE L’ART:
SYSTÈMES DE CONTRÔLE DE FLUX D’INFORMATION
Contrôle de Flux D’Information et Non-Interférence
49

50. Systèmes de CFI
Il existe dans la littérature plusieurs solutions pour le
Contrôle de Flux d’Information (CFI)
Nous les avons réparti principalement en deux types:
CFI statique : le contrôle du flux se fait uniquement à la
compilation
CFI dynamique : le contrôle de flux se fait pendant
l’exécution
50

51. Vérification Statique de la NI
Analyse statique du code source d’un programme, et
ce avant son exécution
S’assurer que les opérations qu’ils réalise respectent la
politique de sécurité du système
Suivi de chaque flux d’information dans le système
Deux types de solutions :
Solutions centralisées
Solutions réparties
51

52. Vérification Statique de la NI
Solutions Centralisées : JIF
JIF : Java Information Flow [Myers00]
CFI sur des programmes écrits en Java
Ajoute une analyse statique au code
Étend Java en ajoutant des étiquettes
Respectent le modèle DLM
Étapes de vérification de la NI
1. Architecte de sécurité définit l’ensemble des contraintes selon la politique
désirée
2. Développeur écrit le programme en associant des étiquettes aux différentes
parties du programme (variables, méthodes, blocs…)
3. Un compilateur (basé sur Polyglot [Nystrom03])
Analyse le programme réalisé (Java + étiquettes)
Vérifie qu’il est non-interférent : les politique définie est-elle renforcée?
Génère un code Java, qui sera compilé par un compilateur Java standard, puis exécuté
52

53. Vérification Statique de la NI
Solutions Centralisées : JIF
Types étiquetés
Dans JIF, chaque valeur a un type étiqueté composé de:
Type Java standard
Étiquette de sécurité
Exemple :
int {Alice → } x = 2;
x est donc une variable entière, dont le propriétaire est Alice.
Compteur Programme
Chaque point dans le programme a une étiquette : PC
Limite supérieure des informations pouvant être déduite
en ce point
53

54. Vérification Statique de la NI
Solutions Centralisées : JIF
Méthode
Étend la méthode Java classique, en ajoutant des
étiquettes pour le CFI :
À la valeur de retour
Aux arguments
Aux exceptions
Définit également deux types d’étiquettes particulières
Étiquette de début : limite supérieure à la valeur du PC à
l’invocation de la méthode
Étiquette de fin : valeur du PC au point de terminaison de la
méthode, limite supérieure sur l’information qui peut être
apprise à la terminaison normale, ou exceptionnelle
54

55. Vérification Statique de la NI
Solutions Centralisées : JIF
Étiquettes et Autorités Dynamiques
Étiquettes ou autorité dynamique peut être utilisée comme
paramètre dans une classe, dont la valeur est déterminée à
l’exécution, à l’instanciation d’un objet de cette classe
Rétrogradation (downgrading)
Ajout d’un mécanisme pour rétrograder le niveau de sécurité
d’une donnée si besoin est
Confidentialité : declassification, Intégrité : endorsement
Exemple :
int {Alice → } x = 2;
y = declassify (x, {Alice → Bob});
55

56. Vérification Statique de la NI
Solutions Centralisées : JIF
Exemple :Version JIF de la classe Vector
56

57. Vérification Statique de la NI
Solutions Centralisées : JIF
Plusieurs travaux sur JIF
Système de type pour représenter JIF
Propriété de Robustesse de JIF
Assurer que la rétrogradation de l’information n’est pas
influencée par un attaquant
Canevas utilisant JIF pour construire des applications web
Construction de systèmes répartis non-interférents à
base de JIF (JIF/Split)
57

58. Vérification Statique de la NI
Solutions Réparties : JIF/Split
JIF/Split [Zdancewic02]
Implémentation à base de JIF pour le concept de
partitionnement sécurisé des programmes
Permet de protéger les données dans les systèmes répartis
contenant des hôtes mutuellement hostiles
Étapes :
1. Programme initialement centralisé, écrit avec JIF
2. JIF/Split permet de le partitionner en un ensemble de
programmes non-interférents
3. Ces programmes peuvent être exécutés de manière
sécurisée sur des hôtes hétérogènes
58

59. Vérification Statique de la NI
Solutions Réparties : Compilateur de [Fournet09]
Même principe de base que JIF/Split
Renforce en plus la sécurité des communications
avec des mécanismes
cryptographiques
Étapes :
1. Partitionnement : Découper le code séquentiel en sous-programmes
non-interférents, selon les étiquettes de sécurité appliquées par le
concepteur
2. Contrôle de flux : Génération d’un code qui garde la trace de l’état
du programme, pour le protéger contre un ordonnanceur malicieux
3. Réplication : Transformation du programme distribué basé sur une
mémoire partagée en un programme où les variables sont
répliquées à chaque nœud
4. Cryptographie : Insertion d’opérations cryptographiques pour
protéger les répliques, et distribution de clefs
59

60. Vérification Dynamique de la NI
Systèmes répartis sujets à des modifications pendant
l’exécution :
Changement du niveau de sécurité des données pendant
l’exécution
Évolution de l’architecture du système (migration ou panne
de certains composants…)
La configuration de sécurité du système doit être
revérifiée
Deux types de solutions :
Solutions centralisées
Solutions distribuées
60

61. Vérification Dynamique de la NI
Solutions Centralisées : CFI dans les OS
Contrôle de flux d’information, sous-jacent, des tâches de l’OS
Association d’étiquettes aux processus et messages du système
Sécurisation des applications existantes en régulant la
communication et le changement d’étiquettes des processus
Objectifs :
Minimiser la quantité de code auquel on doit faire confiance
Permettre aux utilisateurs de spécifier les politiques de sécurité
sans limiter la structure des applications
Exemples :
Flume [Krohn07], HiStar [Zeldovich06], Asbestos
[Efstathopoulos05]
61

62. Vérification Dynamique de la NI
Solutions Distribuées : DStar
DStar [Zeldovich08]
Protection au niveau de l’OS sur des machines mutuellement
hostiles
Extension de HiStar aux systèmes distribués
Application de la DIFC (CFI Distribué) entre les système
Introduit la notion d’exportateur par machine
Seul processus pouvant communiquer avec d’autres processus via
le réseau
Vérifie à chaque communicaiton que l’échange d’information
n’enfreint pas les restrictions de sécurité
Supporte HiStar, Flume ou Linux
Si Linux n’implémente pas la DIFC, il fait confiance à tous les
logiciels qui tournent dessus
62

63. Solutions de CFI
Étude Comparative
Critères de comparaison
Dynamicité
Granularité
Le CFI peut se faire à la granularité de la variable, objet, processus…
Plus la granularité est petit, plus le CFI est précis mais son application
difficile
Support de modules patrimoniaux
Indique le niveau de flexibilité de la solution : prend-elle en
considération les modules hétérogènes? les modules « boîte noire »?
Support automatique de la cryptographie
Support de la distribution du système
63

64. Solutions de CFI
Étude Comparative
64
Systèmes Centralisés Statiques (JIF)
ü CFI de granularité très fine
～ Support des étiquettes dynamiques, mais CFI globalement statique
✗ Pas de support des systèmes patrimoniaux, ni de la cryptographie
automatique, et systèmes cibles principalement centralisés
✗ Gros effort et expertise requis pour affecter les niveaux de sécurité à grain
très fin
Systèmes Distribués Statiques (Jif/Split et Fournet)
ü CFI de granularité très fine
ü Support de la cryptographie automatiquement générée (Fournet)
ü Support de la distribution
～ CFI Statique (sauf pour étiquettes dynamiques de JIF/Split)
✗ Pas de support des systèmes patrimoniaux, ni de la cryptographie
automatique (JIF/Split)
✗ La répartition du système se fait selon les besoins de sécurité, pas selon les
besoins fonctionnels

65. Solutions de CFI
Étude Comparative
65
Systèmes Centralisés Dynamiques (CFI dans les OS)
ü Support de la dynamicité
✗ Pas de support des systèmes patrimoniaux, ni de la
cryptographie automatique, et systèmes cibles
principalement centralisés
✗ Granularité grossière
Systèmes Distribués Dynamiques (DStar)
ü Support de la dynamicité et de la distribution
✗ Granularité en général grosse sinon moyenne
✗ Doit être greffé à un OS supportant la DIFC

66. Solutions de CFI
Pour résumer…
66
Aucune des solutions n’assure tous les critères à la fois
Un CFI à grain très fin demande un effort et une
expertise élevés de la part du développeur du système
Dynamicité est en général négligée au dépend de la
granularité, et vice-versa
Car il est délicat de gérer un CFI à grain fin dans un système
réparti, si on considère son aspect dynamique
Très peu de solutions supportent les systèmes
patrimoniaux
CFI est très proche du code

67. Conclusion
Besoin d’une solution qui :
Configure la politique de sécurité à un haut niveau d’abstraction
Applique le CFI à un niveau de granularité fin
Ne requiert pas d’expertise particulière en langages typés sécurité́
Offre la possibilité de relaxer la propriété́ de non-interférence
Sépare les contraintes fonctionnelles des contraintes de sécurité
Propose une solution pour les modules patrimoniaux
Soit applicable aux systèmes répartis réels
Soit applicable dynamiquement, peu de surcoût en terme de
performances
67
Partie III : CIF et DCIF

68. Références
[Efstathopoulos05] P. Efstathopoulos, M. Krohn, et al.“Labels and event processes in the Asbestos operating system.” In Proceedings of the twentieth
ACM symposium on Operating systems principles, volume 25, page 30.ACM, 2005.
[Fournet09] C. Fournet, G. Le Guernic, and T. Rezk. “A Security-Preserving Compiler for Distributed Programs.” Proceedings of the 16th ACM
conference on Computer and communications security, pages 432–441, 2009.
[Goguen82] J.A. Goguen and J. Meseguer.“Security policies and security models.” IEEE Symposium on Security and Privacy, page 11, 1982.
[Krohn07] M. Krohn,A.Yip, et al.“Information flow control for standard OS abstractions”.ACM SIGOPS Ope- rating Systems Review, 2007.
[Malecha10] G. Malecha and S. Chong. “A more precise security type system for dynamic security tests.” Proceedings of the 5th ACM SIGPLAN
Workshop on Programming Languages and Analysis for Security - PLAS ’10, pages 1–12, 2010.
[Myers00] A.C. Myers and B Liskov. “Protecting privacy using the decentralized label model”. ACM Transactions on Software Engineering and
Methodology (TOSEM), 2000.
[Myers06] A.C. Myers, A. Sabelfeld, and S. Zdancewic. “Enforcing robust declassification and qualified robustness.” Journal of Computer Security,
14(2) :157–196, 2006.
[Nystrom03] N. Nystrom, M.R. Clarkson, and A.C. Myers. “Polyglot : An extensible compiler framework for Java”. In Proceedings of the 12th
International Conference on Compiler Construction, pages 138–152. Springer-Verlag,April 2003.
[Rushby92] J. Rushby.“Noninterference, transitivity, and channel-control security policies”.Technical Report No. CSL-92-02., (650), 1992.
[Zdancewic02] S. Zdancewic, L. Zheng, N. Nystrom, and A.C. Myers. “Secure program partitioning”. ACM Transactions on Computer Systems
(TOCS), 20 :328,August 2002.
[Zeldovich06] N. Zeldovich, S. Boyd-Wickizer, E. Kohler, and D. Mazieres. “Making information flow explicit in HiStar.” In Proceedings of the 7th
symposium on Operating systems design and implementation, volume pages, page 278. USENIX Association, 2006.
[Zeldovich08] N. Zeldovich, S. Boyd-Wickizer, and D. Mazieres. “Securing distributed systems with information flow control”. In Proceedings of the
5th USENIX Symposium on Networked Systems Design and Implementation, pages 293–308. USENIX Asso- ciation, 2008.
68