PFE

ALCINOOS Gestion de portefeuille lectronique par carte puce

Equipe N 16 Projet N 98 Sujet non industriel propos par les lves

ALCINOOS

PFE ING 2008

Sommaire
Introduction ....................................................................................................................................................................................................... 4 Le contexte financier .................................................................................................................................................................................... 4 Le contexte technologique ........................................................................................................................................................................... 4 Notre solution .............................................................................................................................................................................................. 4 Historique ..................................................................................................................................................................................................... 4 Conduite de projet ............................................................................................................................................................................................. 5 Mthodologie utilise .................................................................................................................................................................................. 5 Gestion des fichiers sources : Subversion ............................................................................................................................................... 5 Gestion de projet : Maven ...................................................................................................................................................................... 5 Cycle en V ................................................................................................................................................................................................ 6 Droulement effectif .................................................................................................................................................................................... 7 Ralisation ......................................................................................................................................................................................................... 8 Partie financire ........................................................................................................................................................................................... 8 Difficults et solutions mises en place .................................................................................................................................................... 8 Schma entit/relation ........................................................................................................................................................................... 8 Modlisation UML ................................................................................................................................................................................... 9 Spcifications de la librairie..................................................................................................................................................................... 9 Rsultats ............................................................................................................................................................................................... 11 Partie web-services .................................................................................................................................................................................... 13 Modle Vue Contrleur : Struts ............................................................................................................................................................ 13 Persistance : Hibernate & PostGreSQL .................................................................................................................................................. 13 Tests unitaires : JUnit ............................................................................................................................................................................ 14 Architecture rseau............................................................................................................................................................................... 14 Modlisation UML ................................................................................................................................................................................. 16 Console dadministration ...................................................................................................................................................................... 16 Partie carte puce & Web Service dAuthentification ............................................................................................................................... 18 Architecture gnrale ........................................................................................................................................................................... 18 Protocole dauthentification mutuelle .................................................................................................................................................. 19 La technologie Java Card ....................................................................................................................................................................... 20 Fonctionnalits...................................................................................................................................................................................... 20 Slection de la Java Card ....................................................................................................................................................................... 21 Service dauthentification par certificat ................................................................................................................................................ 21 Modlisation ......................................................................................................................................................................................... 21 Processus .............................................................................................................................................................................................. 22 Dtail dimplmentation ....................................................................................................................................................................... 23 Objets .................................................................................................................................................................................................... 23 Conclusion ....................................................................................................................................................................................................... 25 Annexes ........................................................................................................................................................................................................... 26

30/01/2008

Rapport Final

2 / 26

ALCINOOS

PFE ING 2008

Cadre administratif

Projet
N 98 ALCINOOS : Gestion de portefeuille lectronique par carte puce

Equipe
N 16
Tableau 1

Nom Aucher Barry Demester Franois-Elie Lau Pinsonneau Zanchetta

Prnom Arnaud Aguibou Vincent Cdric Anthony Rmy Cdric

Majeure SI Tech. Info SE SI Tech. Info SI Finance SI Finance SI Tech. Info SI Finance

Email aucher@ece.fr barry@ece.fr vdemeest@ece.fr cfrancoi@ece.fr lau@ece.fr pinsonne@ece.fr zanchett@ece.fr

Note Chef de projet

Rfrent

Tableau 2

Nom Bonnet

Prnom Jean-Franois

Email bonnetjf@ece.fr

30/01/2008

Rapport Final

3 / 26

ALCINOOS

PFE ING 2008

Introduction
Le contexte financier
Dans un milieu o les actionnaires se reposent uniquement sur lInternet pour passer leurs ordres boursiers, nous souhaitons mettre en place un systme plus modulaire de gestion des portefeuilles lectroniques. Il sagit de raliser un module scuris de gestion de comptes en ligne, lequel sera accessible dune part via Internet, mais aussi depuis des bornes extrieures relies au serveur central. Celles-ci permettront de garantir aux actionnaires un accs perptuel leur compte. Lune des nouveauts de notre solution, est quil faudra tre muni dune carte puce pour accder son compte et ainsi garantir la scurit du client.

