L’objectif de cette thèse était d’élaborer un modèle d’identité tirant parti des avantages fournis par un environnement de confiance afin d’obtenir une authentification forte et personnalisée, tout en s’adaptant aisément aux technologies émergentes et convergentes.
Après avoir, dans une première partie, exploré les composantes de l’identité numérique dans les réseaux à travers, d’une part, l’association entre la représentation d’une identité et la preuve de cette dernière – c’est-à-dire l’authentification – et d’autre part, les différents moyens mis en œuvre pour lutter contre la prolifération des identifiants des utilisateurs – c’est-à-dire la fédération d’identité – nous en avons tiré les caractéristiques qui nous semblent être indispensables pour la conception d’un modèle d’identité numérique, à savoir : l’utilisation de standards reconnus et déployés, la recherche d’une authentification forte obtenue par l’alliance de protocoles à la sécurité éprouvée et d’un environnement de confiance dédié, la mise en place d’un format d’identité simple mais fortement associé avec la procédure d’authentification choisie, et enfin, l’assurance de l’adaptation – voire, d’une participation active – du modèle à la convergence.
Nous avons alors décrit, dans le chapitre 3 qui clôt cette première partie, les choix technologiques qui ont fondé notre modèle d’identité, notamment le principe d’une authentification mutuelle via le protocole TLS, lequel se trouve entièrement embarqué dans un microcontrôleur sécurisé, dont les contre-mesures permettent de fournir un environnement de confiance pour le stockage d’éléments cryptographiques sensibles. Nous y présentons également le format de l’identité afférent à cette technologie, ainsi que l’architecture basique nécessaire au fonctionnement de cette technologie.
La seconde partie de cette thèse est ainsi consacrée à la construction du modèle d’identité proprement dit, dans sa version la plus générale, et entièrement adaptée aux usages du Web, qui constituait la cible première de ce modèle. Le principe d’une carte personnelle, et personnalisable, la liberté laissée à l’utilisateur d’y charger des identités associées à des pseudonymes, sont les éléments qui nous ont semblé les plus importants à mettre en place. Nous décrivons l’implémentation d’un serveur d’identité réalisant l’ensemble de ces fonctionnalités, la sécurisation de la génération et du chargement des identités, ainsi que le cycle de vie global du composant, depuis sa création jusqu’à sa disparition.
Sur les bases ainsi posées, nous décrivons alors une architecture entièrement fonctionnelle associant notre modèle d’identité à la fédération d’identité, laquelle se pose ici en moteur pour le déploiement de notre solution sur le Web. La preuve de concept ainsi établie permet à tout utilisateur de s’authentifier auprès d’un serveur Web quelconque sur la base des informations qu’il aura lui- même choisies de stocker dans son composant. Nous illustrons aussi la possibilité de réaliser cette opération à partir d’un terminal mobile – les spécificités techniques liées à ces derniers ayant été prises en compte dans l’implémentation du serveur d’identité et du serveur de fédération d’identité.
145
Enfin, dans une dernière partie, nous évoquons différentes perspectives de déploiement de notre modèle, dont les contextes peuvent mettre à profit tout ou partie de ce dernier. Nous nous sommes efforcés de rechercher des cas extrêmement éloignés les uns des autres afin d’illustrer au mieux la capacité de notre solution à s’intégrer, voire à remplacer, les technologies préexistantes dans chacun de ces domaines.
Le premier cas exposé est celui d’une architecture pour l’authentification sécurisée dans le Cloud Computing, aussi bien pour l’accès à des ressources protégées d’un réseau interne que pour la génération de jetons dans le cadre de la fédération d’identité. Cette architecture met à contribution l’ensemble des fonctionnalités de notre modèle pour le côté client, et permet de faire cohabiter des identités d’organismes différents pour le côté serveur. Elle met également en avant la possibilité de réaliser une authentification sécurisée de composant à composant, qui peut être avantageusement incluse dans la mouvance du M2M.
Le second cas s’oriente sur la dématérialisation d’un service de prépaiement géré, à l’heure actuelle, principalement par le format papier. L’architecture que nous proposons, qui permet de sécuriser la gestion de jetons de prépaiement tout en restant extrêmement fidèle aux principes des architectures en place, a la particularité d’intégrer un composant pour lequel deux identités coïncident – client et serveur, en l’occurrence. Cela permet d’illustrer un principe intéressant, qui stipule que l’identité numérique d’une machine peut, à l’image de l’identité numérique d’un individu, ne pas être unique. Si dans le second cas, les multiples identités permettent de conserver des pseudonymes dans l’interaction avec les différents services, dans le premier cas, les identités peuvent être réparties selon les fonctions, souvent non uniques, attribuées aux machines. Suivant ce raisonnement, notre proposition de modèle d’identité s’intègre alors parfaitement au cas de l’authentification dans le M2M.
Enfin, le dernier cas met en valeur les possibilités offertes par l’ajout de la notion d’identité pour la personnalisation de services tels que la distribution de clés. A partir d’un cadre où le seul outil d’obtention d’une clé permettant l’accès à un lieu pour une durée limitée est une carte impersonnelle du type Mifare, nous réorientons l’ensemble de l’architecture vers l’exploitation des possibilités offertes par les terminaux mobiles tels que les Smartphones, notamment leur compatibilité avec la technologie NFC. Nous mettons alors à contribution les cartes à interface duale afin de maintenir la compatibilité avec le standard Mifare, mais également afin d’introduire notre modèle d’identité au cœur de l’architecture de distribution de clés, qui permet la délégation du service à l’utilisateur tout en assurant la sécurisation du chargement des clés dans la carte. L’orientation vers des services centrés utilisateur est en effet en phase avec la mouvance actuelle perceptible via, notamment, la prépondérance des réseaux sociaux, et ne peut être réalisée que par la prise en compte d’un modèle d’identité assurant un lien personnalisé avec l’utilisateur.
Le modèle d’identité que nous avons présenté dans ce rapport n’est pas exempt de limitations, notamment dans la perspective d’un déploiement à grande échelle. La promotion d’un standard de sécurité tel que l’authentification mutuelle TLS ne peut avoir lieu sans une adaptation globale des relations des serveurs Web avec les utilisateurs. Bien que la fédération d’identité nous permette de
146
repousser le problème, elle ne le résout pas entièrement pour autant. Néanmoins, le problème du déploiement d’une telle solution relève davantage de problématiques liées au monde industriel que d’un travail de thèse. Par conséquent, nous ne nous étendons pas sur ces questionnements dans ce rapport. Néanmoins, les possibilités d’application de notre solution, en dehors de la relation d’utilisateur humain à serveur Web, alliées à son adaptation intrinsèque au principe de la convergence, sont suffisamment nombreuses pour illustrer les nombreuses perspectives dont elle peut faire l’objet, quitte à devenir un standard dans un contexte plus restreint que celui de la généralisation de l’authentification sécurisée sur le Web.