PFE. ALCINOOS «Gestion de portefeuille électronique par carte à puce» Equipe N 16 Projet N 98. «Sujet non industriel proposé par les élèves»

Transcription

1 PFE ALCINOOS «Gestion de portefeuille électronique par carte à puce» Equipe N 16 Projet N 98 «Sujet non industriel proposé par les élèves»

2 Sommaire Introduction... 4 Le contexte financier... 4 Le contexte technologique... 4 Notre solution... 4 Historique... 4 Conduite de projet... 5 Méthodologie utilisée... 5 Gestion des fichiers sources : Subversion... 5 Gestion de projet : Maven... 5 Cycle en V... 6 Déroulement effectif... 7 Réalisation... 8 Partie financière... 8 Difficultés et solutions mises en place... 8 Schéma entité/relation... 8 Modélisation UML... 9 Spécifications de la librairie... 9 Résultats Partie web-services Modèle Vue Contrôleur : Struts Persistance : Hibernate & PostGreSQL Tests unitaires : JUnit Architecture réseau Modélisation UML Console d administration Partie carte à puce & Web Service d Authentification Architecture générale Protocole d authentification mutuelle La technologie Java Card Fonctionnalités Sélection de la Java Card Service d authentification par certificat Modélisation Processus Détail d implémentation Objets Conclusion Annexes /01/2008 Rapport Final 2 / 26

3 Cadre administratif Projet N 98 ALCINOOS : «Gestion de portefeuille électronique par carte à puce» Equipe N 16 Tableau 1 Nom Prénom Majeure Note Aucher Arnaud SI Tech. Info aucher@ece.fr Chef de projet Barry Aguibou SE barry@ece.fr Demester Vincent SI Tech. Info vdemeest@ece.fr François-Elie Cédric SI Finance cfrancoi@ece.fr Lau Anthony SI Finance lau@ece.fr Pinsonneau Rémy SI Tech. Info pinsonne@ece.fr Zanchetta Cédric SI Finance zanchett@ece.fr Référent Tableau 2 Nom Prénom Bonnet Jean-François bonnetjf@ece.fr 30/01/2008 Rapport Final 3 / 26

4 Introduction Le contexte financier Dans un milieu où les actionnaires se reposent uniquement sur l Internet pour passer leurs ordres boursiers, nous souhaitons mettre en place un système plus modulaire de gestion des portefeuilles électroniques. Il s agit de réaliser un module sécurisé de gestion de comptes en ligne, lequel sera accessible d une part via Internet, mais aussi depuis des bornes extérieures reliées au serveur central. Celles-ci permettront de garantir aux actionnaires un accès perpétuel à leur compte. L une des nouveautés de notre solution, est qu il faudra être muni d une carte à puce pour accéder à son compte et ainsi garantir la sécurité du client. Le contexte technologique Les Transactions Électroniques Sécurisées (TES) sont un enjeu fondamental et stratégique pour la société d aujourd hui et de demain. Le défi à relever est celui de la confiance et de la sécurité. Le pôle de compétitivité TES teste actuellement le paiement sans contact par téléphone portable. Nous pouvons donc imaginer les multiples applications de notre solution dans ce futur proche. Notre solution Nous avons réalisé au cours de ce Projet de Fin d Etudes, une solution complète de gestion de portefeuille électronique dont le principal objectif était de garantir la sécurité des accès et des transactions. Dans ce rapport nous allons vous donner un aperçu de notre travail tout en soulignant les technologies libres déployées. Nous commencerons d abord par vous décrire la méthodologie suivie pour la gestion du projet. Puis chaque domaine : finance, web-services, carte à puce, sera traité dans son ensemble, exposant sa réalisation et les résultats obtenus. Historique Tableau 3 Date Evènement 15/10/07 Constitution du groupe de travail 19/11/07 Soumission du sujet à l administration 22/11/07 Validation du sujet par l administration 05/12/07 Soumission du cahier des charges 02/01/07 Premier entretien avec le référant 03/01/07 Installation à l IFG 04/01/07 Début de la conception 30/01/2008 Rapport Final 4 / 26

5 Conduite de projet Méthodologie utilisée Gestion des fichiers sources : Subversion Nous avons commencé par mettre en place un serveur de sources : «Subversion». Il permet de garder un historique des changements, de travailler à plusieurs et d'organiser les versions du projet. C est un outil permettant un développement collaboratif efficace et indispensable sur des réalisations de moyenne à grande envergure. Enfin, il est très bien intégré aux principaux environnements de développement ainsi qu aux systèmes d exploitation. Gestion de projet : Maven Afin d organiser notre projet et de gérer correctement ses dépendances, nous avons choisi d utiliser le gestionnaire : «Maven». C est un outil open-source très populaire, utilisé pour la construction et le déploiement de projets Java. Il a été conçu de façon à supprimer les tâches difficiles du processus de construction. Maven utilise une approche déclarative, où le contenu et la structure du projet sont décrits, plutôt qu'une approche par tâche utilisée par exemple par Ant ou les fichiers make traditionnels. Cela aide à mettre en place des standards de développement au niveau d'une société et réduit le temps nécessaire pour l écriture et le maintien des scripts de construction et de déploiement. src/main/java: code java src/main/resources: ressources src/main/config: Les fichiers de configuration src/main/webapp: répertoir web (pour les war) src/test/java: tests unitaires src/test/resources: ressources pour les tests src/test/filters: Les filtres nécessaires aux tests unitaires, qui ne seront pas déployées Figure 1 : Arborescence src/site: Les fichiers utilisés pour générer le site web Maven s appuie sur des «cycles» de construction. Les cycles de vie des projets sont un concept central de Maven. La plupart des développeurs sont familiers avec les notions de phases de construction comme compile, test et deploy. Enfin, Maven dispose d une gestion avancée des dépendances, permettant encore une fois de simplifier la vie des développeurs, par exemple l introduction des librairies en tant que dépendances uniquement pour la phase de test. 30/01/2008 Rapport Final 5 / 26

6 Cycle en V Le modèle du cycle en V est un modèle conceptuel de gestion qui permet, en cas d'anomalie, de limiter le retour aux étapes précédentes. Les phases de la partie montante doivent renvoyer l'information sur les phases en vis-à-vis lorsque des défauts sont détectés, afin d'améliorer le logiciel. Figure 2 : Cycle en V Nous avons donc décomposé le projet en 3 parties : finance, web-services et carte à puce afin de mieux répartir les tâches entre les différents membres de l équipe. Chaque étape devant systématiquement être validée avant de poursuivre. Nous nous sommes efforcés de suivre ce modèle pour la gestion de notre projet. Les grandes phases du modèle se retrouvent donc dans notre planning prévisionnel (cf. diagramme de Gantt correspondant : Figures 3 & 4). 30/01/2008 Rapport Final 6 / 26

7 Déroulement effectif Pour rappel, nous incluons le planning prévisionnel établi lors du cahier des charges. Figure 3 : Planning prévisionnel On remarque l équilibre entre les différentes phases du projet : la recherche, la conception, la réalisation, et l intégration qui représentent une dizaine de jours chacune. Les tests interviennent sur la fin des phases de réalisation et d intégration, ce qui équivaut à une période d une dizaine de jours. Figure 4 : Planning effectif Nous avons globalement suivi le planning prévu, seules les phases d intégration et la période des tests associés ont duré 2 jours de plus. Cela provient du fait que pour notre projet, nous avions de nombreux modules à faire communiquer. 30/01/2008 Rapport Final 7 / 26

8 Réalisation Partie financière Notre but est dans un premier temps de réaliser un fichier Excel comprenant les fonctions de calcul d espérance et de variance pour notre portefeuille d actions (sujet de M. Rakotodrasimba). Nous avons choisi d adapter ce sujet dans notre propre projet. Il s agit ensuite de réaliser la gestion du portefeuille au travers d une interface web sécurisée. Le portefeuille d actions pourra être enfin exporté au format Excel. Difficultés et solutions mises en place Dans un premier temps, nous avons dû analyser les documents que M. Rakotodrasimba nous avait fournis afin de réaliser l étude du sujet proposé. Le problème rencontré à ce niveau était d assimiler les formules essentielles aux calculs de l espérance et de la variance du rendement. Pour y remédier, nous avons été aidés par M. Rakotodrasimba qui à plusieurs reprises nous a donné les indications relatives aux formules. Schéma entité/relation Voici le schéma utilisé lors de la modélisation de la base de données commune aux différentes parties du projet. Figure 5 : Diagramme de classe UML du modèle BDD 30/01/2008 Rapport Final 8 / 26

