Elaboration d’un modèle d’identité et fédération d’identité

Dans le cadre de notre objectif qu’est l’élaboration d’un nouveau modèle d’identité, la compatibilité avec les différents moyens de lier l’identité entre SP et IdP doit être la plus grande et la plus aisée possible. La fédération d’identité représente en effet un vecteur extrêmement conséquent permettant le déploiement rapide d’un modèle émergent qui ne nécessite pas de changement de configuration d’un parc entier de serveurs d’authentification ou de technologies usuellement supportées et déployées.

Inscrire l’élaboration d’un modèle d’identité dans la réalité suppose, entre autres contraintes, la prise en compte d’un déploiement effectif en dehors de serveurs de tests personnels. Pour cela, la

55

démarche consiste à implémenter un IdP s’appuyant sur l’une des technologies citées précédemment, puis à tester l’authentification auprès d’un SP sur la base de cette technologie. D’après les remarques formulées dans les sections précédentes, la technologie OpenID nous a semblé la plus adéquate à cet effet, grâce notamment à sa simplicité, sa légèreté, et l’absence de coûts que son déploiement engendre.

D’un point de vue strictement industriel, adhérer à un acteur majeur de la fédération d’identité tel que Liberty Alliance, en s’inscrivant notamment dans un cercle de confiance, pourrait avoir beaucoup plus de poids, mais nécessite un investissement prohibitif pour une simple preuve de concept. Toutefois, la compatibilité de la solution élaborée avec la technologie SAML sera illustrée dans la troisième partie de ce rapport qui traitera, dans le chapitre 6, de la mise en place d’un serveur de jetons SAML dans le contexte du Cloud Computing.

Cette recherche d’interopérabilité du modèle d’identité avec ces différents standards interdit par nature l’élaboration d’un format d’identité totalement nouveau – travail qui appartient aux consortiums et organismes de standardisation à même de tenter de l’imposer au sein de l’Internet actuel. Le cadre d’un travail de thèse impose nécessairement des vues plus modestes, sans quoi l’ambition de demeurer réaliste ne tiendrait pas. Par conséquent, l’élaboration d’un modèle d’identité numérique s’appuiera nécessairement sur l’utilisation de standards reconnus mais combinés de manière originale, en recherchant la nouveauté dans l’architecture de gestion sous-jacente davantage que dans le format lui-même. Une preuve de concept impliquant le déploiement d’un IdP de type OpenID s’inscrit donc entièrement dans cette orientation.

2.5 Conclusion

Nous avons pu mettre en évidence à travers ce chapitre différents types d’architecture de gestion de l’identité numérique, qui notamment s’opposent à l’architecture classique associant une identité à un serveur. Les apports en termes de simplicité de gestion pour l’utilisateur sont réels et conséquents, mais la complexité de développement et de déploiement ne l’est pas moins, bien que cela dépende du type d’architecture considérée. Les contraintes en termes de coûts et de risques relatifs à la sécurité et à la vie privée doivent être traitées avec beaucoup de rigueur, les enjeux d’une usurpation d’identité étant extrêmement importants.

Les différents produits et technologies mis au point par différents acteurs de l’identité permettent de fournir à l’heure actuelle la possibilité de répondre à des besoins précis par rapport à ces contraintes, c’est-à-dire à un compromis entre le niveau de sécurité et de garantie de vie privée offerts aux utilisateurs, et le prix à payer pour cela. Depuis OpenID, gratuit et simple mais offrant peu de garanties, jusqu’à Liberty Alliance, ou d’autres produits de fédération d’identité propriétaires, qui offrent une gestion généralement plus fine des problématiques de l’identité numérique mais qui sont nettement plus coûteux et plus lourds, les solutions en place sur le marché couvrent une grande partie des cas d’usage.

56

Indépendamment de cela, et malgré les enjeux majeurs qu’elles se proposent de traiter, les architectures de fédération d’identité restent toutefois critiquables d’un point de vue plus large. En effet, la création de cercles de confiance induit l’existence de communautés fermées et par conséquent difficiles d’accès, dont la finalité consisterait davantage à la mise en place d’un partenariat liant ses différents membres qu’à une véritable volonté de simplifier la gestion des identités pour les utilisateurs. Mais la suppression totale du principe du cercle de confiance n’est pas non plus une solution, car le caractère inter-domaines des informations échangées et des politiques de sécurité ne permet pas, sans relation préalable de confiance, d’accepter en toutes circonstances la délégation de l’authentification à un IdP dont le SP ne sait rien quant au sérieux de son administration. Dans tous les cas, la fédération d’identité se heurte à un paradoxe qui n’a pas trouvé, à l’heure actuelle, de solution satisfaisante.

