1/13
Sécurité dans Pastis
Fabio Picconi
LIP6
13 février 2004
ACI MD Grid Data Services (GDS)
2/13
Plan de l’exposé
1. Pastis2. 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/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/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/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/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/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 KPKBs car il connaît la clef symétrique (Ksym)
• En lecture :– les utilisateurs doivent crypter les données
eux-mêmes
8/13
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/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
Kinode = KPKB
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/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/13
Comparaison
1 sign. 2 sign. 3 sign.
Identité écrivain inconnue connue connue
Révocation droits
réinsertion inode (liens durs)
expiration certificat
expiration certificat
Nombre de sign. à vérifier
1 2 3
Validité certificat
- un seul inode inodes d’un même
propriétaire
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é.