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