(51) Int Cl.: G06Q 20/00 ( ) G06F 21/00 ( )

Transcription

1 (19) (12) EUROPEAN PATENT SPECIFICATION (11) EP B1 (4) Date of publication and mention of the grant of the patent: Bulletin /2 (21) Application number: (22) Date of filing: (1) Int Cl.: G06Q /00 (06.01) G06F 21/00 (06.01) (86) International application number: PCT/US00/ (87) International publication number: WO 01/ ( Gazette 01/26) (4) METHOD AND SYSTEM FOR SECURE AUTHENTICATED PAYMENT ON A COMPUTER NETWORK VERFAHREN UND SYSTEM ZUM SICHEREN, AUTHENTIFIZIERTEN BEZAHLEN IN EINEM COMPUTERNETZWERK PROCEDE ET SYSTEME POUR L EXECUTION AUTHENTIFIEE DE PAIEMENTS SECURISES SUR UN RESEAU INFORMATIQUE (84) Designated Contracting States: AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE () Priority: US (43) Date of publication of application: Bulletin 02/ (73) Proprietor: Arcot Systems, Inc. Santa Clara, CA 904 (US) (72) Inventor: KAUSIK, Balas, Natarajan Los Gatos, CA 90 (US) (74) Representative: Robson, Aidan John Reddie & Grose 16 Theobalds Road London WC1X 8PL (GB) (6) References cited: EP-A WO-A-99/21321 GB-A US-A US-A US-A US-A US-A US-A EP B1 Note: Within nine months of the publication of the mention of the grant of the European patent in the European Patent Bulletin, any person may give notice to the European Patent Office of opposition to that patent, in accordance with the Implementing Regulations. Notice of opposition shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention). Printed by Jouve, 7001 PARIS (FR)

2 1 EP B1 2 Description FIELD OF THE INVENTION [0001] The present invention relates to a method and system for secure authenticated payment at a point-ofsale on a computer network. More particularly, the present invention does not necessarily require any changes in the transaction processing of the financial institutions participating in the transaction. BACKGROUND OF THE INVENTION [0002] In present electronic commerce transactions, buyers may pay for goods and services by presenting the seller with a payment card number, e. g., a conventional credit card number. Because the buyer and seller are connected solely through a computer network (e. g., the Internet), it is not possible for the buyer to authenticate himself as the legitimate cardholder, nor can the buyer sign the sales draft. Thus, the seller honors any valid credit card number that is presented, creating a large opportunity for fraud. [0003] Worse yet, other forms of payment such as debit cards are not presently viable on computer networks. Debit cards require the cardholder to enter a personal identification number ("PIN"), which is used to authenticate the transaction to the cardholder s bank. [0004] However, entering a simple PIN on a networked computer poses a substantial security risk-if the PIN and the debit-card number fell into the wrong hands, the cardholder s bank account would be completely compromised. [000] Thus, with respect to both conventional credit and debit cards, authenticating a cardholder on the network with a solution that is simple, secure, and easy to deploy remains an important unsolved problem. [0006] Digital signature technology offers one means of authenticating the cardholder with a high degree of security. In this technology, each cardholder owns a pair of keys-a signature (private) key and a verification (public) key. The cardholder signs a transaction with his private key, and then sends the transaction, the digital signature, and (optionally) his public key to the merchant. The merchant forwards these items to the bank (or other financial institution), and the bank honors the transaction if the cardholder s public key verifies the cardholder s digital signature. [0007] One security advantage of digital signatures is that the private key of the cardholder typically remains in possession (or at least control) of the cardholder. Thus, there is no inherent risk associated with a transaction that would compromise future transactions. [0008] One disadvantage of the digital signature method described above is that banks and transaction processors would have to change their existing infrastructure to allow digital signatures to flow through their networks. This infrastructure change would basically require a substantial overhaul of the present electronic banking and transaction processing system, which is costly and difficult to achieve. [0009] Thus, there is a need for a method and system that offers the security advantages of digital signatures without necessarily requiring significant changes in the banking and processing network. [00] United Kingdom Patent Application GB describes a method of performing an on-line transaction using card information and a PIN, in which the card information is encrypted and digitally signed on a user s PC and sent to a merchant. The merchant then appends merchant instructions and digitally signs the merchant instructions and sends them direct to a financial institution. The public key is extracted from the digital certificate and used to verify the digital signature containing the financial information so that the recipient of the digital signature can verify that the financial information originated from the user. [0011] United States Patent No.,90,197 describes an electronic payment system and method which uses a cyber wallet in the form of stored and protected account information which can be stored on a user s computer. A public key is used to encrypt information needed by an account service or financial institution to authorize a transaction in the form of an authorization ticket. A private key is used by the account service to decrypt the authorization ticket. The merchant receives the authorization ticket and imbeds additional information regarding the transaction needed by the merchant. SUMMARY OF THE INVENTION [0012] The invention in its various aspects is defined in the independent claims below, to which reference should now be made. Advantageous features are set forth in the appendant claims. [0013] One embodiment of the present invention includes a simple, secure and easy-to deploy method and system for authenticating credit and/or debit cardholders at a point-of sale on a computer network (e.g., the Internet). Cardholders are authenticated using digital signatures on a sales draft, in a manner that does not necessarily require any changes in the transaction process of the financial institutions participating in the transaction. [0014] In this embodiment of the system, the cardholder enrolls for an electronic payment card (either an electronic debit or credit card) at a participating financial institution by visiting its issuer proxy enrollment site, e.g., a web site hosted by an issuer proxy computer associated with the financial institution. At the enrollment site, the cardholder types in his particulars, such as his conventional payment card number, conventional payment card PIN, name, address, etc. The cardholder also (optionally) selects a password (access code) for his electronic payment card that is preferably unrelated to the PIN for his conventional payment card. The issuer proxy generates a public key-private key pair for use by the cardholder if 2

3 3 EP B1 4 the cardholder does not already have such a pair. The issuer proxy binds the cardholder s public key and some or all of the cardholder s payment particulars in a digital certificate using an encryption key (called a domain key) that is shared between the issuer proxy and a bridge computer. Such a domain key will allow the bridge computer to confirm the issuer s certification during a subsequent authorization stage, described below. The cardholder then receives a piece of software that is downloaded to his computer containing his particulars in encrypted form. This piece of software constitutes the cardholder s electronic payment card. It comprises (or is configured to obtain and use) the cardholder s private key, which is (optionally) protected by the password, and the corresponding public-key digital certificate containing the cardholder s payment particulars. [00] Thenceforth, as the cardholder shops online, he can elect to pay via electronic payment. To do so, the cardholder activates his electronic payment card with the previously selected password. The cardholder s electronic payment card software interacts with corresponding software at the online merchant to digitally sign the sales draft created during the transaction with the cardholder s private key. The merchant then sends the signed sales draft and the cardholder s digital certificate to the bridge computer for processing. The bridge computer uses the cardholder s digital certificate to check the digital signature on the sales draft. If the signature is valid, the bridge computer creates a conventional debit or credit transaction to be processed by the banking and transaction network. The particulars needed for creating the conventional transaction, such as the conventional card number and PIN, are extracted and decrypted from the cardholder s digital certificate using the private key associated with the domain key (if the digital certificate was asymmetrically encrypted) or the domain key itself (if the digital certificate was symmetrically encrypted). The embodiment of the invention described above provides one or more or the following advantages: (1) Additional hardware at the cardholder s computer is not necessarily required for deployment. This is in marked contrast to hardware tokens such as smart cards, where cards and card readers are required. Of course, the software comprising the cardholder s electronic payment card can be stored on smart cards, as well as virtually any other storage medium, including, without limitation, floppy disks, hard drives, and magnetic stripe cards; (2) Changes are not necessarily required in the existing banking network; (3) Administrative overhead is low. The cardholder can enroll at any participating financial institution that offers the service, not necessarily the one that issued the cardholder s conventional payment card. Furthermore, enrollment can be on a self-serve basis and does not necessarily require activation mailings by the financial institutions; (4) Electronic payment cards can be deployed rapidly, because they are intuitive to use and require little user or administrator training; and/or () Security can be enhanced via special techniques such as "cryptographic camouflaging," which is commercially available from Arcot Systems, Inc. [0016] The foregoing and other embodiments and aspects of the present invention will become apparent to those skilled in the art in view of the subsequent detailed description of the invention taken together with the accompanying figures and appended claims. BRIEF DESCRIPTION OF THE DRAWINGS [0017] FIG. 1 is a block diagram illustrating an exemplary computer system for secure authenticated payment on a computer network. FIG. 2 is a flow chart illustrating an exemplary method for cardholder enrollment for an electronic payment card. FIG. 2A illustrates an exemplary electronic payment card created using the preferred embodiment of the invention. FIG. 3 is a flow chart illustrating an exemplary method for point-of-sale interaction between a cardholder and a merchant. FIG. 4 is a flow chart illustrating an exemplary method for a merchant to obtain authorization for the payment transaction. DETAILED DESCRIPTION OF THE INVENTION [0018] FIG. 1 is a block diagram illustrating an exemplary computer system for secure authenticated payment on a computer network (e.g., the Internet). The system contemplates a network of computers including a cardholder s computer 0, a payment card issuer s proxy computer 1, a merchant s computer 1, a bridge computer 1, a payment gateway computer 1, and legacy backend computer 0. In this exemplary embodiment, the network is deployed over the Internet, although those skilled in the art will recognize that any public or private communication network including, without limitation, extranets, intranets, and other telephonic or radio communications networks could also be used. Similarly, as used herein, the term computer refers to any device that processes information using an integrated circuit chip, including without limitation mainframe computers, work stations, servers, desktop computers, portable computers, embedded computers, and hand-held computers. Enrollment [0019] Referring now to FIG. 2, at step 0, a cardholder (user) at computer 0 enrolls for an electronic 3

4 EP B payment card (either an electronic debit card or an electronic credit card) at the electronic payment card issuer proxy 1, typically by visiting the website of a participating financial institution on the Internet. At step 2, the cardholder provides the issuer 1 with particular information used to make a payment (payment particulars), such as his conventional payment card number, conventional payment card PIN, conventional credit card holder verification value 2 ("CVV2"), conventional cardholder name and address, or any other cardholder identification information. The issuer proxy 1 can be operated by any trusted financial institution that participates in the electronic payment system, not necessarily the financial institution that issued the cardholder s conventional payment card. [00] The issuer proxy 1 can optionally verify the cardholder s payment information by any of the means available for such verification including, without limitation, creating a payment transaction in the conventional payment network. Such a transaction could be "authorization only" in the sense that it would be used only for verifying the cardholder s payment particulars, with no money actually transferred. [0021] At step 2, the issuer 1 generates a public key-private key pair for the cardholder to use in connection with the electronic payment system. If the cardholder already has a public key-private key pair that he wishes to use in connection with the electronic payment system, he provides his public key to the issuer 1. The cardholder s private key is typically stored on the cardholder s computer 0, often under the control of a PIN or other form of access code (password). The access code can be protected against unauthorized detection using commercially available software technology such as software smart cards from Arcot Systems, Inc., described in "Software Smart Cards via Cryptographic Camouflage," Proceedings IEEE Symposium on Security and Privacy, May 1999, and in US patent number 6,170,08 "Method and Apparatus for Secure Cryptographic Key Storage Certification and Use". [0022] The access code may also be protected against unauthorized detection (e.g., so-called "shoulder surfing") using the technology described in US patent number 6,9,2 "Method and Apparatus for Secure Entry of Access Codes in a Computer Environment". [0023] At step 2, the issuer 1 binds the cardholder s public key and some or all of the cardholder s payment particulars in a digital certificate, typically by encrypting the cardholder s public key and particular identifying information provided by the cardholder. The encryption key used for encrypting the cardholder s payment particulars - called the domain key - is typically shared between the issuer proxy 1 and the bridge computer 1, and may be either a symmetric key or an asymmetric encryption key. In one embodiment, the domain key may be a public key associated with the bridge computer 1, so that only the bridge computer 1 can decrypt the encrypted cardholder particulars (using a corresponding private key associated with the bridge computer 1). In another embodiment, the domain key may be a symmetric encryption key that is shared by the issuer proxy 1 and the bridge computer 1. In either case, the bridge computer will use the domain key (actually, its private key counterpart, if asymmetric; or the domain key itself, if symmetric) to verify the binding, as will be described later in the section entitled "Authorization." After the issue r proxy 1 combines the cardholder s public key with some or all of the cardholder s payment information and digitally signs the combination to create a digital certificate for the cardholder, the digital certificate for the cardholder is loaded into an electronic payment card for the cardholder. Of course, those skilled in the art will realize that many other types of binding can be used including, without limitation, offloading the signing to a trusted third party, or receiving (rather than creating) the digital certificate from the user (although such binding is less secure). [0024] At step 2, the issuer 1 sends and the cardholder s computer 0 receives the cardholder s electronic payment card, e.g., a piece of software that is downloaded to the cardholder s computer 0. The electronic payment card (typically stored in a software wallet) may be further protected against unauthorized access via a PIN (preferably different from the PIN associated with the cardholder s conventional payment card) or other form of user access code. The access code may be protected against unauthorized detection by the abovementioned procedures used to protect the private key PIN. (Indeed, if the two PINs are the same, private key access for digitally signing and electronic payment card access for transaction execution could be accessed via a single protocol.) Setting the access code (PIN) for the electronic payment card is preferably done when the electronic payment card is being created by the issuer 1, but can also be done separately, e.g., when the cardholder first accesses his electronic payment card on the cardholder computer 0. [002] Alternatively, if the cardholder wishes to be able to perform electronic transactions from a variety of locations, the cardholder s private key and/or electronic payment card may be stored at a credential server and downloaded on the fly by a roaming cardholder using a shared secret or challenge-response protocol. In the latter case, commercially available software such as Arcot WebFort from Arcot Systems, Ins., described at and in U.S. patent number 6,263,446 "Method and Apparatus for Secure Distribution of Authentication Credentials to Roaming Users" may be used to effect the roaming functionality. [0026] One advantage of this enrollment process is that the issuer s participation can be passive, in that the issuer proxy 1 can be operated by any trusted financial institution that participates in the electronic payment system, and is not necessarily the bank or financial institution that issued the conventional payment card to the cardholder. This is important because it suffices that one well- 4

