Réunion DataGRAAL - 7 mars 2003, Paris

Slides:



Advertisements
Présentations similaires
Sécurité informatique
Advertisements

1 CNAM Vendredi 29 Novembre 2002 Bases de Données Avancées UV C Responsable : Mr Scholl PROTOCOLE A DEUX PHASES Meryem Guerrouani.
Introduction à la tolérance aux défaillances
Sous-projet IV Communications Placement/Ordonnancement.
Détecteurs de fautes pour réseaux dynamiques P. Sens, L. Arantes, M. Bouillaguet Projet REGAL.
A NETWORK-AWARE DISTRIBUTED STORAGE CACHE FOR DATA INTENSIVE ENVIRONMENTS Brian L. TIERNEY, Jason LEE, Brian CROWLEY, Mason HOLDING Computing Sciences.
Introduction aux environnements répartis
Protocole PPP* *Point-to-Point Protocol.
Stéphanie CLAPIÉ Antoine RENARD
IPv6 et la Mobilité DESS Réseaux 1-INTRODUCTION
Stockage dans DIET Groupe de travail du 16 décembre 2002.
Vue d'ensemble Implémentation de la sécurité IPSec
Design Pattern MVC En PHP5.
IRISA18 novembre ACI Sécurité DADDi Dependable Anomaly Detection with Diagnosis IRISA.
1 ACI DADDI - Réunion de lancement IRISA - Projet ADEPT Michel Hurfin Jean-Pierre Le Narzul Frédéric Tronel 23 mai 2005.
INTRODUCTION.
Chiffrement – Utilisation de GPG
Organisation du système d’information comptable et de gestion
La voix IP : Mr.FERGOUGUI Boudouch Ali kmichou Ansar Atrassi Najoua
Systèmes distribués C. Delporte-Gallet (ESIEE-IGM)
Plateforme de gestion de données de capteurs
Conception et analyse des algorithmes
SSL (Secure Sockets Layer) (couche de sockets sécurisée)
Cours 7 - Les pointeurs, l'allocation dynamique, les listes chaînées
SECURITE DU SYSTEME D’INFORMATION (SSI)
Prof : M.Trannoy - Professeur d'électrotechnique.
Le modèle O.S.I..
Xavier Perrin Emmanuel De Castro Mars 2005 Système distribué
Section XI Traitement de fichiers
Messagerie sécurisée Docteur Christophe BEZANSON (Unaformec)
Atomicité Transactions Atomiques Recouvrement à Base de Journal
Réunion DataGraal Janvier 2003 Grenoble
Le protocole FTP.
Les Algorithmes Cryptographiques Symétriques
Mise en place d'un serveur SSL
Cryptographie Réalisé par TOUJENI Noura BEN SOUISSI Rania KARAOUD Imen
Consensus distribué En ce qui concerne ce document, le problème de consensus sera étudié (examiner, considérer, explorer, analyser). Le problème est provoqué.
D1 - 09/06/2014 Le présent document contient des informations qui sont la propriété de France Télécom. L'acceptation de ce document par son destinataire.
Réseau de stockage étendu
Aymeric BERNARD Stéphane BRINSTER Guillaume LECOMTE.
Réunion de collaboration du 9-10 Juillet 2008 J.L. Béney 1 Logiciel At  Client-Serveur Tcp/ip de la station autonome  Influence de l'architecture matérielle.
EPID-CPI-ISAIP Philippe Bancquart - mise à jour 24/02/ page 1 Gestion des transactions SQLServer.
Vincent Gramoli Advisor : Alexander A. Shvartsman
Pr ZEGOUR DJAMEL EDDINE Ecole Supérieure d’Informatique (ESI)
Mise en oeuvre et exploitation
La sécurité dans les réseaux mobiles Ad hoc
La réplication dans les réseaux mobiles ad hoc
INTRODUCTION.
Le protocole d’authentification
Pr BELKHIR Abdelkader Master RSD Sécurité des systèmes informatiques
Sécurité Les Virus Logiciels non sollicités et réalisant des opérations malveillantes ou destructrices Typologie –D’application :introduit par recopie.
1 Nomination de mandataire Marin BERTIER. 2 Contexte ► Développement des GRIDs  Grand nombre de sites  Organisé hiérarchiquement ► Niveau local  cluster.
1/13 Sécurité dans Pastis Fabio Picconi LIP6 13 février 2004 ACI MD Grid Data Services (GDS)
Etude de la volatilité dans un système de stockage P2P Fabio Picconi – LIP6.
1 Détection et tolérance aux fautes dans JuxMem Sébastien Monnet IRISA / PARIS Lyon, 05/12/2003.
Présence et communication peer-to-peer Diplômant : Yves Bresson Professeur responsable : Yves Dennebouy EIVD Septembre - Décembre 2003.
Étude d ’approfondissement Le Paiement Électronique
Module 3 : Création d'un domaine Windows 2000
Les Réseaux Informatiques
Contributions de l’ENST Bretagne à l’ACI Dispo RSM/SERES.
COMPARAISON ENTRE GNUTELLA ET FREENET
Ingénierie des réseaux
L’horloge et type de transmission
Architecture Client/Serveur
Structures de données avancées : LH* D. E ZEGOUR Institut National d ’Informatique.
Kawthar Karkouda, Nouria Harbi, Jérôme Darmont, Gérald Gavin,
ANNEHEIM Geoffrey21/03/ Protocole de communication Socket TCP/IP Afin que MyCrawler fonctionne de façon optimale, une configuration de deux machines.
Chapitre 8 Protection du trafic réseau à l'aide de la sécurité IPSec et de certificats Module S43.
Département Informatique Les Réseaux Informatiques Couche Transport Protocoles UDP & TCP Laurent JEANPIERRE.
Présentation de HelloDoc Mail
Transcription de la présentation:

