cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc

1. Les architectures de paiement
électronique
Pr BELKHIR Abdelkader
Master RSD
Sécurité des systèmes informatiques

2. INTRODUCTION
Commerce électronique
Avantages:
•Ubiquité de business
•Disponibilité 24/24h, 7/7
Inconvénients:
Réticence des clients (sécurité, objets “touch
and feel” tels que les bijoux et objets
périssables

3. INTRODUCTION
1996 (MasterdCard, Visa,...),
le SET (Secure Electronic Transaction) : protéger des
transactions liées aux cartes de crédit sur Internet.
C’est un ensemble de protocoles et de formats de
sécurité basés sur trois principes :
• Des communications sécurisées entre les parties,
• L’utilisation des certificats X.509v3
• Une certaine "intimité" en restreignant l’information
à ceux qui en ont réellement besoin.

4. SET (Secure Electronic Transaction)
Vue Générale
Le SET doit obéir à certaines contraintes, fixées par
un cahier des charges :
⚫ Fournir la confidentialité des paiements et des
informations liées,
⚫ Assurer l’intégrité des données transférées,
⚫ Fournir l’authentification permettant de vérifier la
légitimité de l’utilisateur d’une carte,
⚫ Fournir l’authentification du marchand,
⚫ Offrir une protection optimale de toutes les parties
de la transaction,
⚫ Etre indépendant des protocoles, plate-formes, OS,
...

5. SET (Secure Electronic Transaction)
Entités intervenantes
⚫ Cardholder : consommateur
⚫Merchant : marchand
⚫Issuer : fournisseur (banque de l’acheteur)
⚫Acquirer: acquéreur (banque du marchand)
⚫Payment gateway (passerelle de paiement)
⚫Certification authority: autorité de certification

6. SET (Secure Electronic Transaction)

7. règles de sécurité
⚫L’acheteur et la passerelle de paiement doivent être
capables de vérifier l’authenticité du marchand
⚫Le marchand doit pourvoir vérifier que l’acheteur
et la passerelle de paiement sont bien authentifiés
⚫Les personnes non autorisées ne doivent pas
pouvoir modifier les messages échangés entre la
passerelle de paiement et le marchand
⚫Le numéro de carte de l’acheteur ne doit pas être
accessible au marchand
⚫Le banquier ne doit pas avoir accès à la nature de la
commande passée par l’acheteur.

8. Déroulement général d’une transaction
1. le client ouvre le compte
2. le client reçoit un certificat
3. les négociants ont leurs propres certificats : le négociant
possède 2 paire de clés : une pour signer et une pour
l’échange de clé. Le négociant dispose également du certificat
de la passerelle de paiement
4. le client passe une commande
5. le négociant est vérifié
6. l’ordre et le paiement sont envoyés
7. le négociant demande l’autorisation de paiement
8. le négociant confirme l’ordre
9. le négociant fournit des marchandises ou le service
10. le négociant demande le paiement

9. Les signatures duales
Dans une signature duale, on trouvera donc deux
messages destinés à deux receveurs distincts :
• l’information de commande (OI: Order Information)
pour le négociant,
• l’information de paiement (PI:
Payement Information)
pour la banque

10. Le fonctionnement de la signature duale

11. Signature Duale
PIM
D
OIM
D
⎮⎮
Has
h
POM
D
En-
cryp
t
Customer
’s
private
key
Dual
Sig.
Mercha
nt
Ban
k
P
I
O
I
Has
h
Has
h
Customer
’s
public key

12. Fonctionnement du paiement
De nombreux types de transaction sont possibles:
⚫la Commande (Purchase Request) ,
⚫l’Autorisation de paiement (Payment Authorization)
⚫le Paiement (Payment Capture).

13. La Commande: Requête du client

14. Commande: Vérification par le marchand

15. Autorisation de Paiement
L’autorisation de la passerelle de paiement a lieu en 7 étapes :
1. Il déchiffre l’enveloppe numérique du bloc d’autorisation
pour obtenir la clef symétrique et déchiffre alors le bloc
d’autorisation
2. Il vérifie la signature du négociant sur le bloc d’autorisation
3. Il déchiffre l’enveloppe numérique du bloc de paiement
(originaire du client et transmis par le marchand) pour obtenir
la clef symétrique et déchiffre alors le bloc de paiement
4. Il vérifie la signature duale sur le bloc de paiement
5. Il vérifie que l’identificateur de transaction reçu du marchand
correspond à celui reçu (indirectement) dans le PI du client
6. Il demande et reçoit une autorisation de l’institution
financière
7. Il renvoie la réponse d’autorisation au marchand

16. Paiement
Cette dernière phase de paiement prend place en 4
étapes :
1. Le négociant envoie une demande de paiement au
gateway de paiement
2. La passerelle vérifie la demande (vérification de la
signature du marchand)
3. La passerelle effectue le transfert de fond vers le
compte du négociant
4. Il informe enfin le négociant du transfert accompli.

17. SET : surcharge
⚫4 messages entre marchand et
client
⚫2 messages entre marchand et
passerelle de paiement
⚫6 signatures digitales
⚫9 RSA encryption/decryption cycles
⚫4 DES encryption/decryption cycles
⚫4 certificate verifications

18. Le SET fut un échec:
⚫les démarches à effectuer complexes
⚫plusieurs communications
⇒ un nouveau schéma de paiement fut créé
à l’initiative de Visa.

19. 3D-Secure
3D-Secure :
un schéma simplifié
une utilisation plus simple
Le schéma global de 3D-Secure est représenté par trois
domaines (d’où le nom 3D pour 3-Domains) :
1. Domaine du client - Domaine émetteur (Issuer)
2. Domaine d’interopérabilité - Domaine interbancaire
3. Domaine du marchand - Domaine acquéreur
(Acquirer)

20. Aperçu architecture

21. Domaine de l’émetteur (ISSUER Domain -
authentifie le client)
– Le client (cardholder) : achète online, fournit les infos
nécessaires (numéro de carte de crédit, mot de passe pour
l’authentification, date d’expiration)
– L’ACS(Access Control Server): vérifier l’authentification,
authentifier un client pour chaque transaction.
– Le navigateur du client : connexion sécurisée entre le MPI
(Merchant Plug-In) présent dans le domaine du marchand et
l’ACS
– L’émetteur (Issuer - souvent une banque) : responsable de
l’obtention de la carte, fournit les informations au DS
(Directory Server) présent dans le domaine d’interopérabilité,
détermine si un client peut utiliser le service ou non.

22. Domaine de l’acquéreur (ACQUIRER
Domain - authentifie le marchand)
– Le marchand.
– Le MPI (Merchant Plug-In) : interface dialogue avec
le client et le DS.
– L’acquéreur (Acquirer - souvent une banque) :
détermine si un marchand peut participer au service
3D-Secure, dialogue avec les entités du domaine
d’interopérabilité afin de gérer les demandes
d’autorisation de paiement.

23. Domaine d’interopérabilité (INTEROPERABILITY
Domain - gère les envois de messages)
– Le DS (Directory Server) : détermine si un numéro
de carte est valide ou non, transmet les requêtes
d’authentifications des clients à l’ACS. Lorsqu’il
reçoit la réponse, il la transmet au marchand.
– L’Authentication History Server (AHS) : historique
de transaction. En cas de conflit entre la banque du
client et celle du marchand, une copie de cet
historique est consultable.
– L’établissement de crédit (ici VisaNet) : reçoit les
requêtes d’autorisations de l’institution financière et
les transmet au fournisseur (Issuer), transmet la
réponse reçue à la banque du marchand.

24. Architecture générale

25. Inscription
1. Le futur détenteur: demande chez le fournisseur de
service (sa banque).
2. Fournit les données nécessaires au Service
d’inscription (Données d’identification, mot de passe,
PAM (Personal Assurance Message)).
La banque valide la demande du client si celui-ci est
jugé apte à utiliser la carte de crédit.
3. Le serveur d’inscription (Enrollment Server) envoie
la MAJ à l’ACS.
le client peut maintenant faire ses achats en ligne.

26. Inscription

27. Achat
1.Le client finalise un achat sur le site internet d’un marchand.
2. Le MPI envoie le PAN(Personal Account Number) au DS.
3. Le DS interroge l’ACS afin de savoir si l’authentification est
possible pour ce client.
4. Si c’est le cas, l’ACS lui répond positivement
5. Le DS transmet cette réponse au MPI
6. Le MPI envoie une PAReq (Payer Authentication Request) à
l’ACS en passant par le browser du client.
7. L’ACS reçoit le PAReq
8. L’ACS authentifie le client en demandant des informations
propres (mot de passe, code, etc.). L’ACS crée ensuite le
PARes (PAResponse) et la signe.

28. Achat (suite)
9. L’ACS envoie des données d’authentification
au Serveur d’historique d’authentification
(AHS).
10. L’ACS envoie le PARes au MPI en passant par
le browser du client.
11. Le MPI reçoit le PARes et vérifie la signature.
12. Le MPI poursuit les transactions avec son
institution financière (par VisaNet).

29. Achat