REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE

Ministère de l’Enseignement Supérieur et de laRecherche Scientifique

Université des Sciences et de la Technologie Houari Boumediene

Faculté d’Electronique et Informatique

Département Télécommunications
Mémoire de MASTER
Domaine : Sciences et Technologie
Spécialité : Génie Electrique
Option : Système de Télécommunications

THEME

Conception et mise en œuvre d’un système de

paiement via SMS dans le réseau GSM

Proposé et dirigé par : Présenté par :

Mr OUADJAOUT Lamine MALIK Ryad

Mr AMROUCHE Abderahmane REZGUI Khadidja

Soutenu le 16/06/12
 Dédicaces

‫"ﻗﻞ إن ﺻﻼﺗﻲ و ﻧﺴﻜﻲ و ﻣﺤﯿﺎي و ﻣﻤﺎﺗﻲ ﷲ رب اﻟﻌﺎﻟﻤﯿﻦ ﻻ ﺷﺮﯾﻚ ﻟﮫ‬

" ‫و ﺑﺬﻟﻚ أﻣﺮت وأﻧﺎ أول اﻟﻤﺴﻠﻤﯿﻦ‬

A mes très chère parents qui m’ont toujours soutenue.

A tous mes frères et sœurs : samir, mohamed, hanane.

A tous mes amis et à toute personne qui m'a aidé et encouragé surtout:
Anis, lyes ,abdou.

A toute la promotion de Systèmesde télécommunications,LES STistes et spécialement

pour :
3mimar, Sidali, Younes, Amine ; Dahmane.
Et enfin spécial dédicace à ma princesse :
Lynda

RYAD
 Dédicaces

‫"ﻗﻞ إن ﺻﻼﺗﻲ و ﻧﺴﻜﻲ و ﻣﺤﯿﺎي و ﻣﻤﺎﺗﻲ ﷲ رب اﻟﻌﺎﻟﻤﯿﻦ ﻻ ﺷﺮﯾﻚ ﻟﮫ‬

" ‫و ﺑﺬﻟﻚ أﻣﺮت وأﻧﺎ أول اﻟﻤﺴﻠﻤﯿﻦ‬

A toutes les personnes chères qui ne sont plus de ce monde et spécialement à mon père.

A la plus tendre et la plus généreuse des mamans qui m’a toujours soutenue.

A tous mes frères etsœurs : mohamed, nesrine, yasmine, abdelkader.

A tous mes amis et à toute personne qui m'a aidé et encouragé surtout:
Affef, Mounir, Asma, Azziz, Billel, Amine, Abdou, Kami, Imene, Bilou,Fati,
Djamal.

A toute la promotion de Systèmesde télécommunications,LES STistes et spécialement

pour :
Amira, Walid, La100,Aicha,Menou, Pina, Yasmine, Khadidja, 3mimar, Ryad, kikim,
Sidali, Younes, Amine 3oumar, Dahmane.
A moi-même.
Et enfin spécial dédicace à ma princesse :
Lydia

Khadidja
 REMERCIEMENTS

Tout d’abord nous tenons à rendre grâce à dieu tout puissant qui nous a aidé tous le long de notre
existence et qui nous a permis d’être là.

Nos sincères remerciements vont à tous ceux qui nous ont soutenues et aidées de près ou de loin pour la réalisation
de ce travail, et plus particulièrement :

Monsieur AMROUCHE notre promoteur ainsi que Monsieur Lamine OUAdJAOUT, qui nous a
encadrées et guidées avec toute attention, nous les remercions pour leurs suivi, la patience et la gentillesse dont ils
ont fait preuve pendant notre projet.

Et en fin nous remercions chaleureusement les membres du jury pour l’honneur qu’ils nous ont fait en acceptent
d’évaluer notre projet.

Que tous ceux qui ont contribué de près ou de loin à la réalisation de ce modeste travail trouvent ici l’expression de
notre sincère gratitude.
 SOMMAIRE

DEDICACES
REMERCIEMENTS
LISTE DES FIGURES
LISTE DES TABLEAUX
LISTE DES ABREVIATIONS
Introduction Générale ………………………………………………………………………...... 1
Chapitre 1 :Principes du paiement par mobile
1.1Introduction…………………………………………………………………………………………………………………. 2

1.2 Présentation des principales solutions de paiement……………………………………………………… 2

1.2.1 Définition des rôles…………………………………………………………………….....................
2
1.2.2 Mécanismes généraux des paiements mobiles……………………………..………………… 2
1.2.3 Définition etrôles du FSPM……………………………………………………………………………. 3
1.2.3.1 Le FSPM est un opérateur mobile assurant ce rôle seul …………………. 4
1.2.3.2 Le FSPM est une institution financière (ou une société contrôlée par
des institutions financières)………………………………………………. 4
1.2.3.3 Le FSPM est un fournisseur de service indépendant ………………….
5
1.2.3.4 Le FSPM est un opérateur mobile assurant ce rôle en partenariat avec un
acteur financier……………………………………………………………….
5
1.3Enjeux des formes de m-paiement et Typologie…………………………………………
5
1.3.1 Enjeux des formes de m-paiement………………………………………………………………. 5
1.3.2 Typologie des formes de m-paiement ……………………………………………………………. 5
1.3.2.1 Selon la méthode de paiement …………………………………………………………… 6
1.3.2.2 Selon la technologie d’accès………………………………………………………………… 6
1.4 critères de description………………………………………………………………………………… 6
1.5 Synthèse de la typologie de paiement …………………………………………………………
7
1.6 Chaînes associées à ce type de méthode de paiement………………………………… 8
1.7 Conclusion………………………………………………………………………………………………….. 9
Chapitre 2 : Systèmes de communications mobiles GSM

2.1 Introduction………………………………………………………………………………….. 10
2.2 Concepts techniques du réseau GSM………………………………………………… 10
2.2.1 Concept cellulaire ………………………………………………………………………………………….. 10
2.2.2 Architecture du réseau GSM……………………………………………………………………………… 11
2.2.2.1 La station mobile « MS »………………………………………………………………………… 12
2.2.2.2 Le sous-système radio « BSS » ………………………………………………………………. 12
2.2.2.3 Le sous-système réseau « NSS »…………………………………………………………… 13
2.2.2.4 Le sous-système d’exploitation « OSS » ………………………………………………… 14
2.2.3 Scénario de communication …………………………………………………….. 14
2.2.4 Interface ………………………………………………………………………….. 15
2.2.5 Les protocoles du standard GSM …………………………………………………………………….. 16
2.3 Concepts techniques du SMS ……………………………………………………………………….. 15 16

2.3.1 Le parcours du SMS…………………………………………………………………………………………… 16

2.3.1.1 Mobile Originated « MO »…………………………………………………………………….. 17
2.3.1.2 Mobile Terminated « MT »……………………………………………………………………. 17
2.3.2 Le processus de l’envoi du SMS…………………………………………………………………… 17
2.3.2.1 Le SMSC …………………………………………………………………….. 17
2.3.2.2 Le ESME……………………………………………………………………... 18
2.3.3 Comment envoyer des SMS depuis et vers un ordinateur…………………………….. 18
2.3.3.1 La méthode du modem…………………………………………………………………………. 18 20
2.3.3.2 La méthode du SMSC……………………………………………………………………………. 20
2.3.3.3 La méthode de l’API……………………………………………………………………………….. 22
2.4 Conclusion …………………………………………………………………………………… 23
Chapitre 3 :Protocoles de communication et cryptographie

3.1 Introduction………………………………………………………………………………… 24
3.2 Introduction au SMPP…………………………………………………………………………….... 24
3.2.1 Connexions……………………………………………………………………………………………………… 25
3.2.2 Les PDU…………………………………………………………………………………………………………… 25
3.2.3 Paramètres optionnels SMPP…………………………………………………………………………… 29
3.3 La signalisation SS7 ………………………………………………………………………………….. 29

3.3.1 Applications SS7 ……………………………………………………………………………………………… 30

3.3.2 La pile de protocoles de communication SS7 …………………………………………………… 30
3.3.2.1 Le niveau 1 de MTP …………………………………………………………………………. 31
3.3.2.2 Le niveau 2 de MTP …………………………………………………………………………. 31
3.3.2.3 Le niveau 3 de MTP ……………………………………………………………………………. 31
3.3.2.4 Niveau 4…………………………………………………………………………………………….. 31
3.3.3 Le MAP dans le Service SMS ……………………………………………………………………… 32

3.4 Introduction au protocole FTP ………………………………………………………………. 35

3.4.1 Le modèle FTP ………………………………………………………………………………………….. 35

3.4.2 Les commandes FTP …………………………………………………………………………………. 36
3.5 Introduction à la sécurité de l’application……………………………………………………. 36

3.5.1 Algorithmes de hachage………………………………………………………………………….. 37

3.5.2 Algorithmes de chiffrement ………………………………………………………………………. 37
3.5.2.1 Les algorithmes symétriques …………………………………………………….. 37
3.5.2.2 Les algorithmes asymétriques …………………………………………………… 38
3.5.2.3 Les algorithmes hybrides ………………………………………………………….. 38
3.5.3 La sécurité du réseau GSM……………………………………………………………………….. 39
3.5.4 Critères de sécurité du paiement mobile…………………………………………………… 41
3.5.5 Vulnérabilités d’un service SMS paiement…………………………………………………. 41
3.5.5.1 SMS spoofing…………………………………………………………………………….. 41
3.5.5.2 Crash d’un mobile……………………………………………………………………… 41
3.5.5.3 Le déni de service……………………………………………………………………… 42
3.5.5.4 IMSI-Catcher……………………………………………………………………………… 42
 3.5.5.5 Man-in-the-middle……………………………………………………………………. 42
3.6 Conclusion……………………………………………………………………… 42

Chapitre 4 :Conception et mise en œuvre d’un système de paiement sur réseaux mobiles GSM via
SMS

4.1 Introduction ……………….………………………………………………………………….. 43

43
4.2 Présentation de la solution en cours à Algérie Poste……………………………………
43
4.2.1 Solution « IBP » Postal Desktop ………………………………………………… 44
4.2.2 Les principaux objectifs …………………………………………………………………………………. 44
4.2.3 Mode d’interconnexion ………………………………………………………………………………… 44
4.3 Solution proposée ……………………………………………………………………………………… 46
4.3.1 Mode d’interconnexion globale………………………………………………………………………. 46
4.4 L’environnement de développement……………………………………………………………. 46

4.4.1 choix du langage de programmation……………………………………….......... 47

4.4.2 Choix du système de gestion de bases de données « SGBD »…………………………… 47
4.5 Préconception……………………………………………………………………………………………… 47
4.5.1 objectifs et cahier de charges ………………………………………………………………………… 48
4.5.2 Déroulement…………………………………………………………………………………………………. 49
4.6 Diagramme de séquences ……………………………………………………………………………
51
4.7 Conception……………………………………………………………………………………………………
51
4.7.1 Création de la base de données …………………………………………………………………….. 54
4.7.2 Développement JAVA…………………………………………………………………………………….
54
4.7.2.1 La classe « PaiementMobile » …………………………………………………………….
54
4.7.2.2 La classe « ConnexionBBD » ………………………………………………………………
54
4.7.2.3 La classe « Mesg » ………………………………………………………………………………
55
4.7.2.4 la classe FTP ……………………………………………………………………………………….
55
4.8 Implémentation………………………………………………………………………………………….
55
4.8.1 Configuration et mise en place………………………………………………………………………… 56
4.9 Schéma d’interconnexion détaillé……………………………………………………………
58
4.10 Tests et évaluation…………………………………………………………………………………
4.11 Conclusion…………………………………………………………………………… 60

Conclusion générale…………………………………………………………………………........ 61

LA BIBLIOGRAPHIE
LES ANNEXES
Liste des figures :
Figure 1.01 : Structure générique de la chaîne de paiements mobiles
Figure 1.02 : Mécanismes généraux des paiements mobiles
Figure 1.03: positionnement de notre solution de paiement en deux dimensions
Figure 1.04 : Mécanismes de paiement d’un débit direct sur le compte bancaire du client
Figure2.01 : Découpage cellulaire de réseau GSM
Figure 2.02 : Architecture générale d’un réseau GSM
Figure 2.03 : Présentation des piles de protocoles sur les différentes interfaces.
Figure 2.04 : Le processus de l’envoi du SMS
Figure 2.05 : modem GSM
Figure 2.06 :La passerelle SMS reliant deux SMSC
Figure 2.07 : La passerelle SMS reliant les SMSC et une application SMS
Figure 3.01 :implémentation générique SMPP
Figure 3.02 : Le format général d'un PDU SMPP
Figure 3.03 : Envoi messages
Figure 3.04 : Réception messages
Figure 3.05 : Pile de protocoles de communication SS7
Figure 3.06 : Envoi d'un SMS à un destinataire joignable
Figure 3.07 : Envoi d'un SMS à un destinataire injoignable
Figure 3.08 : Le modèle FTP
Figure 3.09 : schéma illustrative d’un algorithme de chiffrement symétrique.
Figure 3.10:schéma illustrative d’un algorithme de chiffrement asymétrique.
Figure 3.11 : la signature électronique « algorithme hybride ».
Figure 3.12 : L’algorithme A3
Figure 3.13 : L’algorithme A8
Figure 3.14 :L’algorithme A5
Figure 4.01 : interface IBP.
Figure 4.02 : exemple d’interconnexion SONELGAZ et Algérie Poste
Figure 4.03 : Interconnexion Mobilis et Algérie Poste
Figure 4.04 : Mode d’interconnexion globale
Figure 4.05: diagramme de séquences
Figure 4.06: Table B.D.D. « client »
Figure 4.07 : Table B.D.D. « ccpclient »
Figure 4.08: Table B.D.D. « sonelgaz »
Figure 4.09 : Table B.D.D. « ccppro »
Figure 4.10 : clé étrangère
Figure 4.11 : L’acheminement du message via le protocole MAP
Figure 4.12 : L’acheminement du message via SMPP et son traitement via SQL et FTP.
Figure 4.13 : scénario des messages
Figure 4.14: rapport de paiement
Figure 4.15: capture écran
Figure 4.16: capture écran
Liste des tableaux :
Tableau 1.01 : Mécanismes généraux des paiements mobiles
Tableau 1.02 : les méthodes de paiement
Tableau 1.03 : Les Technologies d’accès utilisé pour initier le paiement
Tableau 1.04 : LesCritères de description
Tableau 1.05 : Mécanismes de paiement
Tableau 2.01 : Interfaces du système GSM
Tableau 2.02 :Les commandes AT
Tableau 4.01 : Table B.D.D. « client »
Tableau 4.02 : Table B.D.D. « ccpclient »
Tableau 4.03: Table B.D.D. « sonelgaz »
Tableau 4.04 : Table B.D.D. « ccppro »
Tableau 4.05 : la définition des champs du protocole SMPP
Tableau 4.06 : la définition des champs de la BDD.
Tableau 4.07 : la définition des champs du protocole SMPP
Introduction générale
 Introduction générale

Ces dernières années, la téléphonie mobile a été un des secteurs les plus dynamiques et les plus
innovants de l'industrie des Télécommunications. Les challenges sont ainsi nombreux alors que les
opérateurs mobiles doivent proposer de nouveaux services à leurs clients.

Ainsi, le transfert de crédits permet au client d’un opérateur de bénéficier de minutes de

communications supplémentaires grâce au crédit transféré par un autre client du même
opérateur. Ces transferts sont la première étape de services de paiement mobiles.

Le m-paiement (mobile payement) offre un canal interactif de communication personnalisée

avec le client à temps réel. C’est un outil pour mieux cerner en permanence la réalité économique
et les besoins des citoyens dans un secteur en pleine évolution et qui peut offrir plus de facilitées.

La problématique actuelle est l’absence des formes de paiement mobile à l’échelle nationale.
Dans ce contexte MOBILIS, filiale d’Algérie Telecom (AT) se propose d’offrir le m-paiement à
ses clients. Ainsi chaque client MOBILIS titulaire d’un compte CCP pourra payer ces factures via le
service SMS grâce à un transfert d’argent. L’application développée dans ce projet consiste à
mettre en oeuvre le traitement des requêtes SMS et l’envoi des réponses correspondantes
« transfert d’argent » en gérant la sécurité de tout le système mis en œuvre.

Le présent mémoire comprend quatre chapitres structurés comme suit :

- Le premier chapitre, sera consacré principes de paiement mobile.
- Dans le second chapitre, l’architecture du réseau GSM ainsi que les concepts techniques du SMS
seront définis.
- Le troisième chapitre fait une description détaillée des différents protocoles utilisés dans notre
application. Ainsi que sur la cryptographie pour sécuriser le paiement.
- Le quatrième chapitre portera sur la conception et la réalisation d’une application qui permet
d’effectuer le paiement des factures via SMS.
- Une conclusion et des perspectives compléteront ce mémoire.
 Chapitre 1 :

Généralités sur les systèmes de paiement mobile

 1.1. Introduction :
Le paiement mobile est l’utilisation du téléphone portable pour fournir des services financiers, qui
peuvent être des transactions financières et des échanges d’informations entre le client et
l’institution financière, ou entre les clients eux même [ART 03].
Il est basé sur l’idée d’utiliser un moyen de communication, le téléphone portable, pour la gestion
du compte alors que le client est en situation de mobilité. La forte pénétration de la téléphonie
cellulaire fait de cet outil technologique un moyen particulièrement intéressant pour atteindre
une population et des zones géographiques n’ayant pas ou peu accès à des services financiers de
base.

1.2. Présentation des principales solutions de paiement :

1.2.1. Définition des rôles :
La chaîne de valeur des paiements mobiles met en évidence six positionnements, comme illustré
par la figure 1.1 [ART 03] :

fournisseur fournisseur institutions

opérateur
Client Marchant de service de solution
mobile financiéres
FSPM m-paiement

Figure 1.1 : Structure générique de la chaîne de paiements mobiles.

Le client choisit un produit, un service ou un contenu (sur un point de vente, via un site
Internet, via un site WAP, etc.) et réalise un paiement avec son terminal mobile pour
l’obtenir. La clientèle visée par les services de paiement mobile est en premier lieu celle
des opérateurs de télécommunication, utilisatrice de téléphone mobile. Cette clientèle est,
par conséquent, constituée de particuliers bénéficiant des règles protectrices issues du
droit de la consommation.
Le marchand fournit les produits, services et contenus à la vente et reçoit en échange le
paiement.
Le fournisseur de service de paiement mobile (FSPM) gère le processus du paiement,
entre le client et le marchand, en opérant un système de paiement. Il fournit une interface
 vers les acteurs ou les outils de paiement permettant les transferts financiers. Ce rôle est
central dans la problématique des paiements mobiles et différents types d’acteurs peuvent
se positionner à ce niveau : opérateurs, banques, fournisseurs de service indépendants.
Le fournisseur de solution de paiement fournit au FSPM une solution technique
permettant la mise en œuvre effective des transactions via un terminal mobile.
L’opérateur de réseau assure la transmission des communications via le réseau mobile
permettant l’acheminement des messages échangés pendant la transaction.
Les institutions financières (banques, organismes gestionnaires de réseaux de carte de
crédit, etc.) jouent un rôle dans la gestion des flux financiers induits par le paiement, entre
le client, le marchand et éventuellement aussi le fournisseur de service de paiement
mobile. En fonction de la typologie du paiement mobile, la présence d’une institution
financière dans la chaîne de valeur pourra se révéler obligatoire ou non [PAP 02].

1.2.2. Mécanismes généraux des paiements mobiles :

Afin d’étudier le mécanisme des paiements mobiles, il est possible de simplifier cette chaîne ci-
dessus en ne considérant que les acteurs ayant un rôle opérationnel dans le processus de
paiement. Cela conduit à faire disparaître l’opérateur de réseau, qui a uniquement un rôle de
transmission des communications mobiles, et le fournisseur de solution de paiement qui n’a qu’un
rôle d’équipementier. Il reste donc quatre entités : le client, le marchand, le fournisseur de service
de paiement mobile et les institutions financières.
Les interactions entre ces quatre entités sont décrites dans la figure 1.2 et le tableau 1.1, dans un
cas général de paiement mobile :

Figure 1.2 : Mécanismes généraux des paiements mobiles.

Tableau 1.1 : Mécanismes généraux des paiements mobiles
Le client choisit un produit, contenu ou service, puis
1
: Commande effectue sa commande vers le marchand.
A la réception de la commande du client, le marchand
: Requête
2 de paiement envoie une requête de paiement vers le fournisseur de
service de paiement.
A la réception de la requête du marchand, le FSPM envoie
3
: confirmation un message ver le client afin que celui-ci confirme le
&identification paiement et authentifie la transaction en saisissant par
exemple un code secret. Cet échange de message a lieu en
4
: OK général via le réseau mobile.
Sur réception de la confirmation du client, le FSPM envoie une
5
: Autorisation demande d’autorisation de paiement vers l’organisme financier
concerné, qui en retour lui confirme que le paiement peut avoir
: ok
6 lieu.

A la réception de la confirmation de l’organisme financier, le

7
: confirmation FSPM envoie la confirmation du paiement
8 : livraison vers le marchand, qui procède alors à la livraison.
L’organisme financier transmet le montant du paiement du
9 :paiement compte client vers le compte bancaire du marchand.

L'opérateur mobile, qui n'apparaît pas sur le schéma présenté, ne joue pas un rôle opérationnel
dans le mécanisme de paiement (sauf si bien sûr il est positionné également en fournisseur de
service de paiement mobile ou marchand, lorsque le service de paiement mobile permet de régler
les services proposés par l’opérateur). Le rôle de l'opérateur consiste à assurer la transmission des
interactions à plusieurs niveaux, selon les cas: entre le client et le FSPM, entre le client et le
marchand ou encore entre le FSPM et le marchand.
1.2.3. Définition et rôle du FSPM
Le FSPM joue un rôle central sur la chaîne des services de paiement mobile. L'étude des services
de paiement permet de distinguer quatre cas principaux:
1.2.3.1. Le FSPM est un opérateur mobile assurant ce rôle seul : Dans ce cas le
service fait surtout l’objet d’un paiement direct sur la facture mensuelle de téléphonie
mobile ou, dans certains cas, le compte prépayé.
1.2.3.2. Le FSPM est une institution financière (ou une société contrôlée par des
institutions financières) :L'acteur jouant le rôle de FSPM est une institution financière
ou une société contrôlée par des institutions financières.
 1.2.3.3. Le FSPM est un fournisseur de service indépendant : Le FSPM peut être
une société indépendante, c'est à dire ni un opérateur télécoms, ni un acteur financier.
1.2.3.4. Le FSPM est un opérateur mobile assurant ce rôle en partenariat avec un
acteur financier : Ce cas est fréquent quand l'opérateur souhaite offrir à ses clients
une palette élargie de moyens de paiement, tels que carte de crédit/débit ou porte-
monnaie électronique. On rencontre alors divers types de partenariats:
Partenariats opérateur - organismes gestionnaires de carte de crédit, destinés à
fournir aux clients de l'opérateur la possibilité de payer directement par carte de crédit.
Ceci en tenant compte des frais encourus par l’opérateur dus à l’intervention de
l’organisme gestionnaire de carte de crédit.
Partenariats opérateur - banques, qui peuvent avoir deux objectifs:
1→Ils peuvent viser à permettre le prélèvement des achats effectués via terminal
mobile directement sur le compte bancaire du client. La banque a alors un rôle passif
dans le processus.
2→Ils peuvent aussi viser à adosser à l'opérateur une structure financière pour la
gestion des porte-monnaie électroniques des clients. La banque a alors un rôle actif
dans le processus de paiement.
Partenariats opérateur - fournisseur d'une passerelle de paiement, où le fournisseur
d'une passerelle de paiement est en fait un intermédiaire destiné à fournir à
l'opérateur un accès vers les institutions financières et des marchands.

1.3. Enjeux des formes de m-paiement et Typologie :

1.3.1. Enjeux des formes de m-paiement :
Le m-paiement permet de renforcer le rôle du téléphone mobile tout en fidélisant davantage la clientèle,
en générant du trafic supplémentaire. Il permet à un opérateur télécom de :
trouver un nouveau relais de croissance en augmentant ses revenus par une valorisation de
nouveaux services.
se positionner plus fortement comme partenaire principal des clients dans leurs besoins au
quotidien.
renforcer son positionnement d’acteur clé sur le marché des télécommunications.
 1.3.2. Typologie des formes de m-paiement:
1.3.2.1. Selon la méthode de paiement :
La typologie de paiement peut être considérée suivant la méthode de paiement, telle que définie
par le tableau 1.2. Il est intéressant de noter que des services ont été identifiés pour chacune de
ces catégories, sauf pour la méthode de paiement "Porte-monnaie terminal".
Tableau 1.2 : les méthodes de paiement
Nom de la catégorie Méthode de paiement
Facture postpayée Paiement via la facture mensuelle de l’opérateur mobile adressée au
client.
Compte prépayé Paiement via le compte prépayé mobile du client, géré par
l’opérateur mobile.
Débit direct Paiement par débit direct sur un compte bancaire du client. Le client
peut par exemple utiliser une carte de débit bancaire ou donner une
autorisation de prélèvement sur son compte bancaire.
Carte de crédit Paiement par débit sur un compte de carte de crédit du client.
Porte –monnaie Paiement par prélèvement sur un compte prépayé spécifique (aussi
réseau appelé porte-monnaie électronique, ou SVA), dédié aux paiements
mobiles, géré dans le réseau par le fournisseur de service de
paiement mobile.
Porte –monnaie Paiement par prélèvement sur un compte prépayé(ou porte-
terminal monnaie électronique), dédié aux paiements mobiles et hébergé sur
le terminal mobile du client, en software ou en hardware.

1.3.2.2. Selon la technologie d’accès :

Nous avons choisi dans un deuxième temps de construire le deuxième niveau de notre
typologie selon la technologie d'accès utilisée pour le paiement.

