Security Models in Distributed Systems: Pastis, Ivy, and Oceanstore

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

2. Plan de l’exposé • Pastis • Modèle de sécurité de base • Utilisation des CHB et PKB • Ivy et Oceanstore • Contrôle d’accè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 d’une 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) • Lorsqu’un 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 l’authenticité d’un PKB au moyen de sa clef de stockage • CHB : Content Hash Block (bloc immuable) • Le bloc est stocké sous le hash des données qu’il 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 d’un élément du log de l’écrivain • Chaque utilisateur ne peut écrire que sur son propre log • Tout l’historique du système de fichier est disponible à travers les logs. • Possibilité d’annuler des mises à jour en ignorant certaines parties d’un ou plusieurs logs

6. Sécurité dans Oceanstore • Le propriétaire d’un 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 d’accès (modèle de base) La clef privée de l’inode est stockée dans l’inode lui-même, cryptée avec une clef symétrique • Contrôle d’accès en écriture : • un nœud PAST refuse l’insertion d’un PKB dont la signature n’est pas valide • l’accè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 • L’identité de l’écrivain n’est pas connue • Ksym partagée par un nombre d’utilisateurs potentiellement très grand  possibilité de perte de clef • On ne peut pas révoquer les droits en écriture • Il faut réinsérer l’inode 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 l’inode à un ou plusieurs utilisateurs • L’inode est signé par l’écrivain avec sa clef personnelle • Un nœud PAST n’accepte un inode que s’il est accompagné du certificat correspondant • Un client récupérant un inode effectue la même vérification • L’authenticité du certificat est vérifiée en utilisant la clef publique de l’inode • Le certificats doivent être renouvelés après leur expiration Kinode = KPKB

10. Modèle à deux signatures (suite) Avantages • On connaît l’identité 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 lorsqu’ils 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 d’identifier 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 à d’autres 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 l’identification de l’écrivain. • Un mécanisme à deux signatures résout ces problèmes mais nécessite d’un certificat différent pour chaque inode. • Un mécanisme à trois signatures évite ce problème. L’impact 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é.