5 7 EP B1 8 recognized financial institution participates in the system. Furthermore, even the participation of this financial institution can be limited to establishing the issuer proxy 1 on the network for self-service access by the cardholder, and does not require mailings to the cardholder, or other physical interaction with the cardholder. [0027] FIG. 2A illustrates an exemplary electronic payment card created using the preferred embodiment of the invention, in which the card contains: (a) the cardholder s digital certificate, comprising the cardholder s payment particulars, and his public key, portions of which are encrypted under the domain key; and (b) the cardholder s private key. Point-of-sale Transaction between a Cardholder and a Merchant on the Computer Network [0028] A cardholder uses his computer 0 to shop at a merchant s website at merchant s computer 1. Referring now to FIG. 3, at step 0, when the cardholder decides what goods or services he wants to buy, the merchant presents the cardholder with an electronic sales draft. [0029] At step 3, the cardholder elects to pay the sales draft using the cardholder s electronic payment card. At step 3, a representation of the cardholder s electronic payment card may be displayed on the cardholder s computer 0. If the cardholder chose to protect his electronic payment card with an access code, then at step 3 the cardholder unlocks and activates his electronic payment card. If the electronic payment card is protected with an access code, then the electronic payment card cannot be activated unless the correct access code is entered. The access code can be stored in a variety of locations including, without limitation, the cardholder s own memory, or a floppy disk, magnetic stripe card, smart card, or disk drive coupled to the cardholder s computer 0. At step 3, the cardholder s (activated) electronic payment card digitally signs the electronic sales draft that was presented to the cardholder in step 0 using the cardholder s private key. Optionally, the cardholder s electronic payment card can automatically fill in the information used by the sales draft. At step, the cardholder s computer 0 sends the digitally signed sales draft and the cardholder s digital certificate to the merchant s computer 1, where it is received by the merchant s computer 1. Authorization [00] Referring now to FIG. 4, at step 0, the merchant s computer 1 sends, and the bridge computer 1 receives, an authorization request from the merchant (seller). The authorization request includes the electronic sales draft with the cardholder s (buyer s) electronic signature and the cardholder s digital certificate. As mentioned above, in one embodiment of the invention, the cardholder s digital certificate includes the cardholder s verification key (public key) and an encrypted version of the cardholder s PIN for his conventional payment card. [0031] At step 4, the bridge computer 1 uses the cardholder s verification key to confirm (verify) that the cardholder s electronic signature on the sales draft was authorized by the cardholder (buyer). If the electronic signature is confirmed, then at step 4 the bridge computer 1 extracts the encrypted version of the cardholder s PIN for his conventional payment card from the cardholder s digital certificate and decrypts the PIN using the private key associated with the domain key (if the PIN was asymmetrically encrypted) or the domain key itself (if the PIN was symmetrically encrypted). In this (or in some equivalent) fashion, the bridge computer 1 can verify the binding (of the payment particulars and the user s public key) that was performed by the issuer 1. The bridge computer 1 uses the decrypted PIN to generate a conventional authorization request as is well-known to those skilled in the art of payment card transaction processing (see, e.g., Visa International Acquirer Services External Interface Specification, April , EIS 80 Version.8, available from Visa). The decrypted PIN may be re-encrypted with a key that is shared by the bridge computer 1 and the transaction processor at payment gateway 1. Certain other particulars that are typically used for creating a conventional authorization request, such as the conventional payment card number, conventional credit card holder verification value 2 ("CVV2"), conventional cardholder name and address, or any other cardholder identification information, may also be extracted and decrypted from the cardholder s digital certificate. [0032] Note that some types of conventional payment transactions do not necessarily use PINs, e.g., some conventional credit card transactions. For these transactions, after the bridge computer 1 verifies the cardholder s digital signature on the sales draft at step 4, the bridge computer 1 generates a conventional authorization request at step 4 without performing the PIN extraction and PIN decryption steps. [0033] At step 4, the bridge computer 1 sends the conventional authorization request to the transaction processor at payment gateway 1. Using the information provided in the authorization request, the payment gateway 1 approves or denies the request and sends its authorization response back to the bridge computer 1. [0034] In an alternative embodiment of the invention, the bridge computer 1 can be integrated into the payment gateway 1. Indeed, any combination of issuer proxy 1, bridge computer 1, and/or payment gateway 1 can be integrated together. [003] The bridge computer 1 receives from the payment gateway 1 either an approval or a disapproval of the authorization request. In either event, at step 4, the bridge computer 1 forwards the authorization response (approval or disapproval) to the merchant (seller) at the merchant s computer 1.

6 9 EP B1 [0036] If the cardholder is making a debit transaction, then at step the merchant s computer 1 sends a confirmation to the payment gateway 1 via the bridge computer 1. [0037] One advantage of this authorization process is that there is minimal impact on the merchant. Another advantage is that the payment gateway 1 can interact with the legacy back-end systems 0 using conventional transaction processing methods. In other words, no changes are necessarily required to the back-end infrastructure. [0038] In an alternate embodiment of the system, the bridge computer 1 can act in "stand-in" mode. Specifically, some financial institutions may choose not to receive the decrypted PIN from the cardholder s digital certificate, relying instead on the bridge computer s assertion that the cardholder s signature verified correctly. If the cardholder PIN was also verified at the issuer proxy 1 during enrollment, the risk of a fraudulent transaction may be deemed low. In such situations, the bridge computer 1 would assemble and transmit an authorization request without a PIN to the transaction processor at payment gateway 1. [0039] In yet another embodiment of the system, the merchant can store a copy of the digital signature of the cardholder along with the sales draft. The bridge computer 1 would process the transaction assuming that the digital signature of the cardholder is valid. In the event that the cardholder disputes the transaction, the merchant must present the stored copy of the sales draft and the cardholder s digital signature. The bridge computer 1 will verify the digital signature and, on the basis of the verification, determine whether the merchant should refund the amount of the transaction. An advantage of this embodiment is that the computational processing required at the bridge computer 1 is reduced. However, the merchant faces an increased risk of fraud. [00] In yet another embodiment of the system, a user who does not have a conventional credit or debit card (or who wants to get additional conventional payment cards), can be given the option of signing up for a conventional payment card during the electronic payment card enrollment process. The conventional payment card number that is given to this user can then be incorporated into the user s electronic payment card. In yet another embodiment of the system, a user may choose to enroll his checking account to an electronic payment credential, rather than a debit or credit card. The user would identify himself via a variety of means at enrollment time, or may be given an activation code by his bank that he would use to identify himself for enrollment. [0041] Although the preferred embodiments of this invention create an electronic payment card for conventional debit or credit cards or conventional checking accounts, the present invention enables a bridge to network payment for almost any conventional transaction system. For example, the present invention could also be used for secure electronic bill payment, person-to-person transactions, and electronic auction settlements. The software described herein, for use by the various computers, is conveniently implemented using C, C++, Java, Javascript, HTML, or XML, running on Windows, Windows NT, Solaris, Unix, Linux, or Macintosh operating systems on virtually any computer platform. Moreover, those skilled in the art will readily appreciate that such software can be implemented using virtually any programming language, running on virtually any operating system on any computer platform. [0042] The various embodiments described above should be considered as merely illustrative of the present invention. They are not intended to be exhaustive or to limit the invention to the forms disclosed. Those skilled in the art will readily appreciate that still other variations and modifications may be practiced. Therefore, it is intended that the present invention be defined by the claims that follow. Claims 1. A method of authenticating an electronic payment over a computer network which comprises a user computer (0), a merchant computer (1), an issuer computer (1), a transaction processor computer (1), and a financial institution computer (1); at least the user computer and the merchant computer being located at different locations from the issuer computer, transaction processor computer, and financial institution computer; the method comprising the steps of: (1) at the issuer computer (1): (a) obtaining financial account data associated with a user; (b) obtaining a public key associated with the user; (c) creating a digital certificate by cryptographically-assured binding the user s public key to at least a portion of the user s financial account data using a cryptographic verification key shared between the issuer computer (1) and the transaction processing computer (1); and (d) transmitting the digital certificate to the user; (2) at the user computer (0): (a) receiving the digital certificate from the issuer computer (1); (b) obtaining a private key associated with the user and corresponding with the user s public key; and then (c) conducting an electronic transaction with 6

