allahou

akbar


ETUDE
ET
ANALYSE
DES
PROTOCOLES

DE
PAIEMENT
SUR
INTERNET


Ousmane
Coulibaly

[Tapez
le
résumé
du
document
ici.
Il
s'agit
généralement
d'une
courte
synthèse
du

document.]

SOMMAIRE :
Introduction
1. Fonctionnement du paiement sécurisé
1.1 - Principe
1.2 - Eléments de sécurisations mise en œuvre
2. Les Protocoles de Sécurisation des transactions
2.1 SSL
2.1.1 Fonctionnement
2.1.2 Les certificats :
2.1.3 Exemples de solutions basées sur SSL :
2.1.4 Critiques :
2.2 SET
2.2.1 Fonctionnement
2.2.2 Les certificats

a) Contenu d’un certificat SET :

b) Hiérarchie de certification
2.2.3 Transaction d'un Achat par le protocole SET
2.2.4 SET et la carte à puce
2.2.5 Critiques
2.3 Le protocole 3D Secure
2.3.1 Architecture :
2.3.2 Transaction d'un Achat par le protocole 3D Secure
2.3.3 Critiques
3. Conclusion


 2

Aujourd’hui, nous assistons à une très grande augmentation du commerce sur
internet et donc à l’essor des transactions sécurisées sur Internet. Il existe de
nombreuses solutions qui permettent de sécuriser les paiements sur internet. Ces
solutions sont développées par les grands acteurs informatiques et les banques.
Mais il existe de nouveaux acteurs qui, grâce au développement du commerce
online se sont placé comme intermédiaires entre les commerçants et les
organismes bancaires.
L’utilisation des cartes bancaire pour acheter sur internet est devenue une
tendance. Face à cette montée du commerce en ligne, une sécurisation des
transactions s’impose.
Les principes de la sécurisation d’une transaction sont :
• la confidentialité (accessible uniquement par le vendeur et l’acheteur)
• l’authentification (identités des parties concernées)

• l’intégrité (aucune modification ne peut être faite pendant le transfert)

• la certification de l’opération (la transaction a bien eu lieu).

Aujourd’hui les principaux systèmes de paiements sur Internet sont :

- Le paiement en clair : l’acheteur fournit son numéro de carte de crédit par un

formulaire sur une page non sécurisée ou par e–mail (fortement déconseiller).

- Le paiement crypté : l’acheteur fournit son numéro de carte de crédit par un

formulaire sur une page sécurisée.

- Le paiement par carte à puce : l’acheteur effectue le paiement à travers un

lecteur de cartes connecté à son ordinateur.

Nous nous intéresserons plus précisément aux paiements sécurisés, qui sont
actuellement les systèmes de paiement les plus utilisés par les internautes.

1
‐
Fonctionnement
du
paiement
sécurisé

La sécurité du paiement par carte bancaire sur Internet est indispensable. En
effet, il permet aux commerçants de vendre à distance. Il existe de nombreuses
solutions pour sécuriser les paiements sur internet.





1.1
‐
Principe

Le commerçant expose son catalogue de services ou de produits sur serveur web.
L’acheteur passe sa commande et sélectionne son moyen de paiement. Il est
ensuite dirigé vers le service de paiement par carte bancaire de la banque, dans
le cas d’un paiement par carte de crédit. Pendant toute la phase de paiement, le
client discutera selon l’architecture de paiement soit avec le serveur de paiement
sécurisé de la banque soit avec le serveur sécurisé d’une société intermédiaire.
Tous les échanges seront sécurisée assurant la confidentialité des renseignements
fournis par le client (numéro et date de validité de la carte de crédit).

Après validation de la requête par l’acheteur, la banque ou la société intermédiaire


 3

se charge d’effectuer :

• authentification du commerçant émetteur de la demande de paiement,

• la demande d’autorisation du paiement
• l’envoi d’un message de confirmation précisant le résultat du paiement vers
le système informatique du commerçant,
• la mise en recouvrement du paiement.




1.2
‐
Eléments
de
sécurisations
mise
en
œuvre

Les piliers de sécurisation mis en œuvre dans le cadre d’un paiement sécurisé sont
les suivants :

• intégrité des données échangées entre le serveur du commerçant et le