9 Modélisation UML La bibliothèque de la librairie finance respecte le diagramme de classes UML suivant. Figure 6 : Diagramme UML pour la librairie finance Spécifications de la librairie La librairie qui a été développée en java peut être réutilisée dans d autres applications. Elle permet de calculer l espérance et la variance d un portefeuille d actions contenant une ou plusieurs lignes d actions (une ligne correspond à l achat d une certaine quantité d une même action, à un prix moyen pondéré ; il peut y avoir plusieurs prix d achat). La classe Return de la librairie permet de créer un objet contenant les données permettant de calculer l espérance et la variance : initialwealth : la liquidité initiale initialprices : un tableau du prix d achat de chaque action numbers : un tableau du nombre d actions achetées drifts : un tableau des moyennes de la variation annuelle volatilities : un tableau d écart-type sur la variation annuelle correlations : une matrice de corrélation entre chaque action rate : le taux d intérêt sans risque maturity : le nombre de jour rapporté à l année d investissement transactioncost : un tableau de frais de transaction La méthode getexpectedvaluewithfees() permet de calculer et de retourner la valeur de l espérance du portefeuille suivant la formule suivante : 30/01/2008 Rapport Final 9 / 26

10 La méthode getexpectedvaluefreefees() correspond à la formule ci-dessus avec des frais de transactions nuls. La méthode getvariancewithfees() retourne la valeur de la variance pour un portefeuille d actions avec frais de transactions suivant la formule suivante : La méthode getvariancefreefees() correspond à la formule ci-dessus avec des frais de transactions nuls. Les autres méthodes sont des sous-calculs entrant dans les calculs de l espérance et de la variance. La classe Exposure représente l exposition de chaque ligne du portefeuille. L utilisateur fixe le pourcentage maximum que sa ligne peut atteindre par rapport à la valeur totale du portefeuille. La méthode geteffectiveexposureforeachline() retourne l exposition réelle de chaque ligne. L interface FinalPrice représente la façon dont doit être exprimé le calcul du prix final anticipé. La classe FinalPriceBS implémente l interface FinalPrice et permet de calculer le prix final de l action à partir du prix initial, du drift (moyenne), de la volatilité (écart-type) et de la maturité. La méthode getexpectedfinalpriceamount() utilise la formule de Black & Scholes et la méthode getexpectedfinalprice() utilise la méthode de Monte Carlo. La classe FinalWealth représente le montant final des liquidités à la date de maturité du portefeuille. La classe InitialWealth représente les liquidités initiales avant d investir. La méthode getremainingcash() retourne la liquidité restante après avoir investi. La classe NumberMax permet de calculer le nombre maximum d actions que l utilisateur peut acheter en fonction de l exposition qu il a lui-même spécifiée avec les frais (getnumbermax ForOneStock()) ou sans les frais de transactions (getnumbermaxforonestockwithout TransactionCosts()). L interface TransactionCost représente la façon dont doivent être implémentés les frais de transactions dans une classe. 30/01/2008 Rapport Final 10 / 26

11 Résultats Deux systèmes ont été développés pour répondre au sujet. Dans un premier temps, nous avons réalisé un fichier Excel contenant des fonctions personnalisées permettant de calculer l espérance et la variance du portefeuille d actions. Ces fonctions ont été développées à l aide de VBA (Visual Basic For Application), langage de programmation donnant la possibilité de créer des programmes au sein de fichier Excel. Cela permet d automatiser les calculs répétitifs. Le fichier se transforme ainsi en une véritable application. Figure 7 : interface du fichier Excel Le fichier Excel présente une interface simpliste. Une première feuille permet d insérer des actions et de paramétrer le drift (moyenne) et la volatilité (écart-type). La deuxième correspond aux frais de transaction variable suivant le montant d achat ou de vente. La troisième feuille permet de paramétrer les corrélations entre les différentes actions. La dernière présente l interface du portefeuille. Le grand tableau résume les positions de chaque ligne : le prix d achat, l exposition, l exposition effective, le nombre maximum d actions que l on peut acheter sans frais de transaction et avec frais de transaction, le nombre effectivement acheté, le prix final simulé à l aide de Monte Carlo ou Black & Scholes, le prix total de vente et les frais de transactions de vente. La case Remaining Cash montre le montant des liquidités restantes. Le second tableau jaune décrit les paramètres du portefeuille : la liquidité initiale, la maturité qui correspond au nombre de jours d investissement divisé par le nombre de jours annuels et le taux d intérêt sans risque. Le premier tableau bleu calcule l espérance, la variance et le risque pour un portefeuille sans et avec frais de transaction. Le second tableau bleu calcule les ratios d espérance et de variance. Le bouton Calculer permet de relancer les calculs lorsque les données ont été modifiées. 30/01/2008 Rapport Final 11 / 26

12 Nous avons ensuite porté l application Excel dans une application java pouvant être intégrée au sein d un site web. La version web donne plus de liberté de personnalisation de l interface et une plus grande ergonomie. La possibilité d exporter le portefeuille au format Excel, sera laissée à l appréciation de l utilisateur. Figure 8 : Interface de gestion du portefeuille d actions Figure 9 : Représentation graphique de la répartition des placements Figure 10 : Exportation du portefeuille d actions 30/01/2008 Rapport Final 12 / 26

13 Partie web-services Modèle Vue Contrôleur : Struts Il s agit d une architecture logicielle qui sépare le modèle de données applicatif, le contrôle logique et l interface utilisateur (Vue) en 3 composants distincts. Ainsi les modifications des vues peuvent être réalisées avec un impact minimal sur le modèle de données. Le contrôle logique est implémenté par les servlets ; Les vues sont générées par les Java Server Pages ; Le modèle est managé par Java Beans. Figure 11 : Modèle MVC 1. Le Servlet reçoit et analyse la requête du client ; 2. Il communique avec le modèle de données applicatif ; 3. Interrogation et/ou mise à jour de la base de données ; 4. Il transmet contrôle et données à la JSP, qui génère la vue ; 5. La JSP communique avec le modèle de données ; 6. La vue est retournée au client. Afin de respecter cette architecture, nous avons décidé d utiliser le framework «Struts». Cette infrastructure permet la conception et l'implémentation d'applications Web de taille importante. Les designers, développeurs de composants logiciels peuvent ainsi gérer leur propre part du projet de manière découplée. Il introduit une certaine complexité, mais Struts montre toute sa puissance dans des applications d'une certaine envergure. Nous allons maintenant aborder la persistance des données et le module associé : «Hibernate». Persistance : Hibernate & PostGreSQL Le terme «persistance de données» en informatique se réfère au mécanisme responsable de la sauvegarde et la restauration de données. La notion d Object Relational Mapping (ORM), y est également très souvent associée : il s agit d une technique permettant de faire correspondre des objets, des tables et leurs relations dans une base de données relationnelle. 30/01/2008 Rapport Final 13 / 26

14 Hibernate est le framework open-source Java utilisé pour gérer la persistance des données des différents systèmes développés lors de ce projet. Ce framework est très largement utilisé, tant dans le domaine de l entreprise que dans les différents projets open-source. Il sert également de base à l'implémentation des java beans de Sun. Dans notre architecture, «Hibernate» sera associé au Système de Gestion de Base de Données (SGBD) : «PostgreSQL». Il s agit là encore d un SGBD Open-Source qui a une excellente réputation auprès des programmeurs. Tests unitaires : JUnit Les tests unitaires permettent de s'assurer du fonctionnement correct d'une partie déterminée d un logiciel. Il s agit de tester un module indépendamment du reste du programme, ceci afin de s'assurer qu'il répond aux spécifications et qu'il fonctionne correctement en toutes circonstances. Cette vérification est essentielle dans certains domaines dits critiques, comme celui de la sécurité. Cela permet également de s assurer tout au long du processus de développement que les différents changements d implémentation répondent encore aux spécifications. JUnit est la librairie Java de référence en ce qui concerne les tests unitaires. Elle est couramment utilisée dans tout type d application Java. Elle s intègre parfaitement avec des outils de gestion de projet tel Maven 2. Nous poursuivrons par l exposé de notre configuration réseau. Architecture réseau Afin de simplifier la gestion des serveurs, nous avons décidé de profiter des atouts de la virtualisation. Nous avons donc implémenté un serveur VMWare Linux sur une Dédibox mise à notre disposition pour les besoins du projet. Sur ce serveur, nous avons virtualisé un réseau local (LAN) avec une passerelle d accès à l Internet ainsi deux machines PC1 et PC2. Figure 12 : Architecture serveurs virtuels 30/01/2008 Rapport Final 14 / 26