Dans un paiement mobile, plusieurs technologies peuvent être utilisées dans l'ensemble du
processus: commande du produit, authentification du client, confirmation de l'achat, envoi d'un
reçu, envoi du produit acheté. Il est bon de préciser toutefois que pour la majorité des paiements,
le processus en lui-même (de l'initiation à la confirmation du paiement) repose sur une seule et
même technologie mobile.
Afin de lever toute ambiguïté, nous établissons cette deuxième typologie selon la technologie
utilisée par le client pour initier le paiement. Les différentes catégories ainsi identifiées sont
mentionnées dans le tableau 1. 3 : [VYA 01]
Tableau 1. 3 : Les Technologies d’accès utilisé pour initier le paiement
Nom de la catégorie Technologie d’accès utilisée pour initier le paiement
SMS Le paiement est initié grâce à l’échange de SMS.
WAP/ i-mode Le paiement est initié à partir d’un portail mobile WAP ou bien i-mode.
Internet Le paiement est initié sur un site Web. Plusieurs types de paiement
mobile permettent en effet également de payer directement via le Web.
Vocal Le paiement est initié par commande vocale, le plus souvent par SVI.
USSD Le paiement est initié via le protocole USSD, qui permet l’échange de
textes courts entre un téléphone mobile et une application.
(voir : annexe A)

1.4. Critères de description :

Chaque solution de paiement est décrite selon des caractéristiques clés. Le tableau1.4 ci-dessous
fournit une description de chacun des critères utilisés dans la description des solutions :
Tableau 1. 4 : Les Critères de description

Caractéristiques des Définition

services
Etat de développement du S'agit-il d'un service commercial, pré-commercial ou d'un test
service pilote?
Statistiques d'usage du service dans la mesure où cette
information est disponible.
Modes de paiement Méthode de paiement disponible pour le client, en référence à
la typologie.
Technologies d’accès Technologie d’accès utilisée pour le paiement:
pour l'initiation du paiement: en référence à la
typologie.
pour le processus d'authentification/confirmation.
Chaîne de la valeur Identification des sociétés impliquées, pour les rôles définis
dans la chaîne de la valeur des paiements mobiles.
Présence d'un Présence ou non d'un acteur financier dans la chaîne de la
intermédiaire financier? valeur. Dans le cas où un acteur financier est présent, son
niveau d'implication est décrit.
Nature des achats Description des produits et services susceptibles d'être achetés
par le client.
Types d’achat Deux types d'achat sont distingués:
achats distants: achats effectués auprès d'un marchand
accessible via un réseau (boutique Web, WAP, etc.)
achats locaux: achats effectués auprès d'un marchand
 situé à proximité (parking, distributeur automatique,
magasins, etc.)
Achats de produits Le service de paiement mobile permet-il – ou non – d'effectuer
physiques? des achats de produits physiques, par opposition à des services
ou des contenus.
Canal de réception des Deux types de canaux de réception des achats sont distingués:
achats canal mobile, dans le cas où le produit acheté est
transféré sur le terminal: sonneries, logos, etc.
canal non mobile, dans le cas contraire.
Procédures d'achat Description du processus du paiement, avec les principales
interactions entre les acteurs de la chaîne de la valeur.
Coût du service de Coût du service de paiement mobile en lui-même, c'est-à-dire
paiement les frais payés par le client, en plus du prix d'achat du produit,
pour pouvoir utiliser le mobile comme moyen de paiement.

1.5. Synthèse de la typologie de paiement :

Nous présentons dans la figure1.3 ci-dessous, la synthèse du positionnement de la solution de
paiement que nous proposons dans ce projet. Celle-ci est positionnée sur les deux dimensions de
la typologie définie : SMS –Débit direct.

Figure 1.3: positionnement de notre solution de paiement en deux dimensions.

 1.6. Chaînes associées à ce type de méthode de paiement :
Dans le type de paiement « Débit direct », une relation directe est nécessaire entre le
fournisseur de service de paiement et l’institution financière. Il est possible également qu'un
intermédiaire assure le lien entre FSPM et l’institution financière, tel que montré par la figure 1.4
et le tableau 1.4.

Figure 1.4 : Mécanismes de paiement d’un débit direct sur le compte bancaire du client.

Tableau 1.05 : Mécanismes de paiement

Le client s’enregistre préalablement auprès d’un FSPM pour

1 : enregistrement des pouvoir utiliser le service de paiement, en donnant les
coordonnées informations relatives à sa carte de débit bancaire ou au
compte sur lequel le montant du paiement doit être prélevé.
Lorsqu’un paiement est effectué, le FSPM transmet les détails
2
: transmission des de la transaction à la banque, qui vérifie la solvabilité du
détails de la transaction compte en fonction du montant du paiement.
L’institution financière paie le marchand, en débitant le
: paiement
3 compte du client et créditant le montant de la transaction sur
le compte du marchand.

1.7. Conclusion :
Le paiement mobile est une évolution technologique inévitable dans le monde actuel, grâce à l’apparition
de nouvelles avancées technologiques. Cependant, ce processus nécessite la connaissance du réseau de
communication utilisé et pose des problèmes pratiques qui nécessitent une sécurité élevée.

Dans le prochain chapitre, nous allons nous intéresser à l’architecture du réseau GSM, qui
servira de moyen de communication, ainsi qu’au processus de l’envoi du SMS, technique retenue
dans ce projet.
 Chapitre 2 :

Systèmes de communications mobiles GSM

2.1. Introduction :
Après l’étude de la typologie du paiement mobile, nous allons aborder dans ce chapitre
l’architecture du réseau GSM ainsi que les concepts techniques du SMS. Nous allons également
définir le processus de l’envoi du SMS et les outils permettant de l’expédier d’un point émetteur à
un point récepteur.

2.2. Concepts techniques du réseau GSM :

L’architecture GSM est utilisée par les pays qui offrent des services de communication par
téléphone mobile à leurs concitoyens.
Le GSM est un service de téléphonie mobile universel de 2ème génération, efficace et satisfaisant
les exigences d’interconnexion et de mobilité, tout en divisant le terrain en zones de couverture
dites cellules.

2.2.1. Concept cellulaire :

Les réseaux de première génération possédaient des cellules de grande taille (50 km de rayon),
au centre desquelles se situait une station de base. Au début, ce système allouait une bande de
fréquences de manière statique à chaque utilisateur qui se trouvait dans la cellule qu'il en ait
besoin ou non.

Ce système ne permettait donc de fournir un service qu'à un nombre d'utilisateurs égal au nombre
de bandes de fréquences disponibles. La première amélioration consista à allouer un canal à un
utilisateur uniquement à partir du moment où celui-ci en avait besoin, permettant ainsi
d'augmenter « statistiquement » le nombre d'abonnés, étant entendu que tout le monde ne
téléphone pas en même temps. Mais ce système nécessitait toujours des stations mobiles de
puissance d'émission importante ( 8 watts), et donc des appareils mobiles de taille et de poids
conséquents.

De plus, afin d'éviter les interférences, deux cellules adjacentes ne peuvent pas utiliser les mêmes
fréquences. Cette organisation du réseau utilise donc le spectre fréquentiel d'une manière sous-
optimale.

C'est pour résoudre ces différents problèmes qu'est apparu le concept de cellule. Le principe
de ce système est de diviser le territoire en de petites zones, appelées cellules et de partager les
fréquences radio entre celles-ci(voir figure 2.1).
 Figure2.1 :Découpage cellulaire de réseau GSM
Ainsi, chaque cellule est constituée d'une station de base à laquelle on associe un certain
nombre de canaux de fréquences à bande étroite, sommairement nommés fréquences. Comme
précédemment, ces fréquences ne peuvent pas être utilisées dans les cellules adjacentes afin
d'éviter les interférences.
On définit des motifs, aussi appelés clusters, constitués de plusieurs cellules, dans lesquels chaque
fréquence est utilisée une seule fois.
2.2.2. Architecture du réseau GSM:
Un réseau GSM (voir figure 2.2) compte une ou plusieurs stations de base par cellule. La station
mobile choisit la cellule selon la puissance du signal. Une communication en cours peut passer
d’une cellule à l’autre permettant ainsi la mobilité des utilisateurs.

Figure 2.2 : Architecture générale d’un réseau GSM

Le réseau GSM peut être divisé en 4 parties:
La station mobile : MS
Le sous-système radio : BSS
Le sous-système réseau : NSS
Le sous-système d’exploitation : OSS

2.2.2.1. La station mobile « MS »:

La carte SIM :
C’est une carte mémoire qui identifie l'abonné sur le réseau. L'accès sera donc refusé si
la carte a été déclarée perdue ou volée. Elle assure donc l'authentification de l'abonné ainsi
que le cryptage de la voix.
L’équipement mobile« ME »:
Il ne fonctionne que si la carte SIM a été insérée et le code secret validé par l'abonné.

2.2.2.2. Le sous-système radio « BSS » :

Le BSS comprend les BTS qui sont des émetteurs-récepteurs ayant un minimum
d'intelligence et les BSC qui contrôlent un ensemble de BTS et permettent une première
concentration des circuits.
Fonctions de la BTS :
La BTS est un ensemble d'émetteurs-récepteurs appelés TRX. Elle a pour fonction la gestion :
des transmissions radios.
de la couche physique des réseaux.
de la couche liaison de données pour l'échange de signalisation entre les
mobiles et l'infrastructure réseau de l'opérateur et de la liaison de données
avec le BSC.
L'exploitation des données recueillies par la BTS est réalisée par le BSC.
La capacité maximale d'une BTS est de 16 porteuses (limite technique rarement atteinte
pour des raisons de fiabilité). Ainsi une BTS peut gérer au maximum une centaine de
communications simultanées.
On distingue deux types de BTS : Les BTS dites « normales » et Les micro –BTS.
On distingue ensuite différentes classes de BTS normales et micro, en fonction de la nature
du réseau (GSM 900 ou DCS 1800) et de la puissance recherchée.
Les BTS normales sont les stations de base classiques utilisées dans les systèmes cellulaires
avec des équipements complémentaires installés dans des locaux techniques et des
antennes sur les toits.
Les micro-BTS sont utilisés pour couvrir les zones urbaines denses avec des microcellules. II
s'agit d'équipements de faible taille, de faible coût qui permet de mieux couvrir un réseau
dense comme le quartier d'une ville à forte densité de population.
Le rayon d'une cellule varie entre 200m en milieu urbain et 30 km en milieu rural.
Fonctions du BSC :
Le BSC est l'organe intelligent du sous-système radio. Il gère une ou plusieurs stations et
remplit différentes fonctions de communication et d'exploitation. Pour le trafic abonné
venant des BTS, le BSC joue un rôle de concentrateur.
II est considéré comme un relais pour les alarmes et les statistiques venant des BTS vers le
centre d'exploitation et de maintenance.
Le BSC pilote les transferts entre deux cellules, il avise d'une part la nouvelle BTS qui va
prendre en charge l'abonné « mobile » tout en informant le HLR de la nouvelle localisation
de l'abonné.
Les BTS sont contactés par le OMC par le biais des BSC.

2.2.2.3. Le sous-système réseau NSS :

Le rôle principal de ce sous-système est de gérer les communications entre abonnés.

Commutateur de service mobile MSC :

Cette entité est responsable de l'acheminement des communications dans le réseau et
assure également l'interconnexion entre le réseau de téléphone cellulaire et le réseau fixe
traditionnel. Elle génère toutes les informations de taxation et gère la complexité des
connexions due aux déplacements réalisés pendant la communication.

Registre des abonnés locaux HLR :

Il s’agit d’une base de données contenant les informations sur les abonnés appartenant à la
région desservie par le MSC. Cette base de données contient également la position
courante de ces abonnés.
 Registre des abonnés visiteurs VLR :
Le VLR est la base de données dans laquelle le MSC peut trouver les données relatives aux
abonnés situés dans son aire de service.
Chaque fois qu'un abonné se localise dans cette aire de service les données sont copiées du
HLR dans le VLR

Centre d’authentification AUC :

L’AUC est une base de données protégée qui contient une copie de la clé secrète inscrite sur
la SIM de chaque abonné.
Cette clé est utilisée pour vérifier l’authentification de l’abonné et pour le chiffrement des
données envoyées.

Registre d’identification d’équipement EIR :

Le registre EIR contient la liste de tous les terminaux valides. Une consultation de ce registre
permet de refuser l’accès au réseau à un terminal qui a été déclaré perdu ou volé.
2.2.2.4. Le sous-système d’exploitation (OSS) :
Ce sous-système est branché aux différents éléments du NSS de même que le BSC, et il est
branché aussi aux :
OMC : maintenance
SMSC : administration des SMS
ISC : administration du Roaming.
Par une vue d’ensemble du réseau l’OSS contrôle et gère le trafic au niveau du BSS.

2.2.3. Scénario de communication :

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. 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.4. Interface :
Les interfaces jouent un rôle important dans le système GSM. Le tableau 2.1 décrit ces interfaces
en précisant leurs localisations par rapports aux éléments du réseau ainsi que leurs utilisations :
Tableau 2.1 : Interfaces du système GSM
Nom Localisation Utilisation
Um MS-BTS Interface radio
Abis BTS-BSC Divers
A BSC-MSC Divers
Interrogation HLR Appel
MSC-HLR
entrant
G
SM-GMSC-HLR Interrogation HLR SM
Entrant
VLR-HLR Gestion Informations
Abonnés
D
Services supplémentaires
HLR-VLR

MSC-SM-GMSC Transport SM
E Exécution de Handover
MSC-MSC

G VLR-VLR Gestion Informations

Abonnés
Vérification terminal
F MSC-EIR

B MSC-VLR Divers
H HLR-AUC Authentification

2.2.5. Les protocoles du standard GSM :

Le réseau GSM est défini à partir de couches de protocoles utilisées au niveau des différentes
interfaces :
l'interface Um (entre le MS et la BTS)
 l'interface Abis (entre la BTS et le BSC)
l'interface A (entre le BSC et le MSC)
Les interfaces ainsi que les protocoles qu'elles utilisent sont normalisés (voir figure 2.3) [TAB 97].

Figure 2.3 : Présentation des piles de protocoles sur les différentes interfaces.
La structuration en couches reprend le modèle OSI pour les trois premières couches:
couche physique,
couche liaison de données,
couche réseau.
(Voir annexe B)

2.3. Concepts techniques du SMS :

Le moyen de transmission de données le plus populaire est le SMS, 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.

Dans cette partie, nous allons aborder les concepts techniques du SMS : définir le processus de
l’envoi du SMS et les outils permettant de l’expédier d’un point émetteur à un point récepteur.
 2.3.1. Le parcours du SMS :
Le SMS permet à un utilisateur de composer un message textuel à partir de son terminal mobile et
de l'envoyer à un destinataire possédant également un téléphone mobile ou à une entité
extérieure au réseau GSM appelée ESME.
On identifie deux types de SMS qui peuvent être classifiés selon l’origine du message[ERA 07] :
2.3.1.1. Mobile Originated « MO »:
Le SMS est envoyé depuis un téléphone mobile et est reçu par un téléphone mobile ou un
ESME. Exemple : Un abonné de téléphonie mobile envoie un SMS à un autre abonné ou
une application m-paiement.
2.3.1.2. Mobile Terminated « MT »:
Le SMS est envoyé depuis un téléphone mobile ou un ESME et est reçu par un téléphone
mobile. Exemple : Une application m-paiement envoie un SMS à un abonné.

2.3.2. Le processus de l’envoi du SMS :

Figure 2.4 : Le processus de l’envoi du SMS

Il y a deux cas :
L’émetteur et le récepteur sont abonnés au même opérateur :
Le SMS venant de l’expéditeur est sauvegardé dans le SMSC de l’opérateur avant qu’il ne
soit transmis au destinataire.
L’émetteur et le récepteur sont abonnés à deux opérateurs différents :
Les opérateurs ont chacun un SMSC, le SMS est sauvegardé dans le SMSC1 qui l’envoie au
SMSC2 avant qu’il ne soit transmis au destinataire.
 2.3.2.1. Le SMSC:
Le SMSC permet de gérer le transfert des SMS entre téléphones mobiles. En particulier, quand un
abonné envoie un SMS vers un autre, le téléphone transmet en réalité le SMS vers le SMSC. Le
SMSC stocke le message puis le transmet au destinataire lorsque celui-ci est présent sur le réseau
(mobile allumé) : le SMSC fonctionne sur le mode "Store and Forward".

Il existe au moins un SMSC par réseau GSM. Comme tout équipement téléinformatique, le
SMSC dispose d'une partie matérielle et d'une autre logicielle ; la partie logicielle serait constituée
d'un environnement « système d'exploitation », d'une base de données spécifique et de son
serveur, d'une application SMSC.

Typiquement, le SMSC offre une variété de protocoles d’interfaces qui permettent aux entités
non-mobiles (ESME) d’envoyer des SMS aux entités mobiles. Ceux-ci incluent d’autant plus que les
protocoles SMPP et EMI (Voir les protocoles dans le chapitre 3), les protocoles du courrier
électronique et d'Internet tels que SMTP et HTTP pour les interfaces E-mail et Web [DEV 08].
Le SMSC peut se relier aux systèmes suivants :
Passerelles d'accès, parmi lesquelles celles des éditeurs de services (ESME) ;
Système de facturation;
Systèmes d'opération, d'administration et de maintenance (OAM).
2.3.2.2. L’ESME:
C’est une application externe qui se connecte à un SMSC et s'engage dans l'envoi et la
réception des SMS.Il ya trois manières de développer une application SMS « ESME » en général:
Se connecter au SMSC directement :
Le moyen le plus rapide de transférer les SMS via le réseau GSM est de se connecter
directement au SMSC ou à la passerelle SMS (Voir les passerelles SMS ci-après). Cette méthode
exige que l’application SMS soit intégrée au réseau de l’opérateur téléphonique. Le lien de
communication entre le logiciel d’application et le SMSC peut s’assurer par un réseau TCP/IP ou
une connexion X.25. L’avantage est la rapidité de la transmission des SMS. L’inconvénient est que
le SMSC est ainsi exposé à toute connexion externe.

Utiliser les API :

Le moyen le plus répandu pour développer des ESME est l’implémentation des API dans le
logiciel de l’application. Une connexion Internet est établie à partir de l’application « le serveur
SMS » qui permet de transférer les données du client à la passerelle SMS du provider qui offre le
service puis au réseau GSM. L’avantage est que les API permettent l’envoi d’un grand flux de SMS
à la fois. L’inconvénient est que les API qui offrent une bonne qualité de services sont payantes
[KHA 05] [DEV 08] [GSM 02].

Utiliser un dispositif sans fil :

Le moyen le plus rentable de mettre en place des ESME légers dans les organisations est
d’utiliser un équipement tel qu’un modem GSM qui est connecté au serveur d’application via
le port série et qui permet de transférer les données sur le réseau GSM. L’avantage de cette
solution est sa modularité : Si le ESME tombe en panne alors le système ne sera pas affecté.
L’inconvénient est que le matériel ne supporte pas un grand flux de données.

 Les Modems GSM:

Un modem GSM est un équipement de communication sur le réseau GSM qui se comporte
comme un modem dial-up. La différence principale entre eux est qu'un modem dial-up envoie et
reçoit des données par une ligne téléphonique fixe, alors qu'un modem GSM envoie et reçoit des
données par les ondes radioélectriques.
Un modem GSM peut être un dispositif externe ou une carte d'ordinateur / la Carte PCMCIA.
Typiquement, un modem GSM externe est lié à un ordinateur par un câble série ou un lien
Bluetooth, tant dis que la carte PCMCIA est conçue à l'utilisation avec un ordinateur portable.
Comme un téléphone mobile GSM, un modem GSM exige une carte SIM. Les ordinateurs utilisent
les commandes AT pour contrôler les modems.
Le nombre de SMS qui peuvent être traités par un modem GSM par minute est très réduit,
seulement environ de 6 à 10 SMS par minute.

Figure 2.5 : modem GSM

Pour y remédier à ce problème, les concepteurs ont inventé le modem GPRS :
 Les Modems GPRS
Un modem GPRS est un modem GSM qui soutient supplémentairement la technologie GPRS
pour la transmission de données. C'est une extension du GSM basée sur l’échange de paquets.
L’avantage du GPRS sur le GSM consiste en ce que GPRS a une plus haute vitesse de transmission
de données.
Le GPRS peut être utilisé comme le porteur de SMS. Si le SMS est utilisé sur le GPRS, une vitesse de
transmission d'environ 30 SMS par minute peut être accomplie, ce qui est beaucoup plus rapide
que l'utilisation du modem GSM. Certains téléphones mobiles de génération ancienne ne
soutiennent pas l'envoi et la réception des SMS sur GPRS.
Pour envoyer ou recevoir des MMS, un modem GPRS est typiquement nécessaire [DEV 08].

2.3.3. Comment envoyer des SMS depuis et vers un ordinateur ?

Nous avons vu jusque-là les trois manières du développement d’un ESME en général. Nous
allons à présent nous intéresser aux outils qui permettent la mise en œuvre de tels ESME suivant
la même logique de développement.
Nous allons présenter les politiques de l’envoi d’un SMS depuis un ordinateur et la réception d’un
SMS sur un ordinateur selon les trois méthodes proposées:
2.3.3.1. La méthode du modem :
Connecter l’ordinateur à un modem GSM/GPRS, ensuite gérer l’envoi et la réception des
SMS avec les commandes AT en utilisant l’Hyper Terminal de Microsoft.
Le MS Hyper Terminal :
Le MS Hyper Terminal est un programme de Microsoft utilisé pour envoyer les
commandes AT aux modems GSM/GPRS.
Il suffit de le lancer (Démarrer-> Programmes-> Accessoires-> Communications->
Hyper terminal), ensuite choisir les paramètres du port Com auquel est branché le
modem et enfin exécuter les commandes AT [DEV 08].
Les commandes AT :
Les commandes AT sont définies dans la norme GSM 07.05 ; elles ont été conçues
par Hayes pour piloter les modems. AT est l’abréviation d’ATtention. Chaque ligne
d’instruction commence par « AT » sous forme de texte (codes ASCII). Les commandes
AT permettent la gestion complète des modems GSM/GPRS et les téléphones mobiles ;
à titre d’exemple :
‫ ײַ‬La lecture, l'écriture et la suppression des SMS.
‫ ײַ‬L’envoi des SMS.
‫ ײַ‬Contrôler la force du signal.
 ‫ ײַ‬Contrôler le statut chargeant et le niveau de charge de la batterie.
‫ ײַ‬La lecture, l'écriture et la recherche des entrées du répertoire téléphonique.

Le tableau 2.2 résume quelque une parmi les plus importantes commandes AT :
Tableau 2.2 : Les commandes AT [Tec 07]
Commande Fonctionnement
ATD, ATA Établir une connexion de données ou de voix à un modem lointain.
AT+CBC Avoir le niveau de charge de batterie.
AT+CGMI Avoir le nom du constructeur du modem.
AT+CSCA Avoir l’adresse du SMSC.
AT+CMGS Envoi d’un SMS.
T+CMGR Lecture des SMS
AT+CMGW Ecriture des SMS
AT+CMGD Suppression des SMS
AT+CMGL Avoir la liste des SMS

2.3.3.2. La méthode du SMSC :

Connecter l’ordinateur au SMSC ou à la passerelle SMS ensuite gérer l’envoi et la
réception des SMS avec les protocoles supportés par le SMSC ou la passerelle SMS.
Les passerelles SMS « SMS Gateways »:
La difficulté qui se pose dans la messagerie SMS est que les SMSC développés par de
différentes sociétés utilisent leur propre protocole de communication et la plupart de ces
protocoles sont des propriétés. Par exemple, Nokia a un protocole SMSC appelé CIMD,
alors qu'un autre équipementier de SMSC, l’appellera CMG, et un autre aura un protocole
SMSC appelé EMI.
Deux SMSC ne peuvent pas être connectés s'ils ne soutiennent pas de protocole SMSC
commun. Pour remédier à ce problème, une passerelle SMS est placée entre deux SMSC et
agit comme un relais qui traduit un protocole SMSC à un autre (voir figure 2.6).

Figure 2.6 :La passerelle SMS reliant deux SMSC

Donc, pour développer une application SMS; l’envoie et la réception des SMS devrait se
faire par la connexion aux différents SMSC ayant chacun son propre protocole, ce qui
signifie que l’application doit soutenir des protocoles spécifiques. En conséquence, la
 complexité de l’application SMS et le temps de développement augmentent. Pour y
remédier, l’application SMS a seulement besoin de se connecter à une passerelle SMS en
utilisant les protocoles SMPP, EMI ou HTTP [DEV 08].

Figure 2.7 : La passerelle SMS reliant les SMSC et une application SMS
2.3.3.3. La méthode de l’API :
Connecter l’ordinateur au provider d’un service SMS, ensuite gérer l’envoi et la
réception des SMS avec les protocoles supportés par le provider [DEV 08].

 Les protocoles de communication:

‫ ײַ‬Le protocole EMI:
Le protocole EMI est une extension du protocole UCP, utilisé principalement pour connecter le
SMSC et le MS. Il a été développé par CMG et actuellement fait partie de LogicaCMG, le leader
des marques des SMSC. Le protocole EMI fonctionne tout comme le protocole SMPP [DIC 07].
‫ ײַ‬Le protocole SMPP:
Le SMPP est un protocole standard d'échange qui permet le transfert des SMS entre le SMSC
et l’ESME. Il utilise en général des connexions TCP/IP, l’une pour l'envoi de données
« Transmitter » et l'autre pour la réception « Receiver ».
2.4. Conclusion :
Dans ce chapitre, nous avons abordé l’architecture du réseau GSM pour ensuite nous intéresser à
l’aspect purement technologique du concept SMS paiement.
Nous allons à présent voir encore plus en détail les différents protocoles utilisés dans notre
application, et nous focaliser sur la cryptographie pour sécuriser cette dernière.
 Chapitre 3 :

Protocoles de communication et cryptographie

3.1. Introduction :

Dans ce 3ème chapitre, nous allons étudier les protocoles nécessaires à l’envoie et la réception des
messages, ainsi que le protocole FTP utilisé pour une communication entre l’organisme offrant le
service et l’operateur.
Une étude sera faite par la suite, sur la cryptographie et la sécurité des SMS.

3.2. Introduction au SMPP:

SMPP est un protocole de niveau-7 du modèle OSI (couche application), qui permet une diffusion
rapide des messages SMS. Il n’est pas destiné à offrir la fonctionnalité de transport(le fenêtrage, le
contrôle de flux et de la gestion des erreurs, etc.). Il est utilisé pour envoyer et recevoir des
messages dans les réseaux cellulaires GSM et UMTS.
La figure « 3.1 » ci-dessous illustre une implémentation générique SMPP entre un ESME
et SMSC :

Figure 3.1 : implémentation générique SMPP

Le SMPP permet par exemple de :
Transmettre le SMS d’un ESME vers une destination unique ou multiple via le SMSC.
Recevoir le SMS sur l’ESME via le SMSC.
Avoir le statut d’un SMS sauvegardé dans le SMSC.
Annuler ou remplacer un SMS sauvegardé dans le SMSC.
Envoyer un SMS enregistré « pour lequel un accusé de réception va être envoyé par le
SMSC au MS ».
Planifier la date et l’heure de l’envoi du SMS.[SMP 99]
Au lieu d'envoyer des messages à partir d’un modem GSM, l’utilisation du protocole SMPP
présente les avantages suivants:
Le protocole SMPP est basé sur TCP/IP.
Les utilisateurs peuvent envoyer des SMS vers un simple shortcode.
Haut débit« jusqu'à 200 messages par seconde ».
Adresse de l'expéditeur alphanumérique peut être attribué[SMP 99].

3.2.1. Connexions:
SMPP est utilisé par les clients pour se connecter à un SMSC. En ce qui concerne SMPP, le
client est appelé ESME. Les SMSCs peuvent également échanger des données en utilisant une
connexion SMPP. Les messages envoyés à un SMSC sont des MT messages. Les messages
reçus à partir d'un SMSC sont des MO messages[SMP 99].
Quand un ESME établit une connexion en utilisant SMPP, cela peut être fait en trois modes:
Transmitter : ESME envoie seulement des messages au SMSC;
Receiver : ESME reçoit seulement des messages ou des rapports de livraison de l'SMSC;
Transceiver: l'EMSE peut envoyer et recevoir des messages vers et depuis le SMSC[TOL
07].

3.2.2. Les PDU:

Les paquets TCP entre le ESME et le SMSC sont appelés PDU. Les types de PDU suivants sont
utilisés dans les connexions SMPP:
Session Management PDU : « gestion de session »
Connexion, déconnexion.
Message Submission PDU : « envoi du message »
Envoi des messages à un téléphone mobile.
Message Delivery PDU : « remise des messages »
La livraison des messages au client SMPP.
Ancillary Operations PDU : « opérations auxiliaires »
Requête message, d'annulation et de remplacement.
PDU les plus utilisée sont les suivants:
bind_transmitter/bind_receiver/bind_transceiver:
Utilisé pour connecter le client avec le SMSC, dans des sessions SMPP un ID et un mot de
passes ont utilisés pour l'authentification.
submit_sm :
Utilisé pour envoyer un message unique à partir du client vers le SMSC« MT ». Ce paquet
contient l'expéditeur, le destinataire, le corps du message et des paramètres optionnels.
deliver_sm:
Quand un message doit être livré au client ce paquet est utilisé« MO ». Il contient des
informations sur l'expéditeur du message et le corps du message. Ce PDU est également
utilisé pour envoyer des rapports de livraison à l'ESME.
query_sm:
Pour interroger l'état d'un message précédemment envoyé. On a besoin d'une référence
de message pour l’interroger.
enquire_link:
Ce paquet est envoyé une fois dans toutes les x minutes pour vérifier si la connexion est
maintenue. Sinon, la connexion est interrompue. Le délai d'attente le plus utilisé pour les
connexions SMPP est d'une minute.
Unbind:
Utilisé pour mettre fin à la session et déconnecter la connexion TCP / IP[SMP 99].

Le format général d'un PDUSMPP se compose d’une partie en-tête et une partie corps, décrites
dans le « Tableau 3.1 » ci-dessous :

Tableau3.1 : Le format général d'un PDU SMPP

PDU SMPP
PDU header (obligatoire) PDU body (facultatif)
Command Command Command Sequence PDU body
length id status number
4 octets Longueur= (la valeur de command length-4)octets
L'en-tête d’un PDU contient:

command_length :Le champ command_length définit la longueur totale en octet du paquet

SMPP.
command_id : Le champ est un identifiant de commande unique, il est attribuée à chaque
demande SMPP dans la gamme:0x00000000à0x000001ff.
command_status :Le champ command_status indique le succès ou l'échec d'une demande
SMPP.
sequence_number : Ce champ contient un numéro de séquence qui associe les requêtes et les
réponses SMPP à fin d’avoir une corrélation et permet un échange de paquet asynchrone.

Le corps PDU contient:

