électronique sur internet
Jean-Claude Paillès
1objectif du commerçant sur internet est bien évidemment d’aboutir, pour chaque visite d’un client sur son site, à une transaction d’achat. Dans la vie courante, l’acte d’achat est tellement banalisé que personne ne prête plus attention à la multitude de présupposés culturels et organisationnels mis en œuvre. Une des difficultés du commerce en ligne est de trouver un substitut à la transaction de contact entre acheteur et vendeur du monde réel, et qui, si possible, offre des avantages pour l’un et pour l’autre : ergonomie, simplicité, sécurité, auditabilité, universalité des usages, interopérabilité, anonymat dans certains cas, et… coûts d’exploitation et commissions réduites.
Il y a actuellement, surtout si l’on considère à la fois les services de paiement et micropaiement, des dizaines de systèmes différents. Cette prolifération, même si l’on sent bien que des convergences se dessinent, n’aide pas le commerce électronique à se développer, et va à l’encontre de la demande de simplification et de transparence souhaitée par l’utilisateur.
Cependant, on peut quand même dire qu’un nombre très limité de types de systèmes de paiement sur internet se dégagent : principalement, on peut citer les systèmes de type carte de D/C2 ou bancaire, les systèmes dont une dénomination commune est le porte-monnaie virtuel, très utilisés en
1. France Télécom R&D.
2. Abréviation de « Carte de débit-crédit ».
L’
micropaiement, sans oublier les systèmes à pièce ou jetons électroniques, mais qui n’ont pas connu un grand succès.
Cet article dresse donc un panorama des approches et techniques utilisées sur le Net, selon l’ordre mentionné ci-dessus. Il aborde dans le dernier chapitre le rôle important que le mobile pourrait jouer un jour dans le domaine du paiement sur internet, mais aussi sur d’autres canaux : vocal, proximité par rapport à un terminal de paiement électronique ou une borne.
Les systèmes de type carte de D/C
En 2002, le nombre de cartes en France était de 45 millions, et 84 % des adultes en possédaient une. Le taux de croissance sur les dernières années montre que ce marché rentre actuellement dans une phase de maturité. En 2002, le nombre d’opérations de paiements-retraits par carte s’est élevé à 5 milliards, alors que le nombre d’opérations par chèque a atteint 4 milliards.
La carte bancaire constitue le moyen de paiement universel par excellence. Son utilisation est possible dans tous les pays du monde, que ce soit pour du paiement de contact, chez les commerçants, que pour le retrait d’argent dans les distributeurs. Elle est donc utilisée en commerce électronique, depuis le début de ce type de commerce, suivant le même modèle de base que pour le commerce de contact. Ce modèle, bien connu est rappelé à la figure 1.
client marchand
banque acquéreur banque
émetteur
organisme de compensation 1: initialisation: offre 2:demande de paiement
4: reçu
3:autorisation
3:autorisation
6:compensation 6:compensation
5:collecte 7: relevé de compte
7:relevé d’opérations
Source : France Télécom R&D
Figure 1. Modèle générique d’une transaction de paiement carte D/C
Notons que l’autorisation peut s’arrêter au niveau de la banque acquéreur (ou de l’organisme à qui elle sous traite cette fonction), si elle se limite à un contrôle par rapport à une liste noire. Il faut noter également que, après le relevé 7 envoyé au client, il se peut que celui-ci proteste auprès de son banquier, et obtienne remboursement (si le mode dans lequel a été effectuée la transaction le permet : en France, pas de présentation du code PIN). Ce remboursement peut se répercuter jusqu’au marchand, et on parle alors de charge back.
Les problèmes de sécurité des transactions de paiement par carte D/C
Un des freins majeurs au développement du commerce électronique B2C3 a été, notamment en France, la crainte d’utiliser sa carte sur le Net, souvent considéré à cet égard comme une jungle hostile. Il faut quand même noter, en France, une forte progression du e-commerce : en 2002, plus de 10 millions de transaction ont été réalisées, soit une progression de 47 % par rapport à 2001 (ACSEL). Néanmoins, ces chiffres restent modestes, par rapport à l’activité commerciale globale. Sur le Net, les risques sont en effet bien réels, et concernent :
1) la protection des identifiants de cartes bancaires (numéros+dates de validité) : l’espionnage sur le réseau est un risque faible, étant donné la complexité d’une telle attaque sur des points d’accès, routeurs, artères internet. La réutilisation de ces numéros par un marchand indélicat est un risque beaucoup plus réaliste ;
2) la dématérialisation de la relation client-marchand peut inquiéter chaque partenaire de la transaction : ce marchand est-il sérieux, va-t-il respecter les termes de la transaction ? Un moyen d’authentifier le marchand et son « sérieux » est donc souvent utile ;
3) réciproquement, le problème de la répudiation par le client se pose4 : si le client a les moyens de nier son achat, qu’il aura si un mécanisme fort et reconnu (par exemple une signature électronique) ne permet pas de l’engager contractuellement ou réglementairement dans sa décision d’achat, alors il y a pour le marchand honnête un risque réel d’impayé, et un frein potentiel au développement de cette forme de commerce électronique.
3. B2C (Business to Consumer), le commerce électronique entre utilisateurs grands publics et marchands ou prestataires de service sur le Net.
4. Il s’agit ici que du paiement, et non des règles relatives à la défense du consommateur qui effectue des achats en VPC (vente par correspondance) et grâce aux règles de la VPC a le droit de renvoyer le bien sous 15 jours et être remboursé.
Notons enfin que si la sécurité a un coût, la fraude en a également un, qui a tendance à s’accroître dans le cas des paiements internet, et qui nécessite des moyens et procédures plus sûrs. Les politiques des grands réseaux sont maintenant de transférer la responsabilité et donc le coût des fraudes, du commerçant vers la banque du client, qui émet le moyen de paiement qu’il utilise, et qui a donc intérêt à investir dans des moyens de sécurisation appropriés. L’évolution des banques européennes vers les cartes à puce EMV, à l’horizon 2005, va d’ailleurs dans ce sens.
Les techniques utilisées
Les différents scénarios techniques sont décrits ci-dessous.
Aucune protection
L’envoi sans protection du numéro de carte bancaire sur le Net concerne – sauf exception – le passé.
Protection de la liaison client-marchand
Actuellement l’utilisation de Secure Socket Layer* ou SSL (en version authentification serveur par client, et chiffrement des échanges) est monnaie courante. Ainsi le risque 1 précédent est partiellement couvert (réutilisation de numéros de cartes possible), et le risque 2 est couvert pour autant qu’on ait confiance en la façon dont a été attribué le certificat au marchand, et donc conscience de l’autorité de certification qui a délivré ce certificat, et connaissance de sa police de délivrance. Hypothèses qui sont loin d’être réalistes pour le grand public.
Le protocole SET
Pour mémoire on peut citer SET* (Secure Electronic Transaction), né en 1996 des efforts conjugués de VISA, MASTERCARD et EUROPAY. SET adopte une approche PKI5. Client et marchand sont certifiés par leur banques respectives, qui jouent donc le rôle d’autorité de certification. Les banques sont elles-mêmes certifiées par une autorité nationale, elles-mêmes certifiées par une brand VISA ou MasterCard, elles-mêmes certifiées par une autorité suprême, ce qui donne donc un « arbre » de certification à 5 niveaux, demandant donc dans le pire cas d’échanger entre 2 parties une chaîne de 4 certificats. La figure 2 schématise ce protocole de façon
5. PKI (acronyme de Public Key Infrastructure) : les différents acteurs dans un système sécurisé selon l’approche PKI sont munis de leurs propres clés et certifiés par une ou plusieurs autorités de certification.
synthétique et approximative. Il concerne 3 parties : le client, le marchand, et l’APG* ou Acquirer Payment Gateway, donc une infrastructure liée à la banque du marchand.
échange certificats authentification M SigC(OCh , Ph), [P]APG
[SigM(message du client, mM)]APG
Client Marchand APG Banques
O: bon de commande, montant m, Nro transaction P: infos de paiement, m, Nro transaction
Autorisation Acquit signé par APG
Acquit signé par Marchand vérif OCh= OMh vérif SigC négociation
OC OM
déchiffre [ ] déchiffre [P]
vérif SigM vérif SigC vérif mM = m dans P
Source : France Télécom R&D
Figure 2. Schéma simplifié du protocole SET
Les notations de la figure 2 sont les suivantes : C, M désignent respectivement le client et le marchand ; SigC (X) désigne la signature par le client C d’une information quelconque X ; Xh est le hash6 de X ; [X]APG
désigne l’information X chiffrée pour l’APG, et donc en utilisant la clé publique de l’APG. Vérif Sig veut dire vérification de la signature d’une entité (C ou M) avec la clé publique adéquate. OC est bon de commande vu du Client ; OM bon de commande vu du marchand. Le bon de commande décrit le bien ou la prestation achetée, et contient en plus le montant et le numéro de transaction. P désigne les informations de paiement, et contient notamment le numéro de la carte bancaire, avec le montant et le numéro de transaction ; m désigne le montant de la transaction.
6. Hash*, signature*, certificat* sont les concepts de base utilisés dans les PKI, dont les principes sont supposés connus du lecteur.
Principes du protocole : le but est d’éviter qu’il y ait des désaccords sur la nature ou le montant de la transaction. L’APG doit vérifier que client et marchand sont bien d’accord sur les termes de la transaction, donc sur O et sur P, bien que O n’ait pas à être connu de l’APG, ni P du marchand M.
Notamment ils doivent être d’accords sur le montant m donné par le client dans P et mM directement donné par M dans le message que M envoie à APG. Cette assurance est donnée par une signature du client et du marchand. Le client s’engage sur les données de O et P par une signature sur ces deux paramètres, faite de façon qu’elle soit vérifiable par M ou l’APG sans dévoiler les informations O et P respectivement à l’APG et au marchand, d’où les principes de la cinématique et du contenu des messages tels qu’ils apparaissent sur la figure 2.
En fait SET a été un échec complet : les raisons en sont sa lourdeur et la complexité des phases d’enregistrement et certification des clients et marchands, et l’immaturité du marché pour des procédures aussi contraignantes, notamment aux Etats-Unis où la répudiation des transactions faites avec cartes de crédit est ancrée dans les comportements des clients. De plus, SET requiert d’installer des logiciels particuliers côté client, et par ailleurs, la mémorisation des clés publiques/secrètes sur le disque dur du PC ne peut être considérée comme une panacée sécuritaire, même si l’accès à la clé secrète est protégé par mot de passe.
Médiateur de confiance
Ce type de technique est actuellement d’une utilisation très large.
Puisqu’il y a des échanges sensibles du point de vue sécurité entre client et marchand, lors de la transaction de paiement, il suffit de les confier à une plate-forme intermédiaire, opérée par un organisme neutre et de confiance.
La figure 3 représente le principe de la cinématique, très simple, de ce type d’approche. Lorsque le client valide son « panier » et demande donc de payer, le marchand le redirige sur l’intermédiaire. Cette redirection correspond aux services de redirection existant dans HTTP7, et elle permet, du fait de l’architecture client-serveur traditionnelle, de passer la main à l’intermédiaire, qui ne peut de lui même rentrer en contact avec le client (avec les mobiles, le push existe). L’intermédiaire peut donc gérer le dialogue de confirmation. Ce dialogue peut être simplement la présentation au client du montant à payer, et la saisie de son numéro de carte D/C. Ou bien l’intermédiaire peut gérer des données des clients préalablement enregistrés, telles que numéro de cartes (il peut y en avoir plusieurs), et demander
7. Http : HyperText Transport Protocol, d’un usage universel sur internet.
simplement une identification/mot de passe au client. Cette dernière option emmène un plus sécuritaire important, puisque les fraudes basées sur l’utilisation d’un numéro de carte volé sont ainsi contrées. Des fonctionnalités de type wallet peuvent être rajoutées : mémorisation de profils utilisateur permettant à celui-ci de ne pas avoir à les saisir à chaque transaction : il s’agit par exemple de l’adresse de livraison, de facturation, de l’e-mail, etc. Cette possibilité est souvent utilisée avec les mobiles, où la saisie d’informations textuelles est fastidieuse. L’intermédiaire se charge des demandes d’autorisation, et peut ultérieurement traiter les collectes. Il n’y a pas besoin, côté client, de logiciels ou données à installer. On utilise le comportement standard des navigateurs sur les redirections http. La réponse au marchand doit être protégée par une preuve que cette confirmation n’a pas été créée avec un browser « bricolé ». Elle peut par exemple se baser sur un cryptogramme utilisant un algorithme symétrique, une clé partagée entre marchand et l’intermédiaire (il y a un contrat entre eux) et des paramètres tels que numéro de transaction, horodatage, etc. Citons comme exemples de tels systèmes SIPS de la société ATOS.
Demande de paiement Demande d’authentification
Dialogue de confirmation
Réponse authentification Navigation, offre
Client Intermédiaire Marchand
Source : France Télécom R&D
Figure 3. Sécurisation basée sur plate-forme intermédiaire
CVD : carte virtuelle dynamique
La technique précédente, quoique simple, exige tout de même des contrats marchands-intermédiaires, et des logiciels côté marchand, souvent appelés « kit marchands ». Son déploiement ne peut donc se faire de façon
instantanée ! La technique CVD est à cet égard, plus simple, et susceptible de déploiements rapides. Elle fait d’ailleurs aujourd’hui l’objet de promotions sous le nom de « e-carte bleue ». Le principe est simple : au lieu d’effectuer les transactions selon la cinématique générique de la figure 1, elles se font avec un numéro temporaire de cartes, d’où le nom « CVD ». Ce numéro a une structure semblable à un vrai numéro de carte D/C, notamment le préfixe « BIN » est le même pour permettre un routage identique à celui de la vraie carte. Le numéro temporaire doit être converti en le vrai numéro avant les opérations d’autorisation (3) et de compensation (6) auprès de la banque émetteur, de façon à ce que les contrôles et imputations se fassent par rapport au bon compte ! Ce numéro doit être obtenu par le client, avant de réaliser la transaction de paiement, auprès d’un serveur auquel il est abonné. Ce numéro est associé à un montant maximum. Ce serveur est consulté en 3 et 6 par la banque émettrice. Ce procédé rend le vol du numéro par le commerçant, ou la modification du montant, inutiles. Il peut poser quelques problèmes, en cas de délais entre autorisation et paiement effectif, ou annulation et il ne protège pas contre une source de fraude importante : le vol de numéros de cartes dans les transactions de contact, dans les pays où la puce n’est pas utilisée, et la réutilisation de ces numéros volés sur internet.
3D Secure de VISA
L’approche plate-forme intermédiaire décrite plus haut est simple, et dans le cas où elle authentifie le client, elle apporte un plus sécuritaire important. Mais pour en faire une approche globale, quasi normalisée, il faut lui apporter :
– l’aspect multiplate-forme : VISA associe au niveau modèle d’architecture la plate-forme à la banque émettrice, en lui laissant le choix des moyens d’authentification de ses clients ;
– la sécurisation des messages marchand/plate-forme doit être vue dans un contexte global de milliers de plates-formes ; dans ce contexte l’approche PKI est la plus simple à mettre en place !
– Le marchand, face à un client qui peut être à l’autre bout du monde, doit avoir le moyen de contacter la plate-forme de la banque émettrice : un annuaire est donc fourni.
Ceci emmène à l’architecture de la figure 4, où apparaissent les 3 domaines « émetteur », « acquéreur », et « interopérabilité ». Le marchand, l’annuaire et la plate-forme émetteur sont intégrés dans une architecture PKI permettant de sécuriser les échanges entre ces entités. La cinématique est simple, à partir des considérations générales ci-dessus : le client navigue sur
un site marchand quelconque (1), puis décide d’acheter quelque chose, et donne donc son numéro de carte bancaire (2) au marchand. Celui-ci demande alors à l’annuaire (3) de contacter la plate-forme correspondant à ce numéro de carte, ce qui provoque les échanges (4) et (5) et il obtient en réponse (6) une indication précisant si, pour ce client, l’authentification 3D est bien disponible. Il envoie alors une demande d’authentification (7) à cette plate-forme, via le terminal du client (redirection comme dans le cas plate- forme intermédiaire, et pour les mêmes raisons). Un dialogue (8) permet alors de réaliser cette opération, qui peut d’ailleurs se réaliser suivant des modes propres à cette relation client/banque. La réponse (9) contient une signature de la plate-forme, qui sera vérifiable par le marchand grâce aux certificats qui lui ont été fournis par l’annuaire ; puis la transaction se poursuit comme dans le cas classique : autorisations, collectes, etc. Cette approche (dont le nom commercial est « verified by VISA ») assure une véritable interopérabilité, et semble actuellement reconnue et susceptible d’un déploiement important.
Client Marchand
Domaine émetteur Domaine Interopérabilité Domaine acquéreu Visa
directory
1 2
3
4 5
6 7
8
9
10 Plate forme
émetteur
circuits habituels
Source : France Télécom R&D
Figure 4. Sécurisation basée sur plate-forme intermédiaire
La solution carte à puce
La carte à puce est le moyen de sécurisation du paiement de proximité le plus efficace. L’évolution en Europe vers la carte EMV, dont un déploiement généralisé est annoncé pour 2005, ne peut que contribuer à élargir son champ d’utilisation au paiement sur internet. Les fonctions d’authentification dynamique (DDA, Dynamic Data Authentication), de plus
en plus présentes dans les cartes EMV, basées sur de la cryptographie asymétrique, s’adaptent bien à la problématique de l’authentification du client dans un contexte ouvert.
Mais se pose le problème du lecteur de carte à puce qui doit être associé au PC du client, donc surcoût, et nécessité d’installation logicielle et matérielle. La qualité sécuritaire du lecteur a aussi une importance fondamentale : en effet, si l’on considère que le PC est ouvert à différents virus et chevaux de Troie, comment rassurer l’utilisateur payeur à propos du what you see is what you pay, donc le risque pour le client d’être trompé sur la prestation qu’il décide d’acheter, qui plus est avec une procédure sécurisée basée sur la carte à puce, et donc sur laquelle il n’aura aucune possibilité de répudiation ? Il faut donc utiliser un lecteur sécurisé, imperméable à tout virus ou agression externe, disposant de ses propres moyens d’entrée sortie (clavier afficheur) et de traitement afin que toute la transaction – présentation du montant, saisie du code confidentiel, calcul des certificats de paiement – soit à l’abri de toute malversation. Ceci implique donc un lecteur spécifique, certifié du point de vue des ses qualités sécuritaires, et authentifiable à distance. Le projet Cyber-COMM, en 2000/2001, mené par le GIE-Cartes Bancaires, différentes banques, et France Télécom, a tenté cette approche, mais a buté sur le problème du déploiement des lecteurs. De cet échec, est née l’initiative FINREAD* qui cherche à relever ce challenge à un niveau européen, en construisant une approche très générique susceptible de convenir à de nombreuses applications sensibles du point de vue sécuritaire. Cette démarche devrait donc contribuer à la constitution d’un marché de lecteurs de cartes plus vaste et rationalisé, donc abaissement des coûts et déploiement facilité. Citons comme exemples d’applications en dehors du domaine paiement, les applications santé, les applications liées aux cartes transport en commun, les applications e-government, etc. Cette approche très générique se base sur une plate-forme JAVA (profil STIP) qui permet d’envisager un développement simple des applications qui dans le lecteur traitent la carte à puce, le clavier/afficheur, les échanges avec le PC, etc., tout en garantissant une portabilité sans faille d’une réalisation de lecteur à une autre.
Le micropaiement
L’éclatement de la bulle internet, et la diminution des revenus publicitaires qui en a résulté, amènent beaucoup de fournisseurs de contenus sur internet à chercher à monnayer leur offre. Le développement
des mobiles et des applications de « data », même si le succès du WAP a été jusqu’à présent très mitigé, devrait avec le GPRS renforcer ce besoin de micropaiement de contenus à forte pertinence temporelle ou géographique (grâce aux fonctions de positionnement)… Enfin l’ère du tout gratuit en ce qui concerne la musique (phénomène du MP3 et systèmes d’échange « P2P » tels que Napster, Kazaa, etc.) devrait aussi s’achever8, devant les assauts répétés de la justice américaine. Elle devrait laisser la place à des offres de contenus en ligne (Musicnet, Pressplay en sont des exemples) ou des systèmes d’échange P2P9 contrôlés, et dans les deux cas le paiement devrait être un prérequis. Il semble donc entendu qu’il existe un besoin fort de systèmes de micropaiement simples pour l’utilisateur (minimum de clics, rien à installer sur le PC), pour les marchands (nécessité d’une certaine standardisation, pour ne pas avoir à s’adapter à n systèmes différents, donc ouverture), pour le recouvrement des sommes dues : le plus simple est la facture de l’IAP/ISP, que tout internaute a l’habitude d’acquitter, mais des solutions comme un compte spécialisé post ou prépayé (dans ce cas on parle de porte-monnaie virtuel ou PMV) sont aussi intéressantes à cet égard, si elles sont suffisamment universelles. Il est clair aussi que les modalités de ce paiement doivent être souples et diversifiées : abonnement, acte, durée, etc.
Et les approches de type « kiosque », comme pour le Minitel, pourraient retrouver du sens dans la Net économie.
L’aspect réglementaire est un autre aspect du micropaiement : l’offre de moyens de paiement est souvent, en France, considérée comme un monopole des banques ; en fait les sociétés qui opèrent des solutions de µ- paiement doivent respecter des réglementations destinées à protéger les intérêts des utilisateurs payeurs et payés. Les sociétés (telles que WHA en France, filiale de France Télécom) opérant ce type de services sont donc amenées à adopter les structures et statuts adéquats.
Les différents types d’approches du µ-paiement
Beaucoup de contenus se payent par abonnement, et dans ce cas on a plus à faire à du paiement régulier qu’à du micropaiement. Si on se restreint à des paiements de contenus à l’acte ou la durée, alors les montants en jeu sont souvent faibles (moins de 10 à 15 €), et ne justifient pas d’une procédure de paiement régulier, pour des raisons économiques, et souvent aussi pour
8. Affirmation incertaine…
9. Peer to Peer, ou client à client, donc échappant au modèle traditionnel client- serveur.
permettre une ergonomie plus légère et spontanée, adaptée au comportement impulsif du client. Les procédés existants sont les suivants.
Utilisation de numéros à « revenus partagés »
AVA, ou Added Value Area est une solution de micropaiement très simple proposée par France Télécom. Elle est basée sur l’utilisation de numéros téléphoniques à « revenus partagés », pour accéder au point d’accès conduisant aux serveurs qui utilisent ce moyen de facturation de leurs prestations. Ce type de solution est donc dans le droit fil du kiosque MINITEL 36XY, qui par sa simplicité et son efficacité avait assuré une part du succès du système Minitel. L’internaute n’a pas à être « abonné » à un système de paiement : la facturation se fait via sa facture téléphonique, suivant le temps passé, et le palier choisi. Le logiciel côté client gère la déconnexion/reconnexion, pour appeler les numéros AVA, et affiche le prix et la durée écoulée depuis le début de la session payante. France Télécom reverse au marchand les sommes perçues auprès du client, moins la commission FT.
Le porte-monnaie électronique
Le porte-monnaie électronique serait une solution naturelle, mais se pose le problème du lecteur de cartes. A ce jour, à notre connaissance, il n’existe pas de véritable pilote ou déploiement de ce type d’approche, dans le monde, même si des systèmes de porte-monnaie électronique existent dans beaucoup de pays (Monéo en France).
Le porte-monnaie virtuel
Les schémas de type « porte-monnaie virtuel » se basent sur une plate- forme intermédiaire de gestion des comptes des clients, et une cinématique proche de celle de la figure 3. Ces comptes peuvent être dédiés micropaiement, pré ou postpayés. Dans le premier cas, il faut alors prévoir une procédure de rechargement, donc de paiement (régulier) du montant rechargé. Dans le second cas, la gestion du risque peut nécessiter des
« préautorisations » à partir d’un compte bancaire du client. Ces comptes peuvent aussi être ceux du client chez l’IAP/ISP. Le rôle de la plate-forme intermédiaire est de permettre l’identification du client le plus simplement possible, sans que celui-ci ait à saisir un identifiant, par exemple en demandant à l’IAP l’identification client correspondant à l’adresse IP (qui est affectée de façon dynamique par l’IAP lors de la connexion à internet).
L’authentification du client se fait dans la phase « dialogue de confirmation » en vérifiant son mot de passe. Ensuite la plate-forme compte
une durée si le paiement est à la durée, et enregistre les µ-transactions, pour pouvoir périodiquement les agréger par client ou par marchand, afin de gérer les paiements et reversements, calculs des commissions, etc.
L’anonymat du client par rapport au marchand est assurée, mais par contre l’intermédiaire connaît tous les comportements de ses clients. Une variante de ces systèmes est basée sur des « cartes à gratter ». L’intermédiaire gère alors des comptes liés aux identifiants des cartes à gratter en cours d’utilisation. L’anonymat dans ce cas est complet, puisqu’il n’y a plus de notion de compte client chez l’intermédiaire.
Parmi les systèmes de µ-paiement exploités, actuellement, on peut citer notamment l’offre WHA, bâtie sur la technologie de la société iPIN, et opérée par une filiale de France Télécom (cf. figure 5). A l’étranger, des systèmes analogues existent.
W-HA
Modes:
•Acte
•Temps
•abonnement
1. Choix offre
2. Demande d’autorisation
3. Identification client (avec @ip) et vérif. Compte Client
4. Confirmation par le client 5. Acquit
6. Livraison
Wanadoo, Club Internet, …..
Source : France Télécom R&D
Figure 5. WHA
Les systèmes à pièce ou jetons électroniques
Pour mémoire, on décrit ici des systèmes comme e-CASH ou Millicent, qui ont eu leurs heures de gloire dans les années 1995-2000 : ces approches n’ont pas abouti, car malgré leur simplicité apparente, leur similarité avec la monnaie traditionnelle, tout ceci basé (dans le cas de e-Cash) sur une couche de cryptographie originale, elles se révèlent difficiles à mettre en place.
Une pièce électronique est une donnée signée par l’émetteur de la pièce, afin qu’il soit le seul à pouvoir créer de la monnaie.
Le marchand recevant une telle pièce en paiement doit s’assurer qu’il ne s’agit pas d’un faux (contrôle de la signature électronique ) et aussi qu’elle n’a pas déjà été dépensée, puisque rien n’est plus facile que dupliquer une donnée informatique ! Une base de données doit donc enregistrer chaque pièce dépensée, et doit être consultée à chaque paiement par le marchand.
Millicent résout ce problème en rendant les pièces spécifiques à un couple client-marchand (ou à un groupe de marchand qui fédèrent leur contrôle d’unicité). Le client doit donc gérer dans la « poche » virtuelle de son PC un grand nombre de monnaies différentes, s’il veut naviguer sur le Net. Ce qui rend ce système assez irréaliste !
Techniques à jeton: l’exemple de e-CASH
C M
A
chargement des jetons
C A
choix n aléa choix x aléa
y=PA(x) yn, IdC
débit compte C de 1F calcule z=SA(yn) z
calcule SA(n) = z/x
jeton= n, SA(n)
paiement
C M A
demande 1F n, SA(n)
vérifie jeton
jeton vérifie que n non déjà utilisé OK OK
anonymat intraçabilité
Source : France Télécom R&D
Figure 6. Principe des protocoles e-CASH
L’approche e-CASH est plus radicale : elle se base sur une base de données unique et donc pose des problèmes d’ouverture évidents. De plus e-CASH utilise une technique de délivrance des pièces autorisant un anonymat et une non-traçabilité comparable à ce que l’on a avec les pièces métalliques du monde réel. Il y a en effet impossibilité (au sens cryptographique) d’associer tel client à telle transaction, ce qui n’est pas le
cas dans les systèmes basés sur un identifiant de compte, qui permet de remonter aisément à une personne.
La figure 6 schématise les protocoles e-CASH : C, M et A sont le client, le marchand, et l’autorité chargée de l’émission de la monnaie électronique et du contrôle de non-réutilisation. La partie gauche schématise la technique de
« signature aveugle », permettant un anonymat complet de la délivrance des pièces à un utilisateur. Elle est basée sur les propriétés multiplicatives de RSA : pour faire signer n sans dévoiler n, C fait signer P(x)n, puis divise la signature obtenue par x pour obtenir la signature de n (P étant la fonction publique inverse de la fonction secrète S). Ces principes ont été améliorés pour supporter des pièces de valeur variable, et pour essayer de trouver des solutions plus attrayantes au contrôle de réutilisation, mais sans jamais conférer à cette technique un intérêt suffisant.
Le cas PayPal
Dans ce panorama des moyens de paiement sur internet, passer sous silence la success story PayPal aurait été une erreur. Actuellement, dans le monde, 20 millions de personnes ont un compte PayPal, et 28 000 nouveaux comptes sont créés par jour10. PayPal est un système de virement de fonds entre comptes identifiés par une adresse e-mail. L’authentification de l’ordre de virement se fait par un mot de passe défini lors de l’enregistrement à PayPal. Ce système n’a donc rien à voir avec les systèmes de paiement cartes traditionnels, et s’apparente plus aux approches de type compte virtuel prépayé, approvisionné par carte de D/C. Il peut aussi bien servir pour des petits montants que pour des montants importants de plusieurs centaines d’euros. Il est particulièrement utilisé sur les sites d’enchère, où il permet des paiements transfrontières simples et économiques.
Le coup de génie de PayPal est d’avoir mis en place un processus d’ouverture de compte en ligne simple, rapide, bon marché, et sécurisé11. Ceci permet une approche marketing « viral » qui transforme le destinataire du paiement en un nouveau client.
10. Données du site PayPal.
11. Lors de l’enregistrement sur le Net à PayPal, l’utilisateur donne diverses informations, dont son numéro de carte bancaire, et un mot de passe est attribué au client. Mais un code de validation, nécessaire pour valider cet enregistrement, lui est communiqué en tant que montant (centimes) de deux transactions apparaissant sur son relevé d’opérations. Il s’agit donc d’un procédé d’authentification du client simple, peu coûteux, et malgré tout efficace.
Betty retire l’argent, ou l’utilise pour payer d’autres personnes.
Andy s’enregistre et donne les identifiants de sa carte de D/C ou compte bancaire
Andy entre l’adresse e-mail de betty, et le montant à lui payer
“You’ve got cash!”
Betty reçoit un e-mail avec lien Paypal
Betty clique sur le lien, et s’enregistre chez Paypal
Source : PayPal
Figure 7. Les étapes d’un paiement PayPal
Le paiement avec les mobiles
Le téléphone mobile se trouve maintenant dans pratiquement toutes les poches des citoyens des pays occidentaux. En France, il y a actuellement presque 40 millions de mobiles, à comparer avec les 45 millions de cartes bancaires ; en Europe, le chiffre est de 300 millions. Le mobile est un terminal personnel, et il dispose de tous les moyens de communication (voix, données, notamment push avec les SMS*, GPRS pour surfer en WAP sur le Net) et de dialogue utilisateur (clavier, afficheur).
De plus en plus les mobiles se dotent de moyens de communication locale : infrarouge (IRDA*), Bluetooth*, et des démonstrateurs utilisant la norme ISO 1444312 existent. On peut également mentionner un moyen de communication plus inattendu, mais qui a fait l’objet de démonstrateurs convaincants : l’affichage sur l’écran du mobile d’un code barre à 2 dimensions, que le terminal, grâce à une caméra, peut analyser et décoder pour obtenir quelques centaines de bits d’information.
De même, le mobile dispose à demeure d’une carte à puce, la SIM, qui si elle est émise par l’opérateur de réseau mobile, évolue de plus en plus vers une plate-forme multi-applicative JAVA, selon les normes JAVA-CARD*.
Par ailleurs, les mobiles eux-mêmes deviennent une plate-forme multi- applicative, pouvant contenir des jeux, y compris des jeux en réseau, et des applications diverses. Le profil JAVA-MIDP* semble pouvoir s’imposer sur
12. Norme de communication entre terminaux et carte sans contact ou tags RFID, à courte distance.
une large part du marché des mobiles, et notons que MIDP2.0 définit une police de sécurité convaincante concernant ces aspects multi-applicatifs : téléchargement sécurisé des MIDLETS, contrôle d’accès interne aux ressources du terminal mobile garant d’une parfaite isolation des applications entre elles, et du respect des restrictions d’accès qui leur sont données.
Bref, certains voient dans le mobile du futur un rôle non seulement de communicateur, mais aussi de PTD : personnal trusted device, donc d’un outil susceptible d’être utilisé comme un terminal personnel dans de nombreuses transactions de la vie quotidienne, comme par exemple la billettique, le paiement, la sécurisation d’accès à l’intranet de son entreprise, etc. La figure 8 illustre différents contextes d’utilisation de ce PTD :
– Distant : le mobile est engagé par exemple dans une transaction de télépaiement, télébillettique, après une étape de navigation WAP ou internet ;
– Local : le mobile communique par un lien local (IRDA, Bluetooth, 14443) avec un terminal de paiement, une borne d’accès ou un automate, pour une transaction quelconque. Ce terminal peut être ou non connecté à un back-office, à travers internet ;
– Home : pour peu que le PC domestique soit doté par exemple de Bluetooth, le mobile peut devenir une sorte d’outil de sécurité du PC, remplaçant en quelque sorte un lecteur de carte à puce connecté au PC, pour sécuriser des transactions entre le PC et un serveur distant.
Les paragraphes suivants dressent un panorama de différentes approches du mobile-paiement, et essayent d’en dessiner les grandes tendances.
• DISTANT
• LOCAL
• HOME
PC WAP / Inte rne t
IRDA Bluetooth
IRDA, usb Bluetooth
Internet Internet
( )
Source : France Télécom R&D
Figure 8. Le PTD et ses grands types d’usage
Les approches techniques possibles
Le mobile est un terminal parmi d’autres, et son incursion dans le domaine du paiement ne change pas les architectures décrites dans les paragraphes précédents. Cependant, ses particularités emmènent des modes de réalisation particuliers, par exemple en ce qui concerne l’authentification du client et son engagement dans la transaction ; plusieurs scénarios différents sont décrits ci-dessous.
L’authentification GSM « basique »
Dès son apparition, la norme GSM a prévu une authentification forte du mobile par le réseau GSM, grâce à la SIM et une procédure challenge/réponse utilisant une clé diversifiée dans le SIM. Tous les mobiles en circulation sont donc authentifiés de cette façon, et ceci peut être mis à profit par des systèmes de paiement qui ainsi n’ont pas à déployer d’équipements spéciaux côté utilisateurs, puisque atteignant d’entrée une cible de 300 millions d’utilisateurs en Europe ! Par exemple, la confirmation d’un paiement peut se faire par l’appel d’un portable par un serveur vocal, un message vocal indiquant les termes de la transaction, et la saisie d’un code confidentiel sur le clavier, transmis en DTMF* ; ou bien l’envoi d’un SMS avec en réponse le code confidentiel signifiant l’approbation de l’utilisateur. Des procédures de ce type sont utilisées par exemple dans le système MOBIPAY, en Espagne. Des procédures identiques sont également envisagées comme une option possible au MPF (Mobile Payment Forum) dans des cinématiques telles que 3D-Secure (cf. figure 4, interaction 8).
Le mobile comme outil de signature électronique
L’utilisation croissante d’internet pour échanger des informations sous forme électronique soulève un certain nombre de problèmes, dont la reconnaissance juridique d’un document électronique, la certitude que l’information a bien été envoyée par l’émetteur annoncé – authentification de l’origine – et qu’elle n’a pas été modifiée au cours de son transfert – intégrité de l’information. Une signature sous forme électronique permet de résoudre, suivant les technologies utilisées, tout ou partie de ces problèmes.
Aujourd’hui, la seule technologie réellement disponible permettant de fournir une signature électronique sur réseaux ouverts est la technologie appelée signature numérique. Elle s’appuie sur des méthodes de cryptologie à clés publiques : le signataire calcule sa signature numérique à l’aide d’une clé privée qu’il est seul à connaître et à pouvoir mettre en œuvre, puis cette
signature peut être vérifiée par n’importe qui grâce à la clé publique correspondante. Il faut toutefois être sûr qu’il s’agit bien de la clé publique du signataire et pas d’un usurpateur essayant de se faire passer pour le signataire. C’est le rôle des certificats électroniques, fabriqués par des prestataires de services de certification devant avoir la confiance des utilisateurs, et qui permettent de faire le lien entre une clé publique et l’identité de son possesseur.
L’apparition de la directive européenne du 13/12/1999 traduit l’importance reconnue à cette technique, notamment pour le développement du e-commerce, au sens très général de ce terme. Elle a pour objectif sa mise en place dans un cadre européen sur le plan de la reconnaissance juridique et la reconnaissance mutuelle des signatures et certificats. Elle stipule qu’une signature électronique qui répond à certaines conditions minimales, normalisées au sein de groupes techniques EESSI (European Electronic Signature Standardization Initiative) doit obligatoirement être admissible comme preuve dans les procédures légales et être considérée comme équivalente à une signature manuscrite devant un tribunal. Même si les modalités du paiement électronique et des moyens de preuve afférents répondent plutôt à une logique de contrat entre le client et sa banque, il est probable que la signature électronique (au sens directive européenne) jouera un rôle important dans le développement du e-commerce B2C13.
Les conditions minimales mentionnées ci-dessus promeuvent les solutions basées sur le mobile, car elles exigent de fait une solution carte à puce pour le support des clés et des algorithmes cryptographiques, et des contraintes sévères sur le lecteur de cette carte à puce, pour satisfaire au problème du what you see is what you sign. Ces contraintes sont relativement faciles à atteindre avec un mobile, du moins ceux, à venir, supportant WAP 2.0, et l’USIM*. En effet les techniques PKI sont la base de la sécurisation des échanges sur le Net, fixe ou mobile, le surcoût des crypto-processeurs pour supporter RSA dans une puce de carte à puce diminue, loi de Moore oblige, et le coût marginal de la fonction signature électronique devrait donc être très faible dans les mobiles du futur, ce qui permet d’être optimiste sur le déploiement de cette technique, en tout cas dans le domaine du B2C.
Ceci justifie le projet ORANGE-TRUST, de FT/ORANGE, dont l’objectif est de permettre à des clients munis d’un mobile de s’engager sur un
« contrat » proposé par un prestataire : des exemples de contrat sont des ordres de paiement, des ordres de bourse, des paris… Le service offert aux prestataires est de les faire bénéficier d’une infrastructure préexistante,
13. Business to Consumer.
accessible par un protocole normalisé de type Web-service. Cette infrastructure comprend les dispositifs de création de signature (les mobiles) et les prestataires de service de certification avec toutes les fonctions et services associés : émission, gestion et révocation de certificats, mais aussi horodatage, archivage, et validation des transactions, et avec une interface indépendante des divers types de mobiles.
Ce service a été utilisé dans différents pilotes d’applications de paiement, avec les établissements tels que COFINOGA. Des actions analogues sont conduites par d’autres opérateurs de mobile européen, et des travaux de normalisation sont en cours à l’ETSI/M-COMM, afin de rendre ces services interopérables entre opérateurs de mobiles.
SIM/WIM Client
SMS 1 SMS 1
2.Demande de signature SMS 2 SMS 2 4.signature
SMS 3 SMS 3 5.Reçu 1. Navigation. Phase
« engagement»
Orange Trust
Wireless PKI Gateway Marchand
Orange Trust
Web service
« signature » Fonctions : Annuaire clés pub.
CRL Horodatage Notarisation
3-Saisie CC
Source : France Télécom R&D
Figure 9. Un service de signature-mobile : ORANGE-TRUST
Ce type de solution technique peut être utilisé dans un système de paiement de plusieurs façons. Par exemple :
– soit on considère que le paiement est une signature donnée au marchand des paramètres de la transaction ;
– soit on insère ce type d’approche dans les schémas de type 3D-SECURE (cf. interaction 8 de la figure 4).
Le mobile supporte une application de paiement
Une application de paiement n’est pas qu’une signature d’un ordre de paiement. Il faut que le client choisisse le moyen de paiement qu’il veut
utiliser, il faut gérer le risque, pour décider par exemple qu’une autorisation est nécessaire, il faut pouvoir enregistrer par exemple des points de fidélité, etc.
Apparaît donc un besoin de faire supporter au mobile une vraie application bancaire, reprenant certaines fonctions de la carte bancaire de paiement et d’autres traditionnellement implémentées dans le terminal de paiement. Ce scénario est le seul permettant une certaine compatibilité avec les back-offices existants, et il peut s’appuyer sur plusieurs types de réalisations :
– le mobile bi-fente, qui a eu son heure de gloire en France en 2000, puisque 7 à 800 000 mobiles bi-fentes ont été vendus par les deux opérateurs ORANGE et SFR. La carte bancaire pouvait donc être insérée dans le mobile lors de la transaction de paiement ;
– le mobile bi-chip, prôné par le forum MOBEY, qui vise à définir les modalités et contraintes du « mobile-paiement ». Des réalisations de cette approche ont été réalisées en Finlande, à petite échelle, sur des mobiles NOKIA. Le mobile contient donc deux puces au format microsim, l’une est la SIM, l’autre est dédiée aux traitements bancaires ;
– le mobile mono-chip, qui lui intègre tout dans la SIM, y compris par exemple l’application bancaire de la carte bancaire. Ce scénario supposant que la SIM est une vraie carte multi-application garantissant une cohabitation sans faille.
L’avenir dira quel est le scénario qui s’impose. Toutefois, ceci dépendra de l’entente entre différents secteurs – banques et opérateurs – qui ont chacun leurs propres intérêts. Il est clair que l’on touche là à des problématiques complexes et multiples : aspects de sécurité des clés bancaires, aspects de responsabilités sur les moyens de paiement, aspects de
« relation client » à travers la maîtrise du support que le client a dans sa poche…
Notons que le projet européen Embedded FINREAD vise à établir une norme sur les contraintes sécuritaires que le mobile (ou tout équipement intégrant cette approche, comme des set top boxes par exemple) doit satisfaire pour supporter une telle application. Ces travaux se positionnent dans la logique du projet FINREAD*, et établissent un ensemble cohérent et pragmatique de contraintes.
Quelques exemples de réalisation Le paiement CB-mobile
Pour mémoire, il s’agit de l’application de paiement avec mobile bi-fente, mentionné plus haut. Elle correspond à l’approche C du paragraphe précédent. L’application paiement était réalisée sous forme de SIM-toolkit14. Ce service était beaucoup utilisé pour le rechargement des comptes mobiles prépayés. Il pouvait également l’être pour
payer en vocal ou sur internet : sur certains sites, le client donnait son numéro de portable (au lieu de numéro de carte D/C, et le dialogue de confirmation ainsi que le paiement avec la carte D/C se faisaient sur le mobile). La diffusion de ce type de mobiles a été arrêtée en 2001, car les conditions de migration de la carte bancaire B0’ vers la carte bancaire EMV ont été jugées trop coûteuses et complexes, et au niveau industriel, un seul fournisseur (SAGEM) produisait des mobiles bi-fentes. Néanmoins l’application subsiste.
Le µ-paiement de contenus
Les contenus que l’on peut obtenir sur son mobile peuvent dans certains cas être payants : sonneries, données à forte valeur, etc. Orange a donc développé CLIC-PAIEMENT. Ce système se base sur WHA, avec les adaptations nécessaires pour le mobile : du fait qu’il est personnel, la confirmation par mot de passe n’a pas été conservée, et l’achat se fait donc en un clic (cf. figure 10). Il correspond à l’approche A, basée sur l’identification/authentification du réseau GSM. Les paiements sont imputés sur un compte dédié CLIC-PAIEMENT, prépayé, qui peut être rechargé par carte à gratter, ou avec l’application paiement CB-mobile, si l’on dispose d’un téléphone bi-fente.
Des systèmes de µ-paiement équivalents existent chez tous les grands opérateurs de mobile européens. Dans le cas de l’iMODE, au Japon, les services de contenus se payent sur une base de µ-paiement correspondant plutôt à un abonnement d’une durée limitée (De plus DOCOMO fait payer les volumes échangés, en plus de l’abonnement).
14. La SIM peut contenir des programmes « toolkit », donner des ordres au mobile, tels que afficher tel texte, envoyer tel SMS, obtenir la saisie de caractères et effectuer divers traitements.
Figure 10. Le service « Clic-Paiement »
Autres exemples
Le µ-paiement peut aussi s’utiliser pour des prestations du monde physique : c’est le cas du paiement sur automate. Des pilotes existent dans différents pays d’Europe. Le mobile (préalablement enregistré auprès du service parking de la ville, et associé avec un identifiant de la voiture) permet à l’utilisateur d’indiquer à un serveur quand il arrive et quand il part. Les contractuelles équipées elles aussi avec un mobile et un dispositif de lecture de l’identifiant de la voiture (code barre par exemple) peuvent savoir si le véhicule est autorisé ou pas en interrogeant le serveur. Le procès verbal peut même être édité automatiquement !
Le cas des automates peut se traiter de différentes façons, suivant que l’on veut accepter n’importe quel mobile pour payer ou que l’on veut se limiter à des mobiles dotés des interfaces appropriées. Dans la première catégorie, on trouve MOBIPAY en Espagne, dans la deuxième on trouve le service c-MODE associé aux terminaux i-MODE de l’opérateur NTT- DOCOMO. Le c-MODE nécessite une liaison mobile – automate, qui peut être infra rouge ou par code barre 2D saisi par un « scanner » sur l’automate.
Cette liaison permet à l’automate d’identifier le mobile, une étape de confirmation se faisant ensuite via SMS entre mobile et plate-forme centrale,
qui peut alors renvoyer un acquit à l’automate pour délivrance du produit.
Plusieurs milliers de distributeurs de boisson auraient été équipés ainsi au Japon.
Stationnement Payant: Zone 3 15F/heure T0231567899
Fin:
T0231313131
PARKING
Arrivée
Départ
98765
Appel 0231567889
« tapez le numéro de zone »
3 Mise à jour BdD
98765 en zone 3
Mise à jour BdD 98765 n’est plus
en zone 3
Contrôle: interrogation BdD locale
Serveur Ville
Source : France Télécom R&D
Figure 11. Une application inattendue du µ-paiement avec mobile
Webographie
Les sites suivants permettent d’approfondir les différents sujets abordés dans cet article :
http ://www.acsel.asso.fr/acsel/index.htm : un site (en français) de l’association du commerce et services en ligne.
http ://www.mobiletransaction.org/ : le forum MET, animé par les grands fabricants de mobile, a établi un ensemble de spécifications sur les transactions.
http ://www.mobilepaymentforum.org/ ce forum, réunissant des banques et des opérateurs de mobiles, étudie notamment les approches de type 3D-Secure, et le rôle exact du mobile.
http ://www.finread.com/index.php : site de FINREAD.
http ://www.mobeyforum.org/ ce forum, très « orienté banques », étudie différents scénarios de paiement de proximité avec le mobile.
http ://www.3gpp.org/ On trouve sur ce site les résultats de tous les travaux sur les mobiles 3G, et plus particulièrement les spécifications du SIM ou USIM, ainsi que MEXE : mobile execution environment, décrivant les contraintes sécuritaires que devront satisfaire les mobiles du futur.
http ://www.cenorm.be/isss/workshop/e-sign/ et
http ://www.ict.etsi.org/eessi/EESSI-homepage.htm donnent toutes les normes relatives à la signature électronique, suite à la directive européenne.
http ://portal.etsi.org/portal_common/home.asp?TbId=542 il s’agit ici du site de l’ETSI, où se trouvent notamment les résultats des travaux du groupe MCOMM sur la signature mobile.
http ://www.visaeu.com/ le site de VISA contient les spécifications de SET, 3D Secure, et diverses informations et démonstrations intéressantes.
http ://jcp.org/?frontpage-spotlight : ce site de SUN contient les spécifications du profil JAVA J2ME/MIDP pour les mobiles.
http ://www.encorus.com/meta/main.htm : Encorus est un fournisseur de technologies de paiement, et plates-formes correspondantes.