7 11 EP B1 12 the merchant computer (1) involving the financial account data, the electronic transaction comprising: (i) receiving a transaction order from the merchant computer; (ii) digitally signing the transaction order with the user s private key; and (iii) transmitting the digitally-signed transaction order with the digital certificate to the merchant computer; (3) at the merchant computer (1): (a) transmitting the transaction order to the user computer (0) for receipt by the user computer as step (2)(c)(i) above; (b) receiving from the user computer the digitally-signed transaction order with the digital certificate; (c) passing through the digitally-signed transaction order and the digital certificate to the transaction processor computer (1); (4) at the transaction processor computer (1): 2 by the transaction processor computer as step (4)(f) above. 2. The method of claim 1, wherein the financial account data includes a personal identification number (PIN) and the digital certificate includes an encrypted version of the personal identification number. 3. The method of claim 2, wherein the step of verifying the binding in the digital certificate includes extracting the encrypted version of the PIN from the digital certificate and decrypting the encrypted version of the PIN using the verification key or a key associated with the verification key. 4. The method of claim 3, wherein the authorization request includes the decrypted PIN.. The method of any of claims 1 to 4, wherein the financial account data includes a card verification value The method of any of claims 1 to, wherein the merchant computer (1) transmits the digital certificate to the transaction processor computer (1) only when requested to do so. (a) receiving from the merchant computer (1) the digitally signed transaction order and the digital certificate; (b) verifying the binding in the digital certificate using the cryptographic verification key or a key associated with the cryptographic verification key, thereby verifying that the user s public key was bound using the cryptographic verification key shared between the issuer computer (1) and the transaction processing computer (1); (c) verifying the transaction order using the user s public key; (d) generating an authorization request on the basis of the verified transaction order; (e) transmitting the authorization request to the financial institution computer (1); (f) receiving any approval of the authorization request from the financial institution computer; and (g) sending the approval to the merchant computer to complete the transaction; and () at the financial institution computer (1) (a) receiving the authorization request from the transaction processor computer (1); (b) determining approval or non-approval of the authorization request; (c) transmitting at least any approval to the transaction processor computer for receipt The method of any of claims 1 to 6, wherein the step of verifying the binding in the digital certificate is performed with an asymmetric key corresponding to the cryptographic verification key. 8. The method of any of claims 1 to 7, wherein the user s public key used in the step of verifying the transaction order is obtained by the transaction processor computer (1) in the step of verifying the binding in the digital certificate. 9. Apparatus for use as issuer computer (1) in accordance with the method of claim 1, the apparatus comprising: (a) a processor; (b) a memory connected to the processor for storing a program to control the operation of the processor; (c) the processor being operable with the program in the memory to execute the steps of: (i) obtaining financial account data associated with a user; (ii) obtaining a public key associated with the user; (iii) creating a digital certificate by cryptographically-assured binding the user s public key to at least a portion of the user s financial account data using a cryptographic verification key shared between the issuer 7

8 13 EP B1 14 computer (1) and a transaction processing computer (1); and (iv) transmitting the digital certificate to the user; whereby the user can conduct an electronic transaction involving the financial account data with a merchant computer (1) in which the digital certificate is transmitted to the merchant computer and thence to the transaction processor computer (1) which can verify the binding in the digital certificate using the cryptographic verification key or a key associated with the cryptographic verification key, thereby verifying that the user s public key was bound using the cryptographic verification key shared between the issuer computer (1) and the transaction processing computer (1).. The apparatus of claim 9, wherein the financial account data includes a personal identification number (PIN) and the digital certificate includes an encrypted version of the personal identification number. 11. The apparatus of claim 9 or, wherein the financial account data includes a card verification value The apparatus of claims 9, or 11, wherein the binding is performed with a cryptographic verification key that is an asymmetric key. 13. Apparatus for use as transaction processor computer (1) in accordance with the method of claim 1, the apparatus comprising: (a) a processor; (b) a memory connected to the processor for storing a program to control the operation of the processor; (c) the processor being operable with the program in the memory to execute the steps of: (i) receiving from a merchant computer (1) a digitally signed transaction order and a digital certificate, the digital certificate including a binding between at least a portion of the user s financial account data and the user s public key formed using a cryptographic verification key shared between an issuer computer (1) and the transaction processing computer (1); (ii) verifying the binding in the digital certificate using the cryptographic verification key or a key associated with the cryptographic verification key, thereby verifying that the user s public key was bound using the cryptographic verification key shared between the issuer computer (1) and the transaction processing computer (1); (iii) verifying the transaction order using the user s public key; (iv) generating an authorization request on the basis of the verified transaction order; and (v) transmitting the authorisation request to a financial institution computer (1). 14. The apparatus of claim 13, wherein the financial account data includes a personal identification number (PIN) and the digital certificate includes an encrypted version of the personal identification number.. The apparatus of claim 14, wherein the binding in the digital certificate is verified by extracting the encrypted version of the PIN from the digital certificate and decrypting the encrypted version of the PIN using the verification key or a key associated with the verification key. 16. The apparatus of claim, wherein the authorization request includes the decrypted PIN. 17. The apparatus of any of claims 13 to 16, wherein the financial account data includes a card verification value The apparatus of any of claims 13 to 17, wherein the transaction processor computer (1) only receives the digital certificate when it requests it. 19. The apparatus of any of claims 13 to 18, wherein the verification of the binding in the digital certificate is performed with an asymmetric key corresponding to the cryptographic verification key.. The apparatus of any of claims 13 to 19, wherein the user s public key used in the verifying of the transaction order is obtained in the verification of the binding in the digital certificate. 21. A computer program for use in the apparatus for use as issuer computer (1) according to claim 9 for directing the issuer computer (1) to perform the steps of: (i) obtaining financial account data regarding a user; (ii) obtaining a public key associated with the user; (iii) creating a digital certificate by cryptographically-assured binding the user s public key to at least a portion of the user s financial account data using a cryptographic verification key shared between the issuer computer (1) and a transaction processing computer (1); and (iv) transmitting the digital certificate to the user; 8