Réunion DataGRAAL - 7 mars 2003, Paris Sécurité dans les systèmes P2P Jean-Michel Busca - LIP6

Contexte En raison de leur nombre très élevé, pas de confiance dans les sites du système espionnage pannes arbitraires, ou attaques malveillantes Constitue un problème, même pour les systèmes les plus simples stockage de données privées / confidentielles diffusion de données publiques / partagées modification des données

Deux aspects Sécurité des données Techniques Sécurité des traitements confidentialité intégrité authenticité Sécurité des traitements pannes, erreurs quelconques attaques malveillantes Techniques cryptographie réplication et algorithmes tolérants les fautes arbitraires

Relations Deux aspects orthogonaux sécurité des données securité des traitements sécurité des traitements sécurité des données Tous deux nécessaires, même dans les cas simples Exemple : production / consommation de données signer les données pour empêcher leur corruption n'empêche pas un site de nier leur existence, ou en fournir une version obsolète ∩ ∩ sécurité des traitements nécessaire =>

Relations (2) Synergie entre les deux aspects en lecture / écriture simple, signer les données facilite la détection des fautes byzantines permet de maximiser le nombre de fautes supporté la cryptographie est utilisée pour authentifier les échanges de messages dans certains algorithmes BFT

Plan Introduction Fautes byzantines – Généralités Modèles de faute Propriétés à assurer Borne sur le nombre de fautes byzantines Fautes byzantines – Algorithme BFT Algorithme BFT – Utilisation et performances Conclusion

Modèles Fautes Système Fail-stop Synchrone Byzantines Asynchrone Omissions Temporelles Faiblement synchrone Byzantines Asynchrone

Propriétés à assurer En dépit des fautes et des lenteurs, un algorithme de réplication doit rester : correct vivace Correction stockage, ex. : la valeur lue est la dernière écrite machine à état, ex. : ordre total des requêtes sur les répliques Vivacité le système ne bloque jamais les requêtes soumises finissent par retourner

Borne sur le nombre de fautes 3 1 Phase 1 : OPER#1 Phase 2 : OPER#2 n - f ACK n - f ACK 4 2 t t vivacité n – 2f ≥ f + 1 n ≥ 3f + 1 correction

Ecriture / lecture de données Comment déterminer la réponse correcte ? dans le calcul précédent, seul un site répond correctement est-ce que cela suffit pour le distinguer ? Données simples, indifférenciées il faut une majorité pour déterminer la bonne réponse n – 2f (intersection) ≥ f (fausses rep.) + f + 1 (bonnes rep.) n ≥ 4f + 1 Données signées, avec un timestamp la bonne réponse est celle de plus haut time stamp il suffit que le site correct la retourne : n ≥ 3f + 1

