WO2002029742A1 - Secure internet paying agent with mobile telephone validation - Google Patents

Secure internet paying agent with mobile telephone validation Download PDF

Info

Publication number
WO2002029742A1
WO2002029742A1 PCT/FR2001/003072 FR0103072W WO0229742A1 WO 2002029742 A1 WO2002029742 A1 WO 2002029742A1 FR 0103072 W FR0103072 W FR 0103072W WO 0229742 A1 WO0229742 A1 WO 0229742A1
Authority
WO
WIPO (PCT)
Prior art keywords
client
validation
payment
server
card number
Prior art date
Application number
PCT/FR2001/003072
Other languages
French (fr)
Inventor
Jacky Montiel
Original Assignee
Societe Ntsys Sa
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Societe Ntsys Sa filed Critical Societe Ntsys Sa
Priority to AU2001293955A priority Critical patent/AU2001293955A1/en
Publication of WO2002029742A1 publication Critical patent/WO2002029742A1/en

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/24—Credit schemes, i.e. "pay after"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation

Definitions

  • One of the problems of payment on the Internet is to reduce the challenges of transactions made online, by implementing solutions guaranteeing security and non-repudiation by the customer.
  • the second approach is based on non-standard certificates and is not strictly non-repudiable since it is based on software installed on very open workstations like clients' PCs.
  • the third approach is the most used today because it does not require any installation on the part of the client, but it is this which triggers the most fraud because the card number is transmitted without client authentication. Having a bank card number (semi-confidential information) is enough to place orders on behalf of a person. A consistent bank card number generator can be used for this purpose.
  • the card number is transmitted by the client for each exchange ( Figure 1) the card number is stored on the client terminal and it is software that is responsible for carrying out the transaction with the seller's intermediary bank server, the client is registered with the IPSC, which keeps its card number and which interrogates the bank card network for each transaction.
  • weakly non-repudiable is meant a transactional device which in normal use uses information known only to the client to sign the transaction and which can only be transmitted to an external host if the client performs an unauthorized operation, which can create a security hole like setting up a spy in his electronic signature system.
  • a weakly non-repudiable system if the customer agrees not to operate certain operations and accepts the rules contractually, becomes non-repudiable by the customer.
  • the main objective of the system is to improve solutions of the systematic card number transmission type, making it possible to limit the risk of fraud to a negligible fraction of transactions by introducing the quality of "low non-repudiation".
  • the second objective is to enable unified web / mobile phone transactions.
  • the proposed device uses an Internet server (8/2) acting as a customer-oriented payment agent and acting as an intermediary in exchanges between IPSC systems (6/2) and the client terminal (7/2).
  • the proxy server can also make authorization requests to other payment systems.
  • This device uses a weakly non-repudiable signature mechanism to authenticate payment requests from customers. Its originality is that it relies on multi-terminal access.
  • 4 types of terminals - the fixed PC (being assumed at home) the occasional PC, called anonymous PC (ex: public multimedia terminal) the simple mobile phone the WAP type mobile phone, with or without WIM module.
  • the payment proxy server requires validation by a mobile phone terminal.
  • the client installs a standard certificate issued by the payment agent upon registration, including among other things a private key to import into the PC browser.
  • a standard certificate issued by the payment agent upon registration, including among other things a private key to import into the PC browser.
  • CODE S personal code
  • CODE V validation code
  • the button to purchase an online transaction includes parameters signed by the seller site: the content of the transaction, the price, the seller code and consists of a link to a payment request to the proxy server.
  • the action on this button triggers an SSL link between the client station and the payment agent and the passage of the previous parameters. Switching to SSL mode causes access to the client certificate and therefore a request to enter the security code for local unlocking. If the code is correct, the connection is established and the proxy server authenticates the client.
  • the seller code passed in parameter is used to establish the relay to the correct IPSC (that of the seller) and to verify that this IPSC accepts the customer's payment method.
  • the security officer has several interfaces to simulate the exchanges of a client with the various IPSCs.
  • the parameters are simply passed on to the proxy server, which blocks relaying pending validation by mobile phone and by displaying a transaction number set by it on the client computer. For each purchase to be validated, this unique number identifies the transaction (seller, order, customer) and must be signed by the proxy server.
  • the mobile phone can be considered both as an order taking and payment initiation terminal.
  • the order is taken as on a PC type terminal. Detailed operation
  • the client registration with the proxy server (figure 2-b) is carried out in a strictly confidential manner: one can use an online registration with SSL for example or a registration at the counter.
  • a validation procedure by the operators of the proxy server may be requested. It must ensure that the information recorded at registration is valid.
  • the proxy server If the client has requested a registration for a fixed PC, the proxy server produces an electronic certificate based on public keys of type X509 issued with his private key to the client by messaging (10/2).
  • the certificate is encapsulated in a format that triggers auto-installation on the client PC.
  • the client When installing the certificate, the client is invited to define their code for protecting the CODE_S keys, known to them alone and used locally.
  • validation code CODE_V known only to him and the proxy server.
  • the data provided by the client and stored on the proxy server are: identity (name, first name) his card number - the usual delivery address optionally: mobile number - CODE V.
  • Validation of customer identity Depending on the rigor of the desired procedure, there can be manual or automatic validation, or simply no validation (acceptance of all registrations) except checks for non-re-registration. In particular, reuse controls on electronic messages and card numbers reduce the effects of re-registration.
  • Purchases are made by a simple hyperlink to the proxy server using the HTTP protocol, the transaction data being passed in parameters. These data are signed by the seller to guarantee integrity vis-à-vis the seller.
  • the payment request received at the proxy server makes it possible to authenticate the client with certainty, because the request in SSL mode comes from a fixed PC with certificate. In this case, the request is automatically validated and immediately relayed.
  • the proxy server If the request is sent from an anonymous PC, relaying is blocked on the proxy server awaiting validation by the mobile channel (the agent has not authenticated a client).
  • the proxy server requests the identity of the client and issues a unique transaction number signed by him for validation, which takes place in one of the 3 authorized modes.
  • the customer calls a fixed number, which puts him in communication with an interactive voice server; he is invited to enter the unique transaction number, displayed on the order taking screen; the server restores the description of the order by voice synthesis; if it is correct, the customer enters their validation code CODE_V.
  • the gateway sends an encrypted payment request signed by it containing: the transaction identifier and the CODE_V entered.
  • the client establishes a WAP / SSL connection to the validation service of the payment proxy server; the customer identifies himself by his first and last name then enters his validation code CODE_V 3.
  • WAP validation with WIM module (“WAP Identity Module")
  • the gateway can use a method of memorizing the customer identity by Cookie.
  • the Cookie is an ASCII clear record comprising the name, first name of the client signed by the proxy server.
  • This device was implemented on a server under Linux system with a front-end firewall under Linux, and an operational IPSC.
  • the system uses HTTPS for SSL exchanges between the client PC and the security agent.
  • the validation by mobile was carried out by a WAP terminal, according to the simple access mode. Authentication from the mobile phone takes place by surname first name, then introduction of the security code passed in SSL session.

Abstract

The invention concerns an Internet server acting as secure paying agent, that is relaying all payment requests to bank card payment systems requiring card number input. The client is registered once on the server by supplying among others his bank card number and by installing a standard X509 certificate on his terminal, protected by a security code known only to him. When purchasing from his initialised PC, the payment request is relayed to the agent server which authenticates the client through his X509 certificate, causing the security code to be requested on the client terminal. The client using such a secure system, accepts not to challenge a purchase carried out by the agent. A request made from an anonymous PC (that is non-initialised), is blocked until a secure validation procedure is carried out. Three validating procedures are proposed: 1) validation from a WAP mobile telephone; 2) validation from a normal mobile telephone; 3) validation for a WAP mobile telephone with WIM module.

