PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008...

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

Transcript of PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008...

Page 1: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

PFE

ALCINOOS

« Gestion de portefeuille électronique par carte à puce »

Equipe – N° 16 Projet – N° 98

« Sujet non industriel proposé par les élèves »

Page 2: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 2 / 26

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 ............................................................................................................................................................................................... 11

Partie web-services .................................................................................................................................................................................... 13

Modèle Vue Contrôleur : Struts ............................................................................................................................................................ 13

Persistance : Hibernate & PostGreSQL .................................................................................................................................................. 13

Tests unitaires : JUnit ............................................................................................................................................................................ 14

Architecture réseau............................................................................................................................................................................... 14

Modélisation UML ................................................................................................................................................................................. 16

Console d’administration ...................................................................................................................................................................... 16

Partie carte à puce & Web Service d’Authentification ............................................................................................................................... 18

Architecture générale ........................................................................................................................................................................... 18

Protocole d’authentification mutuelle .................................................................................................................................................. 19

La technologie Java Card ....................................................................................................................................................................... 20

Fonctionnalités ...................................................................................................................................................................................... 20

Sélection de la Java Card ....................................................................................................................................................................... 21

Service d’authentification par certificat ................................................................................................................................................ 21

Modélisation ......................................................................................................................................................................................... 21

Processus .............................................................................................................................................................................................. 22

Détail d’implémentation ....................................................................................................................................................................... 23

Objets .................................................................................................................................................................................................... 23

Conclusion ....................................................................................................................................................................................................... 25

Annexes ........................................................................................................................................................................................................... 26

Page 3: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 3 / 26

Cadre administratif

Projet

N° 98

ALCINOOS :

« Gestion de portefeuille électronique par carte à puce »

Equipe

N° 16

Tableau 1

Nom Prénom Majeure Email Note

Aucher Arnaud SI Tech. Info [email protected] Chef de projet Barry Aguibou SE [email protected]

Demester Vincent SI Tech. Info [email protected] François-Elie Cédric SI Finance [email protected]

Lau Anthony SI Finance [email protected] Pinsonneau Rémy SI Tech. Info [email protected] Zanchetta Cédric SI Finance [email protected]

Référent

Tableau 2

Nom Prénom Email

Bonnet Jean-François [email protected]

Page 4: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 4 / 26

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

Page 5: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 5 / 26

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

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.

Figure 1 : Arborescence

Page 6: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 6 / 26

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).

Page 7: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 7 / 26

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.

Page 8: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 8 / 26

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

Page 9: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 9 / 26

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 :

Page 10: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 10 / 26

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.

Page 11: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 11 / 26

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.

Page 12: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 12 / 26

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

Page 13: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 13 / 26

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.

Page 14: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 14 / 26

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

Page 15: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 15 / 26

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

88.191.27.69 2425 192.168.238.130 22 Accès SSH PC1 88.191.27.69 2426 192.168.238.131 22 Accès SSH PC2 88.191.27.69 80 192.168.238.130 80 Accès Web PC1 88.191.27.69 81 192.168.238.131 80 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.

Page 16: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 16 / 26

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.

Page 17: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 17 / 26

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

Page 18: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 18 / 26

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

Page 19: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 19 / 26

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.

Page 20: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 20 / 26

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.

Page 21: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 21 / 26

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 2.1.1 et est conforme à la spécification Global Platform 2.0.1.

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.

Page 22: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 22 / 26

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).

Page 23: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 23 / 26

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.

Page 24: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 24 / 26

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+pKGjlL0STfRsadalCtz6wQ14zUvfRuNqFzGbaJClfj7x6APpEQn8MmhhXpocC70KVWrgieg9Rk9yCtVWAXqaTyR6K7Z40PAJPmE1PW8dDhS9ziUiXcPGETzSmoeKhANAYt2xgyTFlO2Vo0qEuqsAQTncUbp1eoq6TJjZmsAhs=</id> <sessionKey>TWZR0dtNdAqMSLIUlyDg3dvmtn2vx6dziVAGJQfqB+wlZhYR2OEJVgxseOdmJZ58bonZEykucKEIs4GNdIrfrn7N9Q5E3vQ9nGMk+hM+lYG/Sx97OaSx14T+MPF7siC8dx2xadZ8BzT4uXD8Lz2yUnzxaeu31gJZNk7J43bqG2s=</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.

Page 25: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 25 / 26

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 !

Page 26: PFE - Arnaud AUCHER’s blogarnaud.aucher.net/pdf/PFE-rapport-final.pdf · ALCINOOS PFE ING 2008 30/01/2008 Rapport Final 3 / 26 Cadre administratif Projet N° 98 ALCINOOS : « Gestion

ALCINOOS PFE ING 2008

30/01/2008 Rapport Final 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 Complément d’informations sur la carte à puce et

le Web Service Authentification 7 8