these doctorat une architecture de securité

Chapitre 5. Une architecture de sécurité de haut niveau
En nous basant sur l’étude bibliographique présentée dans ce manuscrit et des contraintes
suscitées, la solution d’authentification qui s’impose est l’utilisation d’une architecture à clé publique
de type SPKI. Le choix de la solution SPKI s’explique par la nature même des entités à
identifier. En effet, l’infrastructure SPKI permet l’attribution de certificats à des objets logiques
comme les runtimes, les nœuds ou encore les objets actifs ce qui n’est pas le cas de l’infrastructure
PKI dont les certificats identifient une entité physique ou morale en donnant son nom, son émail,
sa localisation, . . . . Ainsi , l’identification des diverses entités sécurisées se fera en attribuant
une identité unique à chaque entité au moyen de certificats.
Une autre fonctionnalité intéressante réside dans la possibilité d’établir une chaîne de certificats.
Le chaînage de certificats permet d’obtenir l’identité de toutes les entités qui ont successivement
généré des certificats jusqu’au certificat final qui identifie l’entité courante. En d’autres
termes, à partir du certificat d’une entité, nous sommes capables de retrouver le certificat de
l’utilisateur qui l’a lancée. Il n’existe aucune limitation à la taille de cette chaîne de certificats.
Cependant il convient de modérer la taille de cette chaîne : étant donné que la validation d’un
certificat requiert la validation de tous les certificats présents dans la chaîne, plus cette chaîne
est courte, plus la validation du certificat sera rapide.
tel-00239252, version 1 - 5 Feb 2008
5.3.1 Un schéma d’authentification hiérarchique
Le principal problème auquel nous devons faire face réside dans la dynamicité des applications
distribuées. En effet, une application évolue tout au long de son exécution. Son nombre
d’objets ou le nombre de nœuds sur lesquels elle est déployée, par exemple, peut augmenter et
diminuer dynamiquement suivant plusieurs paramètres externes ou internes à l’application. Du
point de vue de la sécurité, on doit pouvoir générer des certificats pour ces nouvelles entités sécurisées
sans pour autant devoir interagir avec l’utilisateur.
Selon le principe même des certificats, chaque certificat engendré doit être unique dans un
contexte et représenter une entité sécurisée donnée. Il est certes possible d’écrire le code de création
du certificat et d’effectuer l’association du certificat et de l’entité au sein de l’application.
Cependant nous recherchons à automatiser ce processus et à le rendre transparent aux développeurs
et aux utilisateurs.
Afin de mettre en évidence l’inadéquation du modèle standard des certificats et le besoin
d’adaptation de ce mécanisme dans le cadre de notre modèle de sécurité, nous utiliserons le
scénario suivant :
1. L’utilisateur, muni de son certificat fourni par l’autorité de certification, crée l’objet appelé
Entité 1. En tant qu’entité sécurisée, cet objet reçoit un certificat.
2. Entité 1 va ensuite créer les entités Entité 2 et Entité 3.
3. Entité 3 crée un nouvel objet actif Entité 4,
4. finalement, Entité 4, à son tour, crée un objet actif Entité 5.
En premier lieu, nous présentons la façon dont s’organise le chaînage de certificats dans le
cas standard (figure 5.5). Un certificat comporte une partie référençant l’entité qui l’a généré
et une partie qui l’identifie. Dans notre exemple, chaque certificat, hormis celui de l’utilisateur,
représente une entité sécurisée.
Le scénario dans le cas standard est le suivant :
1. Le certificat de l’Entité 1 contient l’identité de l’utilisateur X dans la partie identifiant le
créateur du certificat.
2. Le certificat de l’Entité 2 et de l’Entité 3 contiennent l’Entité 1 en tant que créateur
du certificat.
3. Le certificat de l’Entité 4 contient l’Entité 3 en tant que créateur du certificat.
4. Le certificat de l’Entité 5 contient l’Entité 4 en tant que créateur du certificat.
74