these doctorat une architecture de securité

Section 6.9. Conclusion
Pour qu’un message soit accepté, il doit être validé par une session, c’est-à-dire être déclaré
comme authentique par les mécanismes cryptographiques associés à la session. Avant d’envoyer
un message entièrement fabriqué, l’attaquant doit découvrir la politique de sécurité de la session
qu’il veut attaquer. Si on considère qu’il a été capable d’intercepter un message, il peut analyser
ce dernier et regarder si le message est chiffré ou si une signature est présente. Il peut à partir
de là deviner la politique de sécurité de la session. Cependant, à moins de détenir les secrets
nécessaires à la fabrication du message, il sera incapable d’émettre un message qui sera validé
par les mécanismes cryptographiques de sa cible.
Usurpation d’identité
Le protocole d’échange de clé Diffie-Hellman que nous utilisons pour l’échange de la clé de
session est connu pour être vulnérable à l’attaque dite d’impersonnation. Cet algorithme ne se
base en effet que sur les clés publiques des entités en présence pour échanger la clé de session.
Dans notre cas, ce protocole est complété par une authentification à base de certificat rendant
impossible ce type d’attaque lorsque l’authentification est requise par la politique de sécurité.
Interruption
tel-00239252, version 1 - 5 Feb 2008
Une partie de l’application distribuée est détruite ou est devenue inaccessible. Il s’agit d’une
attaque sur la disponibilité.
Ce type d’attaque n’est pas géré directement par le mécanisme de sécurité mais par le mécanisme
de rendez-vous. Ce dernier garantit la délivrance du message lors d’une communication.
Si le rendez-vous échoue, le comportement actuel est de lever une exception afin d’en informer
l’utilisateur.
6.9 Conclusion
Dans ce chapitre, nous nous sommes attachés à exposer l’intégration de notre modèle de sécurité
au sein de la bibliothèque ProActive ainsi que ses interactions avec les autres fonctionnalités
(fonctionnelles ou non) de la bibliothèque.
La première partie de ce chapitre a permis une présentation générale de la façon dont s’intègre
notre modèle de sécurité au sein de la bibliothèque. L’organisation de la bibliothèque en
couches distinctes nous a permis d’ajouter la couche liée à la sécurité juste au dessus de la couche
transport. Cet ajout s’est fait de manière transparente vis-à-vis des couches voisines qui n’ont
pas conscience de l’existence de cette couche intermédiaire. Nous avons également détaillé pour
chaque entité le fonctionnement du mécanisme de sécurité en présentant le code java qui aurait
du être ajouté au code métier de l’application sans l’approche implicite pronée par notre mécanisme
de sécurité. Nous avons également exposé l’interface de programmation disponible dans
le cas où le programmeur voudrait, au sein de son application, interagir avec le mécanisme de
sécurité.
La deuxième partie de ce chapitre a présenté l’intégration du mécanisme de sécurité avec les
fonctionnalités majeures de la bibliothèque.
Tout d’abord, nous nous sommes intéressés à la migration des activités et aux implications de
cette mobilité sur notre modèle de sécurité. Pour chacune des implications et seulement dans les
cas nécessaires, nous avons présenté une solution permettant de la rendre compatible avec notre
modèle de sécurité.
La deuxième fonctionnalité majeure présente dans la bibliothèque est la communication de
groupe. Il existe plusieurs types de groupe chacun avec des propriétés propres. L’implantation
des groupes peut être vue comme une extension d’une communication ProActive normale. De ce
123