Le contexte technologique
Les Transactions lectroniques Scurises (TES) sont un enjeu fondamental et stratgique pour la socit daujourdhui et de demain. Le dfi relever est celui de la confiance et de la scurit. Le ple de comptitivit TES teste actuellement le paiement sans contact par tlphone portable. Nous pouvons donc imaginer les multiples applications de notre solution dans ce futur proche.

Notre solution
Nous avons ralis au cours de ce Projet de Fin dEtudes, une solution complte de gestion de portefeuille lectronique dont le principal objectif tait de garantir la scurit des accs et des transactions. Dans ce rapport nous allons vous donner un aperu de notre travail tout en soulignant les technologies libres dployes. Nous commencerons dabord par vous dcrire la mthodologie suivie pour la gestion du projet. Puis chaque domaine : finance, web-services, carte puce, sera trait dans son ensemble, exposant sa ralisation et les rsultats obtenus.

Historique
Tableau 3

Date 15/10/07 19/11/07 22/11/07 05/12/07 02/01/07 03/01/07 04/01/07 30/01/2008

Evnement Constitution du groupe de travail Soumission du sujet ladministration Validation du sujet par ladministration Soumission du cahier des charges Premier entretien avec le rfrant Installation lIFG Dbut de la conception Rapport Final 4 / 26

ALCINOOS

PFE ING 2008

Conduite de projet
Mthodologie utilise
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. Cest un outil permettant un dveloppement collaboratif efficace et indispensable sur des ralisations de moyenne grande envergure. Enfin, il est trs bien intgr aux principaux environnements de dveloppement ainsi quaux systmes dexploitation. Gestion de projet : Maven Afin dorganiser notre projet et de grer correctement ses dpendances, nous avons choisi dutiliser le gestionnaire : Maven . Cest un outil open-source trs populaire, utilis pour la construction et le dploiement de projets Java. Il a t conu de faon supprimer les tches difficiles du processus de construction. Maven utilise une approche dclarative, o le contenu et la structure du projet sont dcrits, plutt qu'une approche par tche utilise par exemple par Ant ou les fichiers make traditionnels. Cela aide mettre en place des standards de dveloppement au niveau d'une socit et rduit le temps ncessaire pour lcriture et le maintien des scripts de construction et de dploiement.

src/main/java: code java src/main/resources: ressources src/main/config: Les fichiers de configuration src/main/webapp: rpertoir web (pour les war) src/test/java: tests unitaires src/test/resources: ressources pour les tests src/test/filters: Les filtres ncessaires aux tests unitaires, qui ne seront pas dployes src/site: Les fichiers utiliss pour gnrer le site web
Figure 1 : Arborescence

Maven sappuie sur des cycles de construction. Les cycles de vie des projets sont un concept central de Maven. La plupart des dveloppeurs sont familiers avec les notions de phases de construction comme compile, test et deploy. Enfin, Maven dispose dune gestion avance des dpendances, permettant encore une fois de simplifier la vie des dveloppeurs, par exemple lintroduction des librairies en tant que dpendances uniquement pour la phase de test.

30/01/2008

Rapport Final

5 / 26

ALCINOOS

PFE ING 2008

Cycle en V Le modle du cycle en V est un modle conceptuel de gestion qui permet, en cas d'anomalie, de limiter le retour aux tapes prcdentes. Les phases de la partie montante doivent renvoyer l'information sur les phases en vis--vis lorsque des dfauts sont dtects, afin d'amliorer le logiciel.

Figure 2 : Cycle en V

Nous avons donc dcompos le projet en 3 parties : finance, web-services et carte puce afin de mieux rpartir les tches entre les diffrents membres de lquipe. Chaque tape devant systmatiquement tre valide avant de poursuivre. Nous nous sommes efforcs de suivre ce modle pour la gestion de notre projet. Les grandes phases du modle se retrouvent donc dans notre planning prvisionnel (cf. diagramme de Gantt correspondant : Figures 3 & 4).

30/01/2008

Rapport Final

6 / 26

ALCINOOS

PFE ING 2008

Droulement effectif
Pour rappel, nous incluons le planning prvisionnel tabli lors du cahier des charges.

Figure 3 : Planning prvisionnel

