Brevet FR2815203A1 — publié le 20020412

Mandataire de paiement sécurisé Internet avec validation par le téléphone mobile Problématique ciblée et Etat de l'art Une des problématiques du paiement sur Internet est de réduire les contestations de transactions passées en ligne, en mettant en place des solutions garantissant la sécurité et la non répudiation par le client. Par ailleurs, les solutions sécurisées existantes sont essentiellement basées sur un accès par terminal PC. Le développement du marché des mobiles, crée de nouveaux besoins d'achat en ligne multi-terminaux et disposer d'un système cohérent unique permettant de payer des achats en boutique depuis son PC, depuis un PC anonyme, ou depuis son téléphone mobile serait un avantage certain. Les solutions proposées aujourd'hui en termes de paiement en ligne depuis les PC avec navigateur utilisent l'un des moyens suivants : 1. introduction d'un terminal sécurisé auxiliaire disposant d'un lecteur de carte bancaire (système du type de celui proposé par la société CyberCOMM), 2. utilisation de certificats électroniques, comme SET 3. transmission du numéro de carte en ligne sur une liaison chiffrée (ex : en utilisant un protocole comme SSL exploitant de la cryptographie publique du type Diffie-Helmann) La première approche nécessite la mise en place d'un terminal spécifique (écran, clavier, processeur) chez le client utilisant la carte bancaire à puce comme les terminaux d'achat classiques. Ce moyen est considéré comme non répudiable. La deuxième approche est basée sur des certificats non standards et n'est pas strictement non répudiable car basé sur du logiciel installé sur des postes très ouverts comme les PC des clients. La troisième approche est la plus utilisée aujourd'hui car ne nécessitant aucune installation de la part du client, mais c'est elle qui déclenche le plus de fraudes parce que le numéro de carte est transmis sans authentification du client. Le fait de disposer d'un numéro de carte bancaire (information semi-confidentielle) suffit pour passer des ordres au nom d'une personne. Un générateur de numéro cohérents de cartes bancaires peut être utilisé à cet effet. Les solutions de paiement sécurisé par carte bancaire sur Internet s'appuyant sur la troisième approche, mettent en oeuvre aujourd'hui des intermédiaires de paiement sécurisé par carte (notés IPSC). Un IPSC assure l'interface entre l'Internet et un réseau de cartes bancaire. La communication entre le client et l'intermédiaire bancaire utilise un des principes suivants : le numéro de carte est transmis par le client à chaque échange (figure 1) le numéro de carte est stocké sur le terminal client et c'est un logiciel qui se charge de réaliser la transaction avec le serveur intermédiaire bancaire du vendeur le client est enregistré auprès de l'IPSC, qui conserve son numéro de carte et qui interroge le réseau cartes bancaires à chaque transaction. Pour ce qui est du paiement par les mobiles les solutions proposées restent limitées à la gestion du système d'information de l'opérateur de mobile. Définitions On entend par faiblement non répudiable, un dispositif transactionnel qui en utilisation normale utilise des informations connues du seul client pour signer la transaction et ne pouvant être transmises vers un hôte extérieur que si le client réalise une opération non autorisée, pouvant créer un trou de sécurité comme la mise en place d'un espion dans son système de signature électronique. Un système faiblement non répudiable, si le client s'engage à ne pas opérer certaines opérations et en accepte les règles contractuellement, devient non répudiable par le client. Objectif du dispositif L'objectif principal du dispositif est d'apporter une amélioration aux solutions de type transmission du numéro de carte systématique, permettant de limiter les risques de fraude à une fraction négligeable des transactions en introduisant la qualité de"non répudiation faible". Le deuxième objectif est de permettre des transactions unifiées Web/téléphone mobile. Description du dispositif Le dispositif proposé utilise un serveur Internet (8/2) agissant comme mandataire de paiement orienté client et intervenant en intermédiaire dans les échanges entre des systèmes IPSC (6/2) et le terminal client (7/2). Le serveur mandataire peut également effectuer des demandes d'autorisation vers des systèmes de paiement autres. Ce dispositif utilise un mécanisme de signature faiblement non répudiable pour authentifier les requêtes de paiement en provenance des clients. Son originalité est qu'il s'appuie sur des accès multi-terminaux. On distinguera 4 types de terminaux : le PC fixe (étant supposé à domicile) le PC occasionnel, dit PC anonyme (ex : borne multimédia publique) - le téléphone mobile simple te téléphone mobile de type WAP, avec ou sans module WIM. Lorsque la prise de commande est faite sur un terminal anonyme, le serveur mandataire de paiement requiert une validation par un terminal téléphone mobile. Dans l'utilisation de base, c'est-à-dire depuis un PC fixe personnel, le client installe un certificat standard délivré par le mandataire de paiement à l'inscription comprenant entre autres une clé privée à importer dans le navigateur du PC. Lors de l'importation, le client choisit : un code personnel appelé code de sécurité (CODES) qui protège l'usage de son certificat un code de validation (CODE~V) qui sera utilisé pour valider les transactions. Le bouton achat d'un transaction en ligne comprend en paramètres signés par le site vendeur : le contenu de la transaction, le prix, le code vendeur et consiste en un lien vers une demande de paiement vers le serveur mandataire. L'action sur ce bouton déclenche une liaison SSL entre le poste client et le mandataire de paiement et le passage des paramètres précédents. Le passage en mode SSL provoque l'accès au certificat client et donc une demande d'entrée du code de sécurité pour son déverrouillage local. Si le code est correct la liaison est établie et le serveur mandataire authentifie le client. Le code vendeur passé en paramètre sert à établir le relais vers le bon IPSC (celui du vendeur) et à vérifier que cet IPSC accepte bien le mode de paiement du client. L'agent de sécurité dispose de plusieurs interfaces pour simuler les échanges d'un client avec les divers IPSC. Lorsque le client intervient sur une borne anonyme ou chez un commerçant qui saisit en ligne la prise de commande pour son compte, celle-ci a été initialisée pour ne pas accéder au certificat. Dans ce cas les paramètres sont passés simplement en clair vers le serveur mandataire qui bloque le relayage en attente de validation par téléphone mobile et en affichant sur le poste client un numéro de transaction fixé par lui. Pour chaque achat à valider, ce numéro unique identifie la transaction (vendeur, commande, client) et doit être signé par le serveur mandataire. Trois cas de validation sont traités : 1. Cas du téléphone simple (figure 3) 2. Cas du téléphone WAP simple (figure 4) 3. Cas du téléphone WAP avec module WIM : authentification forte du client (figure 5) Note : Le téléphone mobile peut être à la fois considéré comme un terminal de prise de commande et de déclenchement de paiement. La prise de commande se fait comme sur un terminal de type PC. Fonctionnement détaillé Inscription/Installation L'inscription du client auprès du serveur mandataire (figure 2-b) est réalisée de manière strictement confidentielle : on peut utiliser un enregistrement en ligne avec SSL par exemple ou un enregistrement au guichet. Une procédure de validation par les exploitants du serveur mandataire, peut-être demandée. Elle doit assurer que les informations relevées à l'inscription sont valides. Si le client a demandé un enregistrement pour PC fixe, le serveur mandataire produit un certificat électronique à base de clés publiques de type X509 émis avec sa clé privée au client par messagerie (10/2). Le certificat est encapsulé dans un format qui déclenche l'auto-installation sur le PC client. A l'installation du certificat, le client est invité à définir son code de protection des clés CODE S, connu de lui seul et utilisé localement. Si le client a demandé la validation par mobile, il fournit son numéro de mobile et choisit un autre code de sécurité, appelé code de validation CODEV connu de lui seul et du serveur mandataire. Les données fournies par le client et conservées sur le serveur mandataire sont : l'identité (nom, prénom) son numéro de carte l'adresse de livraison habituelle - optionnellement : numéro de GSM - le CODEV. Validation de l'identité client Suivant la rigueur de la procédure souhaitée, il peut y avoir validation manuelle ou automatique, ou simplement aucune validation (acceptation de toutes les inscriptions) sauf des contrôles de non ré-inscription. En particulier des contrôles de réutilisation sur les messages électroniques et numéro de carte permettent de réduire les effets de ré-inscription. Transactions Depuis son PC initialisé Les achats sont réalisés par un simple hyperlien vers le serveur mandataire par le protocole HTTP, les données de la transaction étant passées en paramètres. Ces données sont signées par le vendeur pour garantir l'intégrité vis-à-vis du vendeur. La requête de paiement reçue au serveur mandataire permet d'authentifier le client de manière certaine, car la requête en mode SSL provient d'un PC fixe avec certificat. Dans ce cas, la requête est automatiquement validée et immédiatement relayée. Depuis un PC anonyme Si la requête est émise depuis un PC anonyme, le relayage est bloqué sur le serveur mandataire en attente de validation par le canal mobile (l'agent n'a pas authentifié de client). Le serveur mandataire demande l'identité du client et émet un numéro de transaction unique signé par lui pour la validation qui s'opère selon un des 3 modes autorisés. Validation 1. Validation par téléphone Le client appelle un numéro fixe, qui le met en communication avec un serveur vocal interactif ; il est invité à entrer le numéro unique de transaction, affiché sur l'écran de prise de commande ; le serveur restitue par synthèse vocale le descriptif de la commande ; si celui-ci est correct, le client entre son code de validation CODEV. La passerelle envoie une requête de paiement chiffrée et signée par elle contenant : l'identificateur de transaction et le CODEZ introduit. 2. Validation WAP simple : Dans ce cas le client établit une connexion WAP/SSL vers le service validation du serveur mandataire de paiement ; le client s'identifie par son nom et prénom puis entre son code de validation CODEV 3. Validation WAP avec module WIM ("WAP Identity Module") Ce cas est identique sur le principe au cas 2, sauf que le terminal WAP dispose d'une capacité de signature électronique garantissant l'authentification du client ; dans ce cas, le CODE V est signé par le module WIM avec les paramètres de la transaction. Note : Dans les cas 2 et 3 (validation WAP), la passerelle peut utiliser une méthode de mémorisation de l'identité client par Cookie. Le Cookie est un enregistrement en clair ASCII comprenant le nom, prénom du client signé par le serveur mandataire. Exemple d'implémentation Ce dispositif a été implémenté sur un serveur sous système Linux avec un pare-feu frontal sous Linux, et un IPSC opérationnel. Le système utilise HTTPS pour les échange SSL entre le PC client et l'agent de sécurité. La validation par mobile a été réalisée par un terminal WAP, selon le mode d'accès simple. L'authentification depuis le téléphone mobile s'opère par nom prénom, puis introduction du code de sécurité passé en session SSL. Revendications 1. Dispositif de mandatement pour les paiements sécurisés en ligne sur Internet sur des boutiques qui utilisent le chiffrement SSL pour la transmission du numéro de carte sans authentification du client vers un serveur d'autorisation bancaire, caractérisé en ce qu'il - comprend un moyen d'inscription des clients permettant de transmettre au mandataire le numéro de carte une seule fois à l'inscription, et ceci de manière sécurisée par liaison SSL - s'interpose au cours d'une transaction d'achat dans les échanges entre le terminal client et le serveur d'interrogation du réseau cartes bancaires de la boutique, d'une part en identifiant et authentifiant le client grâce à un mécanisme propre de signature électronique, et d'autre part en transmettant le numéro de carte client, mémorisé à l'inscription client, vers l'intermédiaire bancaire par la liaison SSL habituelle, sans authentification du mandataire de la part de l'intermédiaire bancaire. 2. Dispositif de mandatement de paiement selon les revendications 1, caractérisé par le fait qu'il utilise pour chaque client un certificat X509 standard généré sur le serveur mandataire à l'inscription client et transmis par messagerie avec la clé privée associée pour être importé dans le navigateur client, puis utilisé ensuite pour authentifier les clients dans les liaisons HTTP dans les transactions de paiement. 3. Dispositif de mandatement de paiement selon les revendications 1, caractérisé par le couplage possible à un dispositif auxiliaire permettant la validation par le téléphone mobile simple ou WAP, exploitant l'authentification du client par ce système auxiliaire et l'usage d'un code de validation connu seulement du client et du serveur mandataire.