15 Comme vous pouvez le constater sur la figure 12, les machines PC1 et PC2 sécurisent leurs échanges en utilisant le cryptage IPSec. Le tutoriel élaboré pour ce projet est disponible en annexe. Le PC1 héberge l autorité de certification ainsi qu un servlet dispensant un service Web d authentification. Le PC2 héberge la base de données du projet et les servlets liés à la partie finance. Les ressources de la Dédibox ne sont pas uniquement employées pour le serveur de virtualisation, mais aussi pour l hébergement du serveur de sources du projet. L organisation du réseau privé virtuel est agencée selon le schéma de la figure 13. Figure 13 : Plage d adressage IP Pour accéder aux services Web des machines virtuelles PC1 et PC2, il nous a fallu rediriger les ports 80 et 81 de la Dédibox sur leur port 80. Afin de pouvoir configurer les serveurs depuis l extérieur, nous avons aussi dû router les ports 2425 & 2426 de la Dédibox sur les ports 22 (SSH) de PC1 et PC2. Un récapitulatif des ports routés vous est proposé dans le tableau 4. Tableau 4 : Routage des ports IP Source Port Source IP Destination Port Destination Légende Accès SSH PC Accès SSH PC Accès Web PC Accès Web PC2 Avant de se lancer dans la réalisation de la console d administration des utilisateurs, nous l avons modélisé en UML. 30/01/2008 Rapport Final 15 / 26

16 Modélisation UML Voici le diagramme UML de la console d administration, celui-ci respectant l architecture logicielle du modèle Vue Contrôleur. Figure 14 : Diagramme MVC, Console d'administration Console d administration Figure 15 : Authentification Page Cette console permet de gérer les comptes utilisateurs. Les administrateurs doivent s y connecter via l intranet (LAN). Elle est protégée par une authentification par clé de session, aussi, l accès à la console d administration est limité à une liste restreinte de gestionnaires dont l adresse IP a été préalablement enregistrée. 30/01/2008 Rapport Final 16 / 26

17 Figure 16 : List all admins page Tout utilisateur dont l IP ne correspond pas reçoit une erreur «404 Page not found». Cela limite les tentatives d accès non autorisé. Aucune information liée aux privilèges utilisateurs n est stockée du côté client. Lors de l authentification, le mot de passe est haché en MD5, afin de ne pas transiter en clair sur le réseau. Si l identification est réussie, l administrateur est redirigé sur la page de listant les utilisateurs. Figure 17 : List all users page L administrateur a alors la possibilité de lister les administrateurs, les utilisateurs, de manager (ajouter, modifier, supprimer) des utilisateurs, et les administrateurs. Un mode de recherche est aussi mis en place afin d optimiser les requêtes. Figure 18 : User search page 30/01/2008 Rapport Final 17 / 26

18 Partie carte à puce & Web Service d Authentification A l heure où l Internet est accessible par bon nombre de personnes, il s est développé une multitude de services où tout un chacun peut stocker ou consulter ses informations personnelles et cela partout dans le monde. Cependant, Internet n offre pas d emblée un réseau sécurisé où la vie privée est protégée par défaut. Une question émerge alors tout naturellement : comment assurer entre les utilisateurs et les services Web une connexion entièrement sécurisée dans un contexte où la personne doit d abord s authentifier auprès d un système d authentification Web de manière forte et sécurisée quelque soit l endroit où il se situe? La génération actuelle des cartes à puces, appelées Smart Card, embarque des outils cryptographiques puissants. Alors que nous avons pour habitude de simplement nous connecter avec un identifiant et un mot de passe, la Smart Card nous offre la possibilité d établir un protocole d authentification mutuelle avec le système d authentification Web. Nous allons donc vous présenter un système d authentification sécurisée par carte à puce, où cette dernière s authentifie mutuellement avec un système d authentification Web. Architecture générale Figure 19 : Architecture du WSA Le système WSA est divisé en trois composants principaux : Le web service d authentification : «WSCAS» Le terminal client : «JWSA» La javacard : «Cyberflex e-gate 32k» Le web service «WSCAS» permet d authentifier les utilisateurs sur un site web à l aide de leur carte à puce. Pour ce faire, une authentification mutuelle entre la javacard du client et le web service est réalisée. L application terminale est nécessaire pour faire le lien entre le web service et la carte à puce. Elle gère les trames APDU au niveau du lecteur de carte et la connexion SSL avec le web service. L interface graphique niveau utilisateur est rendue dans le navigateur par cette même application. Ceci permet une transparence totale au niveau de son utilisation. En effet, pour 30/01/2008 Rapport Final 18 / 26

19 s authentifier sur un site web, le client sera guidé au sein de son navigateur afin de réaliser les différentes étapes du processus. Pour s authentifier, le client doit tout d abord se rendre sur son site web. Il est alors invité à lancer l application terminale «JWSA» (si cela n était pas déjà fait). Une fois celle-ci en place, il est redirigé en local sur celle-ci dans son navigateur. L application commence alors l authentification mutuelle entre la carte du client et le web service. A la fin de cette procédure, l application terminale redirige l utilisateur sur le site web en passant en paramètre une clé de session. L utilisateur est alors authentifié. Protocole d authentification mutuelle L authentification mutuelle se déroule selon les étapes suivantes : Début de l authentification mutuelle 1. Etablissement de la connexion SSL Le client et le serveur établissent une connexion SSL entre eux. A cette étape, le client et le serveur ne peuvent pas encore se faire confiance. Cette étape permet l échange de messages chiffrés entre les deux pairs. Authentification du serveur auprès du client 2. Le client envoie un challenge au serveur Le challenge est un message généré aléatoirement par le client. Il est attendu du serveur qu il signe le challenge envoyé avec sa clé privée. 3. Le client récupère la signature du serveur Le client vérifie la signature serveur avec la clé publique de celui-ci. La signature doit correspondre au challenge précédemment envoyé. A cette étape, le client peut faire confiance au serveur. Authentification du client auprès du serveur 4. Le client envoie sa clé publique au serveur Le serveur ne connaît pas encore l identité du client, cette étape permet au serveur de connaitre l identité du client à vérifier en fonction de la clé reçue. 5. Le serveur envoi un challenge au client Le challenge est un message généré aléatoirement par le serveur. Il est attendu du client qu il signe le challenge envoyé avec sa clé privée. 6. Le serveur récupère la signature du client Le serveur vérifie la signature client avec la clé publique de celui-ci (reçue à l étape 4). La signature doit correspondre au challenge précédemment envoyé. A cette étape, le serveur peut faire confiance au client. 30/01/2008 Rapport Final 19 / 26

20 La technologie Java Card La Java Card est une carte à puce (aussi appelée Smart Card) capable d exécuter des applications écrites en langage Java et dans laquelle on a embarqué une machine virtuelle Java conçue pour fonctionner dans un environnement aux capacités limitées. Figure 20 : Architecture Java Card Une Smart Card se voit implémenter une plateforme Java Card contenant : l API Java Card, la Java Card Runtime Environment et la Java Card Virtual Machine. Cette plateforme fait l interface entre le système d exploitation de la Smart Card et les applications chargées dans la carte. Fonctionnalités L utilisateur a besoin de s authentifier afin d accéder de manière sécurisée à son compte personnel en ligne, et ceci quelque soit l endroit où il se trouve. L utilisateur doit pouvoir accéder à partir de son ordinateur, muni d'un lecteur de carte à puce, à un site Internet à contrôle d accès sécurisé. Le site distant et la carte à puce devront être authentifiés mutuellement avant d autoriser l accès. Une fois authentifié, le client recevra une clé de session lui permettant d accéder à ses comptes en ligne. Nous mettrons en place un protocole d authentification mutuelle entre la Java Card et le service Web. Par conséquent, l établissement d un protocole d authentification mutuelle nous oriente vers une Java Card contenant comme fonctionnalités : o Un module de génération de nombres aléatoires; o Un module cryptographique pour la signature et la vérification de nombres aléatoire. Nous nous orienterons vers l algorithme asymétrique RSA à clé 1024 bits ; o La gestion du code Pin. 30/01/2008 Rapport Final 20 / 26

21 Sélection de la Java Card Notre choix s est porté sur la Java Card Cyberflexe e-gate 32K. Celle-ci est implémentée sur la plateforme JavaCard et est conforme à la spécification Global Platform Cette carte gère la signature et la vérification RSA avec une clé de longueur maximale de 1024 bits. Elle contient notamment des algorithmes symétriques de chiffrement DES et triple DES ainsi que la fonction de Hashage SHA. Le support PIN est aussi implémenté avec un nombre d essais paramétrable. Service d authentification par certificat Le web service «WSCAS» permet d authentifier les utilisateurs sur un site web à l aide de leur carte à puce. Ce web service d authentification a été conçu pour être utilisable par n importe quel site web, et n importe quel client («Terminal»). Totalement indépendant des autres briques du système d authentification «WSA», il s appuie sur un protocole d échanges simple et interopérable et ne stocke que les clés publiques des clients potentiellement authentifiables. Par souci d interopérabilité, l utilisation du langage XML1 a été choisie. Cela permet de ne pas restreindre l écriture de client ou de site web supportant notre système au seul langage Java. Modélisation Le diagramme de séquence ci-dessous illustre le cheminement menant à l authentification, en suivant le schéma d authentification mutuelle, en y présentant les actions de chacune des parties. 30/01/2008 Rapport Final 21 / 26

22 Figure 21 : Diagramme de séquence du WSCAS Processus Le fonctionnement général de l authentification mutuelle a été détaillé plus haut. Le diagramme ci-dessus correspond à l implémentation effectué dans le cadre du développement du service web d authentification. Cette implémentation se décompose en six principales étapes au niveau du service web. Voici une description rapide du point de vue du service web : 1. Initialisation : le site web initialise l authentification en envoyant toutes les informations nécessaires à l identification de l utilisateur lorsque l authentification sera terminée. 2. Obtention d informations : le client vérifie la disponibilité du service web, et en profite pour en récupérer les différentes informations qui lui sont nécessaires. C est également à cette étape que le web service pourrait vérifier que le certificat «wscas» que détient le client n est pas expiré (non implémenté dans le cadre du ce projet). 30/01/2008 Rapport Final 22 / 26

23 3. Signature du nombre aléatoire : le service web signe le nombre aléatoire que le client lui envoie et lui retourne la signature ainsi obtenue. Cette étape pourrait être facultative. 4. Génération d un nombre aléatoire : le client demande au service web de générer un nombre aléatoire qu il signera ensuite. Le client envoie également l identifiant de sa clé, pour que le service web puisse vérifier qu il est bien dans sa base de données utilisateurs agréés à être authentifiés. 5. Vérification de la signature du client : le service web vérifie la signature du client. Si elle est bonne, le client est valide, et considéré comme authentifié. 6. Vérification du client : Le site web fait la demande au service web pour savoir si le client est authentifié. Chaque «session d authentification» est identifié par une clé de session, unique et temporaire, qui est communiqué entre le client et le service web. Détail d implémentation Le service web se décompose en deux «sous service web». Les échanges entre ces deux services web, ainsi qu entre le service web privé et le site web, se font à travers un canal sécurisé, avec les protocoles IPSec. Cela a pour effet de protéger les étapes sensibles, comme l initialisation du processus d authentification, qui se fait ainsi au sein du réseau de confiance. Le «wscas public» est ouvert sur internet, contrairement au «wscas privé». Les trois étapes effectuées entre le «wscas privé» et le «wscas public» sont les suivantes : 1. Récupérer l initialisation provenant du service web privé : lors de l étape de prise d information de l utilisateur, le service web public récupère l objet initialisation transmis au service web privé pour initier le processus d authentification de son côté. 2. Envoyer l alias au service web privé : Le service web public envoie l alias de l utilisateur au service web privé pour qu au terme de l authentification cet alias soit retransmis au site web. 3. Envoyer la vérification au service web privé : Le service web public a authentifié le client, il transmet l objet vérification qui permettra au site web de vérifier que le client est bien authentifié par le CAS. 30/01/2008 Rapport Final 23 / 26