On remarque lquilibre entre les diffrentes phases du projet : la recherche, la conception, la ralisation, et lintgration qui reprsentent une dizaine de jours chacune. Les tests interviennent sur la fin des phases de ralisation et dintgration, ce qui quivaut une priode dune dizaine de jours.

Figure 4 : Planning effectif

Nous avons globalement suivi le planning prvu, seules les phases dintgration et la priode des tests associs 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

ALCINOOS

PFE ING 2008

Ralisation
Partie financire
Notre but est dans un premier temps de raliser un fichier Excel comprenant les fonctions de calcul desprance et de variance pour notre portefeuille dactions (sujet de M. Rakotodrasimba). Nous avons choisi dadapter ce sujet dans notre propre projet. Il sagit ensuite de raliser la gestion du portefeuille au travers dune interface web scurise. Le portefeuille dactions pourra tre enfin export au format Excel.

Difficults et solutions mises en place Dans un premier temps, nous avons d analyser les documents que M. Rakotodrasimba nous avait fournis afin de raliser ltude du sujet propos. Le problme rencontr ce niveau tait dassimiler les formules essentielles aux calculs de lesprance et de la variance du rendement. Pour y remdier, nous avons t aids par M. Rakotodrasimba qui plusieurs reprises nous a donn les indications relatives aux formules.

Schma entit/relation Voici le schma utilis lors de la modlisation de la base de donnes commune aux diffrentes parties du projet.

Figure 5 : Diagramme de classe UML du modle BDD

30/01/2008

Rapport Final

8 / 26

ALCINOOS

PFE ING 2008

Modlisation UML La bibliothque de la librairie finance respecte le diagramme de classes UML suivant.

Figure 6 : Diagramme UML pour la librairie finance

Spcifications de la librairie La librairie qui a t dveloppe en java peut tre rutilise dans dautres applications. Elle permet de calculer lesprance et la variance dun portefeuille dactions contenant une ou plusieurs lignes dactions (une ligne correspond lachat dune certaine quantit dune mme action, un prix moyen pondr ; il peut y avoir plusieurs prix dachat). La classe Return de la librairie permet de crer un objet contenant les donnes permettant de calculer lesprance et la variance :
initialWealth : la liquidit initiale initialPrices : un tableau du prix dachat de chaque action numbers : un tableau du nombre dactions achetes drifts : un tableau des moyennes de la variation annuelle volatilities : un tableau dcart-type sur la variation annuelle correlations : une matrice de corrlation entre chaque action rate : le taux dintrt sans risque maturity : le nombre de jour rapport lanne dinvestissement transactionCost : un tableau de frais de transaction

La mthode getExpectedValueWithFees() permet de calculer et de retourner la valeur de lesprance du portefeuille suivant la formule suivante :

30/01/2008

Rapport Final

9 / 26

ALCINOOS

PFE ING 2008

La mthode getExpectedValueFreeFees() correspond la formule ci-dessus avec des frais de transactions nuls. La mthode getVarianceWithFees() retourne la valeur de la variance pour un portefeuille dactions avec frais de transactions suivant la formule suivante :

La mthode getVarianceFreeFees() correspond la formule ci-dessus avec des frais de transactions nuls. Les autres mthodes sont des sous-calculs entrant dans les calculs de lesprance et de la variance. La classe Exposure reprsente lexposition de chaque ligne du portefeuille. Lutilisateur fixe le pourcentage maximum que sa ligne peut atteindre par rapport la valeur totale du portefeuille. La mthode getEffectiveExposureForEachLine() retourne lexposition relle de chaque ligne. Linterface FinalPrice reprsente la faon dont doit tre exprim le calcul du prix final anticip. La classe FinalPriceBS implmente linterface FinalPrice et permet de calculer le prix final de laction partir du prix initial, du drift (moyenne), de la volatilit (cart-type) et de la maturit. La mthode getExpectedFinalPriceAmount() utilise la formule de Black & Scholes et la mthode getExpectedFinalPrice() utilise la mthode de Monte Carlo. La classe FinalWealth reprsente le montant final des liquidits la date de maturit du portefeuille. La classe InitialWealth reprsente les liquidits initiales avant dinvestir. La mthode getRemainingCash() retourne la liquidit restante aprs avoir investi. La classe NumberMax permet de calculer le nombre maximum dactions que lutilisateur peut acheter en fonction de lexposition quil a lui-mme spcifie avec les frais (getNumberMax ForOneStock()) ou sans les frais de transactions (getNumberMaxForOneStockWithout TransactionCosts()). Linterface TransactionCost reprsente la faon dont doivent tre implments les frais de transactions dans une classe.

