these doctorat une architecture de securité

Section 6.5. Architecture pair-à-pair et sécurité
FIG. 6.10 – Un serveur pair-à-pair partageant des nœuds
tel-00239252, version 1 - 5 Feb 2008
curité comme des entités sécurisées normales possédant leurs propres politiques de sécurité. Lors
du déploiement de l’application, il est possible de créer un nœud sur un runtime obtenu par le
biais du réseau pair-à-pair. Le nœud sera associé à la politique de sécurité de l’entité qui l’a créé.
Cependant, il est aussi possible d’acquérir un nœud existant et possédant sa propre politique de
sécurité. Un objet actif créé sur un tel nœud sera soumis non seulement à la politique de sécurité
de l’application qui l’a déployé mais aussi à la politique de sécurité du nœud qui l’accueille. Le
fait que la référence sur un runtime ait été acquise via le réseau pair-à-pair ou obtenue lors du
déploiement de l’application est transparente vis-à-vis du mécanisme de sécurité, seule compte
la politique de sécurité du runtime.
Lorsqu’une application utilise le mécanisme pair-à-pair et la sécurité, deux paramètres peuvent
influer sur le temps de calcul global : les communications et la volatilité des pairs. En effet, la
surcharge occasionnée par notre modèle de sécurité est essentiellement concentrée au niveau des
communications et lors de la création d’entités sécurisées.
Le calcul pair-à-pair est particulièrement bien adapté aux applications demandant un ratio
(Temps de communication / Temps de calcul) très petit. Cette propriété est intéressante, elle nous
laisse supposer que la surcharge induite par le chiffrement des communications n’aura qu’un
faible impact sur l’application.
La volatilité des pairs est plus critique, elle implique la génération d’un nouveau certificat
pour chaque nouveau pair. Pour avoir une idée du coût de la surcharge liée au mécanisme de
sécurité, le temps de génération du certificat doit être comparé à la durée de vie du pair. Intuitivement,
on déduit que le coût de la surcharge diminuera avec l’augmentation de la durée de vie
du pair. Ainsi une application qui crée un grand nombre de pairs de très courte durée se verra
plus pénalisée qu’une dont la durée de vie des pairs est plus grande.
Notre but est maintenant de montrer le comportement du mécanisme de sécurité dans le
cas d’une application écrite spécifiquement pour l’architecture pair-à-pair. Cette application se
penche sur le problème des n reines qui doit répondre à la question suivante : “Comment placer
n reines sur un échiquier de n × n sans qu’elles soient en prises ?”. Notons pour la petite histoire
que la bibliothèque ProActive a permis d’établir un nouveau record mondial le 11 juin 2005 en
calculant les solutions possibles pour n=25. Ce résultat a impliqué en moyenne un total de 260
machines de bureau pendant près de 6 mois [93].
113