Paramètres obligatoire: chaque PDU défini dans le champ command_id, il lui correspond une
liste de paramètres obligatoires.
Paramètres optionnels: chaque PDU définit dans le champ command_id, il lui correspond une
liste de paramètres facultatifs [SMP 99].
La session SMPP peut être définie par ces différents états :
OPEN : Un ESME a établi une connexion avec le SMSC mais n'a pas encore publié sa
requête.
BOUND_TX: Un ESME connecté a fait une demande de connexion ESME Transmitter en
publiant un « bind_transmitter » et reçoit une réponse de la part du SMSC qui autorise sa
requête de connexion. Un ESME relié comme un Transmitter peut envoyer des SMS à un
SMSC qui ensuite vont être envoyés à un portable ou un autre ESME. L‘ESME peut aussi
requêter, remplacer ou annuler un message précédemment soumis.
BOUND_RX : Un ESME connecté fait une demande de connexion ESME Receiver en
publiant un « bind_receiver » et reçoit une réponse de la part du SMSC qui autorise sa
requête de connexion. Un ESME relié comme un Receiver peut recevoir des SMS d'un
SMSC (l'origine d'envoi de message peut être un portable, un autre ESME ou SMSC).
BOUND_TRX : Un ESME connecté fait une demande de connexion comme un ESME
Transceiver en publiant un « bind_transceiver » et reçoit une réponse de la part du SMSC
qui autorise sa requête de connexion. Un ESME relié comme un Transceiver supporte
toutes les opérations supportées par un ESME Transmitter et un ESME Receiver. ESME
connecté comme transceiver peut envoyer les SMS vers un SMSC. Les SMS son ensuite
 envoyés vers un portable ou vers un autre ESME. Egalement, dans ce cas, l'ESME peut
recevoir un SMS provenant d'un portable, d’un autre ESME ou de SMSC lui-même.
CLOSED : L’ESME est déconnecté du SMSC et la connexion réseau est fermée. Le SMSC est
alors déconnecté de l’ESME.

Des exemples de raccordement sont présentés dans les figure 3.2 et 3.3 :

Figure 3.2 : Envoi messages

Figure 3.3 :Réception messages

 3.2.3. Paramètres optionnels SMPP:
Pour prolonger le protocole SMPP avec des paramètres supplémentaires, les paramètres
TLV, également appelés paramètres optionnels ont été introduits dans le protocole SMPP
depuis la version3.4, ils sont:
Utilisés pour faire des PDU existants plus efficaces.
Utilisés pour améliorer PDU existants avec de nouvelles fonctionnalités.
Certains TLV couramment utilisés sont les suivantes [SMP 99] :
message_payload:
Utilisé pour coder des messages volumineux. Le PDU submit_sm peut être utilisé pour des
messages jusqu'à 255caractèresseulement. Ce PDU améliore les performances, par
exemple: au lieu d'envoyer un messagecontenant315caractères en deux, on envoie qu’un
seule paquet.
sar_msg_ref_num,sar_segment_seqnum,sar_total_segments:
Segmentation et le réassemblage. Ces valeurs limites d'exposition sont utilisées pour
envoyer un long message en plusieurs parties.
sar_msg_ref_num- Référence du message concaténé.
sar_segment_seqnum- IDdu segment courant.
sar_total_segments-Nombre total de segments.

3.3. La signalisation SS7 :

Le système de signalisation « SS7 » est un protocole de transmission qui fournit la signalisation et

la commande pour différents services et possibilités de réseau. Par opposition à la signalisation
voie par voie, la signalisation par canal sémaphore est définie comme une méthode dans laquelle
une seule voie, appelée canal sémaphore, achemine la signalisation se rapportant à une
multiplicité de circuits.

La signalisation sémaphore peut également servir à échanger des messages de gestion et de

supervision entre commutateurs, la signalisation sémaphore consiste à séparer logiquement
l'aspect signalisation de l'aspect transmission des informations usagers [ZNA 00].
 3.3.1. Applications SS7 :
Les applications courantes de SS7 sont :

Gestion des appels de base (établissement, maintenance, rupture).

Gestion de la mobilité dans les réseaux GSM : roaming, identification, authentification et
localisation des usagers mobiles.
Acheminement des SMS.
Applications RI « Réseau Intelligent » :
‫ ײַ‬Services complémentaires: transfert d’appels, conférence à 3, etc.
‫ ײַ‬Gestion de réseaux VPN.(voir annexe C).
‫ ײַ‬Gestion de cartes prépayées.

3.3.2. La pile de protocoles de communication SS7 :

Le réseau sémaphore étant un réseau à commutation par paquets, il est naturel de reprendre
une architecture en couches. Dans le contexte de SS7 on parle plutôt de niveau, mais le concept
est le même [ZNA 00].
Le protocole SS7 standard a 4 niveaux « couches ». Les niveaux de 1 à 3 constituent la pièce
de transfert de message « MTP » et le niveau 4 est la pièce d’utilisateur (figure 3.4).
Un message SS7 s’appelle une unité de signal« SU » (voir annexe D).

Figure 3.4 : Pile de protocoles de communication SS7

 3.3.2.1. Le niveau 1 de MTP :
Est équivalent à la couche physique du modèle OSI, il définit les caractéristiques physiques,
électriques, et fonctionnelles du lien de signalisation numérique.
3.3.2.2. Le niveau 2 de MTP :
Est équivalent à la couche liaison de données du modèle OSI, il assure la transmission bout à bout
précise d’un message à travers un lien de signalisation.
3.3.2.3. Le niveau 3 de MTP :
Est équivalent à la couche réseau du modèle OSI, il fournit le cheminement de message entre les
points de signalisation dans le réseau SS7.

Le niveau 3 de MTP, conduit des messages basés sur l’étiquette de cheminement dans le
domaine de l’information de signalisation « SIF » des unités de signal de message [MOR 06].
3.3.2.4. Niveau 4 :
Les services SS7 sont décrits par les couches applicatives du modèle OSI « de 4 à 7 »:
ISUP : définit le protocole et les procédures employées pour établir, gérer et rompre
des circuits de commutation qui acheminent la parole et les données entre
commutateurs. Les appels qui commencent et se terminent sur le même
commutateur n’emploient pas la signalisation ISUP.
SCCP: assure des fonctions supplémentaires à MTP3 pour transférer des informations
de signalisation en mode avec ou sans connexion. Tandis que le niveau 3 de MTP
fournit des codes de point pour permettre à des messages d’être adressés aux points
de signalisation spécifiques.
TCAP: permet le déploiement des services de réseau intelligents avancés en
soutenant l’échange de l’information reliée par circuit entre les points de
signalisation en utilisant le service sans connexion de SCCP.
Différentes applications utilisent les services de TCAP parmi celle-ci figurent les
suivantes :
INAP: est le protocole permettant l’exécution de services à valeur ajouté.
Exemple : L’interrogation d’une base de données de numéro vert afin d’obtenir la
traduction entre un numéro vert et le numéro physique correspondant.
OMAP:offre un service de la gestion du réseau sémaphore N°7.
 MAP: le protocole MAP régit l’ensemble des échanges entre équipements du
réseau mobile « NSS ». Il offre les fonctions de signalisation nécessaires à un
service de communication voix ou données dans un réseau mobile. Il a
principalement trait à toutes les fonctions qui permettent à un mobile d’être
itinérant. Il s’appuie sur la pile de protocole SS7 qui garantit un transport fiable.
Le protocole MAP concerne les dialogues entre différentes entités du réseau
mobile notamment, MSC/VLR, MSC Server, SGSN, HLR, EIR, SMSC, etc. Le
protocole MAP est utilisé dans les procédures relatives : au service de mobilité, le
HANDOVER inter-MSC, le traitement d’appel, l‘invocation des services USSD,
l’échange de SMS, au service de localisation…

Nous allons par la suite détailler l’utilité du protocole MAP dans les services SMS.

3.3.3. Le MAP dans le Service SMS :

Le service « SMS », s’appuie sur la capacité d’un terminal mobile à émettre et recevoir des
messages alphanumériques. Les messages courts sont des messages textuels d'au plus 160
caractères « codés à l'aide d'ASCII 7 bits sur 140 octets » et sont délivrés en quelques secondes
lorsque le destinataire est rattaché au réseau.
Pour mettre en place ce service SMS, l'opérateur doit prévoir un ou plusieurs serveurs dédiés et
reliés au réseau « SMSC ».
Le service SMS s'appuie sur le protocole MAP, qui permet le transport du SMS du MSC de
l'émetteur au SMSC, l'interrogation du SMSC au HLR pour identifier le MSC du destinataire, puis le
transport du SMS du SMSC au MSC du destinataire. Les messages MAP relatifs au service SMS sont
[EFO 11] :
MAP-SEND-ROUTING-INFO-FOR-SMS: Ce service est utilisé entre le SMSC et le HLR afin que le
SMSC obtienne l’information de routage lui permettant d’acheminer le message court au MSC,
MSC Server ou SGSN auquel est rattaché le destinataire.
MAP-MT-FORWARD-SHORT-MESSAGE: Ce service est utilisé entre le SMSC et le MSC, MSC
Server ou SGSN afin de délivrer le message court.
MAP-REPORT-SM-DELIVERY-STATUS: Ce service est utilisé entre le SMSC et le HLR. Il permet
de positionner les données MWD dans le HLR lorsque le message n’a pas pu être délivré au
 destinataire ou d’informer le HLR du transfert avec succès du SMS. Ce service est invoqué par
le SMSC.
MAP-READY-FOR-SM : Ce service est utilisé entre le VLR et le HLR ou entre le SGSN et le HLR.
Le VLR ou le SGSN utilise le service soit parce que le mobile a de nouveau une mémoire
disponible pour recevoir des SMS, soit parce que le mobile a de nouveau un contact radio avec
le MSC ou SGSN alors que le MWD est positionné au niveau du VLR ou du SGSN.
MAP-ALERT-SERVICE-CENTRE : Ce service est utilisé entre le HLR et le SMSC. Le HLR initie ce
service si le HLR détecte qu’un usager, dont le MSISDN est dans le fichier MWD, est de
nouveau joignable ou si le mobile a de nouveau de la mémoire disponible pour recevoir le
SMS.
MAP-INFORM-SERVICE-CENTRE : Ce service est utilisé entre le HLR et le SMSC afin que le HLR
informe le SMSC que son adresse SS7 est stockée dans le fichier MWD.

Avec le service SM-MO, la station mobile envoie un message court au SMSC. Dans ce cas, le
cheminement logique des messages courts est le suivant : MS→MSC→SMSC (voir figure 3.5)
Lorsque l'utilisateur mobile souhaite envoyer un message court, il doit indiquer le MSISDN du
destinataire et l’adresse du SMSC. L'adresse du SMSC est présente sur le module SIM.
1. L’émetteur remet le message court à son MSC/VLR de rattachement « VMSC/VLR » à travers la
demande SMS-SUBMIT.
2. Le MSC émet un message MAP-SEND-INFO-FOR-MO-SMS à son VLR pour lui demander le
numéro de téléphone « MSISDN » de l’émetteur et pour vérifier qu’aucune restriction n’est
imposée à cet émetteur. Le VLR retourne alors une réponse MAP-SEND-INFO-FOR-SMS-ack.
3. Si la réponse est positive, le MSC émet le message MAP-MO-FORWARD-SHORTMESSAGE au
SMSC. Ce message contient l’adresse du SMSC, les numéros MSISDN de l’émetteur et du
destinataire, et le message court. Le message court est donc véhiculé dans une transaction MAP.
Le SMSC stocke le message et les adresses dans sa mémoire.
4. Le SMSC demande des informations de routage du message au HLR du destinataire du SMS à
travers la requête MAP-SEND-ROUTING-INFO-FOR-SM, informations qui lui permettent de relayer
le message au MSC approprié (MSC auquel est rattachée MS destinataire). Cette requête contient
notamment le numéro MSISDN du destinataire.
Le HLR utilise ce numéro pour rechercher les informations de routage qu’il retourne au SMSC à
travers la réponse MAP-SEND-ROUTING-INFO-FOR-SM-ack. Cette réponse contient l’IMSI du
destinataire et l’adresse du MSC de rattachement.
5. Le SMSC délivre le message court au MSC à travers une requête MAP-MT-FORWARD-SHORT-
MESSAGE. Le MSC émet la requête MAP-SEND-INFO-FOR-MT-SMS à son VLR en vue d’obtenir des
informations relatives au destinataire. Le paramètre passé dans cette requête est l’IMSI du
destinataire.
6. A partir de l’IMSI fourni par le MSC, le VLR identifie la zone de localisation « LA » du mobile
destinataire. Le VLR lance alors une procédure de paging, technique consistant à effectuer une
recherche sur l’ensemble de la zone où est susceptible de se trouver le mobile demandé. La
procédure de paging est initiée par le VLR mais effectuée par le MSC. La station mobile
destinataire répond positivement. Le VLR retourne une réponseMAP-SEND-INFO-FOR-MT-SMS-
ackau MSC.
7. Le MSC relaye le message court à la station mobile destinataire via le message SMSDELIVER et
reçoit un acquittement SMS-STATUS-REPORT. [EFO 11]

Figure 3.5 : Envoi d'un SMS à un destinataire joignable

3.4. Introduction au protocole FTP :
Le protocole de transfert de fichier FTP définit la façon selon laquelle des données doivent être
transférées sur un réseau TCP/IP. Il a pour objectifs de permettre:

Un partage de fichiers entre machines distantes.

Une indépendance aux systèmes de fichiers des machines clientes et serveur.

Le transfert des données de manière efficace[POS 85].

3.4.1. Le modèle FTP :

Le protocole FTP s'inscrit dans un modèle client-serveur, c'est-à-dire qu'une machine envoie des
ordres (le client) et que l'autre attend des requêtes pour effectuer des actions (le serveur).
Lors d'une connexion FTP, deux canaux de transmission sont ouverts :

Un canal pour les commandes (canal de contrôle).

Un canal pour les données[POS 85].

Serveur Client
Canal de
contrôle Utilisateur

Commandes
Server Réponses Client
PI PI

Server Canal de User

DTP Données DTP

Système de Système de
fichiers fichiers

Figure 3.6 :Le modèle FTP

Ainsi, le client comme le serveur possèdent deux processus permettant de gérer ces deux types
d'information (voir figure3.6) :
Le DTP est le processus chargé d'établir la connexion et de gérer le canal de données. Le
DTP côté serveur est appelé SERVER-DTP, le DTP côté client est appelé USER-DTP
Le PI est l'interpréteur de protocole permettant de commander le DTP à l'aide des
commandes reçues sur le canal de contrôle. Il est différent sur le client et sur le serveur :
  Le SERVER-PI est chargé d'écouter les commandes provenant d'un USER-PI sur le
canal de contrôle sur un [port donné], d'établir la connexion pour le canal de
contrôle, de recevoir sur celui-ci les commandes FTP de l'USER-PI, d'y répondre
et de piloter le SERVER-DTP.

 Le USER-PI est chargé d'établir la connexion avec le serveur FTP, d'envoyer les
commandes FTP, de recevoir les réponses du SERVER-PI et de contrôler le USER-
DTP si besoin.
Lors de la connexion d'un client FTP à un serveur FTP, l’USER-PI initie la connexion au serveur
selon le protocole Telnet. Le client envoie des commandes FTP au serveur, ce dernier les
interprète, pilote son DTP, puis renvoie une réponse standard. Lorsque la connexion est établie, le
serveur-PI donne le port sur lequel les données seront envoyées au Client DTP. Le client DTP
écoute alors sur le port spécifié les données en provenance du serveur[POS 85].
3.4.2. Les commandes FTP :
Toutes les communications effectuées sur le canal de contrôle suivent les recommandations du
protocole Telnet. Ainsi les commandes FTP sont des chaînes de caractères Telnet (en code NVT-
ASCII) terminées par le code de fin de ligne Telnet Carriage Return « retour chariot ».
Les commandes FTP permettent de préciser :

Le port utilisé.

Le mode de transfert des données.

La structure des données.

La nature de l'action à effectuer (List, Store, ...).

On distingue trois types de commandes FTP :

Les commandes de contrôle d'accès.

Les commandes du paramétrage de transfert.
Les commandes de service FTP.

3.5. Introduction à la sécurité de l’application:

Suite à une étude du réseau GSM, il s’est avéré que ce dernier présente un certain nombre de
failles qui ont un impact direct sur la sécurité des applications professionnelles. Sécuriser
l’application consisterait donc à greffer une couche supplémentaire au-dessus des services offerts
afin d’assurer un échange de SMS sécurisés.
Ceci nous amène à étudier certaines notions de cryptographie, puis étudier la sécurité du réseau
GSM et voir les vulnérabilités du système.
3.5.1. Algorithmes de hachage :
L'algorithme de hachage calcule une empreinte (hash) à partir de données fournies en entrée. Si
deux empreintes sont identiques c'est qu'elles ont été calculées d'après les mêmes données, du
moins dans la théorie.
En pratique il est possible d'avoir une même empreinte pour des données différentes. On parle
alors de collision. Néanmoins, les algorithmes utilisés en cryptographie ont très peu de chance de
générer des collisions[MEJ 05].
Dans le cadre de la signature, cet algorithme est utilisé pour créer une empreinte des informations
à signer.
3.5.2. Algorithmes de chiffrement :
L'algorithme de chiffrement permet de protéger des données en les rendant illisibles, si on ne
possède pas la clé pour les déchiffrer. Il existe trois types d'algorithmes de chiffrement :
3.5.2.1. Les algorithmes symétriques (ex : DES):
Rapides.
Basés sur une clé unique, ce qui impose une transmission sécurisée de la clé [MEJ
05].

Figure 3.7 : schéma illustrative d’un algorithme de chiffrement symétrique.

 3.5.2.2. Les algorithmes asymétriques(ex : RSA) :
Lents.
Basés sur un système clé publique / clé privée.
• Chaque personne dispose d’une paire de clé :(Clé privée : connue
uniquement par son propriétaire, Clé publique : publiée dans des annuaires
publics). Si on crypte avec l’une de ces clés, le décryptage se fait
uniquement avec l’autre.
Permettent la signature.[MEJ 05]

Figure 3.8 :schéma illustrative d’un algorithme de chiffrement asymétrique.

3.5.2.3. Les algorithmes hybrides :