30/01/2008

Rapport Final

10 / 26

ALCINOOS

PFE ING 2008

Rsultats Deux systmes ont t dvelopps pour rpondre au sujet. Dans un premier temps, nous avons ralis un fichier Excel contenant des fonctions personnalises permettant de calculer lesprance et la variance du portefeuille dactions. Ces fonctions ont t dveloppes laide de VBA (Visual Basic For Application), langage de programmation donnant la possibilit de crer des programmes au sein de fichier Excel. Cela permet dautomatiser les calculs rptitifs. Le fichier se transforme ainsi en une vritable application.

Figure 7 : interface du fichier Excel

Le fichier Excel prsente une interface simpliste. Une premire feuille permet dinsrer des actions et de paramtrer le drift (moyenne) et la volatilit (cart-type). La deuxime correspond aux frais de transaction variable suivant le montant dachat ou de vente. La troisime feuille permet de paramtrer les corrlations entre les diffrentes actions. La dernire prsente linterface du portefeuille. Le grand tableau rsume les positions de chaque ligne : le prix dachat, lexposition, lexposition effective, le nombre maximum dactions que lon peut acheter sans frais de transaction et avec frais de transaction, le nombre effectivement achet, le prix final simul laide 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 liquidits restantes. Le second tableau jaune dcrit les paramtres du portefeuille : la liquidit initiale, la maturit qui correspond au nombre de jours dinvestissement divis par le nombre de jours annuels et le taux dintrt sans risque. Le premier tableau bleu calcule lesprance, la variance et le risque pour un portefeuille sans et avec frais de transaction. Le second tableau bleu calcule les ratios desprance et de variance. Le bouton Calculer permet de relancer les calculs lorsque les donnes ont t modifies.

30/01/2008

Rapport Final

11 / 26

ALCINOOS

PFE ING 2008

Nous avons ensuite port lapplication Excel dans une application java pouvant tre intgre au sein dun site web. La version web donne plus de libert de personnalisation de linterface et une plus grande ergonomie. La possibilit dexporter le portefeuille au format Excel, sera laisse lapprciation de lutilisateur.

Figure 8 : Interface de gestion du portefeuille dactions

Figure 9 : Reprsentation graphique de la rpartition des placements

Figure 10 : Exportation du portefeuille dactions

30/01/2008

Rapport Final

12 / 26

ALCINOOS

PFE ING 2008

Partie web-services
Modle Vue Contrleur : Struts Il sagit dune architecture logicielle qui spare le modle de donnes applicatif, le contrle logique et linterface utilisateur (Vue) en 3 composants distincts. Ainsi les modifications des vues peuvent tre ralises avec un impact minimal sur le modle de donnes. Le contrle logique est implment par les servlets ; Les vues sont gnres par les Java Server Pages ; Le modle est manag par Java Beans.

Figure 11 : Modle MVC

1. 2. 3. 4. 5. 6.

Le Servlet reoit et analyse la requte du client ; Il communique avec le modle de donnes applicatif ; Interrogation et/ou mise jour de la base de donnes ; Il transmet contrle et donnes la JSP, qui gnre la vue ; La JSP communique avec le modle de donnes ; La vue est retourne au client.

Afin de respecter cette architecture, nous avons dcid dutiliser le framework Struts . Cette infrastructure permet la conception et l'implmentation d'applications Web de taille importante. Les designers, dveloppeurs de composants logiciels peuvent ainsi grer leur propre part du projet de manire dcouple. 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 donnes et le module associ : Hibernate .

Persistance : Hibernate & PostGreSQL Le terme persistance de donnes en informatique se rfre au mcanisme responsable de la sauvegarde et la restauration de donnes. La notion dObject Relational Mapping (ORM), y est galement trs souvent associe : il sagit dune technique permettant de faire correspondre des objets, des tables et leurs relations dans une base de donnes relationnelle. 30/01/2008 Rapport Final 13 / 26

