Post on 03-Apr-2015
Réunion DataGRAAL - 7 mars 2003, Paris
Sécurité dans les systèmes P2P
Jean-Michel Busca - LIP6
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
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 algorithmestolérants les fautes arbitraires
Techniques
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 traitementsnécessaire
=>
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
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
DataGRAAL – 7 mars 2003, Paris
Modèles
Fautes Système
Fail-stop
Byzantines
Synchrone
Asynchrone
Omissions
Temporelles
Faiblement synchrone
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
DataGRAAL – 7 mars 2003, Paris
Borne sur le nombre de fautes
Phase 1 :OPER#1
t
Phase 2 :OPER#2
t
1
2
3
4n - f ACK n - f ACK
n – 2f ≥ f + 1
n ≥ 3f + 1
vivacité
correction
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
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
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
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
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
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
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
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
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épliquechaque 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
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=<o,t>
Pre-Prepare
<v, n, D(m)>
Prepare
<v, n, D(m)>
Commit
<v, n>
Request Reply
<t, r>
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
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
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
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
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-change View-change ACK New view
<v+1, C, P, Q> <v+1, i, d> <v+1, V, X>
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
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
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
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
DataGRAAL – 7 mars 2003, Paris
Plan
Introduction
Fautes byzantines – Généralités
Fautes byzantines – Algorithme BFT
Algorithme BFT – Utilisation et performances
Conclusion
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
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(n2) messages par requête
• nombre de faute tolérées relativement faible
• adaptation nécessaire au contexte très volatile du P2P
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)
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: http://oceanstore.cs.berkeley.edu/
Ivy: http://www.pdos.lcs.mit.edu/ivy/