serveur de la banque assurée par une méthode de scellement,
• authentification du commerçant émetteur de la demande de paiement,
• confidentialité des données échangées entre le client et le serveur de
paiement de la banque (numéro et date de validité de la carte bancaire)
assurée par chiffrement SSL,
• saisie directe des coordonnées Carte Bancaire sur le site sécurisé de la
banque, garantissant que ni le commerçant, ni aucun intermédiaire
technique, n'auront connaissance des informations concernant la carte
bancaire.
2.

Les
Protocoles
de
Sécurisation
des
transactions


Lors d’un paiement par carte bancaire, le cryptage des données personnelles
(nom, adresse, coordonnées bancaires) de l’acheteur nécessaire. Une solution de
sécurisation est proposée par les sites marchands et les sites bancaires. Ces
solutions font appel aux protocoles de sécurisation des transactions : SSL (Secure
Socket Layer) qui est un protocole indépendant et SET (Secure Electronic
Transaction) avec ses variantes, et aujourd’hui 3D Secure. Les protocoles SET et
3D Secure sont développés par des institutions bancaires. Nous nous intéressons à ces
différents protocole de paiement sur internet.

2.1

SSL
(Secure Socket Layer, créée par Netscape).


Aujourd’hui, SSL est la solution la plus utilisée pour sécuriser les transactions .
Cela s’explique d’une part par la simplicité d’utilisation et d’autre part son
intégration à tous les browsers du marché.
SSL est un protocole d’ échange d’information. Il permet d’assurer
l’authentification, la confidentialité et l’intégrité des données transmises.
Dans le cadre d’un paiement en ligne, ces données sont constituées des
informations relatives à la Carte bancaires. Il utilise un moyen de cryptographie
reconnu : l’algorithme à clé RSA.
SSL effectue la gestion des clés et l’authentification du serveur avant que les
informations ne soient échangées

2.1.1


FONCTIONNEMMENT
DE
SSL

Le protocole SSL a été défini par Netscape. Il permet d’associer des propriétés de
sécurité à une socket indépendamment des informations qui seront transportées
par cette socket.


 4

Il fonctionne en trois phases:
• Authentification du serveur à l’aide de certificats (optionnelle pour le client)
• Envoi des clés publiques.
• Envoi des informations codées.

Ces trois étapes sont décrites dans les schémas ci-dessous.

Schéma dans le cas où la société, seule, demande un certificat :

a- Le serveur demande à être certifié par un organisme.

b- Les navigateurs contiennent une liste d’organismes fiables.

Le serveur gère une paire de clés publiques/privées. Le logiciel client demande au

logiciel serveur de lui fournir sa clé publique. Le certificat permet au logiciel du
client de reconnaître de manière sûr l’identité du serveur.

Les informations du client sont aussitôt cryptées avec la clé publique du serveur et
transmises au serveur. Le serveur décode le message avec sa clé privée. Il envoie


 5

ensuite au logiciel client une confirmation du bon déroulement de l’opération.
Avec ce protocole, une nouvelle paire de clés est générée à chaque établissement
de la communication entre le logiciel client de l’utilisateur et le logiciel serveur. La
communication est donc sûre mais en aucun cas le serveur commercial ne peut
s’assurer de l’identité de l’utilisateur à l’autre extrémité.
Une façon de résoudre ce problème, est de joindre à ce processus un système de
validation, comme par exemple un numéro d’identification personnel (NIP) qui
s’obtient par une inscription préalable du client et du serveur.

2.1.2
Les
certificats
:

Un certificat est un document électronique qui atteste qu’une clé publique est bien
liée à une organisation ou à une personne. Il permet la vérification de la propriété
d’une clé publique pour prévenir la contrefaçon de clés publiques. Un certificat
contient généralement une clé publique, un nom ainsi que d’autres champs pour
identifier le propriétaire, une date d’expiration, un numéro de série, le nom de
l’organisation qui contresigne le certificat et la signature elle-même. Le format des
certificats est défini par la norme X509.
Le certificat doit être généré par un tiers de confiance. L’organisme certificateur
donne la crédibilité au certificat.
Il existe deux types de certificats utilisés avec SSL : pour serveur et pour client.
Un certificat coté client sert à identifier un utilisateur, il contiendra donc des
informations sur cet utilisateur. Coté serveur, le certificat a pour but d’authentifier
le serveur et l’organisme qui l’exploite. C’est ce type de certificat dont vous avez
besoin pour mettre en place un serveur sécurisé HTTPS
2.1.3 Exemples de solutions basées sur SSL :

• Transaction SSL sans intermédiaire :

Dans cette configuration, le commerçant signe avec une banque un contrat de