ALCINOOS

PFE ING 2008

Hibernate est le framework open-source Java utilis pour grer la persistance des donnes des diffrents systmes dvelopps lors de ce projet. Ce framework est trs largement utilis, tant dans le domaine de lentreprise que dans les diffrents projets open-source. Il sert galement de base l'implmentation des java beans de Sun. Dans notre architecture, Hibernate sera associ au Systme de Gestion de Base de Donnes (SGBD) : PostgreSQL . Il sagit l encore dun SGBD Open-Source qui a une excellente rputation auprs des programmeurs.

Tests unitaires : JUnit Les tests unitaires permettent de s'assurer du fonctionnement correct d'une partie dtermine dun logiciel. Il sagit de tester un module indpendamment du reste du programme, ceci afin de s'assurer qu'il rpond aux spcifications et qu'il fonctionne correctement en toutes circonstances. Cette vrification est essentielle dans certains domaines dits critiques, comme celui de la scurit. Cela permet galement de sassurer tout au long du processus de dveloppement que les diffrents changements dimplmentation rpondent encore aux spcifications. JUnit est la librairie Java de rfrence en ce qui concerne les tests unitaires. Elle est couramment utilise dans tout type dapplication Java. Elle sintgre parfaitement avec des outils de gestion de projet tel Maven 2. Nous poursuivrons par lexpos de notre configuration rseau.

Architecture rseau Afin de simplifier la gestion des serveurs, nous avons dcid de profiter des atouts de la virtualisation. Nous avons donc implment un serveur VMWare Linux sur une Ddibox mise notre disposition pour les besoins du projet. Sur ce serveur, nous avons virtualis un rseau local (LAN) avec une passerelle daccs lInternet ainsi deux machines PC1 et PC2.

Figure 12 : Architecture serveurs virtuels

30/01/2008

Rapport Final

14 / 26

ALCINOOS

PFE ING 2008

Comme vous pouvez le constater sur la figure 12, les machines PC1 et PC2 scurisent leurs changes en utilisant le cryptage IPSec. Le tutoriel labor pour ce projet est disponible en annexe. Le PC1 hberge lautorit de certification ainsi quun servlet dispensant un service Web dauthentification. Le PC2 hberge la base de donnes du projet et les servlets lis la partie finance. Les ressources de la Ddibox ne sont pas uniquement employes pour le serveur de virtualisation, mais aussi pour lhbergement du serveur de sources du projet. Lorganisation du rseau priv virtuel est agence selon le schma de la figure 13.

Figure 13 : Plage dadressage IP

Pour accder aux services Web des machines virtuelles PC1 et PC2, il nous a fallu rediriger les ports 80 et 81 de la Ddibox sur leur port 80. Afin de pouvoir configurer les serveurs depuis lextrieur, nous avons aussi d router les ports 2425 & 2426 de la Ddibox sur les ports 22 (SSH) de PC1 et PC2. Un rcapitulatif des ports routs vous est propos dans le tableau 4.

Tableau 4 : Routage des ports

IP Source 88.191.27.69 88.191.27.69 88.191.27.69 88.191.27.69

Port Source 2425 2426 80 81

IP Destination 192.168.238.130 192.168.238.131 192.168.238.130 192.168.238.131

Port Destination 22 22 80 80

Lgende Accs SSH PC1 Accs SSH PC2 Accs Web PC1 Accs Web PC2

Avant de se lancer dans la ralisation de la console dadministration des utilisateurs, nous lavons modlis en UML.

30/01/2008

Rapport Final

15 / 26

ALCINOOS

PFE ING 2008

Modlisation UML Voici le diagramme UML de la console dadministration, celui-ci respectant larchitecture logicielle du modle Vue Contrleur.

Figure 14 : Diagramme MVC, Console d'administration

Console dadministration

Figure 15 : Authentification Page

Cette console permet de grer les comptes utilisateurs. Les administrateurs doivent sy connecter via lintranet (LAN). Elle est protge par une authentification par cl de session, aussi, laccs la console dadministration est limit une liste restreinte de gestionnaires dont ladresse IP a t pralablement enregistre. 30/01/2008 Rapport Final 16 / 26

ALCINOOS

