6.1 Introduction
Concept devenu très en vogue au cours des dernières années, le Cloud Computing[92] est souvent associé à une vision abstraite de services du réseau Internet. Pourtant, ce qu’il désigne à l’origine n’a rien d’une révolution technologique, puisqu’il s’agit, pour un serveur donné, de confier la réalisation de traitements et opérations informatiques à des serveurs distants, potentiellement administrés par des tiers. Autrement dit, le Cloud Computing consiste à louer la gestion d’un service donné. Il peut s’agir d’équipements ou de services de couches basses, ce qui constitue alors l’IaaS (Infrastructure as a Service), d’outils de développement sous forme de plateformes, ce qui constitue le PaaS (Platform as a Service), ou bien encore simplement des applications, qui constituent alors le SaaS (Software as a Service).
Dans une architecture s’inscrivant dans le Cloud Computing, les questions relatives à la sécurité et à la confiance se posent naturellement, car la délégation de la gestion de données à un tiers implique la définition d’une politique claire relative à la confidentialité de ces données, et la mise en place de contre-mesures associées à cette politique. Il est possible, en effet, de ne pas souhaiter laisser la possibilité à la tierce partie d’accéder aux données qu’elle stocke sans que cela nuise à la mission qui lui est confiée, par exemple la gestion des accès à des ressources protégées suite à une authentification.
Dans ce contexte, le cas de l’authentification centralisée auprès d’un serveur RADIUS a attiré notre attention. Largement déployé dans des architectures de type 802.1X (cf. chapitre 3), le serveur RADIUS réalise l’authentification d’un client souhaitant accéder à une ressource protégée d’un réseau. Or, il est tout à fait envisageable de considérer ce type d’authentification dans le contexte du Cloud Computing, où le serveur RADIUS serait administré par un tiers. Néanmoins, il est difficile, alors, d’empêcher ce tiers d’espionner les échanges ou d’accéder aux données sensibles relatives à l’authentification des utilisateurs, surtout dans un modèle symétrique. Mais un modèle asymétrique ne rendrait pas davantage le serveur RADIUS à l’abri d’attitudes malveillantes, car la clé privée du serveur reste soumise, en étant stockée directement sur le terminal, aux mêmes faiblesses que nous évoquions dans le chapitre 1.
Une telle architecture se prête assez naturellement à l’emploi de la carte EAP-TLS, à présent en mode serveur, en guise de moyen d’authentification auprès du serveur RADIUS. Nous décrivons, dans ce chapitre, une solution reposant sur une grille de 32 cartes EAP-TLS en mode serveur et en présentons les performances mesurées.
108
Nous présentons également une architecture voisine, à la finalité différente mais reposant sur le même principe de grille de cartes. Cette architecture, dépourvue à présent de serveur RADIUS, viserait à déléguer à un tiers la génération de jetons SAML après une authentification mutuelle TLS réussie, montrant ainsi la possibilité de lier identité TLS, Cloud Computing et fédération d’identités, tout en soulignant le caractère convergent de notre modèle d’identité par l’utilisation d’une technologie de fédération différente de OpenID, qui a fait l’objet de la plateforme de démonstration principale décrite au chapitre précédent.
Dans ce chapitre, nous traitons ainsi la problématique consistant à mettre au point une architecture de Trust as a Service permettant la délégation d’opérations et d’équipements à un tiers tout en assurant la confidentialité et l’intégrité des données auxquelles le tiers pourrait avoir accès. Les deux cas d’utilisation envisagés sont celui de l’authentification auprès d’un serveur RADIUS administré par un tiers, et la génération et distribution par un tiers de jetons pour la fédération d’identité, avec l’exemple de SAML.
6.2 Une architecture d’authentification auprès d’un serveur
RADIUS
6.2.1 Contexte
Nous nous plaçons ici dans le cadre d’une authentification visant à permettre l’accès à une ressource d’un réseau. Cette authentification, réalisée dans le cadre d’une architecture 802.1X[75], emploie, conformément à ce standard, un serveur RADIUS[76], dont nous supposons qu’il a été confié à une tierce partie, en charge de sa seule maintenance. Dans ce contexte, nous ne souhaitons pas que ce tiers puisse s’attaquer aux données sensibles contenues sur ce serveur, ni même les consulter.
A la suite de la présentation de notre modèle d’identité, et notamment de ses apports théoriques en termes de sécurité, l’utilisation d’une carte à puce EAP-TLS du côté serveur nous a semblé être un parti pris assez naturel. De cette manière, toute information ou donnée critique mobilisée dans la procédure d’authentification reste scellée, avec la garantie que le tiers ne pourra ni en avoir connaissance, ni la modifier. Néanmoins, dans le cas où un seul serveur RADIUS centralise les demandes d’authentification d’un grand nombre d’utilisateurs, l’utilisation d’une unique carte EAP- TLS est notoirement insuffisante pour traiter les accès concurrents. Il est ainsi nécessaire de déployer un nombre suffisamment conséquent de cartes.
Dans le cadre d’une plate-forme de démonstration, nous avons opté pour 32 Javacard Gemalto TOP IM GX4[112], placées dans une grille au format SIM. Cette grille de cartes, pouvant en réalité accueillir jusqu’à quatre cents cartes à puce, est hébergée en Allemagne derrière un serveur frontal réalisant le lien avec chacune des cartes de la grille.
109
Habituellement, ce type de grille est utilisé par les constructeurs de téléphones mobiles afin de vérifier leur compatibilité avec les cartes SIM émises par les différents opérateurs. D’autres architectures impliquant une grille de carte à puces ont également vu le jour, comme dans [89] qui combine la puissance de calcul d’un groupe de Javacards afin de générer un ensemble de Mandelbrot. Toutefois, l’usage que nous faisons ici de la grille, où chaque carte constitue un serveur indépendant, est entièrement original.
6.2.2 Présentation de l’architecture
6.2.2.1
Vue générale de l’architecture
Résultat d’un travail présenté dans [90], la première version d’un serveur RADIUS fonctionnant avec des cartes EAP-TLS en mode serveur était constituée, comme le montre la figure 27, d’un hub USB dans lequel étaient insérés 3 cartes EAP-TLS ainsi que le serveur RADIUS proprement dit, dont le code était contenu dans la mémoire Flash d’un composant USB. Bien que fonctionnel, ce prototype restait incompatible avec le format de la grille de cartes qui nous a été proposée, et pour laquelle nous avons légèrement modifié ce modèle.
Figure 27 : Serveur RADIUS fonctionnant avec des cartes EAP-TLS serveur
La principale modification a consisté à séparer ce bloc unique constitué par le serveur RADIUS et ses cartes EAP-TLS en deux parties bien distinctes, et physiquement éloignées :
- Une partie purement logicielle traite le protocole RADIUS
110
Un lien virtuel est établi entre la partie RADIUS et chacune des cartes de la grille par l’intermédiaire de sockets TCP. Une connexion TCP est ouverte pour chaque carte devant être utilisée pour une authentification. Dans le cas où toutes les cartes sont occupées, la demande d’ouverture de connexion TCP est rejetée, bien qu’il soit également possible de la mettre en attente de la libération d’une ressource. Une vue synthétique de l’architecture distribuée alors obtenue est illustrée sur la figure 28.
Figure 28 : Architecture distribuée d’un serveur RADIUS
6.2.2.2
Fonctionnement détaillé de la plateforme
Une telle architecture vise à fournir un haut niveau de confiance en réalisant une authentification entre une carte EAP-TLS client, et l’une des cartes EAP-TLS serveur, de manière à mettre à profit les avantages du composant sécurisé des deux côtés de la connexion. Néanmoins, il est difficile de réaliser des tests de montée en charge à partir de plusieurs dizaines de cartes EAP- TLS client, qui pour des raisons de gestion correcte du parallélisme doivent être distribuées sur plusieurs d’ordinateurs – rendant ainsi élevé, voire prohibitif, le coût de déploiement d’une telle plateforme de démonstration. Par conséquent, nous avons monté une plateforme de test à partir de clients simulés par le logiciel OpenSSL, dont le TLS est artificiellement traité par plusieurs opérations d’encapsulation avant d’être transmis au serveur RADIUS proprement dit. Ces opérations sont effectuées par un pont logiciel que nous appellerons NAS (Network Access Server) par la suite, indispensable pour cette simulation, mais sans objet dans le cas d’une expérience à partir de cartes EAP-TLS client. L’ensemble des éléments mobilisés dans cette plateforme, ainsi que la représentation intégrale du scénario des échanges entre chacun de ces éléments, sont illustrés sur la figure 29.
Il n’est pas nécessaire de revenir sur les opérations réalisées par la partie serveur EAP, le fonctionnement de la carte EAP-TLS ayant déjà été détaillé dans le chapitre 3. Seules deux différences existent par rapport à cette description :
- Le fait que les cartes EAP-TLS sont déployées en mode serveur.
- Le fait que le logiciel proxy réalisant l’interface avec la grille de cartes est de nature différente de celui qui a été décrit. De fait, bien qu’il soit nécessaire de faire tourner en permanence un