9 EP B1 16 whereby the user can conduct an electronic transaction involving the financial account data with a merchant computer (1) in which the digital certificate is transmitted to the merchant computer and thence to the transaction processor computer (1) which can verify the binding in the digital certificate using the cryptographic verification key or a key associated with the cryptographic verification key, thereby verifying that the user s public key was bound using the cryptographic verification key shared between the issuer computer (1) and the transaction processing computer (1). 22. A computer program for use in the apparatus for use as transaction processor computer (1) according to claim 13 for directing the transaction processor computer (1) to perform the steps of: (i) receiving from a merchant computer (1) a digitally-signed transaction order and a digital certificate, the digital certificate including a binding between at least a portion of a user s financial account data and the user s public key formed using a cryptographic verification key shared between an issuer computer (1) and the transaction processing computer (1); (ii) verifying the binding in the digital certificate using the cryptographic verification key or a key associated with the cryptographic verification key, thereby verifying that the user s public key was bound using the cryptographic verification key shared between the issuer computer (1) and the transaction processing computer (1); (iii) verifying the transaction order using the user s public key; (iv) generating an authorization request on the basis of the verified transaction order; and (v) transmitting the authorisation request to a financial institution computer (1). Patentansprüche 1. Verfahren zum Authentifizieren einer elektronischen Zahlung über ein Computernetzwerk, das einen Benutzer-Computer (0), einen Händler-Computer (1), einen Aussteller-Computer (1), einen Transaktionsverarbeitungs-Computer (1) und einen Finanzinstitut-Computer (1) umfasst; wobei sich wenigstens der Benutzer-Computer und der Händler-Computer an anderen Stellen befinden als der Aussteller-Computer, der Transaktionsverarbeitungs-Computer und der Finanzinstitut-Computer; wobei das Verfahren die folgenden Schritte beinhaltet: (1) am Aussteller-Computer (1): (a) Einholen von mit einem Benutzer assoziierten Finanzkontodaten; (b) Einholen des mit dem Benutzer assoziierten öffentlichen Schlüssels; (c) Erzeugen eines digitalen Zertifikats durch kryptografisch gesichertes Binden des öffentlichen Schlüssels des Benutzers an wenigstens einen Teil der Finanzkontodaten des Benutzers mit einem kryptografischen Verifikationsschlüssel, der vom Aussteller-Computer (1) und vom Transaktionsverarbeitungs-Computer (1) gemeinsam genutzt wird; und (d) Senden des digitalen Zertifikats zum Benutzer; (2) am Benutzer-Computer (0): (a) Empfangen des digitalen Zertifikats vom Aussteller-Computer (1); (b) Einholen eines mit dem Benutzer assoziierten privaten Schlüssels, der dem öffentlichen Schlüssel des Benutzers entspricht; und dann (c) Durchführen einer elektronischen Transaktion mit dem Händler-Computer (1) unter Beteiligung der Finanzkontodaten, wobei die elektronische Transaktion Folgendes beinhaltet: (i) Empfangen eines Transaktionsauftrags vom Händler-Computer; (ii) digitales Signieren des Transaktionsauftrags mit dem privaten Schlüssel des Benutzers; und (iii) Senden des digital signierten Transaktionsauftrags mit dem digitalen Zertifikat zum Händler-Computer; (3) am Händler-Computer (1): (a) Senden des Transaktionsauftrags zum Benutzer-Computer (0) für den Empfang durch den Benutzer-Computer gemäß obigem Schritt (2)(c)(i); (b) Empfangen des digital signierten Transaktionsauftrags mit dem digitalen Zertifikat vom Benutzer-Computer; (c) Durchleiten des digital signierten Transaktionsauftrags und des digitalen Zertifikats zum Transaktionsverarbeitungs-Computer (1); (4) am Transaktionsverarbeitungs-Computer (1): (a) Empfangen des digital signierten Transaktionsauftrags und des digitalen Zertifikats 9

10 17 EP B1 18 vom Händler-Computer (1); (b) Verifizieren der Bindung in dem digitalen Zertifikat mit dem kryptografischen Verifikationsschlüssel oder einem mit dem kryptografischen Verifikationsschlüssel assoziierten Schlüssel, um dadurch zu verifizieren, ob der öffentliche Schlüssel des Benutzers mit dem kryptografischen Verifikationsschlüssel gebunden wurde, der vom Aussteller-Computer (1) und vom Transaktionsverarbeitungs-Computer (1) gemeinsam genutzt wird; (c) Verifizieren des Transaktionsauftrags mit dem öffentlichen Schlüssel des Benutzers; (d) Erzeugen einer Autorisierungsanforderung auf der Basis des verifizierten Transaktionsauftrags; (e) Senden der Autorisierungsanforderung zum Finanzinstitut-Computer (1); (f) Empfangen einer Genehmigung auf die Autorisierungsanforderung vom Finanzinstitut-Computer; und (g) Senden der Genehmigung zum Händler-Computer, um die Transaktion abzuschließen; und () am Finanzinstitut-Computer (1): (a) Empfangen der Autorisierungsanforderung vom Transaktionsverarbeitungs-Computer (1); (b) Ermitteln der Genehmigung oder Nichtgenehmigung der Autorisierungsanforderung; (c) Senden wenigstens einer Genehmigung zum Transaktionsverarbeitungs-Computer für den Empfang durch den Transaktionsverarbeitungs-Computer wie im obigen Schritt (4)(f). 2. Verfahren nach Anspruch 1, wobei die Finanzkontodaten eine persönliche Identifikationsnummer (PIN) enthalten und das digitale Zertifikat eine verschlüsselte Version der persönlichen Identifikationsnummer enthält. 3. Verfahren nach Anspruch 2, wobei der Schritt des Verifizierens der Bindung im digitalen Zertifikat das Extrahieren der verschlüsselten Version der PIN aus dem digitalen Zertifikat und das Entschlüsseln der entschlüsselten Version der PIN mit dem Verifikationsschlüssel oder einem mit dem Verifikationsschlüssel assoziierten Schlüssel beinhaltet. 4. Verfahren nach Anspruch 3, wobei die Autorisierungsanforderung die entschlüsselte PIN enthält Verfahren nach einem der Ansprüche 1 bis 4, wobei die Finanzkontodaten einen Kartenverifikationswert von 2 haben. 6. Verfahren nach einem der Ansprüche 1 bis, wobei der Händler-Computer (1) das digitale Zertifikat nur dann zum Transaktionsverarbeitungs-Computer (1) überträgt, wenn er dazu aufgefordert wird. 7. Verfahren nach einem der Ansprüche 1 bis 6, wobei der Schritt des Verifizierens der Bindung im digitalen Zertifikat mit einem asymmetrischen Schlüssel ausgeführt wird, der dem kryptografischen Verifikationsschlüssel entspricht. 8. Verfahren nach einem der Ansprüche 1 bis 7, wobei der im Schritt des Verifizierens des Transaktionsauftrags benutzte öffentliche Schlüssel des Benutzers vom Transaktionsverarbeitungs-Computer (1) in dem Schritt des Verifizierens der Bindung im digitalen Zertifikat eingeholt wird. 9. Vorrichtung für die Verwendung als Aussteller-Computer (1) gemäß dem Verfahren nach Anspruch 1, wobei die Vorrichtung Folgendes umfasst: (a) einen Prozessor; (b) einen Speicher, der mit dem Prozessor verbunden ist, um ein Programm zum Steuern des Betriebs des Prozessors zu speichern; (c) wobei der Prozessor mit dem Programm im Speicher zum Ausführen der folgenden Schritte betrieben werden kann: (i) Einholen von mit einem Benutzer assoziierten Finanzkontodaten; (ii) Einholen eines mit dem Benutzer assoziierten öffentlichen Schlüssels; (iii) Erzeugen eines digitalen Zertifikats durch kryptografisch gesichertes Binden des öffentlichen Schlüssels des Benutzers mit wenigstens einem Teil der Finanzkontodaten des Benutzers unter Verwendung eines kryptografischen Verifikationsschlüssels, der vom Aussteller-Computer (1) und von einem Transaktionsverarbeitungs- Computer (1) gemeinsam genutzt wird; und (iv) Senden des digitalen Zertifikats zum Benutzer; so dass der Benutzer eine elektronische Transaktion unter Beteiligung der Finanzkontodaten mit einem Händler-Computer (1) durchführen kann, in dem das digitale Zertifikat zum Händler- Computer und von dort zum Transaktionsverarbeitungs-Computer (1) gesendet wird, der die Bindung im digitalen Zertifikat mit dem krypto-

