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

Présentation au sujet: "1/13 Sécurité dans Pastis Fabio Picconi LIP6 13 février 2004 ACI MD Grid Data Services (GDS)"— Transcription de la présentation:

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

2 2/13 Plan de l’exposé 1.Pastis 2.Modèle de sécurité de base –Utilisation des CHB et PKB –Ivy et Oceanstore –Contrôle d’accès –Limitations et faiblesses 3.Modèles améliorés –Modèle à 2 signatures –Modèle à 3 signatures 4.Conclusion

3 3/13 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 4/13 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 5/13 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 6/13 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 7/13 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 K PKB s car il connaît la clef symétrique (K sym ) En lecture : –les utilisateurs doivent crypter les données eux-mêmes

8 8/13 Modèle de base : faiblesses L’identité de l’écrivain n’est pas connue K sym 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 9/13 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 K inode = K PKB

10 10/13 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 11/13 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 12/13 Comparaison 1 sign.2 sign.3 sign. Identité écrivaininconnueconnue Révocation droits réinsertion inode (liens durs) expiration certificat Nombre de sign. à vérifier 123 Validité certificat -un seul inodeinodes d’un même propriétaire

13 13/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é.