VAD et achète d’un TPE. Lors d’un achat, le client fournit ses coordonnées
bancaires au serveur marchand à travers une session SSL . Le marchand récupère
ensuite les informations CB stockées sur le serveur. Ensuite il saisie manuellement
le montant à débiter sur le compte du client, via le TPE.

Le marchand est donc autonome, gère son propre site ; Il doit donc avoir de
bonnes compétences en informatique. Il doit aussi acquérir un certificat SSL.


 6

L’inconvénient principal de cette architecture est que les coordonnées bancaires
sont stockées sur une basse de donnée En effet cela est très risqué car un
attaquant malintentionné pourra se les procurer. Le marchand est seul
responsable du bon déroulement du paiement.

• Transaction SSL via un organisme bancaire :

Le porteur valide son achat et choisit de payer par carte bleu. Ensuite Il
fournit ses données confidentielles et N° de Carte de Crédit dans un
environnement sécurisé et crypté. Le commerçant envoie la demande
d’autorisation à son acquéreur qui envoie à son tour cette demande à la banque
du client. Après autorisation de cette dernière, une réponse est envoyée au
marchand. Il finalise la transaction avec le porteur et le stocke pour règlement.

Dans cette architecture, le marchand et client sont en sécurité car l’organisme

bancaire assure aux deux parties le bon déroulement du paiement. Le Marchand
n’a pas besoin d’acheter un certificat SSL.

• Transaction SSL via une société intermédiaire : Cas de PayPal

Actuellement c’est l’un des systèmes de paiement les plus répandu. Le client,
fournit le numéro de sa carte de crédit avec sa date de validation au moment
où il passe la commande. Pour que le système fonctionne, des sociétés de
paiement en ligne s’inscrivent en interface entre le client et le fournisseur. Elles
se chargent de vérifier le numéro de la carte, les listes d'opposition pour perte
ou vol, l'obtention d'un numéro d'autorisation auprès du Centre d'autorisation
Carte bancaire et de procéder à l'encaissement puis au crédit en compte de la


 7

 transaction réalisée sur Internet. Il y a aussi des solutions comme celle de
PayPal.

• Cas de PayPal (Banque en ligne) :

Fonctionnement côté acheteur :

L’acheteur crée un compte PayPal en ligne, l’ approvisionne via virement et/ou

carte bleue. Il effectue les paiements sur internet via son compte en ligne, en
fournissant son identifiant et son mot de passe.

Fonctionnement côté vendeur :

Le vendeur crée également un compte PayPal en ligne. En suite c’est la société
PayPal qui s’occupe des paiements. Le vendeur pourra consulter des transactions
en temps réel. Après paiement le vendeur pourra effectuer des virements
automatiques du compte PayPal au compte bancaire

Scenario de paiement PayPal


 8

2.1.4 Critiques :
Les principaux inconvénients de SSL sont :
• Il y a une seule authentification au début de la session, certificat non
nécessaire pour le client
• Il n’ y a plus de signature des messages envoyés après le HandShake
L’inconvénient principal de toutes ces solutions basées sur SSL est le manque
d’authentification de l’acheteur qui peut répudier à tout moment l’achat. D’une
part cette faiblesse est surtout causée par le protocole SSL dans lequel
l’authentification du client n’est pas obligatoire et d’autre part même en cas
d’authentification, c’est un navigateur qu’on authentifie et non une personne.
Toutes ces solutions sont sensibles aux attaques de types Keylogger et phishing.

2.2


SET

Le protocole Secure Electronic Transaction (SET) est une norme ouverte de
l'industrie pensée par MasterCard International et Visa International. Il a pour
objectifs de faciliter et sécuriser les transactions de commerce électronique sur
les réseaux ouverts, notamment Internet. Il procède essentiellement par
cryptage des données bancaires. Trois acteurs sont impliqués dans ce
protocole:
• le fournisseur appelé marchand
• l’acheteur
• le serveur de paiement qui sert d’interface entre marchand et le
réseau bancaire.
Dans une transaction SET, le porteur de la carte effectue son paiement sans
insérer la carte dans un quelconque lecteur, mais en présentant un certificat
que lui a déjà été délivré par une autorité de certification. Ce certificat permet
d'authentifier le porteur à l'aide de la cryptographie à clé publique.

2.2.1
FONCTIONNEMENT

Architecture
:

a)
Mécanismes
de
SET
:

• Confidentialité

Dans SET, la confidentialité dans un scénario de commerce électronique est le