11 19 EP B1 grafischen Verifikationsschlüssel oder einem mit dem kryptografischen Verifikationsschlüssel assoziierten Schlüssel verifizieren kann, um dadurch zu verifizieren, ob der öffentliche Schlüssel des Benutzers mit dem kryptografischen Verifikationsschlüssel gebunden wurde, der vom Aussteller-Computer (1) und vom Transaktionsverarbeitungs-Computer (1) gemeinsam genutzt wird.. Vorrichtung nach Anspruch 9, wobei die Finanzkontodaten eine persönliche Identifikationsnummer (PIN) enthalten und das digitale Zertifikat eine verschlüsselte Version der persönlichen Identifikationsnummer enthält. 11. Vorrichtung nach Anspruch 9 oder, wobei die Finanzkontodaten einen Kartenverifikationswert von 2 haben. 12. Vorrichtung nach Anspruch 9, und 11, wobei die Bindung mit einem kryptografischen Verifikationsschlüssel durchgeführt wird, der ein asymmetrischer Schlüssel ist. 13. Vorrichtung für die Verwendung als Transaktionsverarbeitungs-Computer (1) gemäß dem Verfahren nach Anspruch 1, wobei die Vorrichtung Folgendes umfasst: (a) einen Prozessor; (b) einen Speicher, der mit dem Prozessor verbunden ist, um ein Programm zum Steuern des Betriebs des Prozessors zu speichern; (c) wobei der Prozessor mit dem Programm im Speicher zum Ausführen der folgenden Schritte betrieben werden kann: (i) Empfangen eines digital signierten Transaktionsauftrags und eines digitalen Zertifikats von einem Händler-Computer (1), wobei das digitale Zertifikat eine Bindung zwischen wenigstens einem Teil der Finanzkontodaten des Benutzers und dem öffentlichen Schlüssel des Benutzers enthält, der mit einem kryptografischen Verifikationsschlüssel gebildet wird, der von einem Aussteller-Computer (1) und dem Transaktionsverarbeitungs- Computer (1) gemeinsam genutzt wird; (ii) Verifizieren der Bindung im digitalen Zertifikat mit dem kryptografischen Verifikationsschlüssel oder einem mit dem kryptografischen Verifikationsschlüssel assoziierten Schlüssel, um dadurch zu verifizieren, ob der öffentliche Schlüssel des Benutzers mit dem kryptografischen Verifikationsschlüssel gebunden wurde, der vom Aussteller-Computer (1) und vom Transaktionsverarbeitungs-Computer (1) gemeinsam genutzt wird; (iii) Verifizieren des Transaktionsauftrags mit dem öffentlichen Schlüssel des Benutzers; (iv) Erzeugen einer Autorisierungsanforderung auf der Basis des verifizierten Transaktionsauftrags; und (v) Senden der Autorisierungsanforderung zu einem Finanzinstitut-Computer (1). 14. Vorrichtung nach Anspruch 13, wobei die Finanzkontodaten eine persönliche Identifikationsnummer (PIN) enthalten und das digitale Zertifikat eine verschlüsselte Version der persönlichen Identifikationsnummer enthält.. Vorrichtung nach Anspruch 14, wobei die Bindung im digitalen Zertifikat durch Extrahieren der verschlüsselten Version der PIN aus dem digitalen Zertifikat und Entschlüsseln der verschlüsselten Version der PIN mit dem Verifikationsschlüssel oder einem mit dem Verifikationsschlüssel assoziierten Schlüssel verifiziert wird. 16. Vorrichtung nach Anspruch, wobei die Autorisierungsanforderung die entschlüsselte PIN enthält. 17. Vorrichtung nach einem der Ansprüche 13 bis 16, wobei die Finanzkontodaten einen Kartenverifikationswert von 2 haben. 18. Vorrichtung nach einem der Ansprüche 13 bis 17, wobei der Transaktionsverarbeitungs-Computer (1) das digitale Zertifikat nur dann erhält, wenn er es anfordert. 19. Vorrichtung nach einem der Ansprüche 13 bis 18, wobei die Verifizierung der Bindung im digitalen Zertifikat mit einem asymmetrischen Schlüssel durchgeführt wird, der dem kryptografischen Verifikationsschlüssel entspricht.. Vorrichtung nach einem der Ansprüche 13 bis 19, wobei der öffentliche Schlüssel des Benutzers, der beim Verifizieren des Transaktionsauftrags verwendet wird, beim Verifizieren der Bindung im digitalen Zertifikat erhalten wird. 21. Computerprogramm zur Anwendung in der Vorrichtung für die Verwendung als Aussteller-Computer (1) nach Anspruch 9 zum Anweisen des Aussteller-Computers (1), die folgenden Schritte auszuführen: (i) Einholen von Finanzkontodaten über einen Benutzer; 11

