these doctorat une architecture de securité

Section 2.9. Conclusion
ce contexte est moins limité en terme de fonctionalités que celui qui s’exécute dans une sandbox.
De plus, le code ne sera exécuté que si le système autorise l’exécution du code signé par la clé
associée au créateur du programme. Il faut noter que, même si l’intégrité du code pourrait être
prouvée, cette solution ne permettrait pas de garantir le comportement de l’application lors de
son exécution.
FIG. 2.17 – Signature numérique du code
tel-00239252, version 1 - 5 Feb 2008
Ce système est donc dépendant de l’algorithme de hachage générant la signature du code.
Si ce dernier n’est pas suffisamment fiable au niveau de l’unicité des empreintes, un attaquant
pourrait alors modifier le code de l’agent tout en obtenant une signature identique.
La protection d’un agent contre son hôte est connu dans la littérature sous le nom de malicious
host problem [58]. Ce problème vise à protéger un programme contre l’interpréteur qui l’exécute.
On peut établir un parallèle entre ce problème spécifique au code mobile et l’utilisation d’un
protocole à méta objets. Dans les deux cas, l’interpréteur a la possibilité de modifier le code de
l’agent s’il le veut vraiment. L’architecture de sécurité présentée dans cette thèse se base sur
l’hypothèse que les hôtes sont de confiance. Ainsi, si un objet est autorisé à migrer vers un hôte,
cela sous-entend que l’hôte est considéré comme de confiance par la personne ayant établi la
politique de sécurité de l’objet mobile.
2.9 Conclusion
Dans ce chapitre, nous avons réalisé un état de l’art des différents concepts qui seront utilisés
dans cette thèse.
Nous nous sommes attachés dans la première section de ce chapitre à introduire les notions de
sécurité dont nous nous servirons tout au long de ce manuscrit. Après avoir défini le vocabulaire
couramment employé, nous avons présenté les concepts fondamentaux (problèmes et solutions)
de la sécurité informatique en général et plus spécifiquement au sein des systèmes distribués.
Nous nous sommes intéressés au contrôle d’accès en exposant le fonctionnement du mécanisme
de moniteur de référence. Ce mécanisme repose sur deux concepts qui sont, pour le premier, le
besoin d’authentification des sujets et pour le deuxième, le besoin d’exprimer des règles d’accès
aux objets par les sujets au moyen d’une politique de sécurité. Une solution de contrôle d’accès
distribué reposant sur le principe des proxies restreints a été présentée.
La section 2.4 nous a permis d’exposer les notions cryptographiques nécessaires à l’introduction
des infrastructures à clés publiques présentées dans la section 2.5. L’utilisation d’une
infrastructure à clé publique permet de solutionner le problème d’authentification des sujets. De
plus, l’utilisation d’un couple de clé publique/privé au sein d’une telle architecture offre la possibilité
d’utiliser des protocoles cryptographiques afin de garantir les échanges de données.
La section 2.6 nous a permis, dans un premier temps de définir la notion de politiques de sécurité.
Nous avons ensuite énuméré les différents types de politiques de sécurité existants ainsi
que leurs spécificités propres. La seconde partie de cette section a mis en évidence les problèmes
27