La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "Réunion DataGRAAL - 7 mars 2003, Paris Sécurité dans les systèmes P2P Jean-Michel Busca - LIP6."— Transcription de la présentation:

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

2 DataGRAAL – 7 mars 2003, Paris 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

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

4 DataGRAAL – 7 mars 2003, Paris 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 =>

5 DataGRAAL – 7 mars 2003, Paris 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

6 DataGRAAL – 7 mars 2003, Paris Plan Introduction 1. 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

7 DataGRAAL – 7 mars 2003, Paris Modèles Fautes Système Fail-stop Byzantines Synchrone Asynchrone Omissions Temporelles Faiblement synchrone

8 DataGRAAL – 7 mars 2003, Paris 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

9 DataGRAAL – 7 mars 2003, Paris Borne sur le nombre de fautes Phase 1 : OPER#1 t Phase 2 : OPER#2 t 1234 n - f ACK n – 2f f + 1 n 3f + 1 vivacité correction

10 DataGRAAL – 7 mars 2003, Paris 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

11 DataGRAAL – 7 mars 2003, Paris Réplication de machines à état Requête Réponse Client Réplique 1 Réplique 2 Réplique 3 Réplique 0 ordonnancement sélection

12 DataGRAAL – 7 mars 2003, Paris Plan Introduction Fautes byzantines – Généralités 1. 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

13 DataGRAAL – 7 mars 2003, Paris 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

14 DataGRAAL – 7 mars 2003, Paris 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

15 DataGRAAL – 7 mars 2003, Paris 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 Points forts

16 DataGRAAL – 7 mars 2003, Paris 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

17 DataGRAAL – 7 mars 2003, Paris 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

18 DataGRAAL – 7 mars 2003, Paris 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

19 DataGRAAL – 7 mars 2003, Paris Fonctionnement – Mode normal n = 4, f = 1 Client Réplique 0 Réplique 1 Réplique 2 Réplique 3 m= Pre-Prepare Prepare Commit RequestReply

20 DataGRAAL – 7 mars 2003, Paris 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

21 DataGRAAL – 7 mars 2003, Paris 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

22 DataGRAAL – 7 mars 2003, Paris 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 1. Conséquences en cas de changement de vue, le dernier n assigné persiste l'ordre total est maintenant garanti sur les changements de vue

23 DataGRAAL – 7 mars 2003, Paris 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

24 DataGRAAL – 7 mars 2003, Paris Fonctionnement – Changement de vue Réplique 0 – primaire v Réplique 1 – primaire v+1 Réplique 2 Réplique 3 View-changeView-change ACKNew view

25 DataGRAAL – 7 mars 2003, Paris 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

26 DataGRAAL – 7 mars 2003, Paris 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

27 DataGRAAL – 7 mars 2003, Paris 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

28 DataGRAAL – 7 mars 2003, Paris Proactive recovery Objectif 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

29 DataGRAAL – 7 mars 2003, Paris Plan Introduction Fautes byzantines – Généralités Fautes byzantines – Algorithme BFT Algorithme BFT – Utilisation et performances Conclusion

30 DataGRAAL – 7 mars 2003, Paris 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

31 DataGRAAL – 7 mars 2003, Paris 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(n 2 ) messages par requête nombre de faute tolérées relativement faible adaptation nécessaire au contexte très volatile du P2P

32 DataGRAAL – 7 mars 2003, Paris 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)

33 DataGRAAL – 7 mars 2003, Paris 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: Ivy:


Télécharger ppt "Réunion DataGRAAL - 7 mars 2003, Paris Sécurité dans les systèmes P2P Jean-Michel Busca - LIP6."

Présentations similaires


Annonces Google