Description

MANDATAIRE DE PAIEMENT SECURISE INTERNET AVEC VALIDATION PAR TELEPHONE MOBILESECURE INTERNET PAYMENT REPRESENTATIVE WITH VALIDATION BY MOBILE TELEPHONE
Problématique ciblée et Etat de l'artTargeted problem and state of the 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.One of the problems of payment on the Internet is to reduce the challenges of transactions made online, by implementing solutions guaranteeing security and non-repudiation by the customer.
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.In addition, existing secure solutions are essentially based on access by PC terminal. The development of the mobile market, creates new multi-terminal online shopping needs and having a single coherent system making it possible to pay for purchases in store from your PC, from an anonymous PC, or from your mobile phone would be a definite advantage.
Les solutions proposées aujourd'hui en termes de paiement en ligne depuis les PC avec navigateur utilisent l'un des moyens suivants :The solutions offered today in terms of online payment from PCs with browsers use one of the following means:
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),1. introduction of an auxiliary secure terminal with a bank card reader (system of the type proposed by CyberCOMM),
2. utilisation de certificats électroniques, comme SET2. use of electronic certificates, such as 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.3. transmission of the card number online over an encrypted link (eg using a protocol such as SSL using public cryptography of the Diffie-Helmann type) The first approach requires the installation of a specific terminal (screen, keyboard , processor) at the customer's site using the chip bank card like conventional purchase terminals. This plea is considered not to be repudiable.
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 œuvre 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.The second approach is based on non-standard certificates and is not strictly non-repudiable since it is based on software installed on very open workstations like clients' PCs. The third approach is the most used today because it does not require any installation on the part of the client, but it is this which triggers the most fraud because the card number is transmitted without client authentication. Having a bank card number (semi-confidential information) is enough to place orders on behalf of a person. A consistent bank card number generator can be used for this purpose. Secure payment solutions by bank card on the Internet based on the third approach, today use secure card payment intermediaries (rated IPSC). An IPSC provides the interface between the Internet and a network of bank cards.
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.Communication between the client and the bank intermediary uses one of the following principles: the card number is transmitted by the client for each exchange (Figure 1) the card number is stored on the client terminal and it is software that is responsible for carrying out the transaction with the seller's intermediary bank server, the client is registered with the IPSC, which keeps its card number and which interrogates the bank card network for each 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.Regarding mobile payment, the solutions offered remain limited to the management of the mobile operator's information system.
DéfinitionsDefinitions
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.By weakly non-repudiable is meant a transactional device which in normal use uses information known only to the client to sign the transaction and which can only be transmitted to an external host if the client performs an unauthorized operation, which can create a security hole like setting up a spy in his electronic signature system.
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 dispositifA weakly non-repudiable system, if the customer agrees not to operate certain operations and accepts the rules contractually, becomes non-repudiable by the customer. Objective of the device
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.The main objective of the system is to improve solutions of the systematic card number transmission type, making it possible to limit the risk of fraud to a negligible fraction of transactions by introducing the quality of "low non-repudiation". The second objective is to enable unified web / mobile phone transactions.
Description du dispositifDescription of the device
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 le 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.The proposed device uses an Internet server (8/2) acting as a customer-oriented payment agent and acting as an intermediary in exchanges between IPSC systems (6/2) and the client terminal (7/2). The proxy server can also make authorization requests to other payment systems. This device uses a weakly non-repudiable signature mechanism to authenticate payment requests from customers. Its originality is that it relies on multi-terminal access. We will distinguish 4 types of terminals: - the fixed PC (being assumed at home) the occasional PC, called anonymous PC (ex: public multimedia terminal) the simple mobile phone the WAP type mobile phone, with or without WIM module. When the order is taken on an anonymous terminal, the payment proxy server requires validation by a mobile phone terminal.
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é (CODE S) qui protège l'usage de son certificat un code de validation (CODE V) qui sera utilisé pour valider les transactions.In basic use, that is to say from a personal fixed PC, the client installs a standard certificate issued by the payment agent upon registration, including among other things a private key to import into the PC browser. When importing, the customer chooses: a personal code called security code (CODE S) which protects the use of his certificate a validation code (CODE V) which will be used to validate 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.The button to purchase an online transaction includes parameters signed by the seller site: the content of the transaction, the price, the seller code and consists of a link to a payment request to the proxy server. The action on this button triggers an SSL link between the client station and the payment agent and the passage of the previous parameters. Switching to SSL mode causes access to the client certificate and therefore a request to enter the security code for local unlocking. If the code is correct, the connection is established and the proxy server authenticates the 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.The seller code passed in parameter is used to establish the relay to the correct IPSC (that of the seller) and to verify that this IPSC accepts the customer's payment method. The security officer has several interfaces to simulate the exchanges of a client with the various IPSCs. When the customer intervenes on an anonymous terminal or at a merchant who enters online the order taking on his behalf, it has been initialized so as not to access the certificate. In this case, the parameters are simply passed on to the proxy server, which blocks relaying pending validation by mobile phone and by displaying a transaction number set by it on the client computer. For each purchase to be validated, this unique number identifies the transaction (seller, order, customer) and must be signed by the proxy server.
Trois cas de validation sont traités :Three validation cases are treated:
1. Cas du téléphone simple (figure 3) 2. Cas du téléphone WAP simple (figure 4)1. Simple phone case (Figure 3) 2. Simple WAP phone case (Figure 4)
3. Cas du téléphone WAP avec module WIM : authentification forte du client (figure 5)3. WAP phone case with WIM module: strong customer authentication (Figure 5)
Note :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éThe mobile phone can be considered both as an order taking and payment initiation terminal. The order is taken as on a PC type terminal. Detailed operation
Inscription /InstallationRegistration / 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.The client registration with the proxy server (figure 2-b) is carried out in a strictly confidential manner: one can use an online registration with SSL for example or a registration at the counter.
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.A validation procedure by the operators of the proxy server, may be requested. It must ensure that the information recorded at registration is valid.
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.If the client has requested a registration for a fixed PC, the proxy server produces an electronic certificate based on public keys of type X509 issued with his private key to the client by messaging (10/2). The certificate is encapsulated in a format that triggers auto-installation on the client PC. When installing the certificate, the client is invited to define their code for protecting the CODE_S keys, known to them alone and used locally.
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 CODE_V connu de lui seul et du serveur mandataire.If the customer has requested validation by mobile, he provides his mobile number and chooses another security code, called validation code CODE_V known only to him and the proxy server.
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 CODE V.The data provided by the client and stored on the proxy server are: identity (name, first name) his card number - the usual delivery address optionally: mobile number - CODE V.
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.Validation of customer identity Depending on the rigor of the desired procedure, there can be manual or automatic validation, or simply no validation (acceptance of all registrations) except checks for non-re-registration. In particular, reuse controls on electronic messages and card numbers reduce the effects of re-registration.
Transactions Depuis son PC initialiséTransactions From initialized PC
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.Purchases are made by a simple hyperlink to the proxy server using the HTTP protocol, the transaction data being passed in parameters. These data are signed by the seller to guarantee integrity vis-à-vis the seller.
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.The payment request received at the proxy server makes it possible to authenticate the client with certainty, because the request in SSL mode comes from a fixed PC with certificate. In this case, the request is automatically validated and immediately relayed.
Depuis un PC anonymeFrom an anonymous PC
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.If the request is sent from an anonymous PC, relaying is blocked on the proxy server awaiting validation by the mobile channel (the agent has not authenticated a client). The proxy server requests the identity of the client and issues a unique transaction number signed by him for validation, which takes place in one of the 3 authorized modes.
Validation 1. Validation par téléphoneValidation 1. Validation by 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 CODE_V. La passerelle envoie une requête de paiement chiffrée et signée par elle contenant : l'identificateur de transaction et le CODE_V introduit.The customer calls a fixed number, which puts him in communication with an interactive voice server; he is invited to enter the unique transaction number, displayed on the order taking screen; the server restores the description of the order by voice synthesis; if it is correct, the customer enters their validation code CODE_V. The gateway sends an encrypted payment request signed by it containing: the transaction identifier and the CODE_V entered.
2. Validation WAP simple :2. Simple WAP validation:
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 CODE_V 3. Validation WAP avec module WIM ("WAP Identity Module")In this case the client establishes a WAP / SSL connection to the validation service of the payment proxy server; the customer identifies himself by his first and last name then enters his validation code CODE_V 3. WAP validation with WIM module ("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.This case is identical in principle to case 2, except that the WAP terminal has an electronic signature capacity guaranteeing client authentication; in this case, the CODE_V is signed by the WIM module with the parameters of the transaction.
Note :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.In cases 2 and 3 (WAP validation), the gateway can use a method of memorizing the customer identity by Cookie. The Cookie is an ASCII clear record comprising the name, first name of the client signed by the proxy server.
Exemple d'implémentationExample of implementation
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é.This device was implemented on a server under Linux system with a front-end firewall under Linux, and an operational IPSC. The system uses HTTPS for SSL exchanges between the client PC and the security agent.
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. The validation by mobile was carried out by a WAP terminal, according to the simple access mode. Authentication from the mobile phone takes place by surname first name, then introduction of the security code passed in SSL session.

Claims

Revendications claims
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'il1. Mandatory device for secure online payments on the Internet in shops that use SSL encryption for the transmission of the card number without client authentication to a banking authorization server, characterized in that it
- 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- includes a means of customer registration allowing the card number to be transmitted to the proxy only once at registration, and this in a secure manner by SSL link
- 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.- intervenes during a purchase transaction in the exchanges between the client terminal and the interrogation server of the bank cards network of the shop, on the one hand by identifying and authenticating the client thanks to its own mechanism electronic signature, and on the other hand by transmitting the customer card number, stored in the customer registration, to the bank intermediary by the usual SSL link, without authentication of the agent by the bank intermediary.
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.2. Payment authorization device according to claims 1, characterized in that it uses for each client a standard X509 certificate generated on the proxy server for client registration and transmitted by messaging with the associated private key to be imported into the client browser, and then used to authenticate clients in HTTP links in payment transactions.
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. 3. Payment authorization device according to claims 1, characterized by the possible coupling to an auxiliary device allowing validation by the simple mobile phone or WAP, exploiting the authentication of the client by this auxiliary system and the use of a code. only known to the client and the proxy server.
PCT/FR2001/003072 2000-10-05 2001-10-05 Secure internet paying agent with mobile telephone validation WO2002029742A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001293955A AU2001293955A1 (en) 2000-10-05 2001-10-05 Secure internet paying agent with mobile telephone validation

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0012706A FR2815203A1 (en) 2000-10-05 2000-10-05 INTERNET SECURE PAYMENT AGENT WITH MOBILE PHONE VALIDATION
FR0012706 2000-10-05

Publications (1)

Publication Number Publication Date
WO2002029742A1 true WO2002029742A1 (en) 2002-04-11

Family

ID=8855016

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2001/003072 WO2002029742A1 (en) 2000-10-05 2001-10-05 Secure internet paying agent with mobile telephone validation

Country Status (3)

Country Link
AU (1) AU2001293955A1 (en)
FR (1) FR2815203A1 (en)
WO (1) WO2002029742A1 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1587238A1 (en) * 2004-04-16 2005-10-19 Sagem S.A. Method for verifying in a radio terminal the authenticity of digital certificates and authentification system
WO2006126834A3 (en) * 2005-05-27 2007-12-27 Lg Electronics Inc Method of certificating message, terminal thereof and system thereof
CN101938520A (en) * 2010-09-07 2011-01-05 中兴通讯股份有限公司 Mobile terminal signature-based remote payment system and method
CN103368978A (en) * 2013-08-02 2013-10-23 公安部第三研究所 System and method for achieving leak application and communication safety detection of smart mobile terminal
WO2014146286A1 (en) * 2013-03-22 2014-09-25 Wong Hoiling Secure payment system and method for bank card by using real-time communication
CN105376059A (en) * 2014-08-15 2016-03-02 中国电信股份有限公司 Method and system for performing application signature based on electronic key

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1831865B (en) * 2006-04-24 2010-09-29 北京易恒信认证科技有限公司 Electronic bank safety authorization system and method based on CPK

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999014711A2 (en) * 1997-09-17 1999-03-25 Andrasev Akos Method for checking rightful use of a debit card or similar means giving right of disposing of a bank account
US6014650A (en) * 1997-08-19 2000-01-11 Zampese; David Purchase management system and method
US6026166A (en) * 1997-10-20 2000-02-15 Cryptoworx Corporation Digitally certifying a user identity and a computer system in combination
EP1028401A2 (en) * 1999-02-12 2000-08-16 Citibank, N.A. Method and system for performing a bankcard transaction

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6014650A (en) * 1997-08-19 2000-01-11 Zampese; David Purchase management system and method
WO1999014711A2 (en) * 1997-09-17 1999-03-25 Andrasev Akos Method for checking rightful use of a debit card or similar means giving right of disposing of a bank account
US6026166A (en) * 1997-10-20 2000-02-15 Cryptoworx Corporation Digitally certifying a user identity and a computer system in combination
EP1028401A2 (en) * 1999-02-12 2000-08-16 Citibank, N.A. Method and system for performing a bankcard transaction

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
VAN THANH D: "Security issues in mobile ecommerce", DATABASE & EXPERT SYSTEMS APPLICATIONS, DEXA,WIEN,AT, 4 September 2000 (2000-09-04), pages 412 - 425, XP002158270 *

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1587238A1 (en) * 2004-04-16 2005-10-19 Sagem S.A. Method for verifying in a radio terminal the authenticity of digital certificates and authentification system
FR2869176A1 (en) * 2004-04-16 2005-10-21 Sagem METHOD OF VERIFYING IN A RADIO TERMINAL THE AUTHENTICITY OF DIGITAL CERTIFICATES AND AUTHENTICATION SYSTEM
WO2006126834A3 (en) * 2005-05-27 2007-12-27 Lg Electronics Inc Method of certificating message, terminal thereof and system thereof
CN101938520A (en) * 2010-09-07 2011-01-05 中兴通讯股份有限公司 Mobile terminal signature-based remote payment system and method
CN101938520B (en) * 2010-09-07 2015-01-28 中兴通讯股份有限公司 Mobile terminal signature-based remote payment system and method
WO2014146286A1 (en) * 2013-03-22 2014-09-25 Wong Hoiling Secure payment system and method for bank card by using real-time communication
CN103368978A (en) * 2013-08-02 2013-10-23 公安部第三研究所 System and method for achieving leak application and communication safety detection of smart mobile terminal
CN103368978B (en) * 2013-08-02 2016-06-08 公安部第三研究所 Realize intelligent mobile terminal application leak and the method for communication security detection
CN105376059A (en) * 2014-08-15 2016-03-02 中国电信股份有限公司 Method and system for performing application signature based on electronic key
CN105376059B (en) * 2014-08-15 2019-04-02 中国电信股份有限公司 The method and system of application signature is carried out based on electron key

Also Published As

Publication number Publication date
AU2001293955A1 (en) 2002-04-15
FR2815203A1 (en) 2002-04-12

Similar Documents

Publication Publication Date Title
EP1153376B1 (en) Telepayment method and system for implementing said method
JP5216594B2 (en) Authentication method for service server on wireless internet and settlement method using the same
EP2139218A1 (en) Method and system for managing a purchase decision taken by a purchaser using a mobile radiotelephone
FR2820853A1 (en) TELEPAYING METHOD AND SYSTEM
EP1815638A1 (en) Method of securing a telecommunication terminal that is connected to terminal user identification module
WO2002082388A1 (en) Secure data exchange device
FR2809260A1 (en) Method for crediting a prepaid account through a telecommunication network, uses information on banking card stored in mobile telephone SIM which is sent to a prepaid account management system
WO2002029742A1 (en) Secure internet paying agent with mobile telephone validation
WO2001041093A1 (en) A system and method for conducting a financial transaction
EP1323140B1 (en) Method for providing identification data of a banking card to a user
KR20020010160A (en) System & Method for Wireless Electronic Commerce Payment service
EP1490851A1 (en) Method and system of securing a credit card payment
EP1354288B1 (en) Method using electronic banking cards for making secure transactions
AU2003274257A1 (en) Method and system for the secure transmission of a confidential code through a telecommunication network
KR100822942B1 (en) System for newly Processing Financial Goods
FR2850772A1 (en) Electronic transaction securing device for use in electronic commerce, has analyzing unit to retransmit intercepted signals to processing unit without modification if they are not in order of passage in secured mode
FR2807247A1 (en) PAYMENT SYSTEM FOR NOT DISCLOSING BANKING INFORMATION ON THE PUBLIC AND QUASI-PUBLIC NETWORK
FR2828966A1 (en) Secure communication of identification data for a limited use Internet transaction payment card, splits data into distinct packets and transmits each packet over distinct networks
EP4014466A1 (en) Method for transmitting digital information
CA2204547A1 (en) A method for providing full end to end secure transactional payment services and electronic fund transfer over any unsecured and unreliable network
WO2002052517A1 (en) Payment method and system and telecommunication equipment used in said system
FR2850813A1 (en) Electronic transaction securing device for use in electronic commerce, has analyzing unit to analyze intercepted signals from control, and quantifying unit retransmitting information quantified in secured mode to telephone
FR2790122A1 (en) Device permitting processing of information contained in payment card and to transmit data to electronic commercial site; uses magnetically recorded data, bar codes etc
KR20090081744A (en) Method for Processing Affiliated Store Online Account Synchronous and Recording Medium
ZA200205258B (en) A system and method for conducting a financial transaction.

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PH PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP