Rapport De PFE

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


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.



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



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



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



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



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



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



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



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



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.



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.



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



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 ! ».



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.


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.



Chapitre 1 : Contexte général du
projet



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.



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,…



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



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 :



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



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.



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



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.



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.



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



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



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



- 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



Chapitre 2 : Contexte théorique



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.



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 ;



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



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.



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



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



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



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.



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


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



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.



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



à 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



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.



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



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.



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



Chapitre 3 : Dossier de conception



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 :



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



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.



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


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.



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.



- 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



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.



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



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.



Figure 14 : Diagramme de cas d’utilisation



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.



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.



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.



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.



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.



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



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



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.



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



Chapitre 4 : Implémentation



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.



2.1. L’interface utilisateur

Figure 22 : Prise d’écrans de quelques interfaces de l’application mobile



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



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.



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



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



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 ;



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



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



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.



Chapitre 5 : Tests, Évaluation et
maintenance



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



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



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.



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 :



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.



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



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



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.



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



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



Conclusion



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.



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



Références



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



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



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


Rapport De PFE

Contenu connexe

Tendances

En vedette

Similaire à Rapport De PFE

Rapport De PFE