fait s’assurer que les numéros de cartes de crédit ne sont visibles que par la
banque autorise transaction. Il s’agit aussi de s’assurer que les informations de la
commande du client ne soient accessibles qu’au vendeur.

• Authentification (niveau client et marchand)

SET permet d’authentifier les deux parties lors d’une transaction. Ces
authentifications sont faites au moyen de certificats X.509v3 avec une signature
RSA.
• Intégrité des données
SET assure l’intégrité des informations transmises au cours d’une transaction.


 9

 b)

Les
Participant
d’une
transaction
SET

Les principaux participants d’une transaction SET sont:

1. le porteur ou l’acheteur; il procède aux achats et paie par la carte bancaire

2. le serveur du commerçant;
3. la passerelle de paiement;
4. l'autorité de certification ;
5. l'institut émetteur de la carte bancaire du porteur ;
6. l'institut acquéreur, qui est souvent la banque du marchand.

Chaque acteur obtenir au préalable un certificat délivré par une autorité de

certification agréée. Ces certificats sont inclus dans les messages échangés entre
le porteur, le commerçant et la passerelle de paiement.

Méthodes
cryptographiques
utilisées
:
Pour répondre aux besoins de sécurité sur Internet, certaines pratiques de
cryptographie sont utilisées :

• le chiffrement et le déchiffrement de données par des techniques à clé

secrète et à clé publique ;
• la technique de création de condensés d’informations obtenus par des


 10

 opérations de hachage;
• la signature des messages échangés afin de permettre l’authentification de
leurs émetteurs.
La clé privée utilisée pour la signature provient du couple de clés de signature,
tandis que la clé publique pour le chiffrement de la clé symétrique provient du
couple de clés de chiffrement.

Le protocole utilise le hachage SHA1 (sans clé ) et le hachage HMAC-SHA1(avec

clé) Les algorithmes utilisés sont :

• Un point sur la méthode de la signature duale :

Une innovation de SET est le procédé dit de la « signature duale » qui permet de
lier à une même signature les éléments de deux messages envoyés vers deux
destinataires distincts qui évite l’aller-retour superflu. Grâce à ce procédé, chaque
destinataire est en mesure de lire le message qui lui est destiné et de vérifier
l'intégrité de l'autre message sans connaître le contenu. Soient O et I (O=Offre
d’achat, I = Instructions de paiement) deux messages à envoyer respectivement
au commerçant et à la passerelle de paiement Ces deux message sont condensés
par la fonction de hachage H et concaténés, le message ainsi obtenu m=H(O)|H(I)
sera signé en utilisant la clé privé de l’acheteur Sc({H(O)|H(I)}) L’acheteur
transmet l’offre d’achat au commerçant et les instructions de paiement à la
banque. Ainsi, le message constitué {O, h(I), Sc({H(O)|H(I)})} est envoyé au
commerçant et {I, H(O), Sc({H(O)|H(I)})} est envoyé à la passerelle de
paiement. Les deux destinataires peuvent s’assurer de l’authenticité du message
qu’ils reçoivent. Si le commerçant accepte l’offre, il transmet son acceptation à la
banque, accompagnée du condensé de l’offre d’achat.

2.2.2
Certification
:

L’accréditation SET vise à distribuer aux acteurs du paiement électronique un
certificat, attestant leur identité. Ce certificat permet de s’assurer des
autorisations que possèdent ces acteurs pour procéder à un achat au moyen d’une
carte de paiement.


 11

Les acteurs du paiement électronique obtiennent leur accréditation en s’adressant
à une autorité habilitée à distribuer des certificats, soit :
• pour un porteur de carte bancaire, la banque qui lui aura émis une
carte ;
• pour un commerçant, la banque qu’il aura chargée d’acquérir des
transactions bancaires pour son compte ;
• pour la banque, la marque de carte (Visa ou MasterCard par exemple) ou
bien l’autorité géopolitique représentant la marque de carte (par
exemple Carte Bleue représentant Visa en France).
a) Contenu
d’un
certificat
SET
:

 