24 Objets Le protocole se base sur un échange d objets, nommé SecureXmlMessage, sérialisé3 en XML. Cet objet est la base de tous les messages transitant entre les différentes parties (client, service web et site web). La forme générale, sérialisée de cet objet est la suivante : <message> <id>t+pkgjll0stfrsadalctz6wq14zuvfrunqfzgbajclfj7x6appeqn8mmhhxpocc70kvwrgieg9rk9yctv WAXqaTyR6K7Z40PAJPmE1PW8dDhS9ziUiXcPGETzSmoeKhANAYt2xgyTFlO2Vo0qEuqsAQTncUbp1eoq6TJjZ msahs=</id> <sessionkey>twzr0dtndaqmsliulydg3dvmtn2vx6dzivagjqfqb+wlzhyr2oejvgxseodmjz58bonzeykuc KEIs4GNdIrfrn7N9Q5E3vQ9nGMk+hM+lYG/Sx97OaSx14T+MPF7siC8dx2xadZ8BzT4uXD8Lz2yUnzxaeu31g JZNk7J43bqG2s=</sessionKey> <object class="infos"> <!-- Serialized object --> </object> </message> Figure 22 : Sérialisation L alias de l objet SecureXmlMessage est «message». Les attributs sont les suivants : Id : un tableau de byte, encodé en base 64. sessionkey : la clé de session permettant de suivre le processus d authentification. object : l objet attaché en fonction de l étape du processus décrits ci-dessous. 30/01/2008 Rapport Final 24 / 26

25 Conclusion Le résultat final répond parfaitement aux objectifs du cahier des charges. En effet, les critères de maniabilité du site web client, de sécurité des accès, des transactions, et de fiabilité des calculs de la librairie finance sont atteints. Il nous faut maintenant étudier le coût du déploiement de bornes de connexions publiques, afin de répandre l usage de notre produit. Pour plus de sécurité, nous pourrions envisager une évolution de la console d administration intégrant des logs sur l activité des utilisateurs couvrant les opérations majeures affectant la base de données. Une entreprise qui reprendrait notre architecture devrait mettre en place un système de sauvegarde périodique de la base de données. De nombreuses applications pour notre système d authentification par carte à puce sont imaginables. La prochaine carte d identité électronique étudie d ailleurs la possibilité d intégrer une clé d authentification comme moyen de sécurisation des transactions. Les thèmes de finance et de sécurité sont d actualité quelques jours après l arrestation et la mise en examen d un trader pour la perte dissimulée de plusieurs milliards d actions au sein d une grosse banque française. Dans cette affaire, les dispositifs de surveillance et de sécurisation des transactions auraient été inefficaces. Il reste donc de nombreux terrains de réflexion à explorer. Ces dernières années, nous pouvons tout de même remarquer une certaine prise de conscience de la part des grands groupes industriels, répondant aux recommandations de la Direction Centrale de la Sécurité des Systèmes d Informations (DCSSI). La fonction de Responsable de la Sécurité des Systèmes d Information (RSSI) a donc un bel avenir! 30/01/2008 Rapport Final 25 / 26

26 Annexes Tableau 5 Numéro Nom du fichier Description 1 Présentation-Admin.pdf Présentation du sujet & équipe PFE 2 Cahier-des-charges.pdf Cahier des charges 3 Abstract-Fr.pdf Résumé du projet en Français 4 Abstract-En.pdf Résumé du projet en Anglais 5 Tutoriel IPSec.pdf Tutoriel sur la mise en place IPSec 6 Wsa.pdf 7 8 Complément d informations sur la carte à puce et le Web Service Authentification 30/01/2008 Rapport Final 26 / 26