PFE ING 2008

Figure 16 : List all admins page

Tout utilisateur dont lIP ne correspond pas reoit une erreur 404 Page not found . Cela limite les tentatives daccs non autoris. Aucune information lie aux privilges utilisateurs nest stocke du ct client. Lors de lauthentification, le mot de passe est hach en MD5, afin de ne pas transiter en clair sur le rseau. Si lidentification est russie, ladministrateur est redirig sur la page de listant les utilisateurs.

Figure 17 : List all users page

Ladministrateur 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 doptimiser les requtes.

Figure 18 : User search page

30/01/2008

Rapport Final

17 / 26

ALCINOOS

PFE ING 2008

Partie carte puce & Web Service dAuthentification

A lheure o lInternet est accessible par bon nombre de personnes, il sest dvelopp une multitude de services o tout un chacun peut stocker ou consulter ses informations personnelles et cela partout dans le monde. Cependant, Internet noffre pas demble un rseau scuris o la vie prive est protge par dfaut. Une question merge alors tout naturellement : comment assurer entre les utilisateurs et les services Web une connexion entirement scurise dans un contexte o la personne doit dabord sauthentifier auprs dun systme dauthentification Web de manire forte et scurise quelque soit lendroit o il se situe ? La gnration actuelle des cartes puces, appeles 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 dtablir un protocole dauthentification mutuelle avec le systme dauthentification Web. Nous allons donc vous prsenter un systme dauthentification scurise par carte puce, o cette dernire sauthentifie mutuellement avec un systme dauthentification Web. Architecture gnrale

Figure 19 : Architecture du WSA

Le systme WSA est divis en trois composants principaux : Le web service dauthentification : WSCAS Le terminal client : JWSA La javacard : Cyberflex e-gate 32k Le web service WSCAS permet dauthentifier les utilisateurs sur un site web laide de leur carte puce. Pour ce faire, une authentification mutuelle entre la javacard du client et le web service est ralise. Lapplication terminale est ncessaire pour faire le lien entre le web service et la carte puce. Elle gre les trames APDU au niveau du lecteur de carte et la connexion SSL avec le web service. Linterface graphique niveau utilisateur est rendue dans le navigateur par cette mme application. Ceci permet une transparence totale au niveau de son utilisation. En effet, pour 30/01/2008 Rapport Final 18 / 26

ALCINOOS

PFE ING 2008

sauthentifier sur un site web, le client sera guid au sein de son navigateur afin de raliser les diffrentes tapes du processus. Pour sauthentifier, le client doit tout dabord se rendre sur son site web. Il est alors invit lancer lapplication terminale JWSA (si cela ntait pas dj fait). Une fois celle-ci en place, il est redirig en local sur celle-ci dans son navigateur. Lapplication commence alors lauthentification mutuelle entre la carte du client et le web service. A la fin de cette procdure, lapplication terminale redirige lutilisateur sur le site web en passant en paramtre une cl de session. Lutilisateur est alors authentifi.

Protocole dauthentification mutuelle Lauthentification mutuelle se droule selon les tapes suivantes : Dbut de lauthentification 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 lchange de messages chiffrs entre les deux pairs. Authentification du serveur auprs du client 2. Le client envoie un challenge au serveur Le challenge est un message gnr alatoirement par le client. Il est attendu du serveur quil signe le challenge envoy avec sa cl prive. 3. Le client rcupre la signature du serveur Le client vrifie la signature serveur avec la cl publique de celui-ci. La signature doit correspondre au challenge prcdemment envoy. A cette tape, le client peut faire confiance au serveur. Authentification du client auprs du serveur 4. Le client envoie sa cl publique au serveur Le serveur ne connat pas encore lidentit du client, cette tape permet au serveur de connaitre lidentit du client vrifier en fonction de la cl reue. 5. Le serveur envoi un challenge au client Le challenge est un message gnr alatoirement par le serveur. Il est attendu du client quil signe le challenge envoy avec sa cl prive. 6. Le serveur rcupre la signature du client Le serveur vrifie la signature client avec la cl publique de celui-ci (reue ltape 4). La signature doit correspondre au challenge prcdemment envoy. A cette tape, le serveur peut faire confiance au client.

30/01/2008

Rapport Final