Réplication de machines à état Réponse Client Requête sélection Réplique 0 Réplique 1 ordonnancement Réplique 2 Réplique 3

Plan Introduction Fautes byzantines – Généralités Fautes byzantines – Algorithme BFT (Castro/Liskov) Description et principes Fonctionnement - Mode normal Fonctionnement – Changement de vue Pro-active recovery Algorithme BFT – Utilisation et performances Conclusion

Description Algorithme de réplication de machine à état la machine à état doit être déterministe l'algorithme garantit une sémantique exactly-once Tolérant les fautes byzantines erreurs logicielles ou humaines ainsi que les attaques malveillantes Supposant un modèle faiblement synchrone délais de transmission finalement bornés réseau non fiable (pertes, duplications, inversions possibles) Implémenté sous forme d'une librairie

Historique Consensus : algorithme de Bracha et Toueg (85) fautes byzantines (sauf fail-stop), en modèle asynchrone inspire le fonctionnement de BFT en mode normal Réplication : Viewstamp replication (88) et Paxos (89) fautes bénignes seulement, en modèle asynchrone (?) BFT réutilise : le découpage primaire/backups et les quorums Réplication : Rampart (94) et SecureRing (98) fautes byzantines, en modèle synchrone (pour la correction) BFT réutilise : la communication de groupe

Points forts Aucun synchronisme nécessaire pour la correction seul synchronisme faible nécessaire pour garantir la vivacité bien adapté à Internet (lenteurs, attaques denial of service) Optimal en nombre de fautes byzantines supportées jusqu'à (n-1)/3 fautes supportées sur une fenêtre de temps donnée Mécanisme de réparation des répliques réparation continue (pro-active recovery) tolère un nombre arbitraire de fautes sur la vie du système  

Principes Répliques organisées en 1 primaire + (n-1) backups le primaire assigne le numéro de séquence des requêtes les backups surveillent son bon fonctionnement : présence, par armement d'un TO numérotation dense des requêtes En cas de faute du primaire, changement de vue élection d'un nouveau primaire, dans la nouvelle vue transfert des informations d'ordonnancement à la nouvelle vue Deux régimes de fonctionnement mode normal changement de vue