Le principe c'est d'utiliser un algorithme symétrique et un algorithme asymétrique dans le même
processus (d'où le terme hybride) en ne prenant que le meilleur de chacun. L'idée générale c'est
de générer une clé pour l'algorithme symétrique. On chiffre le message avec cette clé (avantage
=» rapidité). Ensuite, on chiffre la clé avec un algorithme asymétrique (avantage =» transmission
sécurisée de la clé par le biais d'un système clé publique/clé privée).
Côté destinataire, il suffit de déchiffrer la clé avec la clé publique pour déchiffrer ensuite le
message. Dans le cadre de la signature, cet algorithme est utilisé d'une part pour chiffrer
l'empreinte des informations à signer et d'autre part pour déchiffrer l'empreinte signée lors de la
vérification de la signature.
La signature électronique est un élément substantiel dans le domaine du commerce électronique,
car c’est une empreinte protégée par un certificat permettant la reconnaissance, la confidentialité,
la sécurité, l'authenticité des données de l’usager, et son importance dérive de ses qualités :
 Non imitable.
 Non répudiable.
 Protège le contenu contre les modifications.
 Permet de signer directement tout ce qui est numérisable.

Figure 3.9 : la signature électronique « algorithme hybride ».

1- Calcul de l'empreinte des données à signer.

2- Chiffrement de l'empreinte à l'aide de la clé privée. On obtient alors la signature.
3- Déchiffrement de la signature avec la clé publique. Cela permet de retrouver l'empreinte
associée aux données signées.
4- Calcul de l'empreinte des données signées. On vérifie que cette empreinte correspond à la
précédente, auquel cas la signature est valide : les données sont donc intègres et l'identité de
l'expéditeur est vérifiée.

3.5.3. La sécurité du réseau GSM :

La sécurité du réseau GSM repose sur des mécanismes cryptographiques non publiés et utilisent
d'une part un code enregistré dans la carte SIM : le code IMSI, d'autre part un code unique
composé de 15 chiffres qui identifie le MS : le code IMEI qui est stocké dans le EIR. Le MS
fonctionne uniquement si l’IMSI et l’IMEI sont valides. D’autant plus, une clé secrète Ki est
attribuée par l’opérateur téléphonique et est utilisée en cryptographie dans toutes les fonctions
sécurisées [GSM 02].

L’authentification de l’abonné est assurée par l’algorithme A3 qui exige que le MS et l’opérateur
ont la même clé Ki en calculant un code aléatoire SRES. Le transfert des données via le réseau GSM
est sécurisé grâce au mécanisme de cryptage A5. Le cryptage se fait uniquement entre le MS et le
BTS ; ailleurs aucun cryptage n’est valable. A5 utilise une clé symétrique Kc qui est générée grâce
au mécanisme A8 en utilisant la clé Ki. L’algorithme A5 (dit algorithme de chiffrement à flot) utilise
la clé Kc et les données comme paramètres pour générer la donnée cryptée Ekc qui sera circulée
dans le réseau entre le MS et le BTS.

Figure 3.10: L’algorithme A3Figure 3.11 : L’algorithme A8

Figure 3.12 :L’algorithme A5

Il existe deux versions de l’algorithme A5 : Le A5/1 et A5/2.

Le A5/1: est la version la plus puissante de l’algorithme, l’algorithme fut inventé par
Biryukov, Shamir &Wagni mais ses spécifications n’ont jamais été publiées.
L’A5/2: l’algorithme à flot plus faible. Il a prouvé sa vulnérabilité en 1999 quand il a été
craqué par le cryptologue Goldberg. Depuis ; une troisième version : le A5/3 fut inventée
par Goldberg mais son utilisation demeure réservée [CHI 06].
 3.5.4. Critères de sécurité du paiement mobile:
Un système de paiement mobile sécurisé doit disposer des propriétés suivantes:
Confidentialité: Les informations confidentielles doivent être sécurisées vis-à-vis d'une
personne, d’un processus ou périphérique non autorisées.
Authentification: assure que les parties ayant accès à une transaction ne sont pas des
imposteurs et ils sont de confiance.
Intégrité: l'information et les systèmes n'ont pas été modifiés ou corrompus par l'extérieur
des parties.
Autorisation: Vérifiez que l'utilisateur est autorisé à faire la transaction demandée avec le
code PIN de système SMS-paiements, la sécurité est bien meilleure sur ce sujet.
Non-répudiation: garantit que l'utilisateur ne doit pas nier qu’il a effectué une transaction.
3.5.5. Vulnérabilités d’un service SMS paiement :

Les messages SMS ne sont pas totalement sécurisés, il y a plusieurs failles de sécurité dans le
réseau GSM :

3.5.5.1. 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.5.2. Crash d’un mobile:
Des recherches ont été réalisées 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.5.3. 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 a pour effet de bloquer la queue et de
rejeter tous les messages envoyés vers la cible.
L’opérateur peut utiliser un outil de « monitoring » pour chaque queue créée dans le
buffer de stockage afin d’y remédier.
De plus, la partie la plus importante du SMSC réside dans l’OSS. Il s'agit d'un réseau de
dispositifs qui permettent de gérer les fonctions de base telle que la facturation. La
sécurité ici est critique car cette infrastructure est accessible via IP, donc risque d’être
piratée.

3.5.5.4. IMSI-Catcher :
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.
3.5.5.5. Man-in-the-middle:
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é.
3.6. Conclusion :
Dans ce chapitre, nous avons vu les différents protocoles utilisé dans notre application de
paiement mobile.
Par ailleurs, nous avons introduit certaines notions de cryptographie pour ensuite exposer les
différentes failles du réseau GSM qui seront étudiées pour sécuriser notre application.
Dans le chapitre suivant, nous allons effectuer en premier lieu une analyse de besoins, prendre en
considération la solution actuelle qui sera notre point de départ pour l’adapter. Nous procéderont
ensuite à l’implémentation et l’évaluation des résultats.
 Chapitre 4 :

Conception et mise en œuvre d’un système de paiement sur réseaux

mobiles GSM via SMS
4.1. Introduction :
Dans les trois chapitres précédents, nous avons présenté les principaux axes de notre travail: la
technologie d’accès utilisée pour initier le paiement, les méthodes de développement et de
sécurisation ainsi que les protocoles utilisés dans tout le processus.
Le présent chapitre présente d’une part la phase de conception, qui nécessite une bonne
compréhension de la solution actuelle pour essayer de l’adapter à notre objectif, l’étude des
besoins ainsi que la rédaction d’un cahier de charges. D’autre part, ce chapitre comprend
également la phase d’implémentation, des tests et l’évaluation de la solution proposée.
4.2. Présentation de la solution en cours à Algérie Poste :
Algérie poste est confrontée au principal enjeu, qui consiste à rendre un service public de

meilleure qualité, centré sur les besoins du citoyen.

Dans cette optique, un projet I.B.P. « Informatisation des Bureaux de Poste » a été lancé.
4.2.1. Solution « IBP » Postal Desktop :

Figure 4.1 : interface IBP.

Une interface simple et intuitive facilitant la prise en main par le personnel (figure 4.1). Parmi
ces principales fonctionnalités :
Le service d’encaissement « factures tiers »est paramétré pour un certain nombre de tiers (SEAAL,
MOBILIS, CETELEM, SONELGAZ, Société Générale, BNP Paribas...) et peut-être étendu à d’autres.
Un encaissement peut être total ou partiel.
Exemple :
Pour le paiement d’une facture d’électricité, quatre paramètres sont introduits:
N° de référence.
N° de facture.
N°I.B.P. est variable.
Le montant à payer.
Rappelons que ces 4 champs sont nécessaires pour effectuer une transaction.
4.2.2. Les principaux objectifs :
 Amélioration de la qualité de service par la réduction des délais, des files d’attente.
Disponibilité du service par l’instauration de la polyvalence des guichets.
Amélioration des conditions de travail du personnel.
Ouverture vers les nouvelles technologies.
La réduction maximale de la gestion manuelle fastidieuse.
4.2.3. Mode d’interconnexion : « actuelle »
Le mode d’interconnexion de la solution actuelle déployée par Algérie Poste est illustrée par la
figure 4.2, qui décrit le cheminement des données depuis un guichet d’Algérie poste jusqu’au
SONELGAZ.

Figure 4.2 : exemple d’interconnexion SONELGAZ et Algérie Poste

4.3. Solution proposée :

A notre ère de mobilité, notre approche était avant tout de partir du client, de ses espérances,
pour lui permettre de: Payer ses factures, visualiser l’état de la facture (payé ou pas), en utilisant
son téléphone mobile.
Avoir accès à un tel service quotidiennement H24 sans pour autant se déplacer au guichet.
L’objectif de notre travail est de concevoir et réaliser une application M-paiement qui pourra être
intégrée au système d’information d’Algérie poste (voir figure 4.3) avec une sécurité optimale.
Pour cela, alors nous proposons le schéma d’interconnexion suivant :
 Figure 4.3 : Interconnexion MOBILIS et Algérie Poste
La sécurité du SMS est critique car elle dépend entièrement du réseau GSM. Nous avons vu
précédemment qu’au niveau du réseau GSM, le SMS est crypté « avec l’algorithme A5 » depuis le
BTS jusqu’au MS, ce qui veut dire que toute attaque externe ciblant le BTS ne peut pas intercepter
les SMS en texte clair. Néanmoins, les SMS sont décryptés à partir de la BTS et sont stockées dans
le SMSC en texte clair, ce qui veut dire que toute attaque externe ciblant le SMSC peut intercepter
le contenu des SMS.
Afin de limiter les risques venant de la défaillance du réseau GSM, la solution proposée est
considérée comme un canal de communication à distance entre le SMSC et le serveur d’Algérie
poste.
Toutefois, tout opérateur de téléphonie mobile fournisseur d’une LS (Ligne Spécialisée) est
responsable d’assurer la sécurité des SMS.

La L.S. est une connexion permanente constituée d'un ou de plusieurs tronçons d'un réseau
public mis bout à bout et affectée à une organisation (entreprise, administration,...). C'est une
liaison offrant des débits de connexion symétriques.

Par le biais d'un canal unique exclusivement réservé, une liaison spécialisée offre la possibilité
d'échanger tous types de données : voix, données et vidéos. Toutes les communications sont
normalement sécurisées et offrent ainsi une fiabilité et une confidentialité totales.
Avec ce choix on aura :
Une communication permanente en toute sécurité.
Une bande passante dédiée et garantie.
 4.3.1. Mode d’interconnexion globale :

Figure 4.4 : Mode d’interconnexion globale

L’objectif visé consiste à mettre au point une solution qui permettra aux clients MOBILIS qui
disposent d’un compte CCP d’accéder au service du paiement par mobile via SMS.

4.4. L’environnement de développement:

4.4.1. Choix du langage de programmation:

L’application que nous avons développée est écrite en Java, langage de programmation
développé par SUN. En voici ses principaux avantages :
Il est doté en standard d'une riche bibliothèque de classes (ex : SMPP), comprenant la gestion des
interfaces graphiques (fenêtres, boites de dialogue, contrôles, menus, graphisme), la
programmation multitâche et la gestion des exceptions.
C'est un langage orienté objet dérivé du C multi plateforme.

La particularité principale de Java est que les logiciels écrits dans ce langage sont très facilement
portables sur plusieurs systèmes d'exploitation tels que l’Unix, Windows, Mac OS ou GNU/Linux,
avec peu ou pas de modifications.
 4.4.2. Choix du système de gestion de bases de données « SGBD »:

Nous avons utilisé PostgreSQL 9.1, qui est un système de gestion de bases de données
relationnelles. Ce dernier a été développé à l'université de Californie au département des sciences
informatiques de Berkeley.
PostgreSQL est un descendant Open Source du code original de Berkeley. Il supporte une grande
partie du standard SQL tout en offrant de nombreuses fonctionnalités modernes :
requêtes complexes,
clés étrangères,
déclencheurs « triggers » qui définissent des opérations qui s’effectueront lorsqu’un
événement d’insert, update, delete surviendra dans la base de données,
l'héritage.
4.5. Préconception :
Avant de se lancer dans la conception, on admet que :
L’accès à la base de données est impossible à partir de l’extérieur,
L’utilisateur dispose d’un compte CCP au préalable,
L’utilisateur choisit, durant l’enregistrement, un mot de passe « code » que lui seul est
sensé connaître,
L’opérateur dispose d’une méthode sécurisée pour la distribution de l’application à
ses clients.
4.5.1. Objectifs et cahier de charges :
Le cahier de charges englobe toutes les procédures des traitements que doivent accomplir les
modules de l’application. Ainsi, les tâches à réaliser sont les suivantes:
Recevoir un message au niveau du SMSC par le biais du protocole MAP.
Diriger le message reçu vers l’ESME concerné où l’application sera développée, la
réception se fait par le biais du protocole SMPP.
Interroger la base de données pour donner l’autorisation du service au client, puis
refuser ou appliquer la transaction.
Un message sera envoyé au client contenant une réponse sur la demande.
Rédiger un rapport sous format PDF concernant la transaction.
Envoyer le rapport par le biais du protocole FTP.
 4.5.2. Déroulement :

Le déroulement d’un tel service pour un client enregistré, se fait comme suit :
Le client MOBILIS « MS » envoie un SMS contenant le nom de service « SONELGAZ, SEAAL,
etc. »
L’ESME reçoit le SMS et vérifie l’existence du compte client en interrogeant la base de
données avec des commandes SQL.
Si l’authentification n’est pas vérifiée, un message d’erreur est envoyé au client : « Une
erreur s’est produite, veuillez vérifier la syntaxe ou demandez l’activation du service».
Si l’authentification est vérifiée, l’application « M-paiement » interroge les tables de la
BDD pour avoir des informations concernant la facture à payer et le compte CCP « état de
la facture, montant CCP, montant facture, etc. »
Si la facture est payée « montant facture=0 » le client reçoit comme message « votre
facture a été déjà payée».
Sinon, si le «montant facture > montant CCP » la transaction n’est pas possible, le
client reçoit comme message « impossible de payer votre facture, vous n’avez pas
assez de solde».
Sinon, on aura une possibilité de paiement (montant facture < montant CCP) le client
reçoit comme message « votre facture est payée ».

Dans le dernier cas, qui est notre objectif, la modification de plusieurs champs dans les tables de la
BDD sera faite :
état de la facture =>mise à jour pour garder les traces ;
montant facture => initialiser à 0 ;
débiter le montant du compte CCP du client ;
créditer le montant du compte CCP de SONELGAZ, SEAAL, etc.

Générer automatiquement un rapport de paiement sous format PDF contenant les

informations suivantes :
Numéro MSISDN ;
Nom et prénom;
Numéro de facture ;
 Montant à payer ;
Numéro I.B.P. ;
Etat de la facture ;
Date et heure du paiement.

Algérie poste archivera le rapport de paiement, et l’enverra ensuite à SONELGAZ en utilisant le

protocole FTP afin de mettre à jour le client.

4.6. Diagramme de séquences :

La figure4.5 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 4.5: diagramme de séquences
4.7. Conception :
4.7.1. Création de la base de données :
Avant tout, nous avons créé des tables dans la BDD de notre application qui va contenir toutes
les informations concernant le client, son compte CCP, son compte SONELGAZ, SEAAL, etc. pour
simuler la transaction, effectuer le paiement et générer le rapport.
Dans ce qui suit, nous allons donner un aperçu sur les noms des tables de notre BDD créées avec la
description de tous les champs qui les constituent.
Table 1 : « client » : cette table contient les informations de base sur le client désirant
effectuer le paiement (figure 4.6, tableau 4.1)

Figure 4.6: Table B.D.D. « client »

Tableau 4.1 :Table B.D.D. « client »

Description des champs:

Client_id Identifiant unique de la table « client ».
Ccpclient_id Identifiant reliant la table « client » avec la table « ccpclient ».
Sonelgaz_id Identifiant reliant la table « client » avec la table « sonelgaz ».
Client_nom Le nom du client.
Client_prenom Le prénom du client.
Client_adresse L’adresse du client.
Client_msisdn Le numéro de téléphone « MSISDN ».
Client_code Un code secret affecté au client lors de l’enregistrement.
Client_etat Etat de la transaction de la facture lors d’une demande de service pour garder trace.
 Table 2 : « ccpclient » : elle contient des informations sur le compte CCP du client (figure
4.7, tableau 4.2).

Figure 4.7 : Table B.D.D. « ccpclient »

Tableau 4.2 : Table B.D.D. « ccpclient »

Description des champs:
Ccpclient_id Identifiant unique de la table « ccpclient ».
Ccpclient_numccp Le numéro du compte ccp.
Ccpclient_clef La clé du compte ccp.
Ccpclient_rip Le numéro RIP de compte ccp.
Ccpclient_montant Le montant du compte ccp.

Table 3 : « SONELGAZ » : elle contient les informations sur compte SONELGAZ du client
(figure 4.8, tableau 4.3)

Figure 4.8: Table B.D.D. « SONELGAZ »

Tableau 4.3: Table B.D.D. « SONELGAZ »
Description des champs:
Sonelgaz_id Identifiant unique de la table « sonelgaz ».
Sonelgaz_numreference Numéro de référence de la facture.
Sonelgaz_numibp Numéro I.B.P.
Sonelgaz_numfacture Numéro de la facture.
Sonelgaz_facture Montant de la facture à payer.

Table 4 : « ccppro » : elle contient les informations sur les comptes CCP des sociétés
étatiques et privées (figure 4.9, tableau 4.4)

Figure 4.9 : Table B.D.D. « ccppro »

Tableau 4.4 :Table B.D.D. « ccppro »

Description des champs:

Ccppro_id Identifiant unique de la table « ccppro ».
Ccppro_identifiant Identifiant du compte ccp.
Ccppro_numccp Le numéro du compte ccp.
Ccppro_clef La clé du compte ccp.
Ccppro_montant Le montant du compte ccp.

Clé étrangère et relation entre les tables :

Les tables créées ci-dessus « Figure 4.10 » sont relié entre eux avec des clés étrangères, qui
identifient une colonne ou un ensemble de colonnes d'une table comme référençant une colonne
ou un ensemble de colonnes d'une autre table.
 Figure 4.10 : clé étrangère

4.7.2. Développement JAVA :

Dans le développement de l’application, nous avons partitionné le programme en plusieurs
sous-programmes appelés « classes » pour le simplifier, le rendre plus lisible et plus
compréhensible. Ces classes vont être décrites et définies par la suite :
4.7.2.1. La classe « PaiementMobile »:
C’est la classe principale contient la méthode main (), qui est appelée par la machine virtuelle pour
exécuter l’application. Cette méthode s’occupe de l’exécution des autres classes descendantes.
4.7.2.2. La classe « ConnexionBBD » :
Cette classe assure la connexion java avec base de données à l’aide des drivers et des commandes
SQL. Elle contient une méthode ConnexionBBD (), qui a pour but l’insertion, le chargement et la
mise à jour des tables ainsi que l’extraction des différentes informations nécessaires pour
effectuer la transaction. Ensuite, l’étude de la possibilité d’effectuer cette dernière.
4.7.2.3. La classe « Mesg » :
Cette classe est responsable d’assurer la connexion avec le SMSC, la méthode Bind_Recv () est
utilisée pour recevoir et récupérer le contenue des messages envoyés par le client, l’envoi des
messages est assuré grâce à la méthode Bind_Send ().

4.7.2.4. La classe FTP :

Cette classe utilise la méthode genererFichier () pour la génération automatique d’un rapport de
paiement sous format PDF qui sera ensuite envoyé au serveur de SONELGAZ en utilisant le
protocole FTP. Ce rapport contient les informations récupérées dans la classe connexionBBD.

4.8. Implémentation :
Les différentes classes décrites dans la conception forment un ensemble de trois
applications à implémenter qui sont : l’envoi et la réception des messages, la communication
avec la base de données, la génération des rapports de paiement et l’envoi par le biais du
protocole FTP.

4.8.1. Configuration et mise en place:

Pour commencer les tests, nous devons commencer par définir les champs obligatoires des
protocoles utilisés pour permettre la communication (voir tableau 4.5, 4.6 et 4.7) :
Tableau 4.5 : la définition des champs du protocole SMPP
le protocole SMPP :
Numéro de port "****"
@IP serveur "172.27. ***. ***"
Identifiant "mpaiment"
Mot de passe "test900"
Adresse Range "900"
Version SMPP "3.4"

Tableau 4.6 : la définition des champs de la BDD.

Connexion à la base de données :
Définir le driver "org.postgresql.Driver"
Faire appel à la BDD : "jdbc:postgresql/localhost:5432/algérie poste"
Driver/num° _port/nom_BDD
Identifiant "postgres"
Mot de passe "projet"

Tableau 4.7 : la définition des champs du protocole SMPP

le protocole FTP :
@IP "***.***.***. ***"
Port "21"
Identifiant "Test4"
Mot de passe *****
Emplacement du fichier "C:\Users\localhost\Desktop\rapport.pdf"

4.9. Schéma d’interconnexion détaillé :

Nous allons schématiser l’interconnexion entre les différents équipements de la solution
proposée, ainsi que de détailler toute la communication entre ces derniers, les requêtes envoyées
et les commandes utilisées depuis le MS passant par le SMSC, le ESME, la BDD d’Algérie poste
jusqu’à la BDDSONELGAZ.
La figure 4.11 ci-dessous, décrit le premier tronçon de cette communication. Ce sont les requêtes
MAP responsables de l’acheminement d’un message depuis le MS jusqu’au SMSC :

Figure 4.11 : L’acheminement du message via le protocole MAP

La figure 4.12 ci-dessous, décrit le deuxième tronçon de la communication. Ce sont les requêtes
SMPP responsables de l’acheminement d’un message depuis le SMSC jusqu’au ESME, ensuite les
commandes SQL utilisées pour interroger la BDD d’Algérie poste et enfin le protocole FTP utilisé
pour l’envoi du rapport de paiement au marchand:

Figure 4.12 : L’acheminement du message via SMPP et son traitement via SQL et FTP.
4.10. Tests et évaluation :

Au moment où l’ESME reçoit un message, l’application interroge la BDD et vérifie l’authenticité

du client. On définit les trois cas suivant (voir figure 4.13):

Figure 4.13 : scénario des messages

4.10.1. Le 1ercas :

Le client envoi le message « » pour payer sa facture, l’ESME le reçoit et le traite en

sélectionnant les données nécessaire pour effectuer la transaction.
Dans ce premier cas, la base de données contient les informations suivantes:
Montant ccp=5000 da,
Montant facture=2000 da,
Montant SONELGAZ=400000000da.

Le client reçoit le message « », d’où la faisabilité de la transaction et la modification de plusieurs

champ:
Montant ccp= 3000 da,
Montant facture=0da,
Montant SONELGAZ=400002000da,
Etat de la facture= « payée ».

Un rapport de paiement sera envoyée par la suite à SONELGAZ (voir figure 4.14).
 Figure 4.14:rapport de paiement du 1er cas

4.10.2. Le 2ème cas :

Dans ce deuxième cas, Le client renvoi le message « » juste après la transaction alors que sa

facture a été payée et son compte a été mis à zéro:

Montant ccp=3000 da,
Montant facture=0 da,
Montant SONELGAZ=400002000da.

Le client reçoit le message « » : votre facture a été déjà payée.

Figure 4.15: rapport du paiement du 2ème cas

 4.10.3. Le 3ème cas :

Dans ce troisième cas, Le client envoi le message « » juste après la transaction alors que le

montant de la facture a payée est supérieur au montant de son compte CCP:

Montant ccp=3000 da,
Montant facture=7000 da,
Montant SONELGAZ=400002000da.

Le client reçoit le message « » : votre n’avez pas assez de solde pour effectuer la transaction.

Figure 4.16:rapport du paiement du 3ème cas

4.11. Conclusion :

Nous avons montré dans ce chapitre la mise en place de notre application ainsi que les
différents protocoles utilisés pour son implémentation.

Ce processus est un outil de paiement des différentes factures par un simple moyen qui est le
service SMS. Il vise une facilité des transactions et une génération automatique des rapports
envoyées aux marchands, ce qui permet de régler certains problèmes.
Conclusion générale
 Conclusion générale

L’objectif de ce projet de fin d’étude est la conception et la réalisation d’une solution de M-

Paiement au sein d’Algérie Telecom Mobilis (ATM). L’intérêt majeur de ce projet est la proposition
d’une démarche innovante pour ce genre de solutions en Algérie.

Pour mener à bien notre projet, nous avons commencé par étudier les différentes facettes qui lui
sont liées.

Cependant, le défi majeur a été la proposition d’une solution qui réalise un compromis entre la
sécurité, la simplicité, la compatibilité et la rapidité.

La sécurité de cette application a été mise en évidence par des lignes spécialisées assurées par
l’opérateur lui-même.

Les technologies d’accès SMS sont à la portée de tous et ont contribuées à sa simplicité.

L’optimisation du coût a été assurée vu que la confidentialité, l’intégrité, l’authentification et la

non-répudiation sont assurées uniquement par un seul SMS.

Ceci dit, nous pensons que notre solution manque de perfection. On pourrait l’améliorer en lui
ajoutant la technologie d’accès USSD, des modules de gestion et de monitoring par exemple.

Enfin, nous espérons que ce travail sera réutilisé et complété par MOBILIS pour une future
application de M-Paiement. Surtout avec son entrée en collaboration avec Algérie Poste pour le
lancement du service « RACIDI » qui offre une consultation du solde d’un compte CCP à tout
moment, par simple envoi d'un SMS.
Annexe
ANNEXE A :
L’USSD peut se traduire par « Données deService Supplémentaires Peu Structurées ». C’est
une technologie de communication sur le réseau GSM utilisée pour envoyer du texte entre un
téléphone mobile et une application sur le réseau.

L’USSD est similaire au SMS sauf que les transactions du USSD s’occurrent seulement durantune
session à temps réel. Il n'y a aucune possibilité d'enregistrement et transfert « Store &
Forward » qui est typique aux SMS « autrement dit, un SMSC n'est pas présent sur le circuit de
traitement ». Les temps de réponse pour des services basés USSD interactifs sont généralement
plus rapides que ceux utilisés pour les SMS.

En comparaison, On pourrait dire que l'USSD est un SMS sans mémoire, à savoir que ce sontdes
paquets de structure très semblable et usant le même canal de signalisation mais quel'utilisateur
qui devient indisponible après la sollicitation d'un service USSD ne le recevra jamais car le paquet
non délivré n'est pas resoumis ni gardé en mémoire.

Notons que cette technique a été utilisée par MOBILIS comme en entrant le code
*600#,l’utilisateur recevra sur l’écran de son mobile en moins de 2 secondes ; un menu en une
forme de navigation contenant plusieurs services. L’utilisateur peut entrer :

1 pour le rechargement,
2 pour la consultation du solde… etc.
ANNEXE B :
Les interfaces ainsi que les protocoles qu'elles utilisent sont normalisés.

Figure : Présentation des piles de protocoles sur les différentes interfaces.

La structuration en couches reprend le modèle OSI pour les trois premières couches:
couche physique,
couche liaison de données,
couche réseau.
1. La couche physique :
Définit l'ensemble des moyens de transmission et de réception physique de l'information.
Sur l'interface Abis : le transport des informations se fait numériquement. Au niveau de
l'interface radio, cette couche a de multiples opérations à effectuer : codage correcteur
d'erreur, multiplexage des canaux logiques, mesures radio à effectuer,etc.
2. La couche liaison de données :
Permet de fiabiliser la transmission entre deux équipements :
Sur l’interface Abis : On utilise, pour le support de la signalisation, le protocole LAPD basé
sur le protocole HDLC « numérotation des trames, mécanisme de correction d’erreurs,
etc. ».
Sur les interfaces Um et A : On utilise respectivement le LAPDm spécifique au GSM et le
MTP niveau 2 (SS7 voir après).
3. La couche réseau :
 Permet d'établir, de maintenir et de libérer des circuits commutés (parole ou données) avec un
abonné du réseau fixe. Cette couche comprend trois couches RR, MM et CM

3.1. La sous-couche Radio Ressource (RR) :

Traite l'ensemble des aspects radio. En effet, elle gère l'établissement, le maintien et la
libération des canaux logiques. Au niveau du mobile, elle sélectionne les cellules et surveille la voie
balise à partir des mesures effectuées par la couche physique. Elle est principalement présente
dans la MS et le BSC : les messages transitent entre les deux entités en passant par la BTS mais ne
sont pas interprétés par celle-ci. Toutefois, quelques messages sont échangés entre le mobile et la
BTS ou entre la BTS et le BSC. Pour cela, la BTS comporte deux entités RR' et RSL permettant de
dialoguer respectivement avec l'entité RR de la MS et l'entité RSL du BSC.

3.2. La sous-couche Mobility Management « MM » :

Elle prend en charge la localisation, l'authentification et l'allocation du TMSI « identité locale
restreinte à une zone de localisation de l'abonné mobile, afin de protéger l’abonné contre
l’identification et localisation par un intrus ».

3.3. La sous-couche Connection Management « CM » :

Cette dernière couche est divisée en trois sous-couches CC, SS et SMS.
 L'entité CC traite la gestion des connexions de circuits
 L'entité SMS assure la transmission et la réception des messages courts.
 L'entité SS gère les services supplémentaires.
Les messages des sous-couches CM et MM transitent dans le BSS sans être pris en compte par la
BTS et le BSC.
Sur l’interface A : on trouve les protocoles suivants :
Le protocole MTP : qui est divisé en trois niveaux « MTP1, MTP2 et MTP3 » proches des
trois premières couches du modèle OSI (couche physique, couche liaison de données et
couche réseau). Son but est de permettre le transport et la distribution fiable des
informations de signalisation à travers le réseau et aussi de réagir aux pannes afin
d'assurer continuellement la transmission.
Le protocole SCCP: ce protocole permet de transporter des informations de
signalisation avec ou sans connexion.
Le protocole BSSAP : comprend le BSSMAP et le DTAP.
Deux types de messages peuvent être échangés entre le BSC et le MSC : les messages
interprétés par le BSC concernent la sous-couche BSSMAP et les autres messages
transitant entre le mobile et le MSC sont traités par la sous-couche DTAP (dans ce
deuxième cas, le BSC joue le rôle d'un répéteur). Un mécanisme de distribution permet
d'aiguiller correctement les messages suivant leur type DTAP ou BSSMAP.
o Le protocole BSSMAP : cette sous-couche gère les ressources radio. Elle est
utilisée pour gérer les HO et les mises à jour de localisation. Les trames BSSMAP
sont encapsulées dans la partie "données" des trames SCCP.
o Le protocole DTAP : ce protocole prend en charge les messages CM et MM
entre le mobile et le MSC. Le BSC est considéré comme transparent : les
messages transitent sans modification entre le mobile et le MSC. Les trames
DTAP sont encapsulées directement dans des trames SCCP ou bien dans des
trames BSSMAP.
ANNEXE C :Principe de fonctionnement d’un VPN :

Un réseau VPN repose sur un protocole appelé « protocole de tunneling ».Ce protocole permet de
faire circuler les informations de l’entreprise de façon cryptée d’un bout à l’autre du tunnel.
Ainsi, les utilisateurs ont l’impression de se connecter directement sur le réseau de leur
entreprise.
Le principe de tunneling consiste à construire un chemin virtuel après avoir identifié l’émetteur et
le destinataire. Par la suite, la source chiffre les données et les achemine en empruntant ce
chemin virtuel. Afin d’assurer un accès aisé et peu couteux aux intranets ou aux extranets
d’entreprise, les réseaux privés virtuels d’accès simulent un réseau
privé alors qu’ils utilisent en réalité une infrastructure d’accès partagée, comme internet.
Les principaux avantages d’un VPN :
 Sécurité : assure des communications sécurisées et chiffrées.
 Simplicité : utilise des circuits de télécommunication classiques.
 Economique : utilise internet en tant que média principal de transport, ce qui évite les
couts liés à une ligne dédiée.
ANNEXE D :
Il y a trois types d’unités de signal :
Unités de signal d’appoint (FISU) : diffusent l’information de base seulement de niveau2.
Unités de signal de statut de lien (LSSU) : diffusent un ou deux octets d’information de
statut de lien entre les points de signalisation à l’une ou l’autre extrémité d’un lien.
Unités de signal de message (MSU) : portent toutes les commandes d’appel, question et
réponse de base de données, gestion de réseau, et données d’entretien de réseau dans
le domaine de l’information de signalisation (SIF), Les MSU ont une étiquette de
cheminementqui permet à un point de signalisation de commencement d’envoyer
l’information à un point de signalisation de destination à travers le réseau. [MOR 02]

Figure : les différents champs d’une Unités de signal

Flag : indique le commencement d’une nouvelle unité de signal et implique l’extrémité de
l’unité de signal précédente. La valeur binaire du drapeau est 0111 1110. Avant de transmettre
une unité de signal, le niveau 2 de MTP enlève « les drapeaux faux » en ajoutant un bit zéro après
toute séquence de cinq bits de 1. Lors de réception d’une unité de signal et de dépouillement du
drapeau, le niveau 2 de MTP enlève n’importe quel bit zéro, après toute séquence de cinq bits de
1, pour reconstituer le contenu original du message. Des drapeaux doubles sont enlevés entre les
unités de signal.
BSN : est employé pour accuser réception des unités de signal par le point de signalisation à
distance.
BAVOIR :indique un NegativeAcknowledgment par le point de signalisation à distance une
fois basculé.
FSN : contient le nombre d’ordre de l’unité de signal.
FIB :est employé dans le rétablissement d’erreur comme le BAVOIR. Quand une unité de
signal est prête pour la transmission, le point de signalisation incrémente le FSN par 1 (FSN =
0,…,127). La valeur de somme de CRC est calculée et ajoutée au message de l’avant. Lors de
réception du message, le point de signalisation à distance vérifie le CRC et copie la valeur du FSN
dans le BSN du prochain message disponible programmé pour la transmission de nouveau au point
de signalisation de lancement. Si le CRC est correct, le message en arrière est transmis. Si le CRC
est incorrect, le point de signalisation à distance indique le NegativeAcknowledgment en basculant
le BAVOIR avant l’envoi du message en arrière. Quand le point de signalisation de commencement
reçoit un NegativeAcknowledgment, il retransmet tous les messages en avant, commençant par le
message corrompu, avec le FIB basculé.
La valeur du gisement de LI (indicateur de longueur) détermine le type d’unité de signal :
Teneur en LI Type D’Unité De Signal
0 Unité De Signal D’appoint (FISU)

1..2 Unité De Signal De Statut De Lien (LSSU)

3..63 Unité De Signal De Message (MSU)

SIO :contient le champ de 4-bits sous-service suivi de l’indicateur du service de 4-bits. Le

FISU et le LSSU ne contiennent pas un SIO.
Le champ sous-service contient l’indicateur de réseau et la priorité de message « 0, 3 avec 3
étant la priorité la plus élevée ». La priorité de message est considérée comme seulement dans
des conditions de congestion, ne pas commander l’ordre dans lequel des messages sont transmis.
L’indicateur de service indique l’utilisateur de MTP, permettant ainsi le décodage
d’information contenue dans le SIF.
SIF :contient l’étiquette de cheminement et l’information de signalisation. LSSU et FISU ne
contiennent ni une étiquette de cheminement, ni un SIO pendant qu’ils sont envoyés entre deux
points de signalisation directement reliés.
CRC :la valeur de CRC est employée pour détecter et corriger des erreurs de transmission de
données.
Bibliographie

[ART 03] ‘Autorité de régulation des télécommunications, Etude relative aux moyens de
paiements mobiles‘ : Etude réalisée par les cabinets IDATE et BIRD&BIRD pour le
compte de l’Autorité de régulation des télécommunications, Décembre 2003.

[PAP 02] ‘Mobile Payments: Preparing for the mCommerce Revolution’: White Paper,
Trintech, March 2002.

[VYA 01] ‘A Review of Mobile Commerce Technologies’: Amit Vyas, et al, Department of
Industrial Engineering, University of Iowa, May 2001.

[LAG 00] ‘Les réseaux radio mobiles’: Xavier Lagrange, IC2 (Information-Commande-
Communication), Edition Hermès, Paris, Mai 2000.

[TAB 97] ‘Réseaux Mobiles’: Sami Tabbane, Edition Hermès, Paris, 1997.

[ERA 07] ‘SMS Banking Services: A 21st century Innovation in banking technology ‘: Emmanuel
Rotimi Adagunodo, Obafemi Awolowo University, 2007.

[SMP 99] SMPP ‘Short Message Peer to Peer’, 30 Juillet1999, v3.4.

[TOL 07] ‘SMPP optional TLV patch ’, Stipe Tolj, et al, RFC , December 2007.

[MOR 02] ’Signaling System 7 (SS7) Message Transfer Part 2 (MTP2)- User Adaptation
Layer’ K. Morneault, et al, RFC 3331, IETF, September 2002.

[MOR 06] ’Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) -User Adaptation Layer
(M3UA) ’, K. Morneaul, et al, RFC 4666, IETF, September 2006

[EFO 11] ’Le protocole MAP : Mobile Application Part’, Copyright EFORT 2011.

[POS 85] ’FILE TRANSFER PROTOCOL (FTP) ’, J. Postel, et al, RFC 765, IETF, Octobre 1985.

[CHI 06] ‘Security of mobile banking’, Kelvin Chikomo and Ming Ki Chong 2006.

[KHA 05] ’Security & Vulnerability Analysis of Wireless Messaging Protocols & Applications’,
A.Khan, 2005.

[ZNA 00] ‘Le réseau sémaphore numéro 7:principes, architecture et protocoles’, Simon
ZNATY Copyright EFORT Mai 2000.
[EFO 09] Copyright EFORT, ‘MTP3 : pour une meilleure compréhension de
SIGTRAN/M3UA’, 2009.

[MEJ 05] : H.Mejri, “Introduction à la Cryptographie”, 2005.

Webographie :

[DEV 08] URL: www.developershome.com.

[GSM 02] URL: http://jf.morreeuw.free.fr/security/gsm.html.

[TEC 07] URL: www.technologuepro.com/gsm/commande_at.htm.

[JAA 02] URL: jaaayyy.chez.com/html/Radiomobiles/stage/SMS.html.

[DIC 07] URL: www.diclib.com/cgibin/d1.cgi?l=en&base=en_foldoc&page=showid&id=4497.

[ERA 07] URL: www.iisit.org/images/IISIT_tocVol4.pdf.

[SMP 99] URL: http://www.alvento.com/productos/sms/smpp/smpp34.pdf

[MOR 02] URL: http://www.ietf.org/rfc/rfc3331.txt

[MOR 06] URL: http://tools.ietf.org/html/rfc4666#page-10

[EFO 11] URL: http://www.efort.com

[POS 85] URL : http://www.ietf.org/rfc/rfc959.txt

[KHA 05] URL: www.securitydocs.com/pdf/3026.PDF.

[ZNA 00] URL : http://www.efort.com

[EFO 09] URL :http://www.efort.com

[MEJ 05] URL : http://ebookpp.com/me/mejri-ppt.html