Scurit dans Pastis

1

• Sécurité dans Pastis
• Fabio Picconi
• LIP6
• 13 février 2004
• ACI MD Grid Data Services (GDS)

2
Plan de lexposé

• Pastis
• Modèle de sécurité de base
• Utilisation des CHB et PKB
• Ivy et Oceanstore
• Contrôle daccès
• Limitations et faiblesses
• Modèles améliorés
• Modèle à 2 signatures
• Modèle à 3 signatures
• Conclusion

3
Pastis PAST et Pastry

• Pastry couche KBR (Key-based routing) route un
  message vers la racine dune clef
• PAST couche DHT (Distributed Hash Table) un
  bloc est stocké dans la racine de la clef qui lui
  est associé il est aussi répliqué dans la 2ème,
  3ème,, kème racine

4
Pastis PKBs et CHBs

• PKB Public-Key Block (bloc modifiable)
• Lorsquun PKB est créé on génère une paire clef
  publique clef privée
• Le bloc est signé avec la clef privée et stocké
  sous la clef publique
• Un client vérifie lauthenticité dun PKB au
  moyen de sa clef de stockage

• CHB Content Hash Block (bloc immuable)
• Le bloc est stocké sous le hash des données quil
  contient
• Son intégrité est vérifiée à travers sa clef de
  stockage

5
Sécurité dans Ivy

• Chaque mise à jour est insérée sous la forme dun
  élément du log de lécrivain
• Chaque utilisateur ne peut écrire que sur son
  propre log
• Tout lhistorique du système de fichier est
  disponible à travers les logs.
• Possibilité dannuler des mises à jour en
  ignorant certaines parties dun ou plusieurs logs

6
Sécurité dans Oceanstore

• Le propriétaire dun objet crée une ACL signée
  avec sa clef privée
• Les mises à jour sont
• signées par le client émetteur
• validées par le  primary tier 
• signées par le  primary tier 
• propagées au  secondary tier 
• Pas de mécanisme défini pour certifier les mises
  à jour validées par le  primary tier 

7
Pastis contrôle daccès (modèle de base)

• La clef privée de linode est stockée dans
  linode lui-même, cryptée avec une clef
  symétrique
• Contrôle daccès en écriture
• un nud PAST refuse linsertion dun PKB dont la
  signature nest pas valide
• laccès en écriture est donc restreint à ceux qui
  peuvent signer correctement le PKB
• Un utilisateur autorisé en écriture décrypte
  KPKBs car il connaît la clef symétrique (Ksym)
• En lecture
• les utilisateurs doivent crypter les
  donnéeseux-mêmes

8
Modèle de base faiblesses

• Lidentité de lécrivain nest pas connue
• Ksym partagée par un nombre dutilisateurs
  potentiellement très grand ? possibilité de perte
  de clef
• On ne peut pas révoquer les droits en écriture
• Il faut réinsérer linode sous une autre clef, ce
  qui implique la mise à jour de tous les liens
  durs

9
Amélioration modèle à deux signatures

• Le propriétaire du fichier émet des certificats
  autorisant lécriture sur linode à un ou
  plusieurs utilisateurs
• Linode est signé par lécrivain avec sa clef
  personnelle
• Un nud PAST naccepte un inode que sil est
  accompagné du certificat correspondant
• Un client récupérant un inode effectue la même
  vérification
• Lauthenticité du certificat est vérifiée en
  utilisant la clef publique de linode
• Le certificats doivent être renouvelés après leur
  expiration

Kinode KPKB
10
Modèle à deux signatures (suite)

• Avantages
• On connaît lidentité de lécrivain
• On peut révoquer le droit décriture à un
  utilisateur on attend que le certificat périme
• Inconvénients
• Un certificat signé différent pour chaque inode
• Les certificats doivent être régénérés lorsquils
  expirent
• Vérification plus coûteuse en temps de calcul (2
  signatures)

11
Modèle à trois signatures

• On introduit une troisième signature qui permet
  didentifier le propriétaire du fichier
• Avantages
• Les certificats sont signés avec la clef du
  propriétaire ? un certificat sert pour plusieurs
  inodes (cf. modèle à 2 signatures)
• Inconvénients
• 3 signatures à vérifier pour chaque inode
  (cependant, on peut réutiliser un certificat déjà
  vérifié si on accède à dautres fichiers du même
  propriétaire)

12
Comparaison
13
Conclusion

• Modèle de base (1 signature) ne permet pas la
  révocation des droits de manière efficace ni
  lidentification de lécrivain.
• Un mécanisme à deux signatures résout ces
  problèmes mais nécessite dun certificat
  différent pour chaque inode.
• Un mécanisme à trois signatures évite ce
  problème. Limpact de la troisième signature est
  minimale si on peut valider plusieurs fichiers
  (du même propriétaire) avec le même certificat.
• Réfléchir à de nouveaux schémas de sécurité.