Principes (2) Répliques organisées en quorums de taille 2f+1 tous les quorums intersectent 2 à 2 : mémoire du système chaque quorum contient au moins (f+)1 réplique correcte il existe un quorum sans aucune réplique en faute Utilisation de certificats (acquittements d'opération) : quorum certificate (2f+1) : acquittement de l'opération par toutes les répliques d'un quorum, l'information est stable weak certificate (f+1) : acquittement de l'opération par au moins une réplique correcte

Principes (3) Cryptographie symétrique pour sécuriser les échanges clé secrète dans chaque sens entre deux répliques clé secrète bidirectionnelle entre chaque client et réplique chaque message est authentifié par un MAC Définition de l'état d'une réplique par l'état du service le numéro de vue courant v le log des messages reçus et émis Identification des requêtes / réponses par un timestamp t renseigné par et relatif au client émetteur

Fonctionnement – Mode normal Request Pre-Prepare Prepare Commit Reply m=<o,t> <v, n, D(m)> <v, n, D(m)> <v, n> <t, r> Client Réplique 0 Réplique 1 Réplique 2 Réplique 3 n = 4, f = 1

Fonctionnement normal – Phases Phase Pre-prepare : le primaire assigne un numéro de séquence n à la requête l'envoie aux backups par un message Pre-prepare (n, v) le message est accepté si : la réplique est dans la vue v elle n'a pas déjà assigné n à un autre message

Fonctionnement normal – Phases (2) Phase Prepare : chaque réplique confirme par un message Prepare multicasté collecte ensuite le message Pre-repare + 2f messages Prepare constituant un prepared certificate : un quorum est d'accord pour assigner n à cette requête dans la vue courante v Ne suffit pas en cas de changement de vue

Fonctionnement normal – Phases (3) Phase Commit : chaque réplique multicaste un message Commit collecte ensuite 2f+1 messages Commit, incluant le sien constituant un committed certificate : un quorum sait qu'un quo- rum est d'accord pour assigner ce numéro de séquence à cette requête dans cette vue Conséquences en cas de changement de vue, le dernier n assigné persiste l'ordre total est maintenant garanti sur les changements de vue

Fonctionnement normal – Execution Execution d'une requête par une réplique les requêtes peuvent être committées en désordre mais elles sont exécutées en ordre (numérotation dense) chaque réplique retourne sa réponse directement au client et conserve la dernière en cas de ré-émission de la requête (pour garantir la sémantique exactly-once) Le client reçoit les différentes réponses (t, r) rejette celles ne correspondant au dernier timestamp attend f+1 réponses avec le dernier t et le même résultat r ré-émet la requête initiale si des réponses ont été perdues

Fonctionnement – Changement de vue View-change View-change ACK New view <v+1, C, P, Q> <v+1, i, d> <v+1, V, X> Réplique 0 – primaire v Réplique 1 – primaire v+1 Réplique 2 Réplique 3

Changement de vue - Phases Détection de faute du primaire temporisation réception requête – réception Pre-prepare assignation d'un numéro de séquence incorrect tous les backups détectent finalement la faute Phase View change : chaque réplique multicaste un message View-change v+1 contenant : ses derniers checkpoints, les (n, v) des requêtes pré-préparées et préparées dans les précédentes vues collecte ensuite les View-change des autres répliques, acceptés s'ils contiennent des (n, v) antérieurs à la vue courante

Changement de vue – Phases (2) Phase View change ACK : chaque réplique acquitte les messages View-change auprès du nouveau primaire qui collecte un view-change certificate (quorum de 2f+1 acquit- tements) pour chacun des View-change initiaux Phase New view : le primaire détermine le nouveau checkpoint de départ réassigne des numéros aux requêtes, en garantissant que si une requête a commité dans v-1, elle conserve son numéro diffuse ces informations aux répliques backup

Autres points et optimisations Purge des logs via checkpoint indépendants Infrastructure de diffusion / renouvellement des clés Regroupement des opérations sous forte charge Opérations read-only en un seul échange

Proactive recovery Objectif Hypothèses additionnelles Principe réparer les répliques pour prolonger la vie du système périodiquement, même en l'absence de signe de faute Hypothèses additionnelles modèle de synchronisme plus fort : à partir d'un certain temps t, tous les messages sont remis dans un délai D constant matériel sûr (coprocesseur cryptographique, mémoire read-only, timer inviolable) Principe reboot périodique renouvellement des clés recouvrement de l'état auprès des autres répliques

Plan Introduction Fautes byzantines – Généralités Fautes byzantines – Algorithme BFT Algorithme BFT – Utilisation et performances Conclusion

BFS : Byzantine File System BFT utilisé pour FS tolérant aux fautes byzantines Configuration de test 4 serveurs sur réseau 100 Mbps (f = 1) exécutant le benchmark Andrew Résultat latence de 2 à 24% plus faible avec BFT throughput 52% plus faible pour R/W, 35% pour R

Conclusion Sécurité des données : cryptographie lourde coût CPU d'encryptage / décryptage mouvement de données site de stockage / site de traitement Sécurité des traitements : protocoles byzantins lourds O(n2) messages par requête nombre de faute tolérées relativement faible adaptation nécessaire au contexte très volatile du P2P

Quelques simplifications Sécurité des données : systématiquement décrypter / rencrypter les données pour les manipuler ? OceanStore : techniques de sélection de données dans leur version cryptée (par bloc) Sécurité des traitements : systématiquement appliquer des algo- rithmes complexes ? Ivy : représentation des mises à jour sous forme d'un log des modifications, un log par utilisateur les enregistrements sont constants et auto-certifiants, seule la tête de log est modifiée (et signée)

Bibliographie (extraits) Practical Byzantine Fault Tolerance and Proactive Recovery. M. Castro, B. Liskov. ACM Transaction on Computer Systems, Vol. 20, No. 4, November 2002 OceanStore: http://oceanstore.cs.berkeley.edu/ Ivy: http://www.pdos.lcs.mit.edu/ivy/