Dans le cadre de ce travail de thèse, ainsi qu’il a été spécifié, nous préférons tirer partie de la technologie la plus aisée à déployer sur le Web, à savoir OpenID. Ses défauts, certes nombreux, peuvent trouver des réponses satisfaisantes, notamment du point de vue de la sécurité lors de la procédure d’authentification. Plus précisément, une authentification de type mutuelle par le protocole TLS serait vue d’un très bon œil par l’ensemble des SP souhaitant s’assurer de la mise en place de contre-mesures anti-phishing, tout en permettant à l’utilisateur une gestion plus aisée de son compte par la suppression du mot de passe. Par conséquent, les conclusions que nous avons tirées du premier chapitre de ce rapport restent valables dans ce contexte, gagnant même en pertinence. L’orientation amenée par l’ensemble de cette analyse, tant sur les modèles d’identité et d’authentification, que sur les architectures de fédération d’identité, nous amène donc à creuser plus en détail un modèle d’identité reposant sur le protocole TLS tout en bénéficiant d’un environnement de confiance propre à remédier aux réserves énoncées dans le premier chapitre. A cet effet, la carte EAP-TLS, qui sera le fondement de notre modèle d’identité, constitue le sujet du chapitre suivant.

57

Chapitre 3 : La carte à puce EAP-TLS

3.1 Introduction

Comme nous l’avons montré dans le Chapitre 1, le protocole TLS possède de nombreuses qualités, souvent insuffisamment exploitées. Son déploiement majeur, sous la forme d’une authentification à sens unique de la part du serveur vers le client, permet de réaliser le chiffrement des flux de données applicatifs et de réduire l’efficacité du phishing. Mais en omettant l’authentification mutuelle, qui soumet la création du tunnel sécurisé au succès de l’authentification de l’utilisateur via son certificat X509, ce déploiement n’élimine ni la faiblesse de l’authentification par mot de passe, ni le phishing – qui fonctionnera aussi longtemps qu’une donnée non éphémère tel qu’un mot de passe, transitant sur le réseau, servira à l’authentification – ni les attaques par MITM, dont nous avons vu qu’elles pouvaient compromettre de nombreuses procédures d’authentification, y compris les OTP.

Toutefois, nous avons également mis en évidence à propos de TLS un fait nettement moins répandu dans les analyses des faiblesses du protocole. Il s’agit de son exécution en environnement peu adapté à la conservation d’éléments sensibles tels que des clés secrètes ou privées. Or, l’absence d’environnement de confiance peut, au même titre que les attaques mentionnées plus haut, compromettre l’ensemble de la sécurité offerte par le protocole. L’utilisation de composants sécurisés tels que des cartes à puce permet alors de combler cette faille, au moins en partie. Les bénéfices apportés par ces composants dépendent de leurs propriétés, d’une part, mais aussi, et surtout, de la manière dont ils sont mis à contribution.

Dans la pratique, en effet, l’utilisation des environnements de confiance se limite le plus souvent au stockage d’éléments à longue durée de vie, comme une clé privée asymétrique. C’est notamment l’orientation prise par les « cartes PKI » qui inondent le marché des cartes à puce, et que nous étudierons plus spécifiquement dans ce chapitre. Néanmoins, comme nous l’avons vu au premier chapitre, une telle approche n’est pas suffisante. Pour aller au bout du raisonnement et assurer un très haut niveau de confiance, c’est l’ensemble du protocole TLS qui doit s’exécuter dans le composant dédié.

L’ensemble de ces observations nous a amenés à considérer ce que nous appellerons désormais la « carte EAP-TLS », qui désigne un composant sécurisé, sans limitation aux cartes à puce, embarquant notre implémentation du protocole EAP-TLS. Malgré tout, la carte à puce représente la très grande majorité des supports des implémentations que nous avons effectuées. C’est pourquoi nous nous attarderons plus particulièrement, dans ce rapport, sur les propriétés de la carte à puce et sur les différents types de cartes que nous avons testées.

58

Le but de ce chapitre est de décrire formellement la technologie EAP-TLS embarquée, de la différencier des traditionnelles « cartes PKI » -- qui désignent généralement des composants compatibles avec le standard PKCS #15[78] – et enfin de montrer que les performances de cette technologie sont compatibles avec une utilisation régulière de la part des utilisateurs finaux. Nous terminerons ainsi la première partie de ce rapport par une brève description du modèle d’identité que nous avons envisagé, qui reposera très largement sur cette technologie, et qui prendra en compte les conclusions tirées à l’issue des deux chapitres précédents.