sécurité des systèmes répartis- partie2 - non interférence
DESCRIPTION
Visitez http://liliasfaxi.wix.com/liliasfaxi !TRANSCRIPT
![Page 1: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/1.jpg)
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 de Tunisie 2014
![Page 2: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/2.jpg)
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
![Page 3: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/3.jpg)
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
![Page 4: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/4.jpg)
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
![Page 5: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/5.jpg)
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
![Page 6: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/6.jpg)
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
![Page 7: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/7.jpg)
A!
B!
C!
Suivi du Flux d’Information
7
![Page 8: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/8.jpg)
LA NON-INTERFÉRENCE : ��� CONCEPT ET DÉFINITIONS
Contrôle de Flux D’Information et Non-Interférence
8
![Page 9: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/9.jpg)
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
![Page 10: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/10.jpg)
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
![Page 11: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/11.jpg)
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
![Page 12: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/12.jpg)
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
![Page 13: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/13.jpg)
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
![Page 14: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/14.jpg)
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
![Page 15: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/15.jpg)
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
![Page 16: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/16.jpg)
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
![Page 17: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/17.jpg)
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
![Page 18: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/18.jpg)
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
![Page 19: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/19.jpg)
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
![Page 20: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/20.jpg)
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
![Page 21: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/21.jpg)
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!
![Page 22: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/22.jpg)
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
![Page 23: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/23.jpg)
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
![Page 24: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/24.jpg)
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
![Page 25: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/25.jpg)
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 (s2>0) {
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 s2>0 ou non
![Page 26: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/26.jpg)
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
![Page 27: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/27.jpg)
Sans oublier…
Les exceptions
Les threads
Les canaux temporels
Les ressources partagées
…
27
![Page 28: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/28.jpg)
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
![Page 29: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/29.jpg)
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
![Page 30: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/30.jpg)
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
![Page 31: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/31.jpg)
MODÈLES DES ÉTIQUETTES DE SÉCURITÉ Contrôle de Flux D’Information et Non-Interférence
31
![Page 32: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/32.jpg)
É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
![Page 33: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/33.jpg)
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
![Page 34: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/34.jpg)
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
![Page 35: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/35.jpg)
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
![Page 36: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/36.jpg)
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
![Page 37: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/37.jpg)
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
![Page 38: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/38.jpg)
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
![Page 39: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/39.jpg)
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
![Page 40: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/40.jpg)
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
![Page 41: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/41.jpg)
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
![Page 42: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/42.jpg)
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
![Page 43: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/43.jpg)
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
![Page 44: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/44.jpg)
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
![Page 45: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/45.jpg)
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
![Page 46: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/46.jpg)
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
![Page 47: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/47.jpg)
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
![Page 48: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/48.jpg)
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
Mont re l ’ a chem inemen t 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 }
![Page 49: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/49.jpg)
ETAT DE L’ART: ���SYSTÈMES DE CONTRÔLE DE FLUX D’INFORMATION
Contrôle de Flux D’Information et Non-Interférence
49
![Page 50: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/50.jpg)
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
![Page 51: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/51.jpg)
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
![Page 52: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/52.jpg)
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
![Page 53: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/53.jpg)
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
![Page 54: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/54.jpg)
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
![Page 55: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/55.jpg)
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
![Page 56: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/56.jpg)
Vérification Statique de la NI���Solutions Centralisées : JIF
Exemple : Version JIF de la classe Vector
56
![Page 57: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/57.jpg)
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
![Page 58: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/58.jpg)
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
![Page 59: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/59.jpg)
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
![Page 60: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/60.jpg)
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
![Page 61: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/61.jpg)
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 : F l ume [K rohn07 ] , H i S t a r [Ze l dov i c h06 ] , A sbe s to s [Efstathopoulos05]
61
![Page 62: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/62.jpg)
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
![Page 63: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/63.jpg)
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
![Page 64: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/64.jpg)
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
![Page 65: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/65.jpg)
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
![Page 66: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/66.jpg)
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 suppor tent les systèmes patrimoniaux CFI est très proche du code
![Page 67: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/67.jpg)
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
![Page 68: Sécurité des Systèmes Répartis- Partie2 - non interférence](https://reader036.vdocuments.site/reader036/viewer/2022062307/55857366d8b42a3d2c8b4cab/html5/thumbnails/68.jpg)
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