12 21 EP B1 22 (ii) Einholen eines mit dem Benutzer assoziierten öffentlichen Schlüssels; (iii) Erzeugen eines digitalen Zertifikats durch kryptografisch gesichertes Binden des öffentlichen Schlüssels des Benutzers an wenigstens einen Teil der Finanzkontodaten des Benutzers mit einem kryptografischen Verifikationsschlüssel, der vom Aussteller-Computer (1) und einem Transaktionsverarbeitungs-Computer (1) gemeinsam genutzt wird; und (iv) Senden des digitalen Zertifikats zum Benutzer; so dass der Benutzer eine elektronische Transaktion unter Beteiligung der Finanzkontodaten mit einem Händler-Computer (1) durchführen kann, in dem das digitale Zertifikat zum Händler-Computer und von dort zum Transaktionsverarbeitungs-Computer (1) gesendet wird, der die Bindung im digitalen Zertifikat mit dem kryptografischen Verifikationsschlüssel oder einem mit dem kryptografischen Verifikationsschlüssel assoziierten Schlüssel verifizieren kann, um dadurch zu verifizieren, ob der öffentliche Schlüssel des Benutzers mit dem kryptografischen Verifikationsschlüssel gebunden wurde, der vom Aussteller-Computer (1) und vom Transaktionsverarbeitungs-Computer (1) gemeinsam genutzt wird. 22. Computerprogramm zur Anwendung in der Vorrichtung für die Verwendung eines Transaktionsverarbeitungs-Computers (1) nach Anspruch 13 zum Anweisen des Transaktionsprozessor-Computers (1), die folgenden Schritte auszuführen: (i) Empfangen eines digital signierten Transaktionsauftrags und eines digitalen Zertifikats von einem Händler-Computer (1), wobei das digitale Zertifikat eine Bindung zwischen wenigstens einem Teil der Finanzkontodaten des Benutzers und dem öffentlichen Schlüssel des Benutzers beinhaltet, der mit einem kryptografischen Verifikationsschlüssel gebildet wurde, der von einem Aussteller-Computer (1) und dem Transaktionsverarbeitungs-Computer (1) gemeinsam benutzt wird; (ii) Verifizieren der Bindung im digitalen Zertifikat mit dem kryptografischen Verifikationsschlüssel oder einem mit dem kryptografischen Verifikationsschlüssel assoziierten Schlüssel, um dadurch zu verifizieren, ob der öffentliche Schlüssel des Benutzers mit dem kryptografischen Verifikationsschlüssel gebunden wurde, der von dem Aussteller-Computer (1) und dem Transaktionsverarbeitungs-Computer (1) gemeinsam benutzt wird; (iii) Verifizieren des Transaktionsauftrags mit dem öffentlichen Schlüssel des Benutzers; (iv) Erzeugen einer Autorisierungsanforderung auf der Basis des verifizierten Transaktionsauftrags; und (v) Senden der Autorisierungsanforderung zu einem Finanzinstitut-Computer (1). Revendications 1. Procédé d authentification d un paiement électronique sur un réseau informatique, lequel comprend un ordinateur utilisateur (0), un ordinateur marchand (1), un ordinateur émetteur (1), un ordinateur processeur de transaction (1) et un ordinateur d établissement financier (1), l ordinateur utilisateur et l ordinateur marchand au moins étant situés à des emplacements différents de l ordinateur émetteur, de l ordinateur processeur de transaction et de l ordinateur d établissement financier; le procédé comprenant les étapes consistant à : (1) à l ordinateur émetteur (1) : (a) obtenir des données de compte financier associées à un utilisateur; (b) obtenir une clé publique associée à l utilisateur; (c) créer un certificat numérique par le lien garanti cryptographiquement de la clé publique de l utilisateur avec au moins une portion des données de compte financier de l utilisateur en utilisant une clé de vérification cryptographique partagée entre l ordinateur émetteur (1) et l ordinateur processeur de transaction (1); et (d) transmettre le certificat numérique à l utilisateur; (2) à l ordinateur utilisateur (0) : (a) recevoir le certificat numérique de l ordinateur émetteur (1); (b) obtenir une clé privée associée à l utilisateur et correspondant à la clé publique de l utilisateur; et puis (c) effectuer une transaction électronique avec l ordinateur marchand (1) impliquant les données de compte financier, la transaction électronique comprenant : (i) recevoir un ordre de transaction de l ordinateur marchand; (ii) signer numériquement l ordre de transaction avec la clé privée de l utilisateur; et (iii) transmettre l ordre de transaction signé numériquement avec le certificat numérique à l ordinateur marchand; 12

13 23 EP B1 24 (3) à l ordinateur marchand (1) : (a) transmettre l ordre de transaction à l ordinateur utilisateur (0) pour réception par l ordinateur utilisateur comme l étape (2)(c) (i) ci-dessus; (b) recevoir l ordre de transaction signé numériquement avec le certificat numérique de l ordinateur utilisateur; (c) passer l ordre de transaction signé numériquement avec le certificat numérique à l ordinateur processeur de transaction (1); 3. Le procédé de la revendication 2, dans lequel l étape consistant à vérifier le lien dans le certificat numérique comprend extraire la version chiffrée du PIN du certificat numérique et déchiffrer la version chiffrée du PIN en utilisant la clé de vérification ou une clé associée à la clé de vérification. 4. Le procédé de la revendication 3, dans lequel la demande d autorisation comprend le PIN déchiffré.. Le procédé de l une quelconque des revendications 1 à 4, dans lequel les données de compte financier comprennent une valeur de vérification de carte 2. (4) à l ordinateur processeur de transaction (1) : (a) recevoir de l ordinateur marchand (1) l ordre de transaction signé numériquement et le certificat numérique; (b) vérifier le lien dans le certificat numérique en utilisant la clé de vérification cryptographique ou une clé associée à la clé de vérification cryptographique, vérifiant ainsi que la clé publique de l utilisateur a été liée en utilisant la clé de vérification cryptographique partagée entre l ordinateur émetteur (1) et l ordinateur processeur de transaction (1); (c) vérifier l ordre de transaction en utilisant la clé publique de l utilisateur; (d) générer une demande d autorisation sur la base de l ordre de transaction vérifié; (e) transmettre la demande d autorisation à l ordinateur d établissement financier (1); (f) recevoir une approbation quelconque de la demande d autorisation de la part de l ordinateur d établissement financier; et (g) envoyer l approbation à l ordinateur marchand pour achever la transaction; et () à l ordinateur d établissement financier (1) (a) recevoir la demande d autorisation de l ordinateur processeur de transaction (1); (b) déterminer l approbation ou la non approbation de la demande d autorisation; (c) transmettre au moins une approbation quelconque à l ordinateur processeur de transaction pour réception par l ordinateur processeur de transaction comme l étape (4)(f) ci-dessus. 2. Le procédé de la revendication 1, dans lequel les données de compte financier comprennent un code confidentiel (PIN) et le certificat numérique comprend une version chiffrée du code confidentiel Le procédé de l une quelconque des revendications 1 à, dans lequel l ordinateur marchand (1) ne transmet le certificat numérique à l ordinateur processeur de transaction (1) que lorsqu on lui demande de le faire. 7. Le procédé de l une quelconque des revendications 1 à 6, dans lequel l étape consistant à vérifier le lien dans le certificat numérique, est effectuée avec une clé asymétrique correspondant à la clé de vérification cryptographique. 8. Le procédé de l une quelconque des revendications 1 à 7, dans lequel la clé publique de l utilisateur utilisée à l étape consistant à vérifier l ordre de transaction, est obtenue par l ordinateur processeur de transaction (1) à l étape consistant à vérifier le lien dans le certificat numérique. 9. Appareil à utiliser comme ordinateur émetteur (1) selon le procédé de la revendication 1, l appareil comprenant : (a) un processeur (b) une mémoire connectée au processeur pour stocker un programme destiné à contrôler le fonctionnement du processeur; (c) le processeur étant utilisable avec le programme dans la mémoire pour exécuter les étapes consistant à : (i) obtenir des données de compte financier associées à un utilisateur; (ii) obtenir une clé publique associée à l utilisateur; (iii) créer un certificat numérique par le lien garanti cryptographiquement de la clé publique de l utilisateur avec au moins une portion des données de compte financier de l utilisateur en utilisant la clé de vérification cryptographique partagée entre l ordinateur émetteur (1) et un ordinateur processeur de transaction (1); et (iv) transmettre le certificat numérique à 13