19 / 26

ALCINOOS

PFE ING 2008

La technologie Java Card La Java Card est une carte puce (aussi appele Smart Card) capable dexcuter des applications crites en langage Java et dans laquelle on a embarqu une machine virtuelle Java conue pour fonctionner dans un environnement aux capacits limites.

Figure 20 : Architecture Java Card

Une Smart Card se voit implmenter une plateforme Java Card contenant : lAPI Java Card, la Java Card Runtime Environment et la Java Card Virtual Machine. Cette plateforme fait linterface entre le systme dexploitation de la Smart Card et les applications charges dans la carte.

Fonctionnalits Lutilisateur a besoin de sauthentifier afin daccder de manire scurise son compte personnel en ligne, et ceci quelque soit lendroit o il se trouve. Lutilisateur doit pouvoir accder partir de son ordinateur, muni d'un lecteur de carte puce, un site Internet contrle daccs scuris. Le site distant et la carte puce devront tre authentifis mutuellement avant dautoriser laccs. Une fois authentifi, le client recevra une cl de session lui permettant daccder ses comptes en ligne. Nous mettrons en place un protocole dauthentification mutuelle entre la Java Card et le service Web. Par consquent, ltablissement dun protocole dauthentification mutuelle nous oriente vers une Java Card contenant comme fonctionnalits : o Un module de gnration de nombres alatoires; o Un module cryptographique pour la signature et la vrification de nombres alatoire. Nous nous orienterons vers lalgorithme asymtrique RSA cl 1024 bits ; o La gestion du code Pin.

30/01/2008

Rapport Final

20 / 26

ALCINOOS

PFE ING 2008

Slection de la Java Card Notre choix sest port sur la Java Card Cyberflexe e-gate 32K. Celle-ci est implmente sur la plateforme JavaCard 2.1.1 et est conforme la spcification Global Platform 2.0.1. Cette carte gre la signature et la vrification RSA avec une cl de longueur maximale de 1024 bits. Elle contient notamment des algorithmes symtriques de chiffrement DES et triple DES ainsi que la fonction de Hashage SHA. Le support PIN est aussi implment avec un nombre dessais paramtrable.

Service dauthentification par certificat Le web service WSCAS permet dauthentifier les utilisateurs sur un site web laide de leur carte puce. Ce web service dauthentification a t conu pour tre utilisable par nimporte quel site web, et nimporte quel client ( Terminal ). Totalement indpendant des autres briques du systme dauthentification WSA , il sappuie sur un protocole dchanges simple et interoprable et ne stocke que les cls publiques des clients potentiellement authentifiables. Par souci dinteroprabilit, lutilisation du langage XML1 a t choisie. Cela permet de ne pas restreindre lcriture de client ou de site web supportant notre systme au seul langage Java.

Modlisation Le diagramme de squence ci-dessous illustre le cheminement menant lauthentification, en suivant le schma dauthentification mutuelle, en y prsentant les actions de chacune des parties.

30/01/2008

Rapport Final

21 / 26

ALCINOOS

PFE ING 2008

Figure 21 : Diagramme de squence du WSCAS

Processus Le fonctionnement gnral de lauthentification mutuelle a t dtaill plus haut. Le diagramme ci-dessus correspond limplmentation effectu dans le cadre du dveloppement du service web dauthentification. Cette implmentation se dcompose 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 lauthentification en envoyant toutes les informations ncessaires lidentification de lutilisateur lorsque lauthentification sera termine. 2. Obtention dinformations : le client vrifie la disponibilit du service web, et en profite pour en rcuprer les diffrentes informations qui lui sont ncessaires. Cest galement cette tape que le web service pourrait vrifier que le certificat wscas que dtient le client nest pas expir (non implment dans le cadre du ce projet).

30/01/2008

Rapport Final

22 / 26

ALCINOOS

PFE ING 2008