Un certificat électronique est un document constitué d’un certain nombre d’informations qui
identifient de façon sûre son détenteur, à la manière d’une carte d’identité. Le certificat
d’identification d’une personne contiendra par exemple son nom, prénom, date de naissance
et d’autres caractéristiques. Le format de représentation d’un certificat SET est conforme à la
norme ISO IEC 9594-8 sur X.509v3
Un certificat SET est un cas particulier dans lequel le certificat ne contient aucune
référence au détenteur de la carte bancaire. Il identifie essentiellement une carte
bancaire par son numéro et sa date d’expiration. Toutefois, afin de ne pas pouvoir
associer facilement une carte et son certificat, ces informations importantes sont
cachées en les hachant avec une combinaison spéciale de caractères.
SET utilise deux types de certificats :
• des certificats de signature permettant de signer les messages à envoyer
par chiffrement d’un condensé du message avec la clé privée ;
• des certificats de chiffrement permettant de chiffrer les enveloppes des
messages échangés. (L’enveloppe contient la clé symétrique qui aura servi
à chiffrer le message en entier).
Le porteur de carte ne possède qu’un certificat de signature.

b)
Hiérarchie
de
certification
:

L'architecture de gestion des certificats est composée plusieurs éléments qui
interviennent dans l'arborescence de confiance qui ont pour racine l'autorité de
certification maîtresse et pour feuilles les acteurs participant à une transaction
SET. L'autorité de certification maîtresse est une entité qui trône sur tout l'édifice
de certificat de SET. Elle est l'ultime arbitre qui vérifie l'authenticité des
intervenants et contrôle, l'octroi des certificats électroniques. La certification des
clés publiques est crée de la façon suivante:


 12

 • La clé publique d’un client est certifiée par la banque émettrice de sa carte de
crédit.
• Les clés publiques d’un commerçant sont certifiées par la banque à laquelle il
est affilié.
• Le commerçant devra donc posséder pour chaque réseau de cartes auquel il
sera affilié deux certificats :
- un pour sa clé publique destinée au chiffrement de données.
- un autre pour sa clé publique de vérification de signatures.
• La banque acquéreur doit posséder quatre certificats :
- un certificat de signature.
- un certificat de chiffrement de clés.
- un certificat de signature de certificat.
- un certificat de signature de liste d’opposition. La banque est à son
tour certifie par l’autorité de certification de la marque (Visa,
Mastercard, etc.) qui se situé directement au dessus d’elle.

• L’autorité de certification de la marque est certifié a son tour par l’autorité de

certification maîtresse. Les certificats de l’autorité maîtresse sont auto signés
est accessibles à toutes les entités terminales de SET.

2.2.3 Transaction d'un Achat par le protocole SET

• Messages de paiements

Le tableau ci dessous résume les principaux messages envoyés lors d’une

transaction :


 13

 • Scenario de paiement :

Demande initiale d'achat

L’application cliente envoie un message initiale (Payment Initialization Request ou
PInitReq). Ce message contient le choix de la carte de paiement et la demande
des certificats de chiffrement et de signature du commerçant et de la passerelle de
paiement.

Réponse à la demande initiale d'achat

Ces dernières informations sont renvoyées par le commerçant dans le message de
réponse (PInitRes) en même temps qu’un identificateur de transaction. Le
serveur commerçant attribue à cette transaction un numéro unique et génère un
nombre aléatoire.

Demande d'achat
L’acheteur envoie le message PReq (Purchase Request) signé contenant :

• les informations de commande,


 14

 • les informations de paiement : montant, numéro de carte...
Les données bancaires et de paiement relatives à une transaction sont envoyées
au commerçant sous une forme chiffrée dans une enveloppe digitale que le
commerçant ne peut pas déchiffrer ;

Demande d'autorisation
Le commerçant extrait les informations de commande du message PReq qu’il
reçoit et, à partir des informations de paiement, constitue le message
d’autorisation (AuthReq) qu’il va envoyer à la passerelle de paiement.
La passerelle de paiement déchiffre le message AuthReq en provenance du
commerçant, identifie l’acheteur grâce au certificat et à la signature de ce dernier,
puis constitue un message de demande d’autorisation à destination du réseau
bancaire.

Réponse à la demande d'autorisation

Une réponse à la demande d’autorisation revient à la passerelle de paiement.
Cette réponse peut être positive ou négative. Dans le dernier cas, une justification
du refus peut être fournie. De toute façon, la passerelle va constituer un message
de réponse AuthRes qu’elle va chiffrer et renvoyer au commerçant.

Réponse d'achat
Le commerçant enregistre la réponse, ensuite il envoie la réponse l’utilisateur.
C’est le message PRes (Purchase Response)