14 2 EP B1 26 l utilisateur; en vertu de quoi l utilisateur peut effectuer une transaction électronique impliquant les données de compte financier, avec un ordinateur marchand (1) dans laquelle le certificat numérique est transmis à l ordinateur marchand et de là à l ordinateur processeur de transaction (1) qui peut vérifier le lien dans le certificat numérique en utilisant la clé de vérification cryptographique ou une clé associée à la clé de vérification cryptographique, vérifiant ainsi que la clé publique de l utilisateur a été liée en utilisant la clé de vérification cryptographique partagée entre l ordinateur émetteur (1) et l ordinateur processeur de transaction (1).. L appareil de la revendication 9, dans lequel les données de compte financier comprennent un code confidentiel (PIN) et le certificat numérique comprend une version chiffrée du code confidentiel. 11. L appareil de la revendication 9 ou, dans lequel les données de compte financier comprennent une valeur de vérification de carte L appareil des revendications 9, ou 11, dans lequel le lien est exécuté avec une clé de vérification cryptographique qui est une clé asymétrique. 13. Appareil à utiliser comme un ordinateur processeur de transaction (1) selon le procédé de la revendication 1, l appareil comprenant : (a) un processeur; (b) une mémoire connectée au processeur pour stocker un programme destiné à contrôler le fonctionnement du processeur; (c) le processeur étant utilisable avec le programme dans la mémoire pour exécuter les étapes consistant à : (i) recevoir d un ordinateur marchand (1) un ordre de transaction signé numériquement et un certificat numérique, le certificat numérique incluant un lien entre au moins une portion des données de compte financier de l utilisateur et la clé publique de l utilisateur, formé en utilisant une clé de vérification cryptographique partagée entre un ordinateur émetteur (1) et l ordinateur processeur de transaction (1); (ii) vérifier le lien dans le certificat numérique en utilisant la clé de vérification cryptographique ou une clé associée à la clé de vérification cryptographique vérifiant ainsi que la clé publique de l utilisateur a été liée en utilisant la clé de vérification cryptographique partagée entre l ordinateur émetteur (1) et l ordinateur processeur de transaction (1); (iii) vérifier l ordre de transaction en utilisant la clé publique de l utilisateur; (iv) générer une demande d autorisation sur la base le l ordre de transaction vérifié; et (v) transmettre la demande d autorisation à un ordinateur d établissement financier (1). 14. L appareil de la revendication 13, dans lequel les données de compte financier comprennent un code confidentiel (PIN) et le certificat numérique comprend une version chiffrée du code confidentiel.. L appareil de la revendication 14, dans lequel le lien dans le certificat numérique est vérifié en extrayant la version chiffrée du PIN du certificat numérique et en déchiffrant la version chiffrée du PIN en utilisant la clé de vérification ou une clé associée à la clé de vérification. 16. L appareil de la revendication, dans lequel la demande d autorisation comprend le PIN déchiffré. 17. L appareil de l une quelconque des revendications 13 à 16, dans lequel les données de compte financier comprennent une valeur de vérification de carte L appareil de l une quelconque des revendications 13 à 17, dans lequel l ordinateur processeur de transaction (1) ne reçoit le certificat numérique que lorsqu il le demande. 19. L appareil selon l une quelconque des revendications 13 à 18, dans lequel la vérification du lien dans le certificat numérique est effectuée avec une clé asymétrique correspondant à la clé de vérification cryptographique.. L appareil de l une quelconque des revendications 13 à 19, dans lequel la clé publique de l utilisateur utilisée pour vérifier l ordre de transaction, est obtenue dans la vérification du lien dans le certificat numérique. 21. Programme informatique à utiliser dans l appareil à utiliser en tant qu ordinateur émetteur (1) selon la revendication 9 pour ordonner à l ordinateur émetteur (1) d effectuer les étapes consistant à : (i) obtenir des données de compte financier concernant un utilisateur; (ii) obtenir une clé publique associée à l utilisateur; (iii) créer un certificat numérique par le lien garanti cryptographiquement de la clé publique de 14

15 27 EP B1 28 l utilisateur avec au moins une portion des données de compte financier de l utilisateur en utilisant une clé de vérification cryptographique partagée entre l ordinateur émetteur (1) et un ordinateur processeur de transaction (1); et (iv) transmettre le certificat numérique à l utilisateur; en vertu de quoi l utilisateur peut effectuer une transaction électronique impliquant les données de compte financier avec un ordinateur marchand (1), dans laquelle le certificat numérique est transmis à l ordinateur marchand et de là à l ordinateur processeur de transaction (1) qui peut vérifier le lien dans le certificat numérique en utilisant la clé de vérification cryptographique ou une clé associée à la clé de vérification cryptographique, vérifiant ainsi que la clé publique de l utilisateur a été liée en utilisant la clé de vérification cryptographique partagée entre l ordinateur émetteur (1) et l ordinateur processeur de transaction (1). 22. Programme informatique à utiliser dans l appareil à utiliser en tant qu ordinateur processeur de transaction (1) selon la revendication 13 pour ordonner à l ordinateur processeur de transaction (1) d effectuer les étapes consistant à : 2 (i) recevoir d un ordinateur marchand (1) un ordre de transaction signé numériquement et un certificat numérique, le certificat numérique incluant un lien entre au moins une portion de données de compte financier d un utilisateur et la clé publique de l utilisateur, formé en utilisant une clé de vérification cryptographique partagée entre un ordinateur émetteur (1) et l ordinateur processeur de transaction (1); (ii) vérifier le lien dans le certificat numérique en utilisant la clé de vérification cryptographique ou une clé associée à la clé de vérification cryptographique, vérifiant ainsi que la clé publique de l utilisateur a été liée en utilisant la clé de vérification cryptographique partagée entre l ordinateur émetteur (1) et l ordinateur processeur de transaction (1); (iii) vérifier l ordre de transaction en utilisant la clé publique de l utilisateur; (iv) générer une demande d autorisation sur la base de l ordre de transaction vérifié; et (v) transmettre la demande d autorisation à un ordinateur d établissement financier (1)

16 EP B1 16

17 EP B1 17

18 EP B1 18

19 EP B1 19

20 EP B1