• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Rapport De PFE
 

Rapport De PFE

on

  • 97,127 views

Conception et réalisation d’une solution de « Mobile Banking ».

Conception et réalisation d’une solution de « Mobile Banking ».

Statistics

Views

Total Views
97,127
Views on SlideShare
97,070
Embed Views
57

Actions

Likes
58
Downloads
1
Comments
14

6 Embeds 57

http://www.techgig.com 48
http://www.linkedin.com 5
http://www.lmodules.com 1
http://127.0.0.1 1
https://www.facebook.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

110 of 14 previous next Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Merci
    Are you sure you want to
    Your message goes here
    Processing…
  • salm ,j'ai besoin d'un modèle de rapport pfe, urgent svp
    Are you sure you want to
    Your message goes here
    Processing…
  • bsr , merci
    Are you sure you want to
    Your message goes here
    Processing…
  • slt svp j'ai besoin d'un rapport sur le piqure de scorpion
    Are you sure you want to
    Your message goes here
    Processing…
  • slm svp j'ai besoin d'un modele de rapport de pfe concernat une boite de dévelloppement en language php
    Are you sure you want to
    Your message goes here
    Processing…

110 of 14 previous next

Post Comment
Edit your comment

    Rapport De PFE Rapport De PFE Document Transcript

    • Université Hassan II – Aïn Chock Ecole Nationale Supérieure d’Electricité et de Mécanique Casablanca Département : ENSEIGNEMENTS GENERAUX Filière : Génie Informatique RAPPORT DE PROJET DE FIN D’ETUDES Réalisé au sein de THEME : « Conception et réalisation d’une solution de M-Banking » Soutenu le 24/06/2010, par : Encadré par : Mr. Nadir HAOUARI Mr. A. KADA (BAM) Mme. F. Z. OUAZZANI (ENSEM) Mr. H. EL OUARDI (ENSEM) Membres du jury : Mlle. K. FARAJ (Président) Mr. I. ASSAYAD (Rapporteur) Mr. A. KADA (Encadrant) Mme. F. Z. OUAZZANI (Encadrant) Mr. H. EL OUARDI (Encadrant) Promotion 2010 –‫ء‬ ‫ة، ا ار ا‬ ‫ا‬ – ‫: 08-21-32/98-70-32-2250 : ص.ب.: 8118، ا ا‬ ‫: 99-21-32-2250 – ه‬ ‫آ‬ B.P. : 8118, L’OASIS – ROUTE EL JADIDA, CASABLANCA – TEL : 0522-23-07-89/23-12-89 – FAX : 0522-23-12-99
    • Projet de Fin d’Études 2010 École Nationale Supérieure d’Électricité et de Mécanique 1
    • Projet de Fin d’Études 2010 Remerciements Le travail présenté dans ce mémoire de fin d’études a été effectué au sein de Barid Al Maghrib à Rabat. Je tiens à adresser mes vifs remerciements à son Directeur général, à la Direction des Ressources Humaines et à la Direction « Organisation et systèmes d’information ». Mes sincères remerciements vont à monsieur Ahmed Kada, l’instigateur de ce projet, qui a bien voulu m’accueillir au sein de son service, à Barid Al Maghrib. Je le remercie pour la documentation mise à ma disposition, son aide précieuse et ses conseils tout au long de ce projet. Je le remercie également d’avoir accepté de participer au jury de ce PFE. Je rends hommage à mademoiselle Kenza Faraj, Professeur à l’ENSEM, dont j’ai été l’élève pendant deux ans et qui témoigne par sa participation et sa présidence de ce jury de l’intérêt qu’elle a bien voulu porter à ce travail. Je suis particulièrement redevable à Mme Fatima Zohra Ouazzani Taïbi, Professeur à l’ENSEM. Je la remercie pour sa patience, pour le suivi ininterrompu de ce projet, pour ses conseils et son appui tout au long de ce travail. Qu’elle soit chaleureusement remerciée d’avoir accepté de participer à ce jury. J’exprime mes sincères remerciements à monsieur Hamid El Ouardi, Professeur à l’ENSEM, pour la confiance qu’il m’a faite en acceptant de diriger ce travail, pour son assistance ininterrompue et ses conseils judicieux qui m’ont aidés à mener à bout ce travail. Je le remercie également d’avoir accepté de participer au jury de ce PFE. Je tiens aussi à remercier monsieur Ismaïl Assayad, Professeur à l’ENSEM, dont j’ai été l’élève durant ma troisième année et qui témoigne par sa participation au jury de l’intérêt qu’il a bien voulu porter à ce travail. Je ne saurais terminer sans exprimer mes remerciements les plus sincères à tous mes professeurs de l’ENSEM et à tout le personnel administratif qui nous a supporté pendant trois années. École Nationale Supérieure d’Électricité et de Mécanique 2
    • Projet de Fin d’Études 2010 Dédicace À ma Mère, “Tu m’as donné la vie, la tendresse et le courage pour réussir. Tout ce que je peux t’offrir ne pourra exprimer l’amour et la reconnaissance que je te porte. En témoignage, je t’offre ce modeste travail pour te remercier pour tes sacrifices et pour l’affection dont tu m’as toujours entourée.” À mon Père, “L’épaule solide, l’œil attentif compréhensif et la personne la plus digne de mon estime et de mon respect. Aucune dédicace ne saurait exprimer mes sentiments, que Dieu te Préserve et te procure santé et longue vie. ” À mon frère Amine, À ma sœur Doha, À ma famille, À mes amis… Nadir École Nationale Supérieure d’Électricité et de Mécanique 3
    • Projet de Fin d’Études 2010 Table des matières Remerciements .....................................................................................................................................2 Dédicace ...............................................................................................................................................3 Table des matières ................................................................................................................................4 Liste des figures ...................................................................................................................................9 Liste des tableaux ...............................................................................................................................10 Résumé ...............................................................................................................................................11 Abstract ..............................................................................................................................................12 Introduction ........................................................................................................................................13 Chapitre 1 : Contexte général du projet .............................................................................................17 1. Organisme d’accueil : Barid Al Maghrib (Poste Maroc) ..............................................................18 1.1. Historique et situation de Barid Al Maghrib.............................................................................18 1.1.1. Historique de BAM ................................................................................................................18 1.1.2. Métiers de BAM.....................................................................................................................19 1.1.3. Missions, visions et buts de l’entreprise ...............................................................................20 1.1.3.1. Missions de BAM ...............................................................................................................20 1.1.3.2. Vision de BAM ...................................................................................................................20 1.1.3.3. Objectifs de BAM ...............................................................................................................20 1.2. Développement stratégique de BAM .......................................................................................20 1.3. Organigramme de Poste Maroc ...............................................................................................21 1.4. La direction « Organisation et systèmes d’information » .......................................................21 1.5. Produits de BAM ......................................................................................................................23 1.6. BAM et M-Banking....................................................................................................................25 2. Cahier de charges ........................................................................................................................26 2.1. Généralités................................................................................................................................26 2.2. Partie client ...............................................................................................................................26 2.3. Partie serveur ...........................................................................................................................27 3. Modèles économiques ................................................................................................................28 4. Gestion du projet .........................................................................................................................29 Chapitre 2 : Contexte théorique .........................................................................................................31 1. Introduction .................................................................................................................................32 2. Architecture GSM ........................................................................................................................32 École Nationale Supérieure d’Électricité et de Mécanique 4
    • Projet de Fin d’Études 2010 2.1. Généralités................................................................................................................................32 2.2. Notions de réseaux cellulaires..................................................................................................34 2.3. Carte SIM et téléphone mobile : ..............................................................................................36 2.4. Les protocoles du standard GSM..............................................................................................37 3. Sécurité du standard GSM ...........................................................................................................39 3.1. Authentification et confidentialité ...........................................................................................39 3.2. Aspects de la sécurité ...............................................................................................................40 3.3. Contournement de l’authentification .....................................................................................41 3.4. Contournement de la confidentialité .......................................................................................43 3.4.1. Craquer le A5 directement ....................................................................................................44 3.4.2. A5/2 – Joie de l’attaquant .....................................................................................................44 3.5. Problèmes de sécurité et SMS ..................................................................................................44 3.5.1. Crash d’un mobile..................................................................................................................45 3.5.2. SMS spoofing .........................................................................................................................45 3.5.3. Cryptage du SMS ...................................................................................................................45 3.5.4. Le déni de service ..................................................................................................................45 3.6. Modèles de SMS sécurisés .......................................................................................................46 3.6.1. SMS Handshaking Protocol....................................................................................................46 3.6.2. Quasigroup ............................................................................................................................47 3.7. Exemple de quelques banques .................................................................................................47 3.7.1. USSD ......................................................................................................................................47 3.7.2. WIG ........................................................................................................................................47 3.8. Récapitulatif..............................................................................................................................48 Chapitre 3 : Dossier de conception ....................................................................................................49 1. Introduction .................................................................................................................................50 2. Vue globale du système...............................................................................................................50 3. Les couches du protocole ............................................................................................................50 4. Préconception..............................................................................................................................52 5. Vue globale sur le processus .......................................................................................................53 5.1. Génération et envoi du SMS sécurisé ......................................................................................53 5.2. Réception et décodage du SMS sécurisé..................................................................................54 6. Structure du message ..................................................................................................................55 École Nationale Supérieure d’Électricité et de Mécanique 5
    • Projet de Fin d’Études 2010 7. Sécurité du protocole ..................................................................................................................56 7.1. Confidentialité ..........................................................................................................................56 7.2. Intégrité ....................................................................................................................................57 7.3. Authentification ........................................................................................................................57 7.4. Non-répudiation .......................................................................................................................57 7.5. Disponibilité ..............................................................................................................................57 8. Diagramme de cas d’utilisation ...................................................................................................59 8.1. Cas d’utilisation 1 : Lancer l’application ...................................................................................59 8.2. Cas d’utilisation 2 : Sélection de la transaction........................................................................59 8.3. Cas d’utilisation 3 : L’envoi du message ...................................................................................59 8.4. Cas d’utilisation 4 : Vérification de la sécurité du message par le serveur .............................59 8.5. Cas d’utilisation 5 : Réponse du serveur ..................................................................................59 9. Diagrammes de classes................................................................................................................61 9.1. Diagramme de classes de l’application client ..........................................................................61 9.1.1. La classe « InterfaceUtilisateur »...........................................................................................61 9.1.2. La classe « Bourrage » ...........................................................................................................62 9.1.3. La classe « Signer » ................................................................................................................62 9.1.4. La classe « Crypter » ..............................................................................................................62 9.2. Diagramme de classes du serveur téléphonique .....................................................................62 9.2.1. La classe « MessageSMS » .....................................................................................................62 9.2.2. La classe « Bluetooth » ..........................................................................................................63 9.3. Diagramme de classes du serveur PC .......................................................................................63 9.3.1. La classe « ServeurBanque » .................................................................................................63 9.3.2. La classe « RépondreMessage » ............................................................................................64 9.3.3. La classe « GestionMessage » ...............................................................................................64 9.3.4. La classe « Détailbancaire »...................................................................................................64 9.3.5. La classe « AppelBD » ............................................................................................................64 9.3.6. Les classes « Crypter » et « Signer »......................................................................................64 9.4. Diagramme de classes du serveur BD ......................................................................................65 9.4.1. La classe « BDConnect » ........................................................................................................65 9.4.2. La classe « BDServeur » .........................................................................................................65 9.4.3. La classe « AppelBD » ............................................................................................................65 École Nationale Supérieure d’Électricité et de Mécanique 6
    • Projet de Fin d’Études 2010 9.4.4. La classe « MdpDriver ».........................................................................................................66 9.4.5. La classe « Générateur Mdp » ...............................................................................................66 10. Diagramme de séquences .........................................................................................................67 11. Compatibilité .............................................................................................................................68 11.1. Java ME ...................................................................................................................................68 11.2. Machines virtuelles, configurations et profils ........................................................................69 11.3. Compatibilité et M-Banking....................................................................................................69 Chapitre 4 : Implémentation ...............................................................................................................70 1. Vue d’ensemble ...........................................................................................................................71 2. L’application mobile ....................................................................................................................71 2.1. L’interface utilisateur................................................................................................................72 2.2. Cryptage/décryptage ................................................................................................................73 2.3. La signature ..............................................................................................................................74 2.4. Envoi du message .....................................................................................................................74 2.5. Réception de message ..............................................................................................................75 3. L’application serveur bancaire ....................................................................................................75 3.1. Réception des messages...........................................................................................................75 3.2. Vérifications de sécurité ...........................................................................................................76 3.3. Réponse aux erreurs .................................................................................................................77 3.4. Réponse aux transactions.........................................................................................................78 3.5. Communication SSL/RMI ..........................................................................................................78 3.6. Connexion JDBC ........................................................................................................................78 3.7. Base de données MySQL ..........................................................................................................79 3.8. Générateur de mot de passe pseudo aléatoire........................................................................79 Chapitre 5 : Tests, Évaluation et maintenance ...................................................................................81 1. Tests .............................................................................................................................................82 1.1. La confidentialité : AES .............................................................................................................82 1.2. L’intégrité : SHA-1 .....................................................................................................................82 1.3. Authentification ........................................................................................................................83 1.4. Non-répudiation .......................................................................................................................83 1.5. Attaque par ré-envoi de message ............................................................................................83 1.6. Attaque par usurpation d’identité ...........................................................................................84 École Nationale Supérieure d’Électricité et de Mécanique 7
    • Projet de Fin d’Études 2010 1.7. Attaque par force brute............................................................................................................84 2. Evaluation ....................................................................................................................................85 3. Maintenance ................................................................................................................................89 3.1. Distribution de l’application mobile .........................................................................................90 3.2. L’application front-office ..........................................................................................................90 3.3. Autres .......................................................................................................................................91 Conclusion ..........................................................................................................................................92 Références ..........................................................................................................................................95 1. Bibliographie ................................................................................................................................96 2. Wébographie ...............................................................................................................................96 3. Filmographie ................................................................................................................................98 École Nationale Supérieure d’Électricité et de Mécanique 8
    • Projet de Fin d’Études 2010 Liste des figures Figure 1 : Organigramme de BAM ....................................................................................................21 Figure 2 : Diagramme de Gantt relatif à la gestion de projet .............................................................29 Figure 3 : Architecture GSM ..............................................................................................................33 Figure 4 : Découpage en cellules .......................................................................................................34 Figure 5 : Mesure de niveau et décodage des BCH des cellules voisines ..........................................36 Figure 6 : Mise en évidence de la trame de décodage des voix balises des cellules voisines ............36 Figure 7 : Piles de protocoles de différents sous systèmes du réseau GSM.......................................37 Figure 8 : L’authentification et la génération de la clé ......................................................................39 Figure 9 : L’attaque de Goldberg et Wagner......................................................................................41 Figure 10 : Algorithme de chiffrement A5.........................................................................................43 Figure 11 : Pile des couches du protocole pour l’envoi et la réception de SMS sécurisés ................51 Figure 12 : Vue globale sur le système réalisé ...................................................................................53 Figure 13 : Structure du SMS sécurisé ...............................................................................................55 Figure 14 : Diagramme de cas d’utilisation .......................................................................................60 Figure 15 : Diagramme de classes de l’application mobile ...............................................................61 Figure 16 : Diagramme de classes de l’application serveur téléphonique .........................................62 Figure 17 : Diagramme de classes du serveur PC ..............................................................................63 Figure 18 : Diagramme de classes du serveur BD .............................................................................65 Figure 19 : Diagramme de séquences ................................................................................................67 Figure 20 : Constituants de Java ME .................................................................................................68 Figure 21 : Composition du CLDC et du MIDP ................................................................................69 Figure 22 : Prise d’écrans de quelques interfaces de l’application mobile ........................................72 Figure 23 : Gestion des SMS avant leurs traitements ........................................................................75 École Nationale Supérieure d’Électricité et de Mécanique 9
    • Projet de Fin d’Études 2010 Liste des tableaux Tableau 1 : Forces et faiblesses des différents modèles économiques ...............................................28 Tableau 2 : Analyse des approches courantes utilisées pour le M-Banking ......................................48 Tableau 3 : Comparaison entre les approches de sécurité courantes dans le domaine du M-Banking et le protocole que nous avons conçu dans le projet ..........................................................................58 Tableau 4 : Comparaison de notre solution de M-Banking avec d’autres solutions existantes .........88 Tableau 5 : Evaluation des différentes méthodes de M-Banking......................................................89 École Nationale Supérieure d’Électricité et de Mécanique 10
    • Projet de Fin d’Études 2010 Résumé Le présent document constitue le fruit de notre travail accompli dans le cadre du Projet de Fin d’Études au sein de Barid Al Maghrib. L’objectif de ce projet est la conception et la réalisation d’une solution de M-Banking. Le travail dans ce projet s’est déroulé comme suit : nous avons commencé par faire l’étude des différentes solutions de M-Banking existantes appartenant à des sociétés de pays différents afin d’avoir une idée claire sur les difficultés et les problèmes que nous pouvons rencontrer lors de notre projet. Ensuite, nous avons élaboré un plan de travail qui nous a permis, dans une courte durée, d’obtenir de bons résultats. L’étape suivante consistait à réaliser une étude approfondie des différents aspects techniques liés à ce genre de solutions informatiques comme l’étude du standard GSM par exemple ou celle de la sécurité des communications. Cette étape nous a permis de réaliser une conception, qui a le mérite d’apporter plus de sécurité que les solutions existantes tout en étant compatible avec la majorité des téléphones mobiles du parc mobile marocain et en réduisant considérablement le coût d’utilisation. Enfin, nous avons pu réaliser une solution qui constitue une base solide pour tout travail futur visant la réalisation d’un système bancaire complet utilisant le M-Banking. École Nationale Supérieure d’Électricité et de Mécanique 11
    • Projet de Fin d’Études 2010 Abstract This document constitutes the result of our efforts made in the frame of our project of the end of studies within Barid Al Maghrib. The aim of this project is to conceive and realize a mobile banking solution. The work in this project took place as follows: we began by making the study of the existing solutions of M-Banking belonging to companies of different countries to have a clear idea on the difficulties and the problems which we can meet during our project. Then, we elaborated a work plan which allowed us in a short time to reach good results. The next step consisted in realizing a detailed study about the various technical aspects bound to this kind of computing solutions such as the study of the standard GSM or the study of communications security. This step allowed us to realize a good conception, which has the merit to bring more security than the existing solutions while being compatible with the majority of the mobile phones of the Moroccan mobile park and by considerably reducing the cost-in-use. Finally, we were able to realize a solution which forms a solid base for any future work intended realizing a complete banking system using M-Banking. École Nationale Supérieure d’Électricité et de Mécanique 12
    • Projet de Fin d’Études 2010 Introduction Suite à une récente étude sur l'innovation bancaire menée par Novamétrie, le ‘mobile banking’ « deviendra une pratique généralisée d'ici deux ou trois ans ». Cette étude montre qu’il existe un réel consensus entre les banquiers et leurs clientèles sur le potentiel de développement du M-Banking pour des services simples et pratiques tels que la gestion de compte (pour 88% des banquiers et 66% des clients interrogés) et les paiements (pour 80% des banquiers et 70% des clients). Afin d’avoir une idée claire sur l’intérêt et les enjeux du M-Banking, nous les discutons sous trois volets différents : Le mobile, levier de bancarisation dans les pays émergents : Dans la plupart des pays émergents, le développement des banques se heurte souvent au faible taux de bancarisation structurellement observé auprès de la clientèle de particuliers. En effet, rares sont les pays émergents où le taux de bancarisation dépasse 20% (il était de 40% en 2007 au Maroc avec un objectif d’atteindre 62% en 2013), contrairement aux pays développés où cet indicateur est généralement supérieur à 85%. Le potentiel de croissance pour les banques n’est pas négligeable, notamment en ce qui concerne les activités de « banque au quotidien » (tenue de compte, paiements, services complémentaires). Un décollage du taux de bancarisation permettrait aux établissements bancaires, non seulement d’étendre leurs sources de revenus par augmentation du volume de commissions, mais surtout d’adresser une base de clientèle plus large sur d’autres types d’offres (crédit à la consommation, micro crédit, voire crédit à l’habitat…). Ce constat s’explique par plusieurs facteurs structurels. On peut notamment observer que la majorité de ces économies sont à dominance rurale, ce qui a pour conséquence une concentration des agences autour des grandes villes. Cumulé à un maillage des transports très hétérogène, ce point rend les agences difficiles d’accès pour une grande partie de la population. De plus, les paiements scripturaux sont peu développés du fait du coût élevé de l’accès aux services financiers et de la forte tradition des paiements en espèces. Cependant, le faible taux de bancarisation n’a eu aucune influence sur le taux de pénétration des mobiles, même dans les pays émergents. L’Afrique ne fait pas l’exception. En effet, il y a une « explosion fulgurante » du marché mobile africain selon l’opérateur Orange qui a vu en 2007 le École Nationale Supérieure d’Électricité et de Mécanique 13
    • Projet de Fin d’Études 2010 volume de ses abonnements progresser de plus de 40 % sur le continent. Au Maroc, le taux de pénétration des mobiles en mars 2010 a été évalué par l’ANRT à 86%. Taux de pénétration du mobile élevé, faible taux de bancarisation… et pourquoi ne pas utiliser le mobile comme moyen pour passer les transactions bancaires ? C’est à cette question que répond l’étude mandatée par la société Sybase 365 (société spécialisée dans les services de messagerie mobile) à laquelle 92 des plus grandes institutions financières mondiales (32 banques européennes, 30 banques des USA et 30 banques de la région Asie Pacifique) ont participé. Il en ressort que 66% pensent que c’est un excellent moyen d’améliorer les services bancaires et donc d’augmenter le taux de bancarisation. C’est en effet ce qui s’est passé avec l’offre M-Pesa au Kenya, proposée par Safaricom en partenariat avec Vodafone, qui a rallié plus de 3 millions de nouveaux clients en deux ans. Cet enthousiasme envers le M-banking a été prédit par une étude de Juniper Research réalisée en 2007 qui stipule que : « Si en 2007 environ 2.7 milliards de transactions ont été recensées dans le monde, ce nombre devrait atteindre 37 milliards d’ici 2011. Près de 816 millions de personnes utiliseront des services bancaires via le mobile à cette date ». Les services de M-Banking les plus courants, auxquels les consommateurs ont accès, ont été identifiés par l’étude de la société Sybase 365. En premier lieu vient la consultation de soldes (87% des banques qui offrent le M-Banking), puis les alertes en cas de transactions (77%) suivi de près par le transfert d’argent (74%) et les alertes quand un solde à atteint un certain seuil (71%). Mais ceci n’empêche pas que 50% des 5000 clients bancaires interrogés dans le cadre de l’étude menée par la société Novamétrie trouvent que « le renforcement de la sécurité devrait être le changement majeur à mettre en œuvre ». Sébastien Burlet, président et fondateur de la start-up Lemon Way, l’une des meilleures au monde dans le domaine d’édition des logiciels pour le M-Banking, affirme qu’il a fallu un an de développement et huit développeurs dédiés pour avoir juste une version « release candidate » qui est une version non stable de leur produit de M-Banking. Cette difficulté technique est peut être un obstacle majeur qui freine le développement rapide de ce genre de service dans les pays en voie de développement. En tout cas, Henri Tcheng, associé à BearingPoint, l'un des leaders du conseil en management et technologies, pense que : « Si aujourd’hui, le paiement mobile apparaît comme une question de spécialiste, demain il concernera tout un chacun, de Paris à Bornéo en passant par Tombouctou ! ». École Nationale Supérieure d’Électricité et de Mécanique 14
    • Projet de Fin d’Études 2010 Des facteurs clefs de développement : L’enjeu réside avant tout dans la mise à disposition de services à forte valeur ajoutée pour le client, susceptible d’entraîner l’adhésion d’un plus grand nombre de personnes aux services bancaires. Ainsi le futur service devra par exemple proposer un mode de souscription simple, des services adaptés à la demande et un coût d’accès relativement faible. Cependant, le lancement d’une offre de M-Banking est soumis à plusieurs facteurs clefs de succès. Le business modèle est au cœur de ces préoccupations, avec la question cruciale du lien entre les banques et les opérateurs mobiles. Chacun des acteurs doit évaluer, en fonction de ses objectifs stratégiques, le risque qu’il est prêt à encourir, le cadre réglementaire en vigueur et le positionnement qu’il compte occuper sur les différents maillons de la chaîne de valeur du M-Banking (marketing, distribution, traitement des ordres, facturation…). Cela peut également passer par l’entrée sur le marché d’entités tierces, qui font le lien entre les acteurs bancaires et télécoms. La question de l’interbancarité se pose également au cœur du débat. Là encore, plusieurs options sont à étudier, comme par exemple la mise en place d’un système propriétaire ou bien un partenariat avec un réseau international. Au cœur de cette problématique : le coût des commissions appliquées et les conditions d’accès aux systèmes de compensation. Le risque de voir se développer plusieurs communautés de paiements cloisonnées (par banque ou par opérateur) n’est pas à exclure et viendrait considérablement réduire la portée potentielle des offres de M-Banking. C’est ce qui se passe effectivement au Maroc avec ces deux offres de M-Banking disponibles jusqu’à maintenant : l’offre de Maroc Telecom en partenariat avec Attijariwafa Bank et la Banque Populaire et l’offre de Méditel en partenariat avec BMCE Bank. Chacune des deux solutions n’est disponible que pour les clients de l’opérateur spécifique. Ceci est sur le point de changer avec la solution de M-Banking de Barid Al Maghrib qui a le mérite d’être indépendante des opérateurs ce qui lui permet d’être « ouverte sur la clientèle de tous les opérateurs marocains ». Positionnement et jeu d’acteurs : Un des points clefs sera l’estimation du retour sur investissement, pour lequel la mesure devra prendre en compte les gains directs mais aussi tous les effets d’entraînement liés à l’augmentation du taux de bancarisation. En effet, l’enjeu de telles offres dépasse le simple facteur technologique ou l’effet de mode pour constituer une véritable opportunité de développement pour la nation dans son ensemble. École Nationale Supérieure d’Électricité et de Mécanique 15
    • Projet de Fin d’Études 2010 Dans ce contexte, il est impossible d’assister à la mise en place d’offres globales, exportables d’un pays à l’autre. C’est en tout cas le chemin suivi par la société eTranzact, implantée au Ghana, au Nigeria, au Zimbabwe, et dont l’extension est prévue en Ouganda, en Sierra Leone et en Côte d’Ivoire. On remarque d’ailleurs que, quelle que soit la diversité des services de M-Banking proposés d’un pays à l’autre, les clients n’utilisent principalement que les fonctions de transferts et de paiements de biens et services. Le développement d’offres globales peut néanmoins se heurter à l’organisation et à la réglementation des systèmes de paiements nationaux qui différent d’un pays à l’autre. École Nationale Supérieure d’Électricité et de Mécanique 16
    • Projet de Fin d’Études 2010 Chapitre 1 : Contexte général du projet École Nationale Supérieure d’Électricité et de Mécanique 17
    • Projet de Fin d’Études 2010 1. Organisme d’accueil : Barid Al Maghrib (Poste Maroc) 1.1. Historique et situation de Barid Al Maghrib 1.1.1. Historique de BAM La Poste marocaine a été créée le 22 novembre 1892 par Dahir du Sultan Moulay Hassan 1er réglementant la pratique postale au Maroc. Le premier timbre marocain a vu le jour le 12 Mai 1912 portant l’illustration de la Zaouiya Al Issaouiya de Tanger. En 1956, après l’indépendance, Sa Majesté le Roi Mohammed V a instauré le ministère des postes, télégraphes et téléphones pour une extension des télécommunications et la généralisation des services postaux à tout le royaume. Pour rattraper le retard en matière des postes et télécommunications et doter le pays d’une infrastructure moderne en rapport avec les exigences de son développement économique, le Maroc a créé en 1984 l’Office National des Postes et Télécommunications (ONPT). C’est un établissement public doté de l’autonomie financière. Depuis, l’évolution technologique a donné lieu à une multiplicité de services (radiomessagerie, Internet, etc.). En dix ans l’ONPT a réussi à quintupler les capacités existantes initialement. La réforme se présente donc comme une réponse à la diversité de la demande en produits spécifiques. Mais elle est également le prolongement d’une ouverture récente du secteur, qui a vu l’émergence d’entreprises commerciales qui se sont vues confier, dans les années 1990, des tâches d’opérateurs privés dans le domaine des sous-traitances et du partenariat, relative aux services à valeur ajoutée. La place des télécommunications dans l’économie nationale s’élargit de plus en plus. Pour faire face à la mondialisation, l’ONPT est dissout en vertu de la loi 24/96 et trois entités en sont issues : Ittisalat Al-Maghrib (IAM), Barid Al Maghrib (BAM) et l’Agence Nationale de Réglementation des Télécoms (ANRT). Après la séparation du secteur de la Poste et celui des télécommunications, on a assisté à la création de la société Barid Al Maghrib (BAM) en février 1998 par la loi 24/96, dotée de la personnalité morale et l’autonomie financière et soumise à la tutelle de l’Etat. Depuis cette date, Barid Al Maghrib a concilié ses efforts pour assurer ses missions en tant qu’entreprise publique et celle de la performance d’une entreprise commerciale. École Nationale Supérieure d’Électricité et de Mécanique 18
    • Projet de Fin d’Études 2010 Aujourd’hui, Poste Maroc s’est dotée d’un nouveau statut comme société anonyme marocaine de droit public et est rentrée dans une nouvelle ère, de réorganisation (organisation par pôle) et d’innovation de ses services par le biais de l’introduction des NTIC et les démarches de certification. 1.1.2. Métiers de BAM BAM a pour principaux métiers : • L’émission des timbres-postes ainsi que toute autre marque d’affranchissement; • Les activités relevant du monopole de l’Etat en matière de service de courrier sous toutes ses formes, dans les relations intérieures et internationales; • La collecte de l’épargne à travers la Caisse d’Epargne Nationale (CEN). A cet effet, BAM est habilité à ouvrir des comptes de dépôt à vue ou à terme pour toute personne physique ou morale, au nom de laquelle ou par laquelle des fonds sont versés à la caisse à titre d’épargne; • BAM assure le service des mandats-poste des régimes internes et externes, il se charge également de la gestion du service des comptes courants de chèques postaux conformément à la législation en vigueur. Les opérations d’émission et de paiement ainsi que celles de retrait et de dépôt effectuées par BAM, au titre des services précités, sont imputées au compte courant du trésorier général ouvert à BAM; • BAM assure également tous les autres services dont l’Etat fixe la liste en prenant en considération des besoins du trésor public pour l’accomplissement de ses missions. Une convention conclue entre l’Etat et BAM fixe les conditions de juste rémunération des dits services; • BAM peut créer des filiales et prendre des participations financières dans toutes les entreprises entrant par leurs objectifs dans le cadre de ses missions, conformément aux dispositions de la loi N°39-89; • BAM est ainsi habilité à créer des établissements de formation des cadres, et de formation professionnelle dans le domaine de la poste et des services financiers postaux,… École Nationale Supérieure d’Électricité et de Mécanique 19
    • Projet de Fin d’Études 2010 1.1.3. Missions, visions et buts de l’entreprise 1.1.3.1. Missions de BAM Barid Al Maghrib est une entreprise publique multiservices à dimension internationale. Elle a pour mission principale de fournir un service de qualité et de proximité pour tous, notamment dans les domaines du courrier, de la messagerie et des services financiers. Elle a également pour mission, en tant qu’entreprise opérant dans un environnement concurrentiel, de développer de nouveaux services à valeur ajoutée pour mieux satisfaire sa clientèle. 1.1.3.2. Vision de BAM Etre une entreprise compétitive, innovante, flexible et communicante, ouverte sur son environnement national et international et orientée vers la satisfaction du client. Autrement dit, tendre vers l’Excellence. 1.1.3.3. Objectifs de BAM C’est un ensemble d’objectifs qui résultent souvent de contraintes inhérentes à l’entreprise. • Développer le chiffre d’affaires ; • Améliorer ses parts de marché ; • Réaliser des gains de productivité et accroître la rentabilité. 1.2. Développement stratégique de BAM Les autorités gouvernementales au Maroc ont cherché depuis des années à effectuer un décollage de l’activité économique pour donner au royaume la place qu’il mérite dans le rang des pays émergents. L’un des axes stratégiques de BAM est le développement du réseau postal aussi bien au milieu urbain qu’au milieu rural. Ceci s’est traduit par la création de plusieurs autres établissements postaux portant ainsi leur nombre à plus de 1470 points de contact. Afin de mieux satisfaire ses clients, BAM s’est efforcé d’améliorer la qualité de ses services en veillant à réduire les files d’attente dans les bureaux de poste. Dans cette optique, l’informatisation des bureaux s’est poursuivie en 2005 portant le nombre d’établissements postaux informatisés à 675, soit une croissance de 60% par rapport à 1997, avec un nombre très important de guichets automatiques (231). École Nationale Supérieure d’Électricité et de Mécanique 20
    • Projet de Fin d’Études 2010 1.3. Organigramme de Poste Maroc Figure 1 : Organigramme de BAM 1.4. La direction « Organisation et systèmes d’information » La direction « Organisation et systèmes d’information » prend en charge le développement des applications et projets demandés par les différents services de BAM, leur déploiement et leurs mises à jour. Elle entretient et assure le suivi des applications réalisées par d’autres sociétés. Ainsi, elle dispose de techniciens qui assurent la maintenance et la réparation du matériel informatique. La direction « Organisation et systèmes d’information » est composée de deux divisions: Division Études informatiques et Division Exploitation informatique. Concernant la Division Études informatiques, elle a pour tâches : École Nationale Supérieure d’Électricité et de Mécanique 21
    • Projet de Fin d’Études 2010 • Le suivi et l’étude des projets (mise en place des infos centres, commerce électronique, courrier hybride…); • La réalisation des applications domestiques; • Le suivi et l’informatisation des bureaux de poste; • Le réseau télématique de BAM; • La gestion et mise en place des réseaux télématiques de transfert de fonds (Euro Giro, IFS/IMO, Western Union etc.). Quant à la Division Exploitation, elle est tenue de traiter les applications déjà élaborées et testées au service Études et de les exploiter réellement par la suite, à savoir : • Le service CCP : c’est un service qui assure le traitement des opérations concernant les comptes courants postaux : ouverture, alimentation, paiement des chèques (retraits). • Le service CEN : la CEN joue un rôle très important dans l’économie marocaine, puisqu’elle assure grâce au réseau postal, la mobilisation et la collecte de l’épargne à travers tout le pays. Cependant, les fonds collectés sont déposés auprès de la Caisse de Dépôt et de Gestion (CDG) qui en assure l’usage. Selon les dispositions du dahir de 1959, la CEN offre comme unique produit le compte sur livret. Les épargnants bénéficient d’une part, des intérêts exonérés de prélèvement fiscal et d’autre part, de la gratuité de la tenue des comptes et des transactions. • Le service Paie : il s’occupe de la gestion du personnel de BAM, à savoir (primes, virements, grades…). • Le service CIH, Méditel, Wafasalaf, Al WATANIYA : Il charge BAM de sous-traiter les crédits, les effets et les échéances pour les villes qui ne disposent pas d’agences propres à ces organismes. • Le service de la Maintenance : Il se charge de l’impression des états de sorties, l’impression et la confection des carnets de chèques, l’exploitation des réseaux urbain et interurbain et tout ce qui est Liaisons Spécialisées (LS) et Maghripac ainsi que le suivi et l’assurance de la liaison entre les bureaux de poste. École Nationale Supérieure d’Électricité et de Mécanique 22
    • Projet de Fin d’Études 2010 1.5. Produits de BAM Les produits de BAM se divisent en : • Produits Internes : - IPS ; - BPBAM ; - E-Barkia ; - E-Mandat ; - Amana. • Produits Externes : - ChronoPost ; - Service Western Union ; - Mandat Euro Giro ; - Mandat IFS/IMO. On se limitera, dans toute la suite, aux produits faisant intervenir des opérations bancaires tels que le transfert de fonds, la consultation de compte, …. Pour les transferts de fonds au Maroc, BAM propose les produits suivants : • Le mandat carte ordinaire acheminé via le réseau postal et dont le paiement s’effectue en espèces. • Le mandat carte de versement dont le montant est porté au crédit d’un compte chèque postal. • Le mandat électronique assure le transfert d’argent instantanément dans les principales localités du Royaume. Les atouts du mandat électronique sont : o Un moyen rapide pour le transfert d’argent : le transfert s’effectue en moins de 10 minutes à travers plus de 560 bureaux. o Un moyen garanti et sûr : le correspondant peut encaisser immédiatement le mandat. Il suffit qu’il se présente au bureau de poste payeur dés qu'il est avisé soit par téléphone soit par voie postale. o Un moyen économique : c’est un service peu coûteux. o Accessible : le mandat électronique est présent dans plus de 560 bureaux de poste. Il couvre l’ensemble du Royaume. École Nationale Supérieure d’Électricité et de Mécanique 23
    • Projet de Fin d’Études 2010 • Western Union dont les avantages sont : o Fiabilité : les transferts sont sécurisés par un système performant ; l'argent est remis à la personne désignée par l'émetteur. o Rapidité : le transfert d'argent se fait en quelques minutes grâce au réseau télématique mondial. o Facilité et simplicité : pas besoin de compte bancaire ou postal, pas de frais pour le destinataire. o Pratique : plus de 120.000 agences Western Union dans un réseau mondial de 190 pays. o Pour recevoir de l'argent au Maroc : il suffit de contacter la personne expéditrice à l’étranger ; lui demander de déposer l’argent dans une agence Western Union. Ensuite, le destinataire, muni d’une pièce d’identité, se présente à l’un des bureaux de poste de BAM, remplit le formulaire de réception d’argent et la somme envoyée par son correspondant lui sera remise en quelques minutes. Pour les transferts de fonds à l’international, BAM offre : • Le mandat ordinaire international pour les paiements en espèces, acheminé par courrier postal ; • Le mandat de versement international à un compte chèque postal tenu à l’étranger, acheminé via le réseau postal ; • Western Union. • Eurogiro est un moyen international de transfert électronique pour : o Les virements ordinaires libellés en devise du pays de destination ; o Les mandats internationaux : transfert de fonds du bénéficiaire en devise nationale entre le Maroc et l’Italie, le Danemark, la Suède, la Suisse, l’Allemagne, la France et la Tunisie. École Nationale Supérieure d’Électricité et de Mécanique 24
    • Projet de Fin d’Études 2010 Avantages : - Le bénéficiaire ne paye aucun droit ; - Les tarifs applicables aux mandats EUROGIRO sont identiques à ceux des mandats ordinaires internationaux ; - Les délais de paiements sont très courts dans tous les bureaux de poste ; - La qualité de service dans le transfert de fonds est excellente. • IFS/IMO, pour les mandats internationaux (paiement en espèces) entre le Maroc et la France. Avantages : - Une formule de transfert simple et économique; - Un traitement rapide de l’opération de transfert de fonds; - Les délais de paiements dans tous les bureaux de poste prennent moins de 2 jours; - Un système de traçabilité permettant le suivi et la localisation du parcours du mandat émis. 1.6. BAM et M-Banking Les produits proposés par BAM concernant le volet bancaire sont sûrs et rapides mais présentent tous un inconvénient de taille quant aux transferts de fonds. Le client doit nécessairement se déplacer, muni de son argent, jusqu’à l’une des agences BAM pour faire un transfert de fonds, ce qui représente un risque sérieux à prendre en considération. Une fois l’argent déposé chez BAM, il est nécessaire de prévenir le destinataire ce qui engendre un problème de sécurité des communications en plus de l’attente qui en résulte. Ayant pour but de pallier à ces problèmes et de moderniser ses services, BAM pense sérieusement à l’introduction du M-Banking, dont le présent travail de PFE constitue une base très solide sur laquelle on peut édifier tout le projet. École Nationale Supérieure d’Électricité et de Mécanique 25
    • Projet de Fin d’Études 2010 2. Cahier de charges 2.1. Généralités - Dans le cadre de notre projet, nous devons d’abord concevoir puis réaliser une « Solution informatique » suivant les exigences du cahier de charges. La notion de « solution informatique » diffère de la notion d’application du fait qu’une solution peut contenir plusieurs applications qui marchent ensemble. - La solution que nous devons concevoir doit suivre le modèle client/serveur. - L’application client doit être sous forme d’une application embarquée (ce qui diffère des solutions de M-Banking existante sur le marché marocain) - La partie serveur sera sous forme de plusieurs applications qui marchent ensemble afin de réaliser les traitements désirés. Les parties essentielles du serveur sont le téléphone serveur, le PC serveur et la Base de données. - Dans le cadre de ce projet, nous nous limiterons à deux services principaux de M-banking qui sont : le transfert d’argent et la consultation du solde. 2.2. Partie client - L’importance principale, ici, doit être accordée à la sécurité des transactions. Il nous est demandé de concevoir un système ultra sécurisé apte à être utilisé dans un bon système bancaire. - L’attention est ensuite focalisée sur le point de compatibilité. Il est inutile de créer une application très puissante si la plupart des téléphones du parc mobile marocain ne peuvent pas la supporter. Ici, il nous est demandé de faire un compromis entre la puissance des traitements et la compatibilité avec les téléphones mobiles. - La minimisation du coût d’utilisation est l’un des défis de ce projet. En effet, on pourrait avoir la meilleure solution en matière de sécurité si on n’a pas de limites côté dépenses. Il nous est demandé, ici, de minimiser le coût d’utilisation de l’application tout en préservant la sécurité des transactions. - Plusieurs canaux de communications peuvent être utilisés pour réaliser une application de M-Banking. En effet, on pourrait utiliser aussi bien le WAP, le GPRS, l’EDGE, le 3G que les SMS ou bien le GAP. Dans ce travail, le choix a été porté sur le SMS puisqu’il est le plus utilisé entre ces cannaux. École Nationale Supérieure d’Électricité et de Mécanique 26
    • Projet de Fin d’Études 2010 - Le marché marocain reste encore un marché où il y a un grand pourcentage de personnes non avisées dans le domaine des technologies, il est donc judicieux de trouver un moyen qui leur faciliterait l’utilisation. La forme standard utilisée pour le M-Banking est un SMS contenant une chaîne de caractères qui doit être saisie dans un ordre donné et donc qui peut générer plusieurs erreurs avant de passer la transaction souhaitée. C’est dans ce contexte qu’il nous est demandé de réaliser une application mobile avec de simples interfaces graphiques aidant le client dans l’opération de saisie de ses données. 2.3. Partie serveur - Bien sûr, le serveur devra pouvoir traiter les différentes transactions, en les captant d’abord, puis en vérifiant leur sécurité avant de les réaliser et envoyer une réponse au client. - Le serveur devra suivre un modèle non bloquant, c'est-à-dire que le traitement d’une transaction ne devra pas bloquer les traitements des autres. - Le serveur ne devra jamais initier la communication avec un client : c’est le rôle du client. Le serveur est toujours en écoute seulement. - Le serveur devra contenir un mécanisme de sécurité puissant afin d’éliminer les transactions illicites. - Le serveur devra être programmé de façon à respecter les standards de sécurité côté programmation. École Nationale Supérieure d’Électricité et de Mécanique 27
    • Projet de Fin d’Études 2010 3. Modèles économiques Tableau 1 : Forces et faiblesses des différents modèles économiques Quand on veut réaliser un système de M-Banking, on doit choisir un modèle économique à suivre avant de se lancer dans la préparation de la solution informatique. Ici, nous avons 3 modèles économiques : un modèle en partenariat avec l’opérateur, un modèle d’hébergement chez l’opérateur et un modèle indépendant de l’opérateur. Le modèle en partenariat avec l’opérateur est basé sur le fait que la solution appartient à l’opérateur et donc le rôle de la banque se limite à la gestion des comptes. Ce cas de figure n’est pas favorable à la banque puisque l’opérateur peut imposer l’exclusivité d’utilisation à ces clients et peut aussi imposer une grande marge commerciale en sa faveur puisqu’il est l’élément central dans l’opération. Ceci dit, la banque a un grand avantage car elle ne se soucie plus des problèmes de sécurité et de compatibilité. Le modèle d’hébergement chez un opérateur est basé sur le fait que la banque loue soit un espace mémoire sur les cartes SIM de l’opérateur soit l’utilisation du service USSD de l’opérateur pour lancer son application. Ce cas présente, aussi, plusieurs inconvénients pour la banque, comme le risque d’exclusivité imposé par l’opérateur, la commission de l’opérateur relativement grande et le École Nationale Supérieure d’Électricité et de Mécanique 28
    • Projet de Fin d’Études 2010 risque de réticence des opérateurs qui ont déjà développé des offres de M-Banking même si elle a l’avantage de ne pas se soucier de la sécurité et de la compatibilité. Le troisième modèle économique est le modèle indépendant de l’opérateur. C’est le modèle choisi pour notre projet. Ce modèle se base sur le fait que la solution est celle de la banque et qu’elle n’aura besoin d’aucun contrat avec les opérateurs pour utiliser sa solution. Ceci a de nombreux avantages financiers pour la banque mais lui demande de relever un grand défi technique qui est d’assurer la sécurité et la compatibilité de son application avec le parc mobile marocain. 4. Gestion du projet Figure 2 : Diagramme de Gantt relatif à la gestion de projet Afin de mener à bien notre projet, nous avons planifié les différentes tâches en accordant à chacune une durée précise. Les 3 principales phases du projet qui sont l’étude, la conception et le développement se sont déroulées comme suit : - L’étude : du 24/02 au 01/04 École Nationale Supérieure d’Électricité et de Mécanique 29
    • Projet de Fin d’Études 2010 - La conception : o Étape 1 : du 02/04 au 30/04 o Étape 2 : du 01/05 au 31/05 - Le développement : du 30/04 au 31/05 École Nationale Supérieure d’Électricité et de Mécanique 30
    • Projet de Fin d’Études 2010 Chapitre 2 : Contexte théorique École Nationale Supérieure d’Électricité et de Mécanique 31
    • Projet de Fin d’Études 2010 1. Introduction L’architecture GSM (Global System for Mobile communication) est utilisée par les pays qui offrent des services de communication par téléphone mobile à leurs concitoyens (c’est le cas du Maroc). Le réseau GSM a été initialement conçu pour l’envoi et la réception de la voix mais, avec l’augmentation du nombre d’utilisateurs, le mobile est devenu un outil de transmission des données. Le moyen de transmission de données le plus populaire est le SMS (Short Message Service). Ce service permet l’envoi de messages avec un faible coût. Il est aussi fiable pour la transmission des données non secrètes et utilise un mode asynchrone ce qui permet le stockage du message chez l’opérateur jusqu’à ce qu’il soit envoyé vers sa destination finale. Les banques offrent le service de M-Banking à leurs clients pour réaliser leurs transactions bancaires via SMS. L’utilisateur peut réaliser la transaction à n’importe quel moment et de n’importe quel endroit. La transmission de SMS est, en général, rapide et sa livraison au destinataire est fiable, ce qui fait que le client s’attend à ce que la transaction se fasse en temps réel. Le problème, ici, est que les messages SMS ne sont pas totalement sécurisés. Il y a plusieurs failles de sécurité dans le réseau GSM et par conséquent une grande faiblesse du service de M-Banking s’il repose directement sur la couche SMS. Dans ce chapitre, nous allons donner un aperçu sur l’architecture GSM, rappeler les différentes failles de sécurité ainsi que quelques solutions qui ont été proposées pour résoudre ces problèmes. A la fin du chapitre, nous verrons quelques exemples de services de M-Banking offerts par des banques de l’Afrique du Sud. 2. Architecture GSM 2.1. Généralités Le GSM est un standard très complexe : il est décrit par une documentation de plus de 7000 pages. Le principe de base est donné par la figure 1 où les lignes continues représentent la transmission des données entre les composants essentiels et les lignes pointillées montrent les connexions internes utilisées pour la maintenance. École Nationale Supérieure d’Électricité et de Mécanique 32
    • Projet de Fin d’Études 2010 Figure 3 : Architecture GSM Clé : – MS : (Mobile Station) téléphone mobile – BTS : (Base Transceiver Controller) Antenne téléphonique – BSC : (Base Station Controller) gestionnaire de BTS – MSC : (mobile Switch Center) administration de la plateforme – OMC : (Operation and Management Center) maintenance – SMSC : (Short Message Service Center) administration des SMS – ISC : (International Switching center) administration du Roaming. – EIR : (Equipment Identity Register) identification des mobiles via IMEI – AUC : (Authentification center) authentification – HLR : (Home Location Registry) Base de données de localisation – VLR : (Visitor Location Registry) Base de données de localisation • Le mobile initie la communication en envoyant un signal radio au BTS ; • Le BTS reçoit le signal radio du mobile, le transforme en signal numérique et le transmet au BSC ; École Nationale Supérieure d’Électricité et de Mécanique 33
    • Projet de Fin d’Études 2010 • Le BSC contrôle plusieurs BTS, à la fois, dans une zone géographique déterminée. Il renvoie les signaux reçus au MSC qui interroge à son tour les bases de données HLR et VLR pour localiser le mobile de destination ; • Si le signal a comme origine ou comme destination un téléphone fixe, alors le MSC envoie le signal au GSMC (Global Service Mobile Commutator). Si le signal reçu est un SMS alors il sera envoyé et stocké dans le SMSC jusqu’à ce qu’il soit délivré au destinataire. Même après avoir été délivré, le contenu du SMS reste stocké dans la base de données du SMSC une certaine période dont la durée dépend de l’opérateur ; • Si le signal est un appel international, alors il sera dirigé vers le pays destinataire via l’ISC ; • La maintenance est gérée par l’OMC. L’EIR et l’AUC sont des bases de données utilisées respectivement pour identifier le mobile et pour authentifier l’utilisateur. 2.2. Notions de réseaux cellulaires Les réseaux de téléphonie mobile sont basés sur la notion de cellules, c'est-à-dire des zones hexagonales se chevauchant afin de couvrir une zone géographique. Figure 4 : Découpage en cellules Les réseaux cellulaires reposent sur l'utilisation d'un émetteur-récepteur central au niveau de chaque cellule, appelée « station de base » (BTS). Plus le rayon d'une cellule est petit, plus la bande passante disponible est élevée. Ainsi, dans les zones urbaines fortement peuplées, on utilise des cellules de quelques centaines de mètres tandis que de vastes cellules d'une trentaine de kilomètres sont utilisées pour couvrir les zones rurales. Dans un réseau cellulaire, chaque cellule est entourée de 6 cellules voisines (c'est la raison pour laquelle on représente généralement une cellule par un hexagone). École Nationale Supérieure d’Électricité et de Mécanique 34
    • Projet de Fin d’Études 2010 Afin d'éviter les interférences, les cellules adjacentes doivent être de fréquences différentes. En pratique, deux cellules possédant la même gamme de fréquences doivent être éloignées d'une distance représentant deux à trois fois le diamètre de la cellule. Au cours d’un déplacement, il est possible qu’on sorte d’une cellule. Il est nécessaire alors de changer sa station de base tout en maintenant la communication : c'est le transfert intercellulaire ou handover. Pour gérer ce transfert : - le téléphone GSM mesure en permanence la force du signal radio reçu de la station de base et écoute aussi régulièrement les stations de base des cellules voisines ; - Lorsqu’il constate qu’il reçoit mieux une autre station de base que celle avec laquelle il échange les signaux, il en informe sa station de base ; - La station de base décide alors de passer le relais à la station de base voisine et met en œuvre la procédure de handover. Ce processus oblige le mobile GSM à écouter les stations de base des cellules voisines en plus de la station de base de la cellule dans laquelle il se trouve. Pour détecter un changement de cellule pendant un échange de données vocal, le mobile écoute les balises des cellules voisines. Cette écoute se fait entre l’émission et la réception du burst suivant. A cause du manque du temps, le mobile ne pourra faire qu’une mesure de niveau. Pour décoder les informations provenant de la balise d’une cellule voisine, le mobile a besoin davantage de temps, surtout qu’il faut « attraper » le time-slot 0 qui contient les informations recherchées. C’est la raison pour laquelle le mobile s’arrête d’émettre et de recevoir toutes les 26 trames (slot idle), pour écouter et décoder le canal de contrôle d’une cellule voisine. École Nationale Supérieure d’Électricité et de Mécanique 35
    • Projet de Fin d’Études 2010 Figure 5 : Mesure de niveau et décodage des BCH des cellules voisines Clé : o R : Téléphone en réception de conversation o E : Téléphone en émission de conversation o M : Téléphone en réception (mesure de niveau d’une balise voisine) o D : Téléphone en réception (décodage des informations de la balise voisine) L’enregistrement de l’activité en émission d’un mobile GSM montre bien l’arrêt de l’émission toutes les 26 trames, soit toutes les 120 ms. Figure 6 : Mise en évidence de la trame de décodage des voix balises des cellules voisines Durant cette trame 26, le mobile GSM doit écouter et décoder la voie balise de l’une des cellules voisines. 2.3. Carte SIM et téléphone mobile : La carte SIM contient entre autres les informations suivantes : - Numéro de téléphone de l’abonnée (MSISDN) ; - Numéro d'abonné international (IMSI, international mobile subscriber identity) ; École Nationale Supérieure d’Électricité et de Mécanique 36
    • Projet de Fin d’Études 2010 - Etat de la carte SIM ; - Code de service (opérateur) ; - Clé d'authentification ; - Algorithmes de cryptage A3/A8 ; - Code PIN (Personal Identification Code) ; - Code PUK (Personal Unlock Code). Le téléphone portable contient entre autres les données suivantes : - IMEI (International Mobile Equipement Identity) qui est l’équivalent d’une adresse MAC ; - L’algorithme de cryptage A5. 2.4. Les protocoles du standard GSM La figure ci-dessous représente l'architecture des protocoles GSM des différents éléments du réseau. Au niveau applicatif, on distingue les protocoles suivants qui, au travers de différents éléments du réseau, relient un mobile à un centre de communication (MSC) : Figure 7 : Piles de protocoles de différents sous systèmes du réseau GSM • Le protocole Call Control (CC) prend en charge le traitement des appels tels que l'établissement, la terminaison et la supervision. École Nationale Supérieure d’Électricité et de Mécanique 37
    • Projet de Fin d’Études 2010 • Le protocole Short Message Service (SMS) qui permet l'envoi de messages courts au départ d'un mobile. La longueur d'un SMS est limitée à 160 caractères de 7 bits, soit 140 octets. • Le protocole Supplementary Services (SS) prend en charge les compléments de services. La liste de ces services est longue mais, à titre d'exemple, citons le Calling Line Identification Presentation (CLIP), le Calling Line Identification Restriction (CLIR) et le Call Forwarding Unconditional (CFU). • Le protocole Mobility Management (MM) gère l'identification, l'authentification sur le réseau et la localisation d'un terminal. Cette application se trouve dans le sous réseau de commutation (NSS) et dans le mobile car ils doivent tous les deux connaître la position du mobile dans le réseau. • Le protocole Radio Ressource management (RR) s'occupe de la liaison radio. Il interconnecte une BTS et un BSC car ce dernier gère l'attribution des fréquences radio dans une zone. Les trois premiers protocoles applicatifs précités (CC, SMS et SS) ne sont implémentés que dans les terminaux mobiles et les commutateurs ; leurs messages voyagent de façon transparente à travers le BSC et le BTS. École Nationale Supérieure d’Électricité et de Mécanique 38
    • Projet de Fin d’Études 2010 3. Sécurité du standard GSM 3.1. Authentification et confidentialité Avant de pouvoir envoyer des données à travers l’architecture GSM, il faudra s’authentifier dans le réseau. Ce processus en entier est schématisé par la figure suivante : Figure 8 : L’authentification et la génération de la clé Un élément critique de la sécurité est la carte SIM. Le téléphone seul n'est qu'un type de fournisseur de services (afficheur, clavier, interface radio...). La carte SIM possède un numéro de série unique et une clé secrète de 64 bits gravés. De plus, deux algorithmes cryptographiques y sont implémentés : A3 et A8. Le numéro de série est le numéro de téléphone. L’opérateur le transcrit de façon logique en numéro pouvant être lu par les utilisateurs (pourtant, un client peut garder son numéro quand il change sa carte SIM). La relation est similaire à celle entre les numéros Inode et les noms des fichiers sous UNIX/ Linux. La protection par code PIN constitue aussi un petit ordinateur à l'intérieur de la carte SIM. La clé secrète est physiquement protégée contre la lecture de l'extérieur. Il faudrait détruire la carte SIM pour extraire « directement » cette clé. Elle est fournie, par l’opérateur, avec la carte SIM au moment de l’achat. Une copie de cette clé est sauvegardée dans les disques durs de l’opérateur. École Nationale Supérieure d’Électricité et de Mécanique 39
    • Projet de Fin d’Études 2010 Quand le client allume son téléphone, celui-ci envoie le numéro de série de la carte SIM vers la station de base la plus proche. Celle ci l'envoie ensuite vers les ordinateurs centraux de l’opérateur qui connaît le numéro de la clé secrète correspondante et renvoie un numéro aléatoire RAND au client. Ensuite, la carte SIM calcule la signature SRES = A3(RAND, clé) et l'envoie à la station de base. Entre temps, la station de base reçoit le SRES de la part des ordinateurs centraux et le compare à celui du client. S’ils sont identiques, le client est authentifié. Le problème de sécurité ici est que, si un attaquant connaît la clé secrète, il pourra calculer le SRES et donc s’authentifier à la place du client. En même temps, la carte SIM du client et les ordinateurs centraux de l’opérateur calculent aussi la clé de chiffrement Kc= A8(RAND, clé). C'est un numéro codé sur 64 bits qui sert comme code de chiffrement/déchiffrement. Le SRES et la clé Kc sont envoyés ensemble à la station de base. Si le client est authentifié, toutes les communications qu’il réalisera à partir de son téléphone seront cryptées par l’algorithme A5 en utilisant la clé Kc. 3.2. Aspects de la sécurité Comme dans le chiffrement avec clé publique, aucune information secrète n'est transférée en texte clair sur le canal radio non sécurisé et la clé secrète du client ne quitte jamais les ordinateurs centraux du fournisseur. Et qu'est-ce qui se passe dans le cas où le client appelle de l'étranger, à travers les réseaux d’opérateurs qui ne connaissent pas sa clé secrète ? Si un client allume son téléphone dans le réseau d’un opérateur qui a un contrat de roaming avec le sien alors ce réseau reconnaît à qui est le téléphone et demande à l’opérateur du client le triplet approprié [RAND, A3 (RAND, clé), A8 (RAND, clé)]. Cela explique pourquoi la première connexion à un réseau étranger peut durer quelque temps et la seconde fois, elle est aussi rapide qu’une connexion ordinaire (si le réseau étranger n'a plus de triplets, de nouveaux numéros sont requis à temps). Il faut remarquer, encore une fois, que la clé secrète n'est pas révélée, même à un opérateur de confiance. Nous avons montré que si A3, A8 et A5 sont sûrs, alors tout le système est presque sûr. Il ne reste plus que quelques points faibles : - Le téléphone du client est authentifié dans sa station de base, mais pas inversement. Le téléphone n'est pas capable de notifier qu'il se connecte à une fausse station de base. Pour cela, on utilise un appareil nommé IMSI-Catcher. Cette fausse station de base ne connaît pas École Nationale Supérieure d’Électricité et de Mécanique 40
    • Projet de Fin d’Études 2010 la clé du client mais elle peut extraire les informations de la phase initiale de la conversation et contraindre son téléphone à faire des choses qu’il ne veut pas, par exemple désactiver le chiffrement A5. - Les paquets de données n'ont pas de sommes de contrôle cryptographiques fortes. Un attaquant peut les falsifier et les renvoyer vers la station de base afin de se faire passer pour quelqu’un d’autre auprès du destinataire ciblé. Cette attaque est appelée man-in-the-middle. - Les paquets de données possèdent des numéros de séquences non protégés. Cela permet à l'attaquant de renvoyer ces paquets vers le destinataire encore et encore. 3.3. Contournement de l’authentification L'attitude « sécurité par obscurité », par exemple laisser les algorithmes en cachette, n'a jamais été utile pour la sécurité (outre quelques services secrets expérimentés dans la NSA). C'était le destin des algorithmes A3 et A8. Ils n'étaient jamais publiés dans les spécifications GSM ni rendus public. Évidemment, les algorithmes très fréquemment utilisés ne pouvaient pas rester trop longtemps secrets, et enfin, ils ont été révélés. Récemment, les jeunes cryptologues Goldberg et Wagner de Berkeley n’ont eu besoin que d'un seul jour (notamment le 13 avril 1998) pour y trouver des faiblesses. Ils soulignaient que leur approche n'était pas si novatrice et que chaque bon crypto analyste pouvait trouver des trous de sécurité. Figure 9 : L’attaque de Goldberg et Wagner L'attaque de Goldberg et Wagner exigeait un accès à la carte SIM qui va subir une attaque par envoie d’arguments d’entrée RAND. En fonction des réponses SRES obtenues, de nouveaux École Nationale Supérieure d’Électricité et de Mécanique 41
    • Projet de Fin d’Études 2010 RAND sont créés et envoyés à l’entrée. Après environ 150.000 cycles similaires, la clé secrète est révélée et toute la sécurité du téléphone devient inutile. Le pirate est capable d'émuler la carte SIM à l'aide d'un ordinateur PC connecté à un téléphone quelconque et peut utiliser le téléphone d’un client pour différentes sortes d’activités (comme par exemple faire des appels sur le compte du propriétaire du téléphone). L’attaque décrite fonctionne en pratique, ce qui a été démontré par le GCCC (German Chaos Computer Club). Est-ce vraiment si facile ? Non. La carte SIM n'est pas un superordinateur et pour effectuer environ 150.000 appels, il faut à peu près 8 heures. L'attaquant doit cibler une carte SIM pendant tout ce temps là. L'obstacle suivant est le code PIN. Il contient seulement 4 à 8 chiffres, mais après 3 échecs, la carte SIM s’arrête et demande de saisir le code PUK. Si celui-ci est erroné, après le 10ème essai, la carte est désactivée. L'attaque la plus dangereuse peut être effectuée par voie aérienne en envoyant les requêtes aux téléphones allumés. Cela nécessite un équipement spécial (similaire à IMSI- catcher) et beaucoup de temps. Une attaque plus pratique serait de cloner la carte SIM via Bluetooth ce qui donne plein accès à la carte SIM pour faire tous les genres d’attaques destinées à craquer l’authentification. Enfin, la combinaison A3/A8 (appelée aussi COMP128) n'est que la version de base qui peut être utilisée pour mettre au point d’autres versions. La question de modification de ces algorithmes dépend des fournisseurs. En Allemagne, seul Mannesmann (maintenant Vodafone D2) utilisait la forme originale. Et donc certainement, plusieurs opérateurs ont modifié ces algorithmes même si cela ne garantit pas la sécurité des communications comme on le verra par la suite. L’attaque de Goldberg et Wagner a produit un effet secondaire très intéressant. Notamment, dans toutes les cartes SIM testées, le code de déchiffrage Kc généré n'était long que de 54 bits, et pas de 64. Cette réduction a été expliquée par les opérateurs comme une réaction plus souple aux dangers liés à la sécurité. Il serait très intéressant de connaître la cause réelle de cette réduction de la longueur de la clé car elle entraîne une baisse au niveau de la sécurité (déjà très basse). En tout cas, ce n'est pas tellement important puisqu’on peut procéder autrement en contournant le A5. École Nationale Supérieure d’Électricité et de Mécanique 42
    • Projet de Fin d’Études 2010 3.4. Contournement de la confidentialité Seul le trafic qui passe à travers le canal radio est crypté parce que, théoriquement, un attaquant équipé d'un IMSI-catcher peut l'écouter. Le trafic entre la station de base et les passerelles au réseau téléphonique câblé n'est pas chiffré. L'algorithme de chiffrement/déchiffrement A5 (plus précisément A5/1) est présenté par la figure suivante : Figure 10 : Algorithme de chiffrement A5 Cette figure représente le registre LSFR (linear feedback shift register) qui est le registre à décalage à rétroaction linéaire dont la longueur est de 19 bits. Au début, ce registre a une clé (dans cet exemple, sa longueur est de 19 bits). Le déchiffrement d’un bit se fait comme suit : dans la boucle, les bits 12, 17, 18 et 19 sont soumis à l’opération OU exclusif et le résultat est mis dans le bit de position 1 après avoir déplacé les bits 1...18 d’une position vers la droite. L’algorithme peut utiliser ce produit XOR de quatre bits, appelé rétroaction, comme bit-clé ou bit supérieur. Cette clé- bit est soumise à l’opération XOR avec un bit de texte, et en résultat, on obtient le bit chiffré. Toute cette procédure est ensuite répétée pour le bit de texte suivant, et ainsi de suite. La sécurité dépend de la longueur du registre et des positions des bits qui forment la séquence de dérivation (tap sequence). Mais un simple chiffrement LSFR n’est pas suffisant. Les algorithmes modernes utilisent les non linéarités. Dans le cas de l’algorithme A5, nous avons trois LFSRs de longueur 19, 22 et 23 bits (ensemble, ils constituent la clé de 64 bits) avec différentes séquences de dérivation. A la sortie, on obtient le produit XOR des bits moyens. Le bit de seuil est mis à 1, si au moins un bit moyen est mis à 1, autrement, il est mis à 0. Chacun de ces trois LFSR est traité, si son bit moyen est différent du bit de seuil. C’est de la non linéarité et tout cela constitue justement l’algorithme A5. En plus clair, le A5 est aussi appelé chiffrement de flux : la trame de bits qui dépend de la clé est générée indépendamment du texte en clair (p. ex. les données qui doivent être chiffrées), et soumise École Nationale Supérieure d’Électricité et de Mécanique 43
    • Projet de Fin d’Études 2010 à l'opération Xor. Le destinataire doit faire de même pour obtenir de nouveau le texte en clair. Pourtant, si un pirate change un bit dans le flot de données chiffrées en chemin vers la station de base, le même bit sera changé après le déchiffrement. C'est pourquoi, les chiffres continus doivent être utilisés ensemble avec les sommes de contrôle sécurisées. Remarque : ce n'est pas une solution pour sécuriser un réseau GSM. Un attaquant assez intelligent en possession d’un IMSI-catcher est capable de modifier les données... s'il sait où modifier. C'est un danger potentiel pour la transmission des données, mais pas pour les appels vocaux. 3.4.1. Craquer le A5 directement Les deux algorithmes A5/1 et A5/2 sont restés secrets et ne furent révélés qu’en 1994 ; le projet entier fut reconstitué en 1999 par Briceno. En 2000, deux célèbres crypto analystes Biryukov et Shamir ont craqué A5 de façon très étonnante. Pour ce faire, ils avaient besoin d'un PC avec deux disques durs de 73 Go chacun rempli de certaines données (un mathématicien qualifié peut aider à les générer) et d'une sortie d'A5/1 pour deux minutes et une seconde pour les calculs. Et voilà, ils ont réussi à obtenir la clé et à écouter les conversations. 3.4.2. A5/2 – Joie de l’attaquant Dans les années '90’, les politiciens avaient encore peur que A5 puissent devenir trop fort et aider les terroristes et le criminels. Ceci a obligé les opérateurs à implémenter une version moins forte d'A5 appelée A5/2 (pourtant, l'algorithme complet A5 est également appelé A5/1). Une nouvelle attaque révélée en 2003 a une référence pratique. Les auteurs ont profité du fait que les codes de correction des erreurs ont été ajoutés aux paquets de données et tous cryptés ensemble. C'est une sorte de dépendance algébrique à l'intérieur d'un texte chiffré et peut être utilisée pour effectuer une attaque triviale. Quelques dizaines de millisecondes d'écoute d'une communication cryptée et une seconde de calculs suffisent pour le décryptage. Un attaquant a besoin seulement d’un IMSI-catcher qui simule une station de base et qui est placé près du téléphone. Cet IMSI-catcher exige de passer de l'algorithme de chiffrement A5/1 à A5/2 puis, il écoute et envoie toutes les données à un PC quelconque. 3.5. Problèmes de sécurité et SMS Initialement, la communication par SMS a été créée pour l’envoi de données non sensibles à travers le réseau GSM ouvert. L’authentification mutuelle, le cryptage du contenu, la sécurité bout à bout, la non répudiation et plusieurs autres sujets relatifs à la sécurité ont été omis lors de la conception École Nationale Supérieure d’Électricité et de Mécanique 44
    • Projet de Fin d’Études 2010 du standard GSM. Dans ce paragraphe, nous montrons quelques problèmes relatifs à la sécurité des SMS. 3.5.1. Crash d’un mobile De Haas a réalisé des recherches visant à faire crasher un téléphone NOKIA en utilisant un SMS. L’attaquant envoie un SMS malformé au destinataire. Le message malformé provoque une erreur du type « buffer overflow », ce qui a pour effet de bloquer ou d’arrêter le fonctionnement du mobile. Après avoir subi ce genre d’attaque, un mobile crashé peut redémarrer subitement en bloquant et en arrêtant la gestion des messages SMS. 3.5.2. SMS spoofing L’attaque « SMS spoofing » permet à l’attaquant d’envoyer un message vers le destinataire en se faisant passer pour quelqu’un d’autre. Il est possible d’altérer l’adresse de l’expéditeur et c’est de cette façon que l’attaquant usurpe l’identité d’une personne. 3.5.3. Cryptage du SMS Les données SMS sont envoyées en clair. Le seul chiffrement qui se fait pour ces données est réalisé entre le BTS et le téléphone mobile par l’algorithme A5 qui a déjà été craqué comme on l’a mentionné auparavant. Le cryptage bout à bout n’est pas disponible. Un nouveau A5 est nécessaire. 3.5.4. Le déni de service Il existe une vulnérabilité relative au SMSC. En effet, quand le message est reçu au SMSC, il est mis dans une queue au buffer de stockage relative au numéro du destinataire. L’attaquant peut exploiter cette vulnérabilité en envoyant beaucoup de messages vers le destinataire ciblé. Ceci à pour effet de bloquer la queue et de rejeter tous les messages envoyés vers la cible. Ce genre d’attaque ne réussit pas nécessairement. Il suffit que l’opérateur s’en prémunisse en utilisant un outil de « monitoring » pour chaque queue créée dans le buffer de stockage. École Nationale Supérieure d’Électricité et de Mécanique 45
    • Projet de Fin d’Études 2010 3.6. Modèles de SMS sécurisés 3.6.1. SMS Handshaking Protocol Handshaking (poignée de main) M1: C -> S: EPKpub [nom d’utilisateur || Slt || SQ || Rc] M2: S -> C: ESK [RC || RS || SQ] où SQn > (SQn-1 + 1) M3: C -> S: ESK [RC || RS || SQ] où SQn > (SQn-1 + 1) Transmission des données cryptées M4: C -> S: ESK [DTC || SQn] où SQn > SQn-1 + 1 M5: S -> C: ESK [DTS || SQn] où SQn > SQn-1 + 1 ... Mn Clé: C – Client S – Serveur EPKpub[X] – Crypter le message X en utilisant la clé publique du serveur ESK[X] – Crypter le message X en utilisant la clé de session Slt – Le numéro d’initialisation (communément appelé « Salt number ») RC & RS- Le nombre aléatoire généré respectivement par le client et le serveur SQ – Le numéro de séquence DTC & DTS – Les données envoyées respectivement par le client et le serveur Ratshinanga et Al. ont suggéré un « message hanshaking protocol » (« un protocole de messagerie par échange de poignée de main ») à base de clé publique et de clé de session pour le cryptage de la communication entre le client et le serveur. Les étapes ci-dessus illustrent ce protocole. Le client initie la connexion en envoyant son nom et le « salt number » au serveur dans un message crypté en utilisant la clé publique du serveur. Quand le serveur reçoit le message du client, il le École Nationale Supérieure d’Électricité et de Mécanique 46
    • Projet de Fin d’Études 2010 décrypte en utilisant sa propre clé privée, lit le « salt number » et le nom d’utilisateur puis lit le code PIN de l’utilisateur à partir de la base de données. Le serveur calcule ensuite une clé de session en utilisant un générateur de clés secrètes en se basant sur des paramètres d’entrée spécifiques. Le client calcule aussi cette clé de session puis reçoit un message crypté de la part du serveur avec cette même clé : c’est comme ça que la connexion sécurisée s’établit. La clé de session est générée en créant un hash du nom d’utilisateur, du « salt number » et du PIN. L’attaquant ne peut pas générer ce hash sans connaître le PIN de l’utilisateur. Plus le « salt number » est long plus c’est difficile pour l’attaquant de craquer les messages cryptés. Pour éviter les attaques par ré envoi de message, on utilise le numéro de séquence qui est incrémenté par 1 à chaque fois que le message atteint sa destination et c’est comme ça que le client ou le serveur peut savoir si le message a déjà été envoyé ou non. 3.6.2. Quasigroup Un Quasigroup est une structure algébrique ressemblant à un groupe dans le sens où la « division » est toujours possible. Les Quasigroups diffèrent des groupes du fait qu’ils sont toujours associatifs. Le cryptage par Quasigroup est un cryptage symétrique. Pour crypter un message, on applique un élément de support ‘l’ sur le premier élément x1 afin d’obtenir y1 : y1 = l*x1 et ainsi de suite par récurrence on aura yi+1=yi*xi+1 avec i appartenant à [1 … N-1]. Pour décrypter le message, on utilise la même approche et alors on aura xi+1=yiyi+1 avec i appartenant à [1 … N-1]. Ce type de cryptage est un cryptage itératif. 3.7. Exemple de quelques banques 3.7.1. USSD WIZZIT offre le premier service de M-Banking de l’Afrique du sud. Ils ont pour objectif d’atteindre la population non bancarisée avec un service de M-Banking facile d’utilisation : en effet, il suffit d’entrer un code USSD (Unstructured Supplementary Service Data) pour se connecter au serveur bancaire pour réaliser la transaction. D’autres banques, comme la « FNB » demandent à entrer le PIN (mot de passe du compte bancaire) pour réaliser une connexion USSD avec le serveur mais, ceci n’offre pas plus de sécurité, vu que les données bancaires transmises sont stockées en clair chez l’opérateur. 3.7.2. WIG La plupart des banques de l’Afrique du sud utilisent la technologie WIG (Wireless Internet Gateway) comme « Standard Bank » ou « ABSA » pour le transfert des transactions de M-Banking. École Nationale Supérieure d’Électricité et de Mécanique 47
    • Projet de Fin d’Études 2010 La procédure d’enregistrement pour le M-Banking se fait de la manière suivante : le client commence par s’enregistrer auprès de la banque qui lui fournit une carte SIM 32K, puis il doit contacter l’opérateur pour activer le service bancaire sur cette carte. Pour réaliser une transaction bancaire par téléphone, le client lance l’application enregistrée sur sa carte SIM. Un menu contenant les types de transactions possibles s’affiche, il choisit alors le genre de transaction à réaliser et l’envoie via SMS au serveur de la banque qui se charge de l’effectuer. 3.8. Récapitulatif Dans la section 3, nous avons présenté une analyse des différentes approches sécuritaires mentionnées dans ce chapitre, que nous pouvons résumer comme suit : Approches de sécurité existante Failles de sécurité Un message en clair envoyé à travers un L’A5 a été craqué. réseau GSM qui crypte la transmission en utilisant le A5. Les SMS en attente d’être délivrés à Si le contenu du message n’est pas crypté alors un destination sont stockés dans le SMSC employé malveillant pourrait obtenir des données confidentielles. USSD Banking L’authentification ici est basée sur le numéro de l’expéditeur et donc si la carte SIM est perdue ou bien le téléphone est volé, alors on pourra passer des transactions bancaires sans l’accord du détenteur du compte. En plus, le message envoyé est crypté seulement entre le BTS et le mobile et donc il est stocké en clair au SMSC. Authentification par mot de passe L’opérateur peut lire le mot de passe quand il sera stocké au SMSC. La technologie WIG La transaction bancaire est liée à la carte bancaire. Si cette carte est volée, alors on pourra passer des transactions bancaires sans l’accord du détenteur du compte. Tableau 2 : Analyse des approches courantes utilisées pour le M-Banking École Nationale Supérieure d’Électricité et de Mécanique 48
    • Projet de Fin d’Études 2010 Chapitre 3 : Dossier de conception École Nationale Supérieure d’Électricité et de Mécanique 49
    • Projet de Fin d’Études 2010 1. Introduction La couche de sécurité à introduire doit être conforme aux principes d’un service sécurisé, qui sont la confidentialité, l’intégrité, l’authentification, la non-répudiation et la disponibilité. En plus, elle devra offrir plusieurs avantages : - Protocole à haut débit : la couche de sécurité conçue ne doit pas entraîner un grand retard lors de la réalisation des transactions. - Réduction des coûts : nous devons minimiser le nombre de SMS à envoyer pour réaliser une transaction afin de réduire les coûts d’utilisation. - Compatibilité : nous pourrons utiliser l’application de M-Banking sur la plupart des téléphones du parc mobile marocain. - Sécurité : La confidentialité du message transmis par le client à la banque doit être préservée. Tout individu non autorisé à voir les données des clients et qui a pu obtenir le message transféré ne pourrait pas lire son contenu et, si le message est altéré, alors la banque devrait pouvoir remarquer que le contenu du message a changé. 2. Vue globale du système La structure de la solution que nous proposons pour le M-Banking est divisée en 4 parties : - L’application mobile qui est responsable de la génération du SMS sécurisé et de son envoi à travers le réseau GSM au serveur bancaire. - Le serveur bancaire téléphonique qui reçoit le SMS et l’envoie au serveur PC via le Bluetooth. - Le serveur PC qui écoute les messages entrants, les décrypte et suit un protocole de sécurité bien précis pour vérifier la sécurité du message reçu. - La base de données qui contient toutes les données bancaires des clients. 3. Les couches du protocole Le processus de communication entre le serveur bancaire et la base de données est indépendant de celui entre le mobile du client et le serveur bancaire. Dans ce projet, la sécurité de la communication entre le mobile client et le serveur bancaire est cruciale. La figure suivante montre la pile des couches du protocole que l’application doit suivre : École Nationale Supérieure d’Électricité et de Mécanique 50
    • Projet de Fin d’Études 2010 Figure 11 : Pile des couches du protocole pour l’envoi et la réception de SMS sécurisés Dans ce système, l’application mobile est la seule qui peut initier la communication avec le serveur bancaire. La figure ci-dessus peut être décrite de la façon suivante : - La couche « application bancaire » fournit une interface entre l’utilisateur et l’application. Elle prend les données bancaires de l’utilisateur et les transforme en un format interprétable par la machine. - La couche « SMS sécurisé » est responsable de la traduction des informations de l’application bancaire mobile sous forme d’un message sécurisé. - La couche « SMS » quant à elle, reprend le message sécurisé et lui donne la forme d’un SMS standard. - La couche « SMTP » est le protocole standard de transmission des SMS qui permet de véhiculer le SMS entre le client et la banque. - Le réseau « GSM » est le réseau à travers lequel le message est transmis sous forme d’ondes radio. Quand le serveur bancaire reçoit le message, le processus inverse est lancé, en recevant le SMS, en décryptant son contenu, en vérifiant la validité de son contenu, en réalisant la transaction bancaire et enfin, en renvoyant le résultat de la requête au client sous forme d’un SMS sécurisé. École Nationale Supérieure d’Électricité et de Mécanique 51
    • Projet de Fin d’Études 2010 4. Préconception Avant de se lancer dans la conception, on admet que : - Le client fait confiance au serveur bancaire ; - L’accès à la base de données est impossible à partir de l’extérieur ; - L’utilisateur dispose d’un compte bancaire au préalable ; - L’utilisateur choisit, durant l’enregistrement, un mot de passe (PIN) que lui seul et la banque sont sensés connaître ; - La banque dispose d’une méthode sécurisée pour la distribution de l’application à ses clients ; - L’utilisateur peut avoir une liste de mots de passe OTP lors de l’enregistrement ou bien sur une simple demande ; - Le client peut demander une nouvelle liste afin que l’ancienne soit désactivée si la liste de mot de passe OTP est perdue. École Nationale Supérieure d’Électricité et de Mécanique 52
    • Projet de Fin d’Études 2010 5. Vue globale sur le processus Dans le réseau GSM, les SMS sont envoyés d’une manière asynchrone vers le destinataire. L’expéditeur ne peut savoir si le destinataire a reçu le message que lorsqu’il reçoit un message de confirmation de la livraison de la part de l’opérateur. Le protocole que nous avons conçu, utilise lui aussi un envoi de message de manière asynchrone. Figure 12 : Vue globale sur le système réalisé Puisque ce protocole a besoin de réaliser une communication asynchrone, on peut penser à le diviser en 2 parties. La première partie est relative à la génération de messages tandis que la seconde concerne la vérification de la sécurité du message envoyé. 5.1. Génération et envoi du SMS sécurisé L’application mobile demande toutes les données bancaires du client qui sont : le numéro de compte, le mot de passe du compte, le numéro de séquence et le mot de passe OTP. Ces informations sont utilisées pour générer le SMS sécurisé à envoyer au serveur bancaire. L’application a un numéro de version déjà prédéfini qui est inséré dans le message. La signature est un numéro qui peut assurer l’intégrité du message pour le destinataire. Quelques uns des champs utilisés pour la signature sont cryptés et d’autres non. Ceci assure l’intégrité et la facilité d’utilisation sachant qu’un attaquant ne saura pas calculer la signature car il ne connait pas le contenu crypté. Si l’intégrité du message est compromise, la transaction sera rejetée par le serveur. Dans les sections qui suivent nous décrirons les champs utilisés pour calculer la signature. Les champs à crypter dépendent du besoin du développeur. Ici, nous avons choisi de crypter quelques champs et de laisser les autres pour alléger la charge sur le serveur tout en conservant le maximum de sécurité possible. L’algorithme utilisé pour le cryptage est un algorithme de cryptage École Nationale Supérieure d’Électricité et de Mécanique 53
    • Projet de Fin d’Études 2010 symétrique. La clé utilisée pour le cryptage est une clé jetable, appelée communément clé OTP (One Time Password) et que seuls le client et la banque connaissent. Quand l’application termine la génération du contenu sécurisé, elle le met dans un message SMS suivant la structure que nous décrirons dans le paragraphe « structure du message ». 5.2. Réception et décodage du SMS sécurisé Quand le serveur reçoit le message, il le décrypte suivant la structure qui sera décrite dans les sections suivantes. Le serveur commence par vérifier le numéro de version du message. S’il est correct, alors il passe aux autres étapes de vérifications. Ensuite, il lit le numéro du compte et vérifie s’il existe ou non dans la base de données. S’il existe, il vérifie si le numéro de séquence utilisé est correct. Une fois ces vérifications de sécurité terminées (sans rejet), le serveur charge le mot de passe OTP à partir de sa base de données. Cet OTP est indexé dans la base de données par le numéro du compte et le numéro de séquence du client. Le serveur utilise ce mot de passe pour décrypter le contenu du message. Si le décryptage est réussi alors l’OTP utilisé est éliminé et le numéro de séquence est incrémenté par 1. Après le décryptage du message, le serveur lit le contenu sécurisé requis pour le calcul de la signature puis la détermine en utilisant le même algorithme que celui du client et compare le résultat avec la signature du message : si les deux signatures sont identiques, alors le message n’a pas été altéré en cours de route, sinon il sera écarté. Si cette étape est réussie, le serveur charge le mot de passe du compte du client (PIN) et le compare avec celui du message. Si toutes ces vérifications de sécurité réussissent alors la transaction sera réalisée. École Nationale Supérieure d’Électricité et de Mécanique 54
    • Projet de Fin d’Études 2010 6. Structure du message Le SMS sécurisé est composé de plusieurs champs pour répondre aux différentes contraintes de sécurité. La figure ci-dessous montre la structure détaillée du message sécurisé où le nombre de bits assignés à chaque champ dépend du niveau de sécurité requis. Figure 13 : Structure du SMS sécurisé Le rôle de chaque champ peut être décrit de la façon suivante : - Version : la version de l’application mobile correspond à une valeur prédéfinie. Le premier test de sécurité concerne ce champ, puisque le serveur vérifie si le numéro de version est valide ou non. Si le numéro de version du message n’est pas celui de l’application alors le message ne sera pas traité car il se peut qu’un message qui n’est pas destiné à ce genre de transaction arrive par erreur au serveur bancaire et donc l’utilité de ce champ est de diminuer la charge au niveau du serveur. - AccID : le numéro de compte de l’utilisateur, qui permet au serveur de déterminer les coordonnées à charger à partir de la base de données. Ce champ assure une indépendance vis-à-vis du mobile utilisé pour réaliser la transaction. - Seq : est le numéro de séquence relatif au mot de passe OTP actuel. Il permet la synchronisation de l’OTP de l’utilisateur avec la liste des OTP du serveur. S’ils ne sont pas synchronisés (c'est-à-dire que le numéro de séquence du message est différent de celui de la base de données) alors une attaque imperceptible a, peut être, eu lieu. École Nationale Supérieure d’Électricité et de Mécanique 55
    • Projet de Fin d’Études 2010 - Longueur du message crypté : ce champ contient le nombre de bits cryptés qui suivent, c’est-à-dire la longueur du champ suivant. Il a donc pour but d’aider le serveur dans la manœuvre de décryptage du message. - Longueur de la signature : ce champ a le même rôle que le champ précédant mais pour la signature. - Signature : ce champ contient la signature du message qui a pour rôle de préserver son intégrité. Cette signature est calculée en utilisant les valeurs des champs : Version, AccID, Seq, PIN, Type de Transaction et information de la transaction. Le contenu de la partie cryptée par l’OTP est le suivant : - PIN : ce champ contient le mot de passe du compte bancaire du client qui est utilisé pour l’authentification. - Type de transaction : comme son nom l’indique, ce champ indique au serveur quel genre de transaction le client voudrait réaliser. - Information de la transaction : ce champ contient les données nécessaires pour que la transaction puisse avoir lieu. Ces données dépendent du type de transaction choisie: o Si la transaction est « voir solde », le serveur n’a besoin d’aucune donnée supplémentaire. Mais, pour assurer la sécurité de la transaction contre une éventuelle attaque du type « Brute Force » et pour garder son type secret, on utilise le bourrage qui permet d’atteindre la taille maximale du message. o Si la transaction est « transférer argent », le serveur a besoin de connaître le compte destinataire de cet argent et bien sûr le montant à transférer. Là, aussi, on utilise le bourrage pour les mêmes objectifs qu’une transaction « voir solde ». 7. Sécurité du protocole Le protocole de sécurité que nous avons conçu doit être conforme aux principes d’un service sécurisé. Les sections suivantes décrivent comment ce protocole répond à chacun de ces principes. 7.1. Confidentialité La confidentialité est assurée par le cryptage du message en utilisant une clé symétrique OTP partagée entre le client et le serveur bancaire. La force de la confidentialité du message dépend École Nationale Supérieure d’Électricité et de Mécanique 56
    • Projet de Fin d’Études 2010 intrinsèquement de la force de l’algorithme de génération de mot de passe pseudo-aléatoire utilisé et de la force de l’algorithme de cryptage. Ceci dit, le client ne doit pas divulguer son mot de passe OTP afin de ne pas compromettre la sécurité de son propre compte. 7.2. Intégrité L’intégrité est assurée par la signature du message basée sur des éléments cryptés et d’autres non cryptés. Si un seul élément du message est altéré en cours de route (soit par une mauvaise transmission soit par une tierce partie) alors le serveur pourra le savoir en recalculant la signature et en la comparant avec la signature du message. La force de l’intégrité du message dépend de façon intrinsèque de la force de l’algorithme de hachage et de la confidentialité du message. 7.3. Authentification Pour que le serveur puisse authentifier l’utilisateur, il faut que ce dernier lui envoie les données d’authentification correctes qui sont le numéro de compte et le mot de passe du compte qui va avec. L’authentification se fait donc à base du mot de passe PIN choisi initialement par le client lors de l’ouverture de son compte auprès de la banque. La force de l’authentification dépend de la manière avec laquelle le client a choisi ce mot de passe (il y a des mots de passe plus forts que d’autres), de l’intégrité du message et de sa confidentialité. 7.4. Non-répudiation Le mot de passe OTP est supposé connu seulement par la banque et par le client. La banque ne génère pas le même mot de passe OTP plus d’une fois et donc chaque OTP est unique dans la base données du serveur bancaire. Chaque paire mot de passe OTP, numéro de séquence ne peut être utilisée que par un et un seul client. La banque ne peut générer la même paire (mot de passe OTP, numéro de séquence) pour deux utilisateurs différents et donc un client ne peut pas nier avoir envoyé un message parce qu’il est le seul qui a cette paire unique (OTP, Seq) pour crypter le message. On peut donc dire que la paire (OTP, Seq) est semblable à une signature sur un chèque bancaire. 7.5. Disponibilité La disponibilité ici dépend fortement de la disponibilité de l’opérateur. Si le réseau de l’opérateur est en panne alors une transaction devra attendre son rétablissement avant de pouvoir être traitée par la banque. Ce problème peut être évité en utilisant plusieurs téléphones serveurs appartenant chacun à un opérateur différent : en effet, la probabilité pour que tous les opérateurs tombent en panne au même moment est très faible et donc la disponibilité côté serveur bancaire pourra être assurée. École Nationale Supérieure d’Électricité et de Mécanique 57
    • Projet de Fin d’Études 2010 Un autre facteur qui intervient dans la disponibilité est le dimensionnement de la plateforme du serveur bancaire : en effet, plus on a de téléphones serveur, plus on peut recevoir de requêtes et, plus le serveur PC est puissant, plus on pourra traiter de requêtes. Le décryptage et le calcul de la signature sont deux traitements qui peuvent alourdir le PC serveur. C’est pour cela que le protocole de sécurité que nous avons conçu minimise la charge utile à traiter en laissant un en-tête composé de 3 champs en clair afin de pouvoir éliminer directement tout message qui vient par erreur au serveur bancaire. En plus de l’en-tête, nous utilisons des ports d’envoi et de réception spéciaux pour les messages, qu’on ne peut utiliser en général qu’avec une application qui gère les ports du téléphone (et donc même si quelqu’un envoie par inadvertance un message au serveur bancaire celui-ci ne sera même pas capté parce qu’il n’a pas été envoyé sur le port d’écoute du serveur). Approches de sécurité courantes Le protocole de sécurité que nous avons conçu Le SMS est crypté en A5 seulement entre le Nous utilisons un puissant algorithme de cryptage mobile et le BTS puis il est gardé par avant l’envoi du SMS. Le serveur et le mobile ont les l’opérateur en clair dans le SMSC jusqu’à ce moyens pour crypter/décrypter le SMS sécurisé. qu’il soit remis au destinataire. Utilisent quelquefois le mot de passe du Nous utilisons le mot de passe OTP qui est un mot de compte seulement. passe jetable et donc même si un attaquant obtient l’OTP utilisé il ne pourra pas s’authentifier auprès du serveur. « SMS Handshaking Protocol » permet un Pour le protocole que nous avons conçu, un seul échange de clé entre l’expéditeur et le message, initie, sécurise et réalise la transaction avec destinataire pour pouvoir initier une session. le serveur, ce qui le rend sûr, rapide et moins coûteux. Ceci est coûteux côté temps et argent. La vérification en utilisant l’USSD dépend Ici, les transactions se passent d’une manière du numéro de l’expéditeur. En plus, le indépendante du numéro de mobile. Ceci permet, en message USSD est crypté seulement entre le plus la sécurité bout à bout utilisée, d’éviter toute mobile et le BTS. tentative de passer une transaction illégale auprès de la banque. Tableau 3 : Comparaison entre les approches de sécurité courantes dans le domaine du M-Banking et le protocole que nous avons conçu dans le projet École Nationale Supérieure d’Électricité et de Mécanique 58
    • Projet de Fin d’Études 2010 8. Diagramme de cas d’utilisation 8.1. Cas d’utilisation 1 : Lancer l’application Le client veut utiliser son mobile pour réaliser une transaction bancaire distante. Il commence par lancer l’application mobile de M-Banking et choisit le type de transaction bancaire qu’il veut faire. 8.2. Cas d’utilisation 2 : Sélection de la transaction Le client est devant deux choix, soit il veut vérifier son solde soit il veut transférer de l’argent. Les champs à remplir dépendent de ce choix. 8.3. Cas d’utilisation 3 : L’envoi du message Une fois les détails requis saisis, le client confirme l’envoie du message au serveur bancaire. L’application mobile génère un SMS sécurisé contenant tous les détails nécessaires à la réussite de la transaction puis l’envoie à travers le réseau GSM vers sa destination finale. 8.4. Cas d’utilisation 4 : Vérification de la sécurité du message par le serveur Quand le serveur reçoit le SMS, il le lit et décrypte son contenu. Il vérifie l’intégrité du message et réalise l’opération d’authentification. Enfin, il réalise la transaction bancaire souhaitée par le client. 8.5. Cas d’utilisation 5 : Réponse du serveur Après la réalisation de la transaction, le serveur bancaire envoie le résultat de la transaction au client pour l’informer que l’opération a été bien accomplie. S’il y a un problème dans le traitement de la requête du client, un message lui sera envoyé pour le prévenir. École Nationale Supérieure d’Électricité et de Mécanique 59
    • Projet de Fin d’Études 2010 Figure 14 : Diagramme de cas d’utilisation École Nationale Supérieure d’Électricité et de Mécanique 60
    • Projet de Fin d’Études 2010 9. Diagrammes de classes Dans cette section, nous donnons le diagramme de classes de chaque partie de la solution que nous proposons avec l’explication détaillée des classes utilisées. 9.1. Diagramme de classes de l’application client Figure 15 : Diagramme de classes de l’application mobile 9.1.1. La classe « InterfaceUtilisateur » Cette classe est responsable de l’interaction entre le client et l’application mobile. Elle gère tout le menu graphique qui permet au client d’interagir avec l’application. La méthode « start() » est la méthode utilisée pour lancer l’application. La méthode « envoyerMessage() » est utilisée pour l’envoi de messages SMS via l’interface de messagerie du téléphone. La méthode « recevoirMessage() » écoute les messages rentrants sur un port d’écoute donné. Les méthodes « getCryptage() » et « getSignature() » sont utilisées pour le cryptage et la signature d’un contenu donné. La méthode « créerMessage() » crée le SMS en disposant les différents éléments de la transaction suivant le modèle de sécurité dont nous avons déjà parlé auparavant. Cette classe utilise une chaîne de connexion « MessageConnection » pour se connecter et une variable de type « Message » pour le stockage des messages entrants ou sortants de l’application. École Nationale Supérieure d’Électricité et de Mécanique 61
    • Projet de Fin d’Études 2010 9.1.2. La classe « Bourrage » Le bourrage est l’opération qui consiste à ajouter un ensemble de bits aléatoires au mot initial afin d’atteindre une longueur donnée. La méthode « bourrer() » consiste à ajouter une séquence aléatoire de bits à la fin du mot alors que la méthode « bourrerFront() » est utilisée pour ajouter le bourrage avant le premier bit du mot. 9.1.3. La classe « Signer » C’est la classe responsable du calcul de la signature du message. La méthode « créerEmpreinte() » crée l’empreinte numérique du message avant de le signer avec la méthode « signer() ». La méthode « comparer » permet de vérifier la signature d’un message reçu par l’application mobile. 9.1.4. La classe « Crypter » Cette classe est responsable du cryptage du message. Lorsque le client choisit d’envoyer le message, cette classe intervient pour crypter son contenu avec la méthode « crypterMessage() ». Si le client reçoit une réponse sécurisée du serveur, la méthode « décrypterMessage() » est utilisée pour lire son contenu. La méthode « créerMachine » sert à créer l’outil qui va être utilisé soit pour le cryptage soit pour le décryptage du message. 9.2. Diagramme de classes du serveur téléphonique Figure 16 : Diagramme de classes de l’application serveur téléphonique 9.2.1. La classe « MessageSMS » Cette classe commence par créer une chaîne de connexion « con » et une variable « msg » pour stocker les messages envoyés ou reçus. Elle lance l’écoute des messages entrants sur un port donné et les transmet à la classe Bluetooth avec la méthode « lanceréception() ». La méthode « envoyerMsg() » permet d’envoyer la réponse du serveur au client à travers le réseau GSM. École Nationale Supérieure d’Électricité et de Mécanique 62
    • Projet de Fin d’Études 2010 9.2.2. La classe « Bluetooth » Cette classe crée d’abord une chaîne de connexion « con » avec le PC serveur et pour cela, elle commence par le détecter via la méthode « détecter() » puis lance l’écoute sur un port donné en utilisant la méthode « recevoir() » qui, une fois le message reçu du serveur, le transmet à la classe « MessageSMS » afin de l’envoyer au client concerné. La méthode « envoyer() » reçoit les messages des clients qui lui sont transmis par la classe « MessageSMS » et les envoie au PC serveur 9.3. Diagramme de classes du serveur PC Figure 17 : Diagramme de classes du serveur PC 9.3.1. La classe « ServeurBanque » Cette classe gère la coordination entre le serveur téléphonique et le serveur PC. La méthode « lancerServeur() » initialise la communication avec le serveur téléphonique. Le « Main() » gère tout le système. Une fois le serveur PC est lancé, il commence l’écoute sur un port donné pour les éventuels messages qui lui seront transmis par le serveur téléphonique. Quand il reçoit un message, la classe « RépondreMessage » génère un message de réponse en se basant sur les résultats des autres traitements qui vont être réalisés par les autres classes : c’est pour ça qu’elle constitue une classe centrale dans l’application. École Nationale Supérieure d’Électricité et de Mécanique 63
    • Projet de Fin d’Études 2010 9.3.2. La classe « RépondreMessage » Cette classe prend en charge les messages reçus. La méthode « getRéponse() » va générer le message de réponse et ceci d’abord en faisant subir au message reçu tous les traitements des autres classes avant de crypter la réponse en utilisant la méthode « crypterRéponse() ». Ces traitements commencent par décortiquer le message en le divisant de la même manière que ce qu’on a vu à propos de la structure du message et en mettant chaque partie dans le champ qui lui correspond dans la classe « GestionMessage ». 9.3.3. La classe « GestionMessage » Cette classe gère le message reçu en le répartissant sur les différents champs de la classe avant de commencer les traitements. Ces traitements concernent aussi bien les vérifications (les méthodes « vérifVersion() », « vérifAccIDExist() » et « vérifSeq() ») des 3 premiers champs du message que l’obtention d’informations en utilisant les « getters » car les champs de la classe sont de nature « private » afin d’améliorer la sécurité propre du serveur. 9.3.4. La classe « Détailbancaire » Cette classe encapsule les données du message nécessaires pour la réalisation de la transaction bancaire après avoir décrypté le message. Elle contient entre autres le PIN qui est utilisé pour l’authentification du client avant la réalisation de la transaction. 9.3.5. La classe « AppelBD » Cette classe contient des méthodes pour se connecter à la base de données afin de récupérer des données ou bien de la mettre à jour. Les données récupérées sont utilisées pour la vérification de sécurité du message reçu. Les données avec lesquelles on met à jour la base de données sont employées pour réaliser la transaction demandée par le client. 9.3.6. Les classes « Crypter » et « Signer » Comme leur nom l’indique, ces deux classes sont utilisées pour le cryptage/décryptage mais aussi pour signer/vérifier la signature des messages. École Nationale Supérieure d’Électricité et de Mécanique 64
    • Projet de Fin d’Études 2010 9.4. Diagramme de classes du serveur BD Figure 18 : Diagramme de classes du serveur BD 9.4.1. La classe « BDConnect » Cette classe utilise plusieurs méthodes internes pour la création de l’objet de connexion à la base de données (Object DataBase Connection ODBC). Elle commence par construire le dit objet lors de l’initiation de la communication avec la base de données. Elle maintient l’état de la connexion afin de pouvoir réaliser les différentes transactions avec la base de données. Les méthodes « getConnection() » et « getStatement() » permettent de reprendre les valeurs de l’objet de connexion et de la chaîne de connexion d’une manière sécurisée en utilisant les « getters ». 9.4.2. La classe « BDServeur » Cette classe utilise la classe « BDConnect » pour préserver sa connexion avec la base de données. Elle contient différentes méthodes pour l’insertion ou le chargement et la mise à jour de la base de données. 9.4.3. La classe « AppelBD » Cette classe est identique à la classe « AppelBD » du serveur PC. Elle contient des méthodes pour appeler celles (les méthodes) du serveur PC. Cette classe est semblable à une interface du serveur BD. Elle permet une grande facilité de manipulation de la base de données sans affecter le serveur PC. Elle est toujours en écoute des requêtes venant du serveur PC. École Nationale Supérieure d’Électricité et de Mécanique 65
    • Projet de Fin d’Études 2010 9.4.4. La classe « MdpDriver » Cette classe génère les listes de mots de passe OTP pour les clients de la banque en se basant sur la classe « GénérateurMdp ». Cette classe est destinée à être utilisée par la banque : le client n’a aucune autorité pour choisir son mot de passe OTP. La méthode « générerMdps() » génère la liste de mots de passe pour un client donné et insère cette liste dans la base de données après avoir vérifié que ces mots de passe ne se répètent pas chez un autre client. Ceci permet de garder des mots de passe OTP « uniques » dans la base de données. 9.4.5. La classe « Générateur Mdp » Cette classe Génère les mots de passe OTP en se basant sur une graine (le nombre avec lequel on initialise la génération d’OTP). Pour cela, elle utilise la méthode « nextMdp() ». École Nationale Supérieure d’Électricité et de Mécanique 66
    • Projet de Fin d’Études 2010 10. Diagramme de séquences La figure suivante illustre le diagramme de séquences qui gère tout le système. Il décrit tout le processus de fonctionnement de l’application dans les moindres détails. Figure 19 : Diagramme de séquences École Nationale Supérieure d’Électricité et de Mécanique 67
    • Projet de Fin d’Études 2010 11. Compatibilité En informatique, la compatibilité prend deux aspects : la compatibilité logicielle et la compatibilité matérielle. Chacune de ces compatibilités comporte deux volets : une compatibilité ascendante et une compatibilité descendante. Dans ce chapitre, nous aborderons la compatibilité matérielle de notre solution. La compatibilité matérielle ascendante veut dire qu’un logiciel peut fonctionner sur un matériel plus ancien pendant que la compatibilité matériel descendante signifie que le logiciel peut fonctionner sur du matériel plus récent. Afin de bien comprendre ce que représente la compatibilité dans le domaine de la téléphonie mobile, il faut introduire certaines notions indispensables relatives à Java ME. 11.1. Java ME Java ME (anciennement appelé J2ME) est le framework Java spécialisé dans les applications mobiles. Des plates-formes Java compatibles avec Java ME sont embarquées dans de nombreux téléphones portables et PDA. Figure 20 : Constituants de Java ME Une plate-forme J2ME est composée : - D’une machine virtuelle Java capable d'exécuter les applications Java ; - D'une « configuration », c'est-à-dire un sous-ensemble des classes et bibliothèques Java qui contiennent le minimum de codes nécessaires pour faire fonctionner une machine virtuelle Java (JVM) ; - D'un « profil », c'est-à-dire d’un ensemble d'API Java qui définit la façon dont les applications se connectent à l'interface logique des téléphones portables. École Nationale Supérieure d’Électricité et de Mécanique 68
    • Projet de Fin d’Études 2010 11.2. Machines virtuelles, configurations et profils Pour les systèmes embarqués, deux types de machines virtuelles java sont envisageables : - KVM (Kilobyte Virtual Machine) qui est utilisé avec les systèmes à capacités limitées ; - CVM (Compact Virtual Machine) qui est utilisé avec les systèmes à grandes capacités. Les configurations les plus courantes sont : - CLDC (Connected Limited Device Configuration), que l'on retrouve par exemple dans les téléphones mobiles à capacités limitées ; - CDC (Connected Device Configuration), qui est plutôt utilisé dans des décodeurs de télévision numérique et les smartphones, OS Phones, etc. Les profils les plus courants sont : - MIDP (Mobile Information Device Profile), dont sont équipés les téléphones mobiles à capacités limitées ; - « Foundation Profile » qui est destiné à la configuration CDC c'est-à-dire pour les mobiles à grandes capacités. 11.3. Compatibilité et M-Banking Dans notre projet, nous avons travaillé avec le triplet (KVM, CLDC, MIDP) car il assure une compatibilité ascendante (avec les mobiles pour lesquels ils ont été créés) et descendante avec les mobiles à plus grandes capacités comme les smartphones par exemple car ils sont munis du triplet (CVM, CDC, Foundation Profile). Figure 21 : Composition du CLDC et du MIDP École Nationale Supérieure d’Électricité et de Mécanique 69
    • Projet de Fin d’Études 2010 Chapitre 4 : Implémentation École Nationale Supérieure d’Électricité et de Mécanique 70
    • Projet de Fin d’Études 2010 1. Vue d’ensemble Les différentes classes décrites dans le dossier de conception forment un ensemble de quatre applications à implémenter qui sont : l’application client, l’application serveur téléphonique, l’application serveur PC et la partie base de données. Nous avons réalisé cette solution de M-Banking à base du langage Java, et ceci en utilisant Java SE et Java ME (pour l’application embarquée). 2. L’application mobile Pour l’implémentation de l’application client, nous avons considéré deux langages qui sont : NET C# et Java ME mais, nous avons choisi le dernier car : - La plupart des téléphones mobiles vendus partout dans le monde contiennent la machine virtuelle de Java. - Les applications Java sont « portables ». - La technologie Java est une technologie approuvée : elle possède déjà plusieurs bibliothèques qui facilitent la programmation. Nous avons utilisé l’outil NetBeans 6.8 comme environnement de développement intégré. NetBeans contient un module appelé « Sun Java ME sdk 3.0 » qui peut simuler l’utilisation d’un téléphone portable et ainsi, on peut faire des tests directement sur PC. Nous avons réalisé le déploiement de cette application sur un téléphone SAMSUNG GT-S5600 en utilisant les outils : « SAMSUNG New PC Studio », « SAMSUNG Composite USB Driver » et « TkFileExplorer 2.2 ». Puisque l’application est basée sur Java, alors elle marche indépendamment du mobile utilisé mais, la méthode de déploiement d’un mobile à un autre peut changer. Pour permettre à l’application d’envoyer et de recevoir des messages SMS, nous avons eu recours à des APIs de messagerie SMS qui sont installés par défaut sur le simulateur de NetBeans. Pour améliorer la sécurité des transactions, les SMS sécurisés envoyés ou reçus par le client ne sont pas stockés dans le mobile. École Nationale Supérieure d’Électricité et de Mécanique 71
    • Projet de Fin d’Études 2010 2.1. L’interface utilisateur Figure 22 : Prise d’écrans de quelques interfaces de l’application mobile École Nationale Supérieure d’Électricité et de Mécanique 72
    • Projet de Fin d’Études 2010 La figure ci-dessus illustre quelques actions que peut réaliser l’application mobile (les prises d’écrans ont été faites dans le simulateur). Le premier écran est l’écran d’accueil qui s’affiche pendant cinq secondes avant de passer à l’écran principal de l’application. A partir de l’écran principal, on peut soit remplir les champs pour voir son solde, soit remplir ces champs et les champs de la fenêtre du transfert d’argent afin de transférer de l’argent soit demander de l’aide. L’écran principal contient un champ pour entrer le numéro de serveur. Ce champ sera éliminé dans la version finale de l’application : il a été retenu seulement pour les besoins de tests. Les autres champs sont utilisés pour insérer les données nécessaires à la transaction. Nous avons imposé certaines restrictions sur ces champs lors de la programmation, par exemple : - Le numéro de serveur ne peut être qu’en format numérique (même si nous avons introduit un « + » afin de pouvoir utiliser les numéros internationaux), - Le numéro de séquence est un chiffre allant de 0 à 999, - Chaque champ contient un nombre minimum et maximum de caractères qu’on peut saisir. 2.2. Cryptage/décryptage Pour ce projet, nous avons utilisé l’algorithme AES (Advance Encryption Standard) afin de crypter les données bancaires. Le cryptage et le décryptage sont implémentés dans la classe « crypter ». Les méthodes de cryptage transforment la chaîne de caractères à crypter en un tableau de bits qui est, ensuite, crypté bit à bit. Le cryptage AES utilise des clés de 128 bits, 192 bits ou 256 bits. Pour notre projet, nous avons jugé suffisant d’utiliser une clé 128 bits car elle permet : - La création d’un message suffisamment sécurisé (comme on le verra après) ; - Un cryptage rapide ; - et donc, une transaction rapidement réalisée. Le mot de passe OTP du client est donc de longueur 128 bits ce qui équivaut à 16 caractères de 8 bits chacun. Après le cryptage, la longueur du message augmente sensiblement : c’est ce qui explique le champ « charge utile » dont nous n’avions pas parlé lors de la conception de la couche de sécurité. École Nationale Supérieure d’Électricité et de Mécanique 73
    • Projet de Fin d’Études 2010 2.3. La signature L’algorithme choisi ici est le SHA-1 (Secure Hash Algorithm 1). Il est implémenté dans la classe nommée « signer ». SHA-1 est une fonction de hachage cryptographique conçue par la National Security Agency des États-Unis (NSA), et publiée par le gouvernement des États-Unis comme un standard fédéral de traitement de l'information (Federal Information Processing Standard du National Institute of Standards and Technology (NIST)). Elle produit un résultat (appelé « hash » ou condensat) de 160 bits. SHA-1 est le successeur du SHA-0 qui a été rapidement abandonné par le NIST pour des raisons de sécurité insuffisante. Le SHA-0 était légitimement soupçonné de contenir des failles qui permettaient d'aboutir rapidement à des collisions (deux documents différents qui génèrent le même condensat). Face à la controverse soulevée par le fonctionnement du SHA-0 et certains constats que l'on attribue à la NSA, le SHA-0 s'est vu modifié peu après sa sortie (1993) et complexifié pour obtenir le SHA-1 (1995). Une collision complète sur le SHA-0 a été découverte par Antoine Joux et al. en août 2004. 2.4. Envoi du message Avant d’envoyer le message, son contenu doit subir toutes les opérations de sécurité requises. Le contenu du message SMS est la concaténation du numéro de version, du numéro de compte du client, du numéro de séquence, du contenu crypté et de la signature. Le protocole que nous avons créé spécifie que le PIN, le type de transaction et les informations utiles à la transaction soient cryptés. Il spécifie aussi que le message doit avoir une signature afin d’en assurer l’intégrité. Afin d’envoyer le SMS avec le Java ME, il faut utiliser la librairie WMA. Elle utilise le format « sms://<numéro de téléphone>:<port> » pour pouvoir créer une connexion avec le téléphone serveur. Nous utilisons, ici, un autre port que le port standard (port 0) afin de diminuer la charge à traiter par le serveur. Avant d’envoyer le SMS, l’application crée un « Thread » qui va s’occuper de la gestion du message pour que le processus de messagerie soit non-bloquant, c'est-à-dire que l’application pourra gérer, en même temps, un message entrant et un autre sortant. École Nationale Supérieure d’Électricité et de Mécanique 74
    • Projet de Fin d’Études 2010 2.5. Réception de message L’application mobile écoute les messages entrants sur un port donné. Ce port est un numéro de 16 bits qui peut être choisi librement par le programmeur entre 0 et 65635. Les ports utilisés pour notre application peuvent être choisis entre 49152 et 65635 car la rangée 0-49151 est déjà assignée pour des applications privées. On peut réserver l’utilisation d’un certain port à notre application auprès de l’organisation mondiale IANA (Internet Assigned Number Authority). Si le port utilisé par l’application mobile est déjà utilisé par une autre application alors les deux applications ne fonctionneront pas correctement. Pour ce projet, nous avons utilisé le port 50040 comme port d’écoute. Lorsque l’application reçoit un nouveau message, elle lance une nouvelle interface qui demande au client d’entrer son numéro de compte et son PIN afin de décrypter le message reçu. Si les données saisies sont correctes, l’application décrypte le message et vérifie l’intégrité du message reçu. Une fois ces étapes de sécurité réussies, l’application affiche le message à l’écran du mobile. 3. L’application serveur bancaire Puisque les applications mobile et serveur ont quelques fonctionnalités similaires, il serait judicieux de réutiliser des parties de l’application mobile dans la création de l’application serveur. C’est pour ça que nous avons utilisé le même langage de programmation pour le serveur, c'est-à-dire Java (en fait Java ME pour le téléphone serveur et Java SE pour le PC serveur et pour la base de données). Nous avons implémenté l’application serveur téléphonique sur un SAMSUNG-SGH E250 en utilisant les applications SoftickPPP 3.03 et Samsung XXXX Java Uploader 1.1. Pour l’application serveur PC et base de données, nous les avons implémentées sur un PC HP Pavilion dv6000. 3.1. Réception des messages L’application qui tourne au niveau du serveur contient une boucle infinie qui écoute toujours les messages entrants. Quand un message arrive, le serveur le gère de la façon suivante : Figure 23 : Gestion des SMS avant leurs traitements École Nationale Supérieure d’Électricité et de Mécanique 75
    • Projet de Fin d’Études 2010 La figure ci-dessus montre comment le serveur reprend les messages SMS afin de les traiter. Quand la banque reçoit un message SMS, le téléphone serveur le place dans la file de SMS du téléphone. L’application PC serveur reprend ce message puis l’efface de la file du téléphone. Le SMS sera ensuite traité et stocké dans la base de données. Cette persistance est nécessaire en Afrique du sud selon l’ECTASA (Electronic Communications and Transactions Act of South Africa) car cela permet de contrer l’attaque par ré-envoi de messages. C’est un point qu’on a choisi d’intégrer dans notre application comme on le verra par la suite. 3.2. Vérifications de sécurité Le serveur bancaire commence par répartir le message sur les différents champs de la classe « Gestion Message ». On commence par vérifier que le numéro de version est identique à celui choisi pour l’application client. Pour cette application, nous avons choisi pour numéro de version le numéro « 5s7 ». Si les deux numéros de version ne concordent pas, alors le serveur arrête le traitement du message car ceci ne se produit que si le message est une attaque où bien qu’il a été envoyé par erreur au serveur bancaire. Bien sûr, la banque n’envoie aucune réponse à ce genre de message : ceci fait partie de la politique de limitation des dépenses. Si les deux versions concordent, alors le serveur bancaire vérifie l’existence du numéro de compte du client. Si le numéro de compte du client n’existe pas dans la base de données, le serveur envoie un message au client l’informant que le numéro de compte saisi n’existe pas. Si la vérification est réussie, le serveur entame l’étape de vérification du numéro de séquence. L’application serveur compare le numéro de séquence envoyé avec celui de la base de données. S’ils ne concordent pas, un message est envoyé au client pour l’informer qu’il y a eu erreur sur le numéro de séquence. Si les numéros de séquences concordent, la banque récupère le mot de passe OTP de la base de données afin de décrypter le message. Si elle n’y arrive pas, la banque envoie un message au client le prévenant qu’une erreur c’est produite. Si le serveur récupère l’OTP avec succès, il décrypte le message. Si le décryptage échoue, un message d’erreur sera envoyé au client. Si le décryptage réussit, le serveur supprimera l’OTP utilisé de la liste des OTPs valides et incrémentera le numéro de séquence par 1. Les données décryptées sont passées à la classe « Détailbancaire » qui les répartit sur les différents champs qu’elle contient. Ensuite, le serveur vérifie l’intégrité du message en comparant la signature du message à la signature qu’il calcule à base des éléments cryptés et non-cryptés du message. Si École Nationale Supérieure d’Électricité et de Mécanique 76
    • Projet de Fin d’Études 2010 elles diffèrent, le serveur envoie un message au client l’avertissant que le message a été altéré en cours de route. Si l’étape d’intégrité est validée, le serveur passe à l’étape d’authentification, où il compare le PIN du message avec le PIN stocké dans sa base de données. S’ils sont différents, alors il envoie un message d’erreur au client. Si cette dernière étape de sécurité réussit, alors le serveur est sûr de l’authenticité de la transaction. Il commence donc par examiner le type de transaction demandée puis l’exécute. Le résultat de la transaction est ensuite mis sous forme d’un message sécurisé avant d’être envoyé au client. Il est crypté en utilisant un mot de passe 16 bits créé en appliquant une fonction de concaténation au numéro de compte du client et à son PIN. Ce mot de passe est bien sûr secret car seul le client est supposé connaître son mot de passe PIN. C’est avec ce procédé que nous assurons la confidentialité de la réponse. En ce qui concerne l’intégrité du message de réponse, nous lui rattachons sa signature créée en utilisant le SHA-1. 3.3. Réponse aux erreurs Si le message de réponse au client est un message d’erreur, alors il devra commencer, comme n’importe quel message allant du serveur au client, par la chaîne « xlmsdf » qui permet d’éviter à l’application mobile de traiter les messages qui lui arrivent par erreur. Ensuite, le contenu du message sera sous l’une des formes suivantes : - Numéro de compte incorrect ; - Numéro de séquence incorrect ; - Mot de passe du compte incorrect ; - Votre message a été altéré. Veuillez reprendre l’opération ; - Erreur serveur, veuillez réitérez l’opération. Les erreurs serveur peuvent être catégorisées comme suit : - Le serveur ne peut pas récupérer le mot de passe de la base de données ; - Le serveur ne peut pas lire le message ; École Nationale Supérieure d’Électricité et de Mécanique 77
    • Projet de Fin d’Études 2010 - Le serveur ne peut pas déterminer le montant à transférer ; - Le serveur ne peut pas réaliser le transfert d’argent ; - Erreur de cryptage du message de retour. Bien sûr, le contenu de la réponse sera crypté et signé afin d’assurer la sécurité bout à bout. 3.4. Réponse aux transactions Comme mentionné dans le paragraphe précédent, si la réponse du serveur ne commence pas par la chaîne « xlmsdf » alors elle ne sera pas traitée par le client. La réponse sera envoyée sous forme d’un message sécurisé au client à son port d’écoute 50040. 3.5. Communication SSL/RMI Dans ce projet, nous avons choisi d’utiliser le SSL (Secure Socket layer) avec la méthode RMI (Remote Method Invocation) pour assurer une communication distante sécurisée avec la base de données. Le SSL/RMI a été implémenté dans la classe « AppelBD ». Avant de pouvoir utiliser ce moyen de communication, il faudrait d’abord avoir les outils de sécurité nécessaires à sa mise en œuvre comme le certificat serveur, le dépôt des clés du serveur (communément appelé « key store ») et le fichier de confiance du client (communément appelé « trust store »). Pour établir une communication SSL, la base de données doit contenir le dépôt de clés du PC serveur qui, lui aussi, doit contenir le fichier de confiance client. Quand le canal SSL est négocié, la communication devient alors confidentielle. On crée ensuite une connexion RMI entre le serveur PC et la base de données et ceci en créant un objet de connexion distante utilisant la classe « AppelBD ». Cet objet sera utilisé par les deux parties. La connexion SSL fait appel aux méthodes distantes en utilisant l’objet de connexion distante. Ceci permet à la banque de faire appel aux méthodes de la base de données à distance et de récupérer les données de la base depuis une ligne sécurisée. 3.6. Connexion JDBC Pour écrire un programme Java communiquant avec la base de données, on a besoin de la bibliothèque de connexion à la base de données JDBC (Java DataBase Connectivity). Nous avons choisi MySQL comme base de données pour ce projet. École Nationale Supérieure d’Électricité et de Mécanique 78
    • Projet de Fin d’Études 2010 Avant l’exécution des requêtes SQL, l’application doit se connecter à la base de données. Pour cela, il faut utiliser la chaîne de connexion qui est sous la forme « jdbc:mysql://<chemin vers la base de données> ». 3.7. Base de données MySQL La base de données MySQL est constituée de quatre tables : - Account(AccID, Name, Balance, PIN); - OTP(AccID*, Seq, Password) ; - DeletedOTP(AccID*, Seq, Password) ; - ReceivedMessage(Message, Time, Originator). La table “Account” est utilisée pour enregistrer les informations du client. La table « OTP » stocke les mots de passe OTP non utilisés pour un client donné. La table « DeletedOTP » sert à conserver les OTPs usagés. La table « ReceivedMessage » est employée pour rendre les messages reçus persistants dans la base de données. 3.8. Générateur de mot de passe pseudo aléatoire Un générateur de mot de passe pseudo aléatoire PRNG (Pseudo Random Number Generator) est un algorithme utilisé pour générer une séquence de nombres dont les propriétés approchent celles des nombres aléatoires. Cette séquence n’est pas « vraiment » aléatoire du fait qu’elle repose sur un ensemble de valeurs initiales appelées « les états PRNGs ». Pour avoir une séquence de nombre vraiment aléatoire il faut avoir recours à des machines qui utilisent par exemple le transit des électrons dans une jonction PN afin de réaliser la séquence où bien qui utilisent les radiations d’un matériau radioactif pour ça. Dans le cadre de notre projet, nous avons utilisé l’algorithme HMAC afin d’assurer la fonction de PRNG. Le HMAC est un type de code d'authentification de message (CAM), ou MAC en anglais (Message Authentication Code), calculé en utilisant une fonction de hachage cryptographique en combinaison avec une clé secrète. Comme avec n'importe quel CAM, il peut être utilisé pour vérifier simultanément l'intégrité de données et l'authenticité d'un message. N'importe quelle fonction itérative de hachage, comme MD5 ou SHA-1, peut être utilisée dans le calcul d'un HMAC; le nom de l'algorithme résultant est HMAC-MD5 ou HMAC-SHA-1 : pour ce projet, nous avons choisi d’implémenter le HMAC-SHA-1. La qualité cryptographique du HMAC dépend de la qualité cryptographique de la fonction de hachage et de la taille et la qualité de la clé. Il est intéressant de École Nationale Supérieure d’Électricité et de Mécanique 79
    • Projet de Fin d’Études 2010 savoir que le HMAC-SHA-1 est utilisé dans le protocole IPsec et TLS pour avoir une idée sur sa force. La fonction HMAC est définie comme suit : Avec : - h : une fonction de hachage itérative, - K : la clé secrète complétée avec des zéros pour qu'elle atteigne la taille de bloc de la fonction h - m : le message à authentifier, - "||" désigne une concaténation et "" un ou exclusif, - ipad et opad, chacune de la taille d'un bloc, sont définies par : ipad = 0x363636...3636 et opad = 0x5c5c5c...5c5c. Donc, si la taille de bloc de la fonction de hachage est 512, ipad et opad sont 64 répétitions des octets, respectivement, 0x36 et 0x5c. École Nationale Supérieure d’Électricité et de Mécanique 80
    • Projet de Fin d’Études 2010 Chapitre 5 : Tests, Évaluation et maintenance École Nationale Supérieure d’Électricité et de Mécanique 81
    • Projet de Fin d’Études 2010 1. Tests Nous avons réalisé plusieurs tests afin d’identifier les points forts et les points faibles de la solution. Ces tests balaient à peu près tout le spectre technique qu’engendre ce genre d’application. 1.1. La confidentialité : AES Le niveau de sécurité du protocole que nous avons conçu dépend de la force de l’algorithme de cryptage utilisé. Le type d’algorithme requis pour ce genre d’application est un algorithme symétrique qui réalise un chiffrement rapide : c’est pour cela que nous avons choisi le AES. L’Agence de Sécurité Nationale des Etats Unis d’Amérique NSA (National Security Agency) a conduit une étude sur l’utilisation de l’algorithme AES afin de protéger des informations classées secret défense. Le résultat de cette étude est que la NSA considère aujourd’hui l’algorithme AES comme adéquat pour le cryptage des informations et des systèmes relevant de la sécurité nationale des USA. Elle a aussi considéré que l’utilisation d’une clé 128 bits est suffisante pour la protection des informations classées secret défense. La rapidité du cryptage dépend de la taille du message original. Afin de pouvoir tester la rapidité de cet algorithme, nous avons introduit sur une première version de l’application mobile un « timer » capable de nous donner exactement la durée que prend cette opération. Ce test montre que pour un mobile « SAMSUNG GT-S5600 », le cryptage prend en moyenne moins de 200 millisecondes pour être réalisé, ce qui montre qu’il est très rapide. La seconde phase de tests concerne l’implémentation de l’algorithme AES que nous avons réalisé dans notre application. Pour cela, nous avons utilisé un test « boite noire » (communément appelé « black box test »). Nous avons commencé par crypter un message et nous avons utilisé, ensuite, des clés invalides proches de la vraie clé afin d’essayer de forcer la serrure. Le résultat montre que l’implémentation que nous avons réalisée de cet algorithme est satisfaisante car aucune des fausses clés utilisées n’a pu décrypter le message. 1.2. L’intégrité : SHA-1 La signature permet de maintenir l’intégrité du message sécurisé intacte. Ici, la rapidité est aussi un facteur important. Pour la signature, nous avons utilisé l’algorithme SHA-1. L’algorithme SHA-1 est considéré comme un algorithme sûr, puisqu’il est impossible de le craquer en utilisant de simples moyens informatiques : en effet, à ce jour, la meilleure attaque connue contre cet algorithme a besoin d’un « calcul distribué à l’échelle planétaire » (d’après le spécialiste en cryptographie Adi Shamir). Même une machine superpuissante ne peut pas le craquer toute École Nationale Supérieure d’Électricité et de Mécanique 82
    • Projet de Fin d’Études 2010 seule. Craquer la signature n’a pas le même sens que craquer le cryptage puisque ces deux opérations ont des rôles différents. Ici, quand on parle de craquer le SHA-1, ça veut dire trouver le message initial à partir de la signature ou bien trouver deux messages différents qui ont la même signature. Nous avons aussi utilisé un ″timer″ afin de calculer le temps que prend la création de la signature : le résultat moyen est de 150 millisecondes. Le second test que nous avons réalisé consiste à s’assurer de la bonne implémentation de la signature. Pour cela, nous avons pris un message sécurisé que nous avons altéré en modifiant un seul bit de la signature et en le ré-envoyant vers sa destination. Ceci a eu pour effet de générer un message d’erreur. Ce qui montre bien que nous avons réussi une bonne implémentation de cet algorithme. 1.3. Authentification Le mot de passe du compte client PIN est protégé à l’intérieur de la partie cryptée du message sécurisé. Un intrus ne pourra donc pas lire le PIN du client et ne pourra pas l’utiliser pour réaliser une attaque inaperçue (en se faisant passer pour le vrai client). 1.4. Non-répudiation La conception que nous avons faite de l’OTP et du numéro de séquence rend très difficile, voir impossible au client de réfuter le fait d’avoir réalisé une transaction avec la banque. Pour tester la non-répudiation, il faudrait tester notre générateur de mot de passe pseudo aléatoire. Les principes mathématiques sur lesquels repose le HMAC-SHA-1, en plus de l’utilisation d’une graine unique (nous utilisons comme graine la date constituée de l’année, le mois, le jour, l’heure, la minute et la seconde) empêchent le générateur de créer le même mot de passe deux fois. Pour notre cas, nous avons utilisé un test client, c'est-à-dire un test d’utilisation où nous avons généré à des dates différentes plusieurs séquences d’OTP sans déceler aucune erreur d’implémentation mais, il faudrait un test plus précis et à grande échelle comme un test de montée en charge afin de réaliser une vérification plus approfondie. 1.5. Attaque par ré-envoi de message Si nous supposons que l’attaquant a pu intercepter le message mais n’a pas pu lire son contenu, une attaque qui pourrait mettre à mal le système est de ré-envoyer le même message encore et encore. Ceci pourrait vider le compte du client par exemple (si la transaction demandée dans le message est du type « transfert d’argent »). École Nationale Supérieure d’Électricité et de Mécanique 83
    • Projet de Fin d’Études 2010 Malheureusement pour l’attaquant, ce genre d’opération ne peut pas réussir sur notre système qui vérifie le numéro de séquence à chaque message reçu. En effet, après avoir réalisé une transaction avec un client, le système incrémente le numéro de séquence que doit utiliser le client pour sa prochaine transaction avec la banque. Afin de tester notre système contre cette attaque, nous avons envoyé un premier message valide au système qui l’a accepté sans problème puis nous avons ré-envoyé le même message : ce dernier a été immédiatement éliminé. 1.6. Attaque par usurpation d’identité Une attaque par usurpation d’identité est quand l’attaquant essaie de se faire passer pour un client authentique de la banque. Si l’attaquant s’arrange pour avoir le numéro de compte d’un client, il ne pourra pas passer de transactions avec la banque car il lui manque le mot de passe du compte PIN et même si par miracle il arrive à l’obtenir, il lui faut la séquence d’OTP et le numéro de séquence pour pouvoir tromper la banque. Pour tester la sécurité de notre système contre ce genre d’attaques, nous avons envoyé un message avec un compte bancaire valide et un PIN valide mais une erreur dans l’OTP : le résultat est que le message a été écarté. 1.7. Attaque par force brute L’attaque par force brute, communément appelée « Brute Force Attack » est une attaque qui consiste à essayer une multitude de clés aléatoirement afin de craquer le cryptage. Le calcul suivant donne le temps nécessaire, en moyenne, pour qu’une attaque de ce genre puisse craquer le message crypté : L’attaquant ne connaît pas la clé, donc il doit supposer qu’elle contient des chiffres et des lettres, c'est-à-dire qu’il doit s’attendre à essayer des séquences constituées par les caractères suivants : [a-z] = 26 caractères, [A-Z] = 26 caractères, [0-9] = 10 caractères. Donc le nombre de caractères possibles est : 26 + 26 + 10 = 62 caractères. La longueur de la clé OTP est entre 8 et 16 caractères, il devra essayer : 628+629+6210+6211+6212+6213+6214+6215+6216=4,845*1028 combinaisons. Nous supposons que l’attaquant a besoin en moyenne de la moitié de ces essais afin de trouver le mot de passe correct c’est-à-dire qu’il lui faut essayer 2,422*1028 combinaisons. École Nationale Supérieure d’Électricité et de Mécanique 84
    • Projet de Fin d’Études 2010 Supposons que l’attaquant possède un calculateur puissant capable de réaliser 106 opérations de décryptages par seconde. Le nombre moyen d’années nécessaires pour que l’attaquant puisse craquer le message est de : années. Ce calcul montre qu’en moyenne, il est impensable d’utiliser une attaque par force brute pour essayer de craquer le message crypté. L’utilisation d’un mot de passe OTP donne plus de force au protocole car il rend toute étude mathématique pour décrypter le message très difficile voir inutile puisque il n’y a pas de machine assez puissante pour supporter la charge de calcul que cela nécessite. 2. Evaluation Il est évident que pour évaluer notre solution de M-Banking, nous devons la comparer directement aux autres solutions. Pour cela, nous disposons d’informations intéressantes à propos du M-Banking en Afrique du Sud et c’est sur cette base que nous avons réalisé cette comparaison. Les banques en Afrique du Sud utilisent, en général, deux méthodes de M-Banking. La première méthode consiste à utiliser l’USSD pour authentifier le client et annoncer au serveur bancaire que le client s’apprête à réaliser une transaction. Le client envoie, ensuite, un message SMS normal à la banque la prévenant du genre de transaction qu’il veut réaliser. Cette approche est adoptée par la « First National Bank ». La seconde méthode consiste à utiliser le WIG pour le transfert des messages SMS contenant les détails de la transaction. Une autre méthode qui est apparue tout récemment utilise le canal GPRS au lieu du canal SMS pour réaliser les transactions de M-Banking. Le tableau suivant montre une comparaison entre les différents types de M-Banking : École Nationale Supérieure d’Électricité et de Mécanique 85
    • Projet de Fin d’Études 2010 USSD banking SMS Banking existant GPRS Notre banking solution USSD+SMS WIG+SMS Coût La plupart des L’USSD est Ici, on a L’utilisation Ici, on a opérateurs offrent gratuit. Le besoin du GPRS besoin d’un le service USSD coût de la d’envoyer demande le seul SMS gratuitement. Le transaction plusieurs transfert pour réaliser client ne paie que est celui du SMS afin d’une la pour le service message de réaliser grande transaction. bancaire. qu’elle une quantité de utilise. transaction. données. Le coût dépend de cette quantité. Sécurité La chaîne de Ici, l’USSD WIG a été La Ici on utilise caractères et le SMS construit « Standard l’AES avec envoyée par ne sont pas pour des Bank » une clé USSD n’est pas cryptés. fins de utilise une jetable OTP cryptée. L’authentifi sécurité. Il clé 128 bits de 128 bits L’authentification cation supporte le pour crypter en plus d’une repose sur l’IMSI dépend de principe de les signature à contenu dans la l’IMSI de la sécurité transactions base du carte SIM carte SIM bout à bout. bancaires SHA-1. Le L’authentifi par GPRS. PIN du client cation se Par contre est utilisé base sur l’algorithme pour L’IMSI de de sécurité l’authentifica la carte utilisé n’est tion et le SIM pas numéro de mentionné séquence pour éviter certaines attaques. École Nationale Supérieure d’Électricité et de Mécanique 86
    • Projet de Fin d’Études 2010 Vitesse de La vitesse de toutes ces méthodes de M-Banking dépend du réseau de transmission l’opérateur ce qui veut dire qu’elle dépend de la couverture de l’opérateur et de la charge du trafic dans le réseau. Fiabilité Mode de USSD est Le SMS à Communicat Le SMS est communication synchrone. travers un ion enregistré synchrone. Le client canal WIG synchrone. chez Réponse reçoit une est La l’opérateur immédiate réponse asynchrone. connexion en attente immédiate Le canal peut se d’être délivré du serveur WIG va couper si le au bancaire attendre la signal est destinataire. réponse du faible ce qui serveur. Le peut message engendrer SMS est une perte de enregistré données chez l’opérateur en attente d’être délivré. Compatibilité Tout téléphone Tout Requiert un Le mobile Ici, on a qui supporte téléphone téléphone doit être besoin d’un l’USSD peut supportant compatible compatible mobile qui utiliser ce genre l’USSD et le avec le avec le supporte les de transaction SMS SAT (Sim WAP et l’un SMS et le Application au moins langage Java. Toolkit) des 3 protocoles suivants : GPRS, EDGE et 3G École Nationale Supérieure d’Électricité et de Mécanique 87
    • Projet de Fin d’Études 2010 Facilité Ne dispose On entre les Pour ce Ici aussi on Ici, on d’utilisation d’aucune données genre dispose dispose interface. Le d’authentifi- d’applicati- d’une d’interfaces client entre cation on, on interface facilitant la directement ses directement dispose pour entrer saisie de données comme en USSD généraleme les données données pour s’il va passer un (comme si nt d’une ou bien on les appel on allait interface. les entre utilisateurs téléphonique passer un directement appel) dans le ensuite on navigateur doit créer un message avec une certaine structure pour réaliser la transaction Tableau 4 : Comparaison de notre solution de M-Banking avec d’autres solutions existantes Nous avons aussi donné une notation à chacune de ces méthodes en suivant les critères du tableau précédent. Pour chaque critère, la méthode peut être soit bonne (3 points), soit moyenne (2 points) soit mauvaise (1 point). Nous avons aussi utilisé une pondération pour les différents critères car ils n’ont pas la même importance. USSD USSD + WIG + GPRS Notre Taux de Banking SMS SMS Banking solution pondération Coût 3 2 1 2 2 20% Sécurité 1 1 2 2 3 30% Vitesse de 3 3 3 3 3 10% transmission École Nationale Supérieure d’Électricité et de Mécanique 88
    • Projet de Fin d’Études 2010 Fiabilité 3 2 2 1 2 10% Compatibilité 3 3 1 1 3 20% Facilité 1 1 3 3 3 10% d’utilisation Résultat 14 12 12 12 16 100% Résultat 2.2 1.9 1.8 1.9 2.7 pondéré Tableau 5 : Evaluation des différentes méthodes de M-Banking Donc, le classement des méthodes de M-Banking est comme suit : 1. Notre solution 2. USSD Banking 3. GPRS Banking et USSD+SMS 4. WIG + SMS Ce qui justifie très bien les différents choix que nous avons faits dans notre projet. 3. Maintenance En informatique, il y a trois types de maintenance : - La maintenance corrective - La maintenance adaptative - La maintenance évolutive La maintenance corrective consiste à corriger les différents bugs qui peuvent apparaître dans une application pendant que la maintenance adaptative consiste à adapter l’application à son environnement, par exemple, si une mise à jour du système d’exploitation entraîne un mauvais fonctionnement de l’application, alors on doit réaliser ce genre de maintenance. École Nationale Supérieure d’Électricité et de Mécanique 89
    • Projet de Fin d’Études 2010 Dans ce chapitre, nous discuterons plutôt la maintenance évolutive de l’application qui consiste à faire évoluer une application, par exemple à la suite de la demande d'un utilisateur pour modifier son comportement ou pour proposer de nouvelles fonctions. 3.1. Distribution de l’application mobile Tout au long de ce rapport, on a discuté de la sécurité de la solution en supposant qu’elle est déjà installée sur un téléphone mobile. En fait, on devrait donner une plus grande attention à la distribution. En effet, un attaquant peut créer une application qui a une interface similaire et qui, au lieu d’envoyer les données vers la banque, les envoie à l’attaquant ce qui rend le protocole de sécurité utilisé inutile. Nous avons pensé, ici, à quelques solutions pour remédier à ce problème : - La banque peut fournir l’application au client au moment de son enregistrement au service de M-Banking. La banque peut installer l’application dans le mobile du client via Bluetooth. - La banque peut distribuer l’application sur des CDs signés numériquement. Le client devra vérifier la signature sur son PC avant d’installer l’application. Le problème de cette solution est qu’elle ne peut pas être utilisée par des clients n’ayant pas un minimum de connaissances technologiques. - La banque peut utiliser une tierce partie de confiance, une autorité de certification par exemple, afin de certifier numériquement l’application mobile. Les téléphones des clients doivent être réglés sur le mode confiance pour cette tierce partie. Dans ce cas, la banque peut diffuser l’application par internet et le client peut la télécharger et l’installer facilement sur son mobile via le réseau WAP ou GPRS. Ce type d’installation est appelé installation OTA (Over-The-Air). Quand le client termine le téléchargement de l’application, le mobile pourra vérifier si l’application est certifiée par la tierce partie de confiance. Cette solution est aujourd’hui possible au Maroc, avec Poste Maroc qui devient la première autorité de certification du royaume. 3.2. L’application front-office Afin que la solution que nous proposons soit prête à l’utilisation, elle devra contenir une partie front-office qui sera utilisée par les employés des agences de la banque. Cette partie assure les fonctions suivantes : - Souscription du client, affectation d’un profil client, définition de la liste des bénéficiaires, etc. ; École Nationale Supérieure d’Électricité et de Mécanique 90
    • Projet de Fin d’Études 2010 - Modification des informations du compte (changement des propriétés du compte, changement du profil client, changement de la liste des bénéficiaires, etc.) ; - Prise en charge des oppositions et des levées d’opposition ; - Gestion des comptes d’accès et habilitations pour les employés de l’agence ; - Consultation et reporting (relevé du compte mobile, la liste des opérations de gestion et de comptabilité effectuées en agence quotidiennement, etc.). 3.3. Autres Plusieurs autres ajouts peuvent être réalisés soit pour compléter soit pour améliorer la solution. Dans le cadre de ce rapport, nous ne pouvons pas détailler toutes les nouvelles perspectives mais nous donnons des exemples de voies qu’on peut explorer : - On peut implémenter d’autres services liés au M-Banking comme le M-Business, le M- Commerce, le M-Marketing, le M-Remittance, etc. ; - On peut aussi ajouter des modules de gestion et de monitoring ; - On peut travailler sur d’autres canaux, c'est-à-dire ajouter le canal Internet et le GAB en plus du SMS ; - On peut améliorer les interfaces clients en utilisant des ″Canvas″ au lieu des ″Forms″. École Nationale Supérieure d’Électricité et de Mécanique 91
    • Projet de Fin d’Études 2010 Conclusion École Nationale Supérieure d’Électricité et de Mécanique 92
    • Projet de Fin d’Études 2010 Conclusion L’objectif de notre projet de fin d’études est la conception et la réalisation d’une solution de M- Banking au sein de Barid Al Maghrib. L’intêret majeur de ce projet est qu’il propose une démarche innovante pour ce genre de solutions au niveau du Maroc. Pour mener à bien notre projet, nous avons commencé par étudier les différentes facettes qui lui sont liées. L’absence totale de solution de M-Banking open source reposant sur l’utilisation du canal SMS est un problème auquel on a dû faire face. En effet, la documentation théorique sur les principes du M- Banking est disponible, par contre, on ne trouve pas de documentation technique ou bien des communautés d’aide dans ce domaine. On a aussi rencontré des difficultés d’ordre technique liées surtout au manque de temps et de ressources financières. Ceci nous a mené plusieurs fois à changer les méthodes matérielles et les bibliothèques logicielles qu’on prévoyait d’utiliser au départ tout en gardant le fond de la conception de notre projet. Un exemple typique de ces difficultés est l’utilisation du Bluetooth pour la communication entre le PC serveur et le téléphone serveur. Cependant, le défi majeur a été de proposer une solution de M-Banking qui réalise un compromis entre sécurité, compatibilité, rapidité et coût d’utilisation. Pour la sécurité de notre solution, nous avons utilisé un cryptage AES à base de clés OTP 128 bits générées à l’aide du générateur de mot de passe pseudo aléatoire HMAC basé sur l’algorithme HMAC-SHA-1. En plus du cryptage nous avons utilisé une signature à base de l’algorithme de hachage SHA-1. Pour assurer la compatibilité, nous avons utilisé le triplet (KVM, CLDC, MIDP). La rapidité est assurée par un compromis entre le niveau de sécurité et le temps de calcul des éléments de sécurité (cryptage = 200 millisecondes et signature = 150 millisecondes). Enfin, nous avons pu assurer tout ça avec le moindre coût, puisque la confidentialité, l’intégrité, l’authentification et la non-répudiation sont assurées par seulement un seul SMS. École Nationale Supérieure d’Électricité et de Mécanique 93
    • Projet de Fin d’Études 2010 Ceci dit, nous ne pensons pas que notre solution de M-Banking soit parfaite. On pourrait l’améliorer en lui ajoutant des modules de gestion et de monitoring par exemple. Enfin, nous espérons que ce travail sera réutilisé et complété par Barid Al Maghrib pour une future application de M-Banking, surtout avec son entrée ce 8 juin 2010 dans le domaine des banques en créant sa propre banque « Al Barid Bank ». École Nationale Supérieure d’Électricité et de Mécanique 94
    • Projet de Fin d’Études 2010 Références École Nationale Supérieure d’Électricité et de Mécanique 95
    • Projet de Fin d’Études 2010 1. Bibliographie 1- Alex Biryukov, Adi Shamir, David Wagner : « Real Time Cryptanalysis of A5/1 on a PC ». Fast Software Encryption Workshop 2000, April 10-12, 2000, New York City. 2- Eberspaecher, Hans-Joerg Voegel, Christian Bettstetter : « GSM Switching, Services and Protocols 2nd Edition». John Wiley & Sons Inc., West Sussex, 1999. 3- Marko Hassinen, Smile Markovski : « Secure SMS messaging using Quasigroup encryption and Java SMS API ». SPLST 03, Kuopio, Finland June 17 18, 2003. 4- Steve Lord : « Trouble at the Telco: When GSM Goes Bad ». Network Security, volume 2003, issue 1, January 2003, pages 10-12. 5- William Stallings : « Network Security Essentials (2nd Edition) ». Prentice Hall, 2003. 6- Niina Mallat, Matti Rossi, Virpi Kristiina Tuunainen : « Mobile Banking Services ». Communications of the ACM, 47(5):42 46, 2004. 7- Reinhard Wobst : « Qui peut écouter mon portable? ». Article publié dans le numéro 1/2004 du magazine “Hakin9”. 8- S. Karnouskos, A. Vilmos, P.Hoepner, A. Ramfos, N. Venetakis : « Secure Mobile Payment - Architecture and Business Model of SEMOPS ». EURESCOM summit 2003, Evolution of Broadband Service, Satisfying user and market needs, 29 Sept - 1 Oct, 2003, Heidelberg, Germany. 9- Pr. El Bakkali Hanane : « Sécurité Applicative ». cours ENSIAS. 10- Documentation interne de BAM. 2. Wébographie http://www.maghress.com/fr/financesnews/6928 http://www.infoworld.com/d/networking/nokia-phones-vulnerable-dos-attack-068 http://www.lavieeco.com/economie/12828-un-taux-de-bancarisation-de-62-en-2013.html http://www.isaac.cs.berkeley.edu/isaac/gsm.html http://www.hackcanada.com/blackcrawl/cell/gsm/gsm-secur/gsm-secur.html http://www.telquel-online.com/202/eco_sujet_202.shtml http://ram-0000.developpez.com/tutoriels/cryptographie/ http://www.maroceco.ma/web/ÉCONOMIE/TIC/meditel-lance-son-offre-mobil-banking- avec-bmce-bank.html http://www.itu.int/ITU-D/ict/cs/uganda/material/uganda.pdf École Nationale Supérieure d’Électricité et de Mécanique 96
    • Projet de Fin d’Études 2010 http://www.schneier.com/paper-attacktrees-ddj-ft.html http://conventions.coe.int/Treaty/EN/Treaties/Html/185.htm http://www.ucc.co.ug/marketInfo/marketstatistics.php http://www.c-sam.com/ http://www.etsi.org/WebSite/homepage.aspx http://cryptome.org/a5-3-attack.pdf http://cryptome.org/gsm-spy.htm http://cryptome.org/gsm-crack.htm http://cryptome.org/jya/crack-a5.htm http://www.jeuneafrique.com/Article/LIN12116mbanksruett0/M-banking---debuts- prometteurs.html http://www.businessmobile.fr/actualites/securite-la-vulnerabilite-des-technologies-gsm-et- voip-en-question-39381123.htm http://mbanking.blogspot.com/ http://en.wikipedia.org/wiki/Mobile_banking http://en.wikipedia.org/wiki/Mobile_banking http://brandonmcgee.blogspot.com/ http://brandonmcgee.blogspot.com/ http://www.01net.com/editorial/395307/le-m-banking-successeur-du-e-banking/ http://finance.sia-conseil.com http://www.itmag.sn/index.php/Telecom/Croissance/lafrique-laboratoire-du-mobile-banking.html http://www.lesafriques.com/actualite/le-maroc-bascule-dans-le-m- banking.html?Itemid=89?articleid=21359 http://www.journaldunet.com/ebusiness/expert/43907/le-m-banking-enfin-un-succes.shtml http://www.linformaticien.com/Actualités/tabid/58/newsid496/4357/les-banques-prevoient-l- essor-du-m-banking/Default.aspx http://www.lesafriques.com/technologies-et-monetique/m-banking-de-belles-perspectives-mais- aussi-des-craintes-sur-la-fiab.html?Itemid=197?articleid=6520 http://fr.wikipedia.org/wiki/Advanced_Encryption_Standard École Nationale Supérieure d’Électricité et de Mécanique 97
    • Projet de Fin d’Études 2010 http://www.securiteinfo.com/cryptographie/aes.shtml http://www.progressive-coding.com/tutorial.php http://fr.wikipedia.org/wiki/Authentification_forte http://en.wikipedia.org/wiki/One-time_password http://www.securiteinfo.com/cryptographie/otp.shtml http://en.wikipedia.org/wiki/HMAC http://upe.acm.jhu.edu/member_sites/zarfoss/HMAC.html http://www.worldlingo.com/ma/enwiki/fr/HMAC http://fr.wikipedia.org/wiki/SHA-1 http://www.faqs.org/rfcs/rfc3174.html http://en.wikipedia.org/wiki/Pseudorandom_number_generator http://www.itl.nist.gov/div897/sqg/dads/HTML/pseudorandomNumberGen.html http://random.mat.sbg.ac.at/ 3. Filmographie Le documentaire « Hacker » de la « National Geographic Channel ». École Nationale Supérieure d’Électricité et de Mécanique 98