Demande de compensation
Le message CapReq envoyé par le commerçant à la passerelle de paiement pour
demander le paiement effectif des messages de paiement préalablement autorisés
(recouvrement ou remise des transactions). Il contient : montant de chaque
transaction, référence d’autorisation, identificateur de la transaction, le bon chiffré
et signé etc.

Réponse à la demande de compensation

La passerelle de paiement envoie ces données à la banque acquéreur. Ensuite elle
envoie le message CapRep qui contient la réponse de la banque avec le montant
crédité au compte du commerçant.

2.2.4

SET
et

la
carte
à
puce

Un des inconvénients de SET est la nécessité pour le porteur d’obtenir un
certificat et pour la banque émettrice de fournir le serveur d’accréditation et
l’organisation qu’il implique. Le certificat et la clé privée associée est le moyen
utilisé par le porteur pour s’authentifier. Or, la carte à puce constitue déjà un
moyen d’authentification du porteur. En effet, un paiement effectué à l’aide
d’une carte à puce génère un message signé reçu par un TPE et envoyé à la
banque acquéreur.
Donc, la carte à puce peut se substituer à la certification SET ou être utilisé en


 15

complément. Ainsi une variante de SET a vu le jour en France : C-SET.

C-SET est une architecture de paiement sur Internet sécurisée par carte à puce. Il
fut pensé par le Groupement des Cartes Bancaires,. C’est une adaptation de SET.
Cette architecture de paiement rajoute une sécurité physique en intégrant
l'environnement "carte à puce" à SET. Il est mieux sécurisé que SET, mais il est
compatible avec SET. La solution est mieux sécurisée grâce à l’apport de la carte
à puce. Elle rajoute notamment :

• Une protection contre la délivrance de "certificats" aux faux porteurs : la

carte à puce et le code confidentiel permettent d'authentifier le vrai
porteur de la carte, pour télécharger dans la carte les "données Internet"
propres au porteur,
• protection contre les virus "chevaux de Troie" : l'utilisation d'une carte à
puce et d'un lecteur sécurisé de cartes à puce, avec son propre logiciel et
son propre clavier numérique, permet d'être insensible aux "chevaux de
Troie" ;

Scenario de paiement C SET









2.2.5 Critiques :


 16

Le protocole SET, plus élaboré que SSL, se voulait le standard pour les paiements
électroniques. Mais ce protocole impliquait l’acquisition de certificats électronique
personnels pour authentifier l’acheteur et le vendeur. Cette lourdeur de la
vérification systématique des certificats et la lourde charge de calculs
cryptographiques ont fait qu’il pas réussi à s’imposer et a été abandonné depuis
2002.
C SET également est devenu obsolète pour diverses raisons (prix d'acquisition
onéreux de l'accessoire, outil peu commode à l'usage, etc.)

2.3
Le
protocole
3D
SECURE

Les solutions basées sur SET ayant toute échoués Visa a décidé de réfléchir à un
autre protocole : 3D Secure.

3-D Secure est aussi un protocole de paiement sécurisé sur Internet. Il a été
développé par Visa en 2002 pour augmenter le niveau de sécurité des
transactions, et il a été adopté par Mastercard. Il permet une meilleure
authentification du détenteur de la carte de paiement lors d'achats effectués sur
des sites web.

Cette architecture a pour but de permettre au commerçant de diriger l’acheteur

vers sa banque pour que celle-ci l’authentifie et recueille son accord sur la
transaction en cours. Et ceci de la même façon, quelle que soit la méthode
d’authentification adoptée par la banque.

Avant 3D-Secure, la transaction s'effectuait uniquement entre deux intervenants :

l'acheteur et le marchand. Avec 3D-Secure, un troisième intervenant est de la
partie : la banque de l'acheteur. D'où le "3D".Depuis Octobre 2008, une
transaction CB, pour laquelle le commerçant a mis en œuvre le système 3D-
Secure, et qui a fait l ’objet d ’une autorisation acceptée de l ’émetteur, bénéficie
du transfert de responsabilité de l ’acquéreur vers l ’émetteur

2.3.1 ARCHITECTURE :
3-D est la contraction de « Three Domains » .L’ architecture 3D Secure divise
l’espace réticulaire en trois domaines paiement qui interagissent :
 Domaine Acquéreur (entre la banque acquéreur et son commerçant)
 Domaine Emetteur (entre la banque émettrice et son porteur)
 Domaine Interbancaire qui permet de faire communiquer les deux autres
domaines.

3-D Secure distribue les traitements et les responsabilités de façon équilibrée

entre les trois domaines et décrit le circuit de l'information entre ces domaines.

La banque émetteur gère la relation avec son porteur en lui donnant, si

nécessaire, les moyens de réaliser une authentification.

La banque acquéreur gère la relation avec son commerçant en lui donnant les
moyens d’accéder au système 3-D Secure.

Le domaine interbancaire permet au commerçant de démarrer l’authentification de


 17

l’acheteur de manière uniforme, quelque soit le moyen d’authentification utilisé,
par la mise à disposition de services d’annuaires.

3-D Secure décrit les traitements au travers de composants mis en place dans
différents domaines et d’un protocole de communication « standardisé

• Composants 3D :

Les 3 principaux composants du protocole 3D Secure sont :

 MPI Merchant Plug-In (Domaine Acquéreur) : C’est le point de connexion

du serveur du marchand à l’infrastructure 3D Secure. Il permet de
communiquer avec le DS et le serveur de paiement de l’acquéreur.
 ACS Access Control Server (Domaine Emetteur) : Servant à la fois
d’autorité d’enregistrement des porteurs de cartes désireux de participer au
programme 3D Secure et d’autorité d’authentification des acheteurs au
cours d’une transaction. C’est ce serveur qui assure le marchand de la
validité de l’identité de l’acheteur donc la validité de la transaction. Ce
serveur est géré par l’émetteur.
 DS Directory Server (Domaine d ’interopérabilité) : Joue le rôle
d’intermédiaire entre le marchand et l’émetteur. Il existe un directory Visa
et un Mastercard.

2.3.2 Transaction d'un Achat par le protocole 3D Secure

• Messages de Paiement :

Les 4 messages principaux échangés lors d’une transaction 3D Secure sont :

- VEReq / VERes - Verification Enrollment Request / Response

•Permet d ’accéder au Directory Server

•Phase de vérification de l’inscription de la carte

- PAReq / PARes - Payer Authentification Request / Response

•Permet d’accéder à l’ACS de la banque du porteur

•Déclenche la phase d’authentification / consentement de l’acheteur

(PAReq)
Collecte du résultat (PARes)
La figure ci dessous présente les étapes d’un paiement 3D Secure avec les
différents messages envoyés.


 18

NB : À noter que 3D Secure est basé sur SSL donc utilise des certificats SSL à
différents niveaux. A la différence de SET, le certificat SSL Serveur permettant à
l’acheteur d’authentifier le site marchand n’est plus fourni par un organisme
financier. Ici le marchand fait appel à l’autorité de certification publique de son
choix.

2.3.3 CRITIQUES DU PROTOCOLE

Le fameux chercheur britannique Ross Anderson avec son collègue Steven

Murdoch ont signalé de nombreuses faiblesses dans le protocole 3D Secure. Dans
l’article “ Verified by Visa and MasterCard SecureCode: or, How Not to Design
Authentication “, les deux chercheurs expliquent que le système regorge en fait
de faiblesses. Ainsi, l'authentification se fait dans un iframe, un élément HTML
qui permet d'intégrer un page dans une autre. Du coup, la page d'authentification
ne dispose pas d'URL, et l'internaute de peut pas vérifier son origine. C'est la porte
ouverte au phishing et aux attaques par interception.
Un autre point négatif du protocole est qu’il ne diminue pas le risque de vol de
numéros de carte sur les bases de données des marchands. Au contraire de SET,
le numéro de carte de crédit n’est pas caché au marchand. Le marchand ou son


 19

fournisseurs de service le stocke dans les bases de données. Nous sommes donc
dans une situation identique à la transmission du numéro de carte à travers une
session SSL avec en plus une vérification de l’identité de l ‘acheteur auprès de sa
banque.
Le principe de 3D-Secure consiste donc à demander à l'acheteur (le client) de
s’authentifier auprès de sa banque (issuer) lors de la phase paiement.
Pour s'authentifier, l'acheteur doit fournir un code secret (code PIN, mot de passe
OTP) convenu avec sa banque. Mais un problème se pose si ces moyens
d’autentifications sont rejouables. Par exemple le code d’un utilisateur pourra être
récupéré à travers un keylogger ou un cheval de Troie et réutiliser par la suite.
Une solution serait que le protocole impose une authentification forte entre le
client et sa banque.
D’ailleurs en France, d’ici Juin 2010 toutes les banques devront proposer un
moyen d’authentification non rejouable car il est impératif que l'authentification du
client auprès de sa banque soit non rejouable. Il ne s'agit pas ici de se prémunir
du risque de sniffing sur Internet (qui est en grande partie géré par HTTPS), mais
des malwares (Keylogger). Les pirates peuvent ainsi récupérer ainsi toutes les
données saisies dans le navigateur d'un poste infecté, si l'authentification est non
rejouable (comme un mot de passe ou une date de naissance), le pirate en aura
connaissance mais ne pourra le réutiliser.

• Solutions pour un moyen d'authentification non-rejouable

Petit tour d'horizon des solutions disponibles.

o Calculette One Time Password (OTP)

Pour les cartes équipées d'une carte à puce (système EMV), il est
possible d'utiliser une calculette qui produira un challenge à saisir sur le site
de la banque lors de l'achat. Ce challenge sera un hash calculé en fonction
du code PIN saisi par l'utilisateur. Le HSM de la banque pourra ainsi vérifier
l'identifié du client. C'est un TPE virtuel.
Les protocoles derrière ce système sont le Mastercard Chip
Authentication Protocol (CAP) ou le VISA Dynamic Passcode Authentication
(DPA). A noter que de nombreux faiblesses ont été signalé dans le protocole
EMV CAP par Ross Anderson dans son article : “Optimised
 to
 Fail:
 Card

Readers
for
Online
Banking”


o Token OTP
Tout le monde connait le SecurID de RSA. Un porte-clé avec un code
à 6 chiffres non prédictible qui s'affiche et change toutes les 30
secondes.
La banque possède un serveur synchronisé de son côté.

o Authentification par SMS

C'est l'authentification double canal. Lors de la phase de paiement, la
banque voit envoi un SMS avec un code à usage unique que vous devez
saisir pour valider le paiement.
3. CONCLUSION


 20

Dans cette étude, nous avons vu de nombreux protocoles de paiement sur
internet. Certains d’entre eux n’ont jamais pu s’imposer comme standard
international. Cependant, deux architectures sont les plus répandues. Les solutions
basées sur SSL et l’architecture 3D Secure. Le succès des solutions SSL s’explique
par leur facilité de mise en œuvre, leur légèreté et leur rapidité. Ces solutions
bénéficient surtout du succès de SSL qui est intégré à tous les navigateurs du
marché. Quant à 3D Secure, il met les utilisateurs et les commerçants en
confiance en exigeant une authentification du client auprès de sa banque. Ainsi
cela permet de réduire la fraude pour les commerçants et rajoute une sécurité
supplémentaire pour le paiement. La plus part des protocoles étudiées sont
sensibles au phishing ou à une attaque du type man in the middle.

BIBLIOGRAPHIE :
Transparents Cours « Le Transport sécurisé SSL/TLS, SET » : par Monsieur Ahmed
Serhrouchni
Article « Le commerce électronique : un état de l’art » par Ludovic Me et Renaud
Chaillat
Article “Optimised to Fail: Card Readers for Online Banking”, Saar Drimer, Steven J.
Murdoch, and Ross Anderson

Article “ Verified by Visa and MasterCard SecureCode: or, How Not to Design
Authentication “ Steven J. Murdoch, Ross Anderson

Article « Paiement sécurisé sur Internet avec le protocole SET » par Gérard
RIBIÈRE
Livre « Paiements électroniques sécurisés » Mostafa Hashem Sherif Avril 2007
Livre « Sécurité informatique: risques, stratégies et solutions » Par Didier Godart
Janvier 2005

Pages web visitées :

http://wearesecure.blogspot.com/2009/07/la‐banque‐de‐france‐impose‐le‐3d‐secure.html


http://www.idf.net/articles/paiements.html


http://www.0faute.com/set.htm


http://fr.wikibooks.org/wiki/Monétique/Les_solutions_de_paiement_par_mobile


http://www.commentcamarche.net/faq/16311‐3d‐secure‐verified‐by‐visa‐securecode‐qu‐est‐ce‐que‐c‐est


http://www.indicthreads.com/1496/security-and-threat-models-secure-electronic-transaction-set-protocol/

http://www.clubgenies.com/modules/smartsection/cours%20reseaux%20informatique/Ge
neralites%20et%20Protocoles/Payement%20securise%20sur%20internet%20avec%20le
%20protocole%20SET.pdf

http://www.journaldunet.com/0404/040422mastercard.shtml


http://pro.01net.com/editorial/511837/le‐paiement‐en‐ligne‐par‐3d‐secure‐trop‐bancal‐selon‐des‐
experts/



 21