3. Signature du nombre alatoire : le service web signe le nombre alatoire que le client lui envoie et lui retourne la signature ainsi obtenue. Cette tape pourrait tre facultative. 4. Gnration dun nombre alatoire : le client demande au service web de gnrer un nombre alatoire quil signera ensuite. Le client envoie galement lidentifiant de sa cl, pour que le service web puisse vrifier quil est bien dans sa base de donnes utilisateurs agrs tre authentifis. 5. Vrification de la signature du client : le service web vrifie la signature du client. Si elle est bonne, le client est valide, et considr comme authentifi. 6. Vrification du client : Le site web fait la demande au service web pour savoir si le client est authentifi. Chaque session dauthentification est identifi par une cl de session, unique et temporaire, qui est communiqu entre le client et le service web. Dtail dimplmentation Le service web se dcompose en deux sous service web . Les changes entre ces deux services web, ainsi quentre le service web priv et le site web, se font travers un canal scuris, avec les protocoles IPSec. Cela a pour effet de protger les tapes sensibles, comme linitialisation du processus dauthentification, qui se fait ainsi au sein du rseau de confiance. Le wscas public est ouvert sur internet, contrairement au wscas priv . Les trois tapes effectues entre le wscas priv et le wscas public sont les suivantes : 1. Rcuprer linitialisation provenant du service web priv : lors de ltape de prise dinformation de lutilisateur, le service web public rcupre lobjet initialisation transmis au service web priv pour initier le processus dauthentification de son ct. 2. Envoyer lalias au service web priv : Le service web public envoie lalias de lutilisateur au service web priv pour quau terme de lauthentification cet alias soit retransmis au site web. 3. Envoyer la vrification au service web priv : Le service web public a authentifi le client, il transmet lobjet vrification qui permettra au site web de vrifier que le client est bien authentifi par le CAS.

30/01/2008

Rapport Final

23 / 26

ALCINOOS

PFE ING 2008

Objets Le protocole se base sur un change dobjets, nomm SecureXmlMessage, srialis3 en XML. Cet objet est la base de tous les messages transitant entre les diffrentes parties (client, service web et site web). La forme gnrale, srialise 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 : Srialisation

Lalias de lobjet 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 dauthentification. object : lobjet attach en fonction de ltape du processus dcrits ci-dessous.

30/01/2008

Rapport Final

24 / 26

ALCINOOS

PFE ING 2008

Conclusion
Le rsultat final rpond parfaitement aux objectifs du cahier des charges. En effet, les critres de maniabilit du site web client, de scurit des accs, des transactions, et de fiabilit des calculs de la librairie finance sont atteints. Il nous faut maintenant tudier le cot du dploiement de bornes de connexions publiques, afin de rpandre lusage de notre produit. Pour plus de scurit, nous pourrions envisager une volution de la console dadministration intgrant des logs sur lactivit des utilisateurs couvrant les oprations majeures affectant la base de donnes. Une entreprise qui reprendrait notre architecture devrait mettre en place un systme de sauvegarde priodique de la base de donnes. De nombreuses applications pour notre systme dauthentification par carte puce sont imaginables. La prochaine carte didentit lectronique tudie dailleurs la possibilit dintgrer une cl dauthentification comme moyen de scurisation des transactions. Les thmes de finance et de scurit sont dactualit quelques jours aprs larrestation et la mise en examen dun trader pour la perte dissimule de plusieurs milliards dactions au sein dune grosse banque franaise. Dans cette affaire, les dispositifs de surveillance et de scurisation des transactions auraient t inefficaces. Il reste donc de nombreux terrains de rflexion explorer. Ces dernires annes, nous pouvons tout de mme remarquer une certaine prise de conscience de la part des grands groupes industriels, rpondant aux recommandations de la Direction Centrale de la Scurit des Systmes dInformations (DCSSI). La fonction de Responsable de la Scurit des Systmes dInformation (RSSI) a donc un bel avenir !

30/01/2008

Rapport Final

25 / 26

ALCINOOS

PFE ING 2008

Annexes

Tableau 5

Numro 1 2 3 4 5 6 7 8

Nom du fichier Prsentation-Admin.pdf Cahier-des-charges.pdf Abstract-Fr.pdf Abstract-En.pdf Tutoriel IPSec.pdf Wsa.pdf

Description Prsentation du sujet & quipe PFE Cahier des charges Rsum du projet en Franais Rsum du projet en Anglais Tutoriel sur la mise en place IPSec Complment dinformations sur la carte puce et le Web Service Authentification

30/01/2008

Rapport Final

26 / 26