réunion datagraal - 7 mars 2003, paris sécurité dans les systèmes p2p jean-michel busca - lip6

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

Upload: anette-forest

Post on 03-Apr-2015

105 views

Category:

Documents


0 download

TRANSCRIPT

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

Réunion DataGRAAL - 7 mars 2003, Paris

Sécurité dans les systèmes P2P

Jean-Michel Busca - LIP6

Page 2: 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

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

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

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

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

=>

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

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

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

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

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

DataGRAAL – 7 mars 2003, Paris

Modèles

Fautes Système

Fail-stop

Byzantines

Synchrone

Asynchrone

Omissions

Temporelles

Faiblement synchrone

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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>

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

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

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

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

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

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

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

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

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

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>

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

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

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

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

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

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

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

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

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

DataGRAAL – 7 mars 2003, Paris

Plan

Introduction

Fautes byzantines – Généralités

Fautes byzantines – Algorithme BFT

Algorithme BFT – Utilisation et performances

Conclusion

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

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

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

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

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

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)

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

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/