Réunion DataGRAAL - 7 mars 2003, Paris

Présentation au sujet: "Réunion DataGRAAL - 7 mars 2003, Paris"— 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 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 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

4 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 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 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

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

8 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 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

10 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 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

12 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

13 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 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 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  

16 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 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 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 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

20 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 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 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

23 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 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

25 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 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 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 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

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

30 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 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

32 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 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: