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

Commerce électronique 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

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.

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

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

SET (Secure Electronic Transaction)

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.

Déroulement général d’une transaction le client ouvre le compte 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

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

Le fonctionnement de la signature duale

Signature Duale PIMD OIMD  Hash POMD En- crypt Customer’s private key Dual Sig. Merchant Bank PI OI public key

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

La Commande: Requête du client

Commande: Vérification par le marchand

Autorisation de Paiement L’autorisation de la passerelle de paiement a lieu en 7 étapes : 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 Il vérifie la signature du négociant sur le bloc d’autorisation 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 Il vérifie la signature duale sur le bloc de paiement Il vérifie que l’identificateur de transaction reçu du marchand correspond à celui reçu (indirectement) dans le PI du client Il demande et reçoit une autorisation de l’institution financière Il renvoie la réponse d’autorisation au marchand

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

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

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

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)

Aperçu architecture

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.

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.

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.

Architecture générale

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.

Inscription

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.

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

Achat