these doctorat une architecture de securité
these doctorat une architecture de securité
these doctorat une architecture de securité
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Section 5.2. Un modèle <strong>de</strong> sécurité générique et hiérarchique<br />
tionnaire <strong>de</strong> l’entité fille (5.3, schéma a). Cette étape se répétera à chaque nœud jusqu’à ce que<br />
le message arrive à <strong>de</strong>stination. Si on considère, que les politiques à appliquer à chaque com-<br />
tel-00239252, version 1 - 5 Feb 2008<br />
FIG. 5.3 – Hiérarchie d’entités sécurisées<br />
munication imposent le chiffrement <strong>de</strong>s communications, on se retrouve avec <strong>une</strong> succession <strong>de</strong><br />
phases <strong>de</strong> chiffrement/déchiffrement du message. Cette redondance cryptographique induit non<br />
seulement <strong>une</strong> hausse <strong>de</strong> latence <strong>de</strong>s communications, <strong>une</strong> forte baisse du débit <strong>de</strong>s communications<br />
entre <strong>de</strong>s objets actifs due au chiffrement et <strong>une</strong> surconsommation <strong>de</strong>s ressources système<br />
en terme <strong>de</strong> mémoire et <strong>de</strong> temps CPU.<br />
La structure arborescente pose un problème <strong>de</strong> performance au niveau <strong>de</strong> l’entité sécurisée correspondant<br />
à la racine <strong>de</strong> l’arbre car elle doit gérer toutes les communications <strong>de</strong> ses entités<br />
filles, elle agit comme un goulot d’étranglement. Cette racine étant le point d’entrée <strong>de</strong> toutes les<br />
communications, <strong>une</strong> panne <strong>de</strong> celle-ci impacterait toutes les entités filles.<br />
Pour palier à ces problèmes, nous avons modifié la façon dont se comportent les entités sécurisées<br />
quand elles se trouvent emboîtées les <strong>une</strong>s dans les autres. Chaque entité possè<strong>de</strong> <strong>une</strong><br />
référence sur l’entité qui la contient (si elle existe). Les entités peuvent ainsi communiquer entre<br />
elles afin <strong>de</strong> convenir <strong>de</strong> la politique <strong>de</strong> sécurité à appliquer pour <strong>une</strong> communication donnée.<br />
C’est l’entité qui protège directement l’objet qui sera chargée d’appliquer la politique <strong>de</strong> sécurité<br />
résultant du calcul <strong>de</strong> toutes les politiques <strong>de</strong> sécurité s’appliquant à cette communication. Les<br />
autres entités n’ont comme seul rôle que <strong>de</strong> fournir la ou les politiques <strong>de</strong> sécurité qu’elles veulent<br />
imposer à cette interaction. De cette manière, l’entité sécurisée est complètement autonome dans<br />
la gestion <strong>de</strong> ses interactions avec le mon<strong>de</strong> extérieur. Ses seules interactions avec ses entités<br />
parentes se font lors <strong>de</strong> l’initialisation d’<strong>une</strong> session. Nous obtenons par la même occasion, un<br />
chiffrement du message <strong>de</strong> bout-en-bout. Seule l’entité sécurisée <strong>de</strong>stinataire du message aura<br />
la possibilité <strong>de</strong> déchiffrer ce <strong>de</strong>rnier.<br />
5.2.2 Le gestionnaire <strong>de</strong> sécurité<br />
Une entité sécurisée est composée d’un gestionnaire <strong>de</strong> sécurité et d’un objet protégé. Le gestionnaire<br />
<strong>de</strong> sécurité est au cœur du système <strong>de</strong> sécurité d’<strong>une</strong> entité. Il sert <strong>de</strong> chef d’orchestre<br />
69