La carte à identités TLS

4.2.1 Cas d’une carte à une identité

Nous élaborons notre modèle d’identité numérique en nous appuyant sur le principe de la carte EAP-TLS, d’après les arguments que nous avons déjà exposés dans le chapitre précédent. Le format exact de cette identité est celui du conteneur explicité à la section 3.3.3. Néanmoins, en tant que tel, ce modèle est difficilement exploitable pour une gestion approfondie des identités utilisateurs. En effet, si une carte ne contient qu’un seul conteneur susceptible de fournir une identité TLS, c’est-à- dire un certificat X509 et les clés associées, deux cas peuvent se présenter :

1. L’utilisateur reçoit une carte EAP-TLS vierge, i.e. sans conteneur déjà chargé. Dans ce cas, la gestion consistera à le laisser générer une identité qui devra être chargée dans sa carte.

2. L’utilisateur reçoit une carte EAP-TLS dans laquelle un conteneur racine a déjà été chargé, sans nécessairement de rapport avec la véritable identité de l’utilisateur, et dont la fonction serait de pouvoir certifier la carte auprès du serveur d’identités.

81

Chacun de ces deux cas conduit à une impasse. En effet, dans le premier cas, aucune contre- mesure n’est mise en place afin de vérifier l’authenticité de la carte utilisateur. Il est alors aisé de réaliser une contrefaçon en chargeant simplement dans un composant une application réalisant les mêmes fonctionnalités que la carte EAP-TLS. De même, un attaquant pourra aisément charger lui- même une identité dans son composant, une fois le format de celui-ci analysé, sans avoir à déclarer cette dernière au serveur d’identités. Bâtir une gestion des identités sur un tel modèle semble donc loin d’être optimal.

Dans le second cas, le conteneur racine a pour vocation de résoudre le problème précédent. Il contiendrait, en guise de CN du certificat X509, un numéro de série unique qui serait placé dans une liste blanche, de manière à ce que le serveur puisse vérifier la validité de la carte fournie par l’utilisateur. Pour autant, cette vérification étant effectuée, il faudrait, pour rester cohérent, interdire à l’utilisateur de réécrire ce conteneur pour y placer une identité qu’il aurait générée. En effet, une telle action ne permettrait pas au serveur de vérification ultérieure de la validité de la carte utilisateur. Bien qu’il soit possible de mettre en place une vérification de l’identité générée sur la base, par exemple, de la clé publique du certificat associé, il est possible à l’utilisateur de charger cette identité dans d’autres composants que le sien. Autrement dit, le lien entre l’identité réelle de l’utilisateur et l’identité générée, et donc entre l’utilisateur et sa carte, est rompu. Par conséquent, la gestion des identités utilisateurs ne peut être opérée convenablement selon ce modèle. Quant à considérer l’interdiction de générer une identité afin d’empêcher l’effacement du conteneur racine, cela revient à considérer l’absence pure et simple de gestion d’identités utilisateur, puisque ce dernier serait définitivement lié à une unique identité dont il n’aurait pas même eu le loisir de choisir le CN. Bien qu’il s’agisse, à proprement parler, d’un modèle d’identité numérique viable, son intérêt est extrêmement limité, et ne répond pas à notre ambition de laisser à l’utilisateur le choix du pseudonymat. Nous ne retiendrons donc pas un tel modèle.

4.2.2 Cas d’une carte à plusieurs identités

L’analyse précédente nous amène à envisager un modèle reposant sur une carte EAP-TLS pouvant accueillir en même temps plusieurs identités. Dans un tel paradigme, nous pouvons concilier les différents éléments soulevés précédemment. Notamment, il est possible de disposer d’un conteneur pré-enregistré dans la carte lorsque cette dernière parvient à l’utilisateur, tout en laissant à ce dernier le loisir de charger d’autres identités dans des emplacements dédiés. Ce conteneur racine, comme nous l’avons appelé (de même que nous appellerons respectivement par la suite identité

racine et certificat racine, l’identité et le certificat associés à ce conteneur), permet à l’origine de

réaliser le lien entre l’émetteur de la carte, l’utilisateur, et le serveur d’identité. Il occupe donc une fonction essentielle du point de vue de la gestion des identités. Néanmoins, il est possible d’objecter qu’un simple numéro de série, unique, et écrit de manière permanente dans la carte, est suffisant pour remplir cette fonction. A cela, les arguments suivants peuvent être opposés :

82

 La présence d’un conteneur d’identité originel, contenant par exemple le numéro de série dans le CN du certificat X509, permet d’utiliser le TLS embarqué afin d’authentifier, notamment, la carte au serveur. Par ce moyen, ce n’est pas uniquement le numéro de série qui est vérifié, mais également la validité du certificat associé.

 La présence de clés asymétriques dans le conteneur constitue une opportunité pour sécuriser le chargement des identités générées par l’utilisateur.

Le deuxième point, notamment, pousse la logique du conteneur racine à assurer également le lien entre l’identité réelle de l’utilisateur et les identités générées. Ce lien, pour exister, suppose l’unicité et le caractère non interchangeable de la carte EAP-TLS utilisateur, et l’assurance que les conteneurs d’identité ne peuvent pas être copiés d’une carte à l’autre. Une telle procédure de sécurisation implique la présence d’une clé résiduelle au sein de la carte, sur laquelle l’utilisateur n’a aucune possibilité d’action. Cette sécurisation, détaillée dans la section 4.3.4, met ainsi précisément à contribution les clés asymétriques du conteneur racine.

L’utilité de ce conteneur étant reconnue, au moins un autre emplacement est nécessaire afin de laisser à l’utilisateur la possibilité de générer, et charger, une identité dont il aura choisi la dénomination. Du point de vue du serveur d’identités, le lien entre le conteneur racine et les identités générées par l’utilisateur est assez simple à réaliser, pourvu que la génération d’identités soit conditionnée à une préalable authentification par l’identité racine. Un tel modèle permet donc de répondre aux ambitions que nous avions énoncées en termes de service, à savoir l’établissement de ce lien, d’une part, et la promotion du pseudonymat, d’autre part.

Enfin, dans un contexte où plusieurs conteneurs d’identités peuvent cohabiter dans un même composant, l’intérêt de la commande Set-Identity, décrite au chapitre précédent (section 3.3.4) et jusqu’ici assez artificielle, est à présent entièrement palpable, d’autant que la présence d’un conteneur racine confère une différence de statut aux identités présentes, différence dont il sera nécessaire de tenir compte.