WO2001084763A2 - Method for transmitting payment information between a terminal and a third equipment - Google Patents

Method for transmitting payment information between a terminal and a third equipment Download PDF

Info

Publication number
WO2001084763A2
WO2001084763A2 PCT/EP2001/004579 EP0104579W WO0184763A2 WO 2001084763 A2 WO2001084763 A2 WO 2001084763A2 EP 0104579 W EP0104579 W EP 0104579W WO 0184763 A2 WO0184763 A2 WO 0184763A2
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
message
payment terminal
smart card
mobile equipment
Prior art date
Application number
PCT/EP2001/004579
Other languages
French (fr)
Other versions
WO2001084763A3 (en
Inventor
Levente Buttyan
Edwin Wiedmer
Eric Lauper
Original Assignee
Swisscom Mobile Ag
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 Swisscom Mobile Ag filed Critical Swisscom Mobile Ag
Priority to EP01943278A priority Critical patent/EP1277301B1/en
Priority to DE60104411T priority patent/DE60104411T2/en
Priority to AT01943278T priority patent/ATE271733T1/en
Priority to AU65897/01A priority patent/AU6589701A/en
Publication of WO2001084763A2 publication Critical patent/WO2001084763A2/en
Publication of WO2001084763A3 publication Critical patent/WO2001084763A3/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • 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/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • 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/388—Payment protocols; Details thereof using mutual authentication without cards, e.g. challenge-response
    • 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
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04K—SECRET COMMUNICATION; JAMMING OF COMMUNICATION
    • H04K1/00—Secret communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50—Secure pairing of devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • the present invention concerns an electronic payment method for goods and services. More specifically, the present invention concerns a method for effecting electronic payments using smart cards and short distance wireless communication technologies.
  • smart cards in user authentication enables the introduction of strong authentication, based on cryptographic techniques, because the smart card can perform cryptographic operations and store cryptographic keys for the user if) a tamper resistant zone.
  • Using smart cards requires smart card readers to be installed at the points of authentication and users to produce a smart card and to introduce it in an untrusted equipment.
  • Smart cards can also be inserted in the smart card slot of a user's mobile equipment, for example a personal digital assistant (PDA) or a mobile phone, in order to provide for a secure authentication in a telecommunication network, e.g. a mobile telecommunication network.
  • the smart card may contain cryptographic computing means, for example a processor and a memory containing a program which can be executed by the processor for computing cryptographic functions, for securing sessions over the mobile network.
  • Mobile stations including a short distance wireless interface for example a radio or infrared interface, are known that allow for a data transfer and/or synchronization between the mobile station and other terminals or computers in the vicinity.
  • a smart card reader which can connect to fixed and public terminals (e.g., a PC or a POS terminal in a shop) via a short distance wireless interface has the following advantages:
  • the personal mobile equipment of the user allows the user to directly communicate with her smart card (the mobile equipment has a keypad and a display); if traditional smart card readers are used, then the user has to type on the keyboard of the terminal and the smart card can only display messages on the display of the terminal, thus a malicious terminal can alter the communication between the user and the smart card;
  • the smart card is never inserted into an untrusted device, which could try to obtain more data from the smart card than it should;
  • Using a mobile station connected over a wireless interface to a payment terminal poses some new security problems.
  • the main one is the problem of mutual authentication between the smart card and the fixed terminal in the presence of other, potentially malicious users.
  • Other security problems may also arise (e.g. problems related to integrity, confidentiality and privacy).
  • the main technical problem is that the communication channel between the personal mobile equipement (smart card reader) and the payment terminal (point of authentication) is not secure.
  • the card reader is built in or physically connected (with a short wire) to a fixed payment terminal, e.g. in a point-of-sale, then the messages and payment orders sent between the card and the terminal cannot be eavesdropped, modified, replayed, etc. by an attacker. This would require physical access to the terminal, the card reader, or the wire that connects them.
  • the card and the terminal can be sure that the messages they receive during the rest of the session come from the other party.
  • the present invention is concerned with solutions for safely using the user mobile equipment (such as a mobile phone or a personal digital assistant) as the smart card reader, or more generally as cryptographic computing means for authenticating the user when he wants to use a payment terminal. More specifically, the present invention is concerned with solutions for connecting the user mobile station to payment terminals using short distance wireless communication (e.g. Bluetooth, HomeRF or infrared), and which avoid the above-mentioned drawbacks.
  • short distance wireless communication e.g. Bluetooth, HomeRF or infrared
  • the security problems of the prior art are solved with a new protocol that builds a secure (authentic and/or confidential) logical channel between the cryptographic computing means on the user mobile side, the payment terminal and further to the billing server.
  • the secure logical channel is based on a secret that is exclusively shared by the smart card in the mobile equipment and the terminal, and on the application of cryptographic techniques.
  • the main job of the inventive protocol is the safe establishment of this shared secret by involving the user as an authentic channel between the terminal and the mobile station.
  • the inventive protocol assumes three business roles: the user, the merchant, and the billing server.
  • Each user is registered with at least one billing server, which maintains a billing account for the user.
  • the user is mobile, which means that she physically moves and visits various merchant sites (e.g., shops).
  • the user can buy goods or services from the merchant. Instead of instant payment to the merchant, the appropriate amount is charged to the billing account of the user.
  • the billing server collects charging updates from the merchants and regularly (e.g., at the end of every month) creates one single bill for each user, which contains all the purchases of that user.
  • the billing server debits the money from an electronic account in the user's smart card.
  • the billing server then distributes the appropriate shares to the merchants.
  • the novelty of the approach is the use of short distance wireless communication technology for the communication between the user (smart card in the user's mobile equipment) and the merchant (payment terminal, e.g. point-of-sale).
  • the card In traditional credit card payment, the card is often handed over to the merchant, who can read all the information on the card and potentially misuse it.
  • the card In the inventive approach, the card is plugged into the personal mobile station of the user and only payment information related to the current purchase is revealed to the merchant.
  • Another advantage is that, while in traditional credit card systems billing is performed by banks and credit card companies, in the invention, anybody can become a billing service provider, in particular any telco who has competency in billing and reputation (which usually means trust).
  • a new unique transaction identification and the terminal name is displayed on the display of said terminal or of the mobile equipment, and entered by the user on the input means of the other of one of said payment terminals or mobile equipments.
  • the terminal name and transaction id is used for establishing a secure channel between the mobile equipment and the payment terminal.
  • the secure channel that is established is an authentic channel.
  • the protocol can also be used to prevent eavesdropping (i.e. to establish an authentic and a confidential channel).
  • the user has a smart card and a personal mobile equipment, in which the smart card can be inserted, and which has short distance wireless communication capabilities.
  • the inventive method would, however, work as well if the user has a personal digital assistant (PDA) which has short distance wireless communication capabilities.
  • PDA personal digital assistant
  • a method for transmitting payment information between a mobile station and a payment terminal (1 1) over a short distance wireless interface comprising:
  • An important characteristic of an electronic payment system is whether it is online or offline.
  • the merchant contacts the bank of the user at each purchase in order to verify the solven- cy of the user.
  • the bank is contacted only offline (e.g., once each day) in order to update the charging information of the user.
  • Online systems are used for high value payments and when the merchant does not trust the user. For low value payments and when the merchant trusts the user, offline systems are more efficient.
  • the inventive solution can be used with both types of applications, and let the merchant choose whether online verification of solvency is necessary or not. The invention will be better understood with the help of the following description, given as an example, and illustrated by the figure which show.
  • Figure 1 illustrates the principals and the channels of a system including a smart card inserted in a mobile phone or PDA, a payment terminal and a billing server.
  • Figure 2 illustrates the messages which are exchanged between two partners according to the ISO/IEC 9798-3 protocol.
  • Figure 3 illustrates the messages and keys which are exchanged between two partners in a modification of the ISO/IEC 9798-3 protocol.
  • Figure 4 illustrates the messages which are exchanged for authorizing a money transfer.
  • Figure 5 illustrates the messages which are exchanged between the principals over the various channels in a preferred embodiment of the invention.
  • Figure 1 illustrates the principals and the channels among them.
  • ⁇ C her smart card 100, e.g. a SIM-card (subscriber identification card), WIM card (WAP identification card) or UlM-card (UMTS identification card).
  • the smart card is introduced or may be a part of a mobile equipment, e.g. a mobile phone or a PDA (not shown).
  • the mobile equipment including the smart card is called the mobile station.
  • ⁇ T the payment terminal 11 (point-of-sale) of the merchant.
  • ⁇ S the billing server 7, which may be operated by the operator of the mobile network or by a third instance.
  • the physical channels are:
  • ⁇ md the display 102 of the mobile equipment containing the card (C ⁇ U)
  • ⁇ mk the keypad 103 of the mobile equipment containing the card (U ⁇ C)
  • ⁇ net the fixed network 70 between the payment terminal 11 and the billing server 7 (T e S)
  • the logical channels are:
  • ⁇ Sig ⁇ the channel realized by the digital signature with the private key of the user 1.
  • ⁇ Ku the channel implemented by the encryption with the public key of the user 1.
  • Sig ⁇ the channel realized by the digital signature with the private key of the payment terminal 1 1.
  • the display 102 md of the mobile equipment is authentic and timely. Authenticity means that if the mobile equipment shows a message and states that this message comes from the smart card 100, then indeed the message comes from the smart card 100. Timeliness means that the mobile equipment does not maliciously delay messages originating from the smart card 100, but displays them as the card generates them. This, of course, means that the mobile equipment is trusted: the user believes that it has not been tampered by anybody and that it behaves correctly.
  • the keypad 103 mk of the mobile equipment is authentic and timely. We assume that only the user 1 of the smart card 100 can send messages to the smart card via the keypad 103 of the mobile equipment. Requiring the user 1 to enter the PIN assigned to the smart card 100 when the card is inserted in the mobile equipment or before starting a payment transaction can ensure this. Furthermore, we assume that the mobile equipment does not maliciously delay the input from the user 1, but delivers it to the card 100 as the user enters it.
  • the terminal display 110 td is authentic and timely. This means that messages displayed on the screen 110 of the terminal 1 1 originates from the terminal and at the time at which they are displayed. •
  • the wireless link 101 wl between the mobile equipment and the fixed terminal 1 1 is insecure. We assume that passive attacks (eavesdropping) and active attacks (message modification, generation and replay) are possible on the wireless link between the mobile station and the terminal.
  • Sigu is an authentic channel from the smart card 100, because only the smart card knows the private key of the user 1; thus, one can be sure that messages that are signed with this private key originate from the smart card 100.
  • Sig ⁇ is an authentic channel from the payment terminal 11, because only the terminal can generate messages that are signed with the private key of the terminal.
  • ⁇ K ⁇ is a confidential channel to the terminal, because only the terminal can decrypt messages that are encrypted with the public key of the terminal.
  • An objective of the invention is to find a protocol that establishes an authentic and confidential (in order to hide payment information from eavesdroppers) logical channel between the terminal 11 and the smart card 100, and further to the billing center 7, using only the already existing physical and logical channels described above, and to find a payment protocol, in which the user 1 authorizes the billing server 7 to pay the merchant for the goods or services provided and to charge the corresponding amount to her billing account.
  • Figure 2 shows the standardized ISO/IEC 9798-3 mutual authentication protocol.
  • Figure 3 shows an inventive extension of this protocol with key establishment functions.
  • the ISO/IEC 9798-3 protocol is based on public key cryptography, and assumes that both participating entities A, B have a public key certificate. This is consistent with our assumptions about the existing channels between the smart card and the terminal.
  • the initiator of the protocol A generates a fresh random number r a , and sends it to the responder B.
  • B also generates a fresh random number r ⁇ , and digitally signs r ⁇ , r A and A (the identifier of A). Then it sends a message to A which contains the public key certificate cert B of B, the random number rt > , the identifier of A, and the digital signature Sig B (r B , f ⁇ , A). Upon receiving this message, A verifies the certificate and the digital signature of B. If the verifications are successful, then B is authenticated.
  • the rationale is that a valid signature can only be generated by someone who knows the appropriate private key (i.e., B), and the data, on which the signature has been generated, is fresh (because it contains the random number r A ).
  • a ⁇ B certA, B, S/g f ⁇ , r B , B)
  • A then digitally signs r A , r B and B, and sends a message to B which contains the public key certificate of A, the identifier of B, and the digital signature Sig a ⁇ r ⁇ r Bf B).
  • B Upon receiving this message, B verifies the certificate and the digital signature of A. If the verifications are successful, then A is authenticated for similar reasons as before.
  • the signature operation is such that it reveals the data which is signed, then we require that first a cryptographic hash value is computed from the data, and then this hash value is signed with the signature operation. In this way, k is not revealed to eavesdroppers.
  • the design of a payment protocol is based on the observation that payment is equivalent with authentication if money is represented by accounts. This means that, in the inventive payment protocol, the payment will be an authentic statement of the payer (i.e., the user), which says that she is willing to transfer a given amount from her account to the account of the payee (i.e., the merchant). The authenticity of the statement is verified by the payee, as well as the entity that handles the accounts (i.e., the billing server).
  • the protocol is illustrated in Figure 4 and described as follows:
  • msgl A ⁇ B : cert ⁇ A, B, T-info, P-info, Sig A (A, B, T-info, P-info)
  • A digitally signs her identifier A, the identifier B of the payee B (payment terminal 11), the transaction information T-info, and the payment information P-info. It is not specified explicitly what T-info and P-info are.
  • T-info contains a unique transaction identifier, the identifier of the service that has been provided, the date and the time of the provision, the unit price, etc.
  • P-info contains the identifier of the billing server, the amount to be paid, an expiry date until which the payee must present this message to the billing server, etc.
  • B verifies the certificate and the digital signature of A.
  • B generates a receipt of payment by computing a cryptographic hash value h(msg ⁇ ) of the first message, and generating a digital signature on the result. He then sends his certificate and the signature to A.
  • msg3 B ⁇ S : cert ⁇ A, B, T-info, P-info, Sig A (A, B, T-info, P-info)
  • B contacts the billing server S (7), and sends the first message (i.e., A's statement that she is willing to pay) to it.
  • S verifies the signature and checks that this payment has not been processed before. Then it transfers the appropriate amount to B and updates the billing account of A. S logs the payment into an internal database for further verification purposes.
  • the payment terminal T (11) displays the identifier T of the terminal and the transaction information T-info on the display 102 of the terminal.
  • the transaction information contains a unique (at least with respect to this terminal) transaction identifier T-id, the identifier of the service provided, the date and the time of the provision, the price, etc.
  • the user U (1) types in the identifier of the terminal Tand the transaction identifier T-id on the keypad 103 of the mobile equipment, which sends this information to the smart card C (100).
  • the smart card 100 generates a first fresh random number r c , and sends it to the payment terminal 1 1 together with T and T-id via the wireless link 101.
  • the terminal 11 may receive several messages from other terminals 11 and smart cards 100 that are in its communication range while waiting for this message from the smart card. It handles only the message that contains its identifier 7 " and the valid transaction identifier T-id. All other messages are discarded.
  • the payment terminal 11 generates a second fresh random number r ⁇ . It signs the random number of the smart card r c , together with its own random number r T , its identifier T, and the transaction identifier T- id. It then sends its certificate certr, its random number r ⁇ , and the digital signature to the smart card 100.
  • the smart card verifies the certificate and the signature of the terminal. Besides having a valid signature on it, the certificate should contain the terminal identifier 7 " that has been typed in by the user on the keypad of the mobile equipment. If the verifications are all successful, then the payment terminal 11 is authenticated.
  • the smart card 100 generates a random symmetric key k and encrypts it with the public key K ⁇ of the payment terminal 11. This public key is obtained from the certificate of the terminal.
  • the smart card 100 signs the random numbers ty and r c , the identifiers T and T-id, and the freshly generated symmetric key k. Then it sends the certificate of the user certu, the encrypted symmetric key and the digital signature to the terminal. If the signature does not hide the data that is signed, then in a variant embodiment the signed data is hashed with a cryptographic hash function before being signed.
  • the terminal decrypts the encrypted part and verifies the certificate and the signature of the smart card 100. If the verifications are successful, then the user's smart card is authenticated to the terminal. Furthermore, the smart card and the payment terminal established a shared symmetric session key k.
  • the payment terminal 11 sends its identifier and the transaction information, which has been displayed to the user on the display 110 of the payment terminal 11, to the smart card 100.
  • This messages is encrypted with the shared session key k. Since only the payment terminal 11 knows this key (apart from the smart card 100, of course), the smart card believes that this message is sent by the terminal.
  • the smart card 100 displays the received information on the display 102 of the mobile equipment.
  • the user 1 verifies it and compares it to the information that is displayed by the payment terminal 11 on its display 110.
  • the user 1 confirms (e.g., she pushes the OK button on the mobile equipment).
  • the smart card 100 generates the payment message, which contains the identifiers of the user and the merchant's payment terminal, the transaction information, and the payment information, and it is digitally signed by the smart card 100 with the private key of the user. If the signature does not hide the data that is signed, then we require that first the data is hashed with a cryptographic hash function, and the hash value is signed with the private key of the user.
  • the payment message is encrypted with the session key k, and sent to the terminal. This encryption hides the payment information from attackers. Upon receiving this message, the terminal 11 decrypts it, and verifies the digital signature.
  • the terminal 11 can now contact the billing server 7, or a certification revocation list server, to check the solvency of the user 1 (online solvency check).
  • the terminal 11 generates a payment receipt by computing the cryptographic hash value of the payment message (without the encryption) using some publicly known cryptographic hash function h, and signing the hash value.
  • the payment receipt is encrypted with the session key k, and sent to the smart card 100.
  • T ⁇ S certu, U, T, T-info, P-info, Sigy(U, T, T-info, P-info)
  • the terminal 11 contacts the billing server 7, and presents the payment message received from the user 1.
  • This message is sent via a channel 70 (net), the security of which is provided by means outside of the scope of this report.
  • the billing server 7 verifies the certificate and the signature of the user. It then checks that this payment has not been processed before by looking up its internal log database. If the verifications are successful, then the billing server transfers the appropriate amount to the merchant and updates the billing account of the user. It also logs the transaction into its internal log database.
  • the method preferably uses an underlying public key infrastructure.
  • Public key certificates may be issued by certification authorities (CAs), which may be hierarchically organized.
  • Revocated certificates may be listed on a certificate revocation list (CRL).
  • CAs certification authorities
  • CTL certificate revocation list
  • ⁇ for low value payments the user does not perform any revocation checks
  • ⁇ for high value payments and for low value payments in case the merchant does not trust the user, the merchant checks the user's certificate against the online CRL via the fixed network
  • the merchant checks its local copy of the CRL that it updates regularly from the online CRL server.
  • the terminal 11 (the smart card 100) believes that the smart card 100 (the terminal 1 1) has recently sent a message (repeated its random number), which means that both should be present (authentication).
  • the smart card and the terminal believe that k is a shared secret key between them (key establishment).
  • the terminal 11 and the billing server 7 believe that the user 1 authorized the payment.
  • the terminal 1 1 believes that the user's authorization is fresh (since it arrives encrypted with the fresh secret key), but the billing server 7 cannot be sure about the freshness of this authorization. That is why we require the server 7 to look at its internal log database and check that this authorization has never been processed before.
  • the protocol has two phases: (1 ) it establishes an authentic and confidential channel between the smart card of the user and the payment terminal of the merchant, and (2) it provides the means to authorize transfer of money from the account of the user to the account of the merchant. Accounts are managed by a trusted third party, which is called billing server. Implementation guidelines
  • the wireless link 101 between the smart card 100 in the user's equipment and the terminal 1 1 can be based on radio or infrared communications.
  • This first message always contains enough information for a receiver 1 1 to decide whether it has to take care of it, or whether it is a message for someone else.
  • the intended receiver can, thus, recognize which broadcast message is sent to it and respond to it. Since the broadcast message can contain the MAC address of the sender, the receiver can send the response directly to the sender. The response can also contain the MAC address of its sender (the MAC address of the intended receiver of the broadcast message). Thus, after the first message exchange, both communicating parties know the address of the other and can send messages directly to each other.
  • the protocol may be implemented with software in the terminal 1 1 and in the smart card 100 implemented with current cryptographic libraries.
  • the terminal side an example is the ABA JCE library, which is a pure Java implementation of the JCE (Java Cryptography Extension) interface defined by Sun Microsystems Inc.
  • the smart card side an example is an implementation of the Java Card interface.
  • Both the smart card 100 and the payment terminal 1 1 must generate fresh random numbers. These numbers should be generated by the pseudo-random number generator (PRNG) available in the cryptographic library. This PRNG is represented by the SecureRandom class, which is part of the JCE interface. As the security of the method depends on the quality of the random number, seeding of the PRNG must be solved carefully.
  • PRNG pseudo-random number generator
  • Seeding the PRNG may be a problem on the smart card, because multi-threading is not allowed on most cards (i.e., self-seeding cannot be used) and capturing random events does not seem to be easy either.
  • One solution can be that the mobile equipment creates the seed possibly using random events generated by the user.
  • This choice is determined by the number of public and private key operations performed by the smart card.
  • the smart card 100 performs 1 public key encryption, 3 digital signature verifications, and 2 digital signature generations. This means 4 public key and 2 private key operations. Therefore, we suggest a scheme in which public key operations require less computation than private key operations.
  • Such a scheme is RSA, which can be used for both encryption and digital signature, and which is available in the cryptographic library.
  • MD5 For digital signature, we suggest to use MD5 with RSA, which hides the data that is signed.
  • the protocol uses symmetric key encryption to protect payment information from eavesdroppers. Any kind of block cipher algorithm can be used for this purpose.
  • IDEA in CBC mode.
  • pseudo-code which may be run by the computing means in the smart card 100 and by the payment terminal 11 in order to carry out this payment protocol. The one skilled in the art will be able to write the necessary modules in the smart card and in the terminal 11 which correspond to those pseudo-codes.
  • M2 cert, r, sig (M2 has the right format)
  • cert is the certificate of 7 " and it is correct, then go to step 7 else listen further on the wireless interface until a message M2 with a correct certificates arrives. If a timeout occurs before M2 has been received, raise an exception and stop.
  • M3 cert, C, sig (M3 has the right format)
  • M3 cert, C, sig (M3 has the right format)
  • go to step 9 else listen further on the wireless interface until a message M3 with the expected format arrives. If a timeout occurs before M3 has been received, raise an exception and stop. 9. If cert is correct, then go to step 10, else listen further on the wireless interface until a message M3 with a correct certificate arrives. If a timeout occurs before M3 has been received, raise an exception and stop.
  • P5 U, T, T-info, P-info, sig, then go to step 17, else listen further on the wireless interface until a message M5 with the expected format arrives. If a timeout occurs before M5 has been received, raise an exception and stop.
  • an authentic and confidential channel is established between the user's mobile equipment and the payment terminal by first displaying the terminal name and a new unique transaction id on the display of the payment terminal and then entering manually the terminal name and the transaction id on the keypad of the mobile equipment.
  • an authentic and confidential channel can be built by displaying the unique transaction id on the display of the mobile equipment and then entering manually the mobile id and transaction id in the payment terminal.
  • the embodiments of the invention described with reference to the drawings comprise equipments such as terminals, smart cards and mobile equipments, and methods performed in or by such equipments
  • the invention also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the invention into practice.
  • the program may be in the form of source code, object code, a code intermediate source and object code such as in partially compiled form, or in any other form suitable for use in the implementation of the methods and protocols according to the invention.
  • the carrier may be any entity or device capable of carrying the program.
  • the carrier may comprise a storage medium, such as a ROM, for example a CD-ROM or a semiconductor ROM, for example an EEPROM, or a magnetic or optical recoding medium, for example a floppy disc, hard disk or smart card.
  • a storage medium such as a ROM, for example a CD-ROM or a semiconductor ROM, for example an EEPROM, or a magnetic or optical recoding medium, for example a floppy disc, hard disk or smart card.
  • the carrier may be a transmissible carrier such as an electrical or optical signal which may be conveyed via electrical or optical cable or by radio or other means.
  • the carrier may be constituted by such cable or other device or means.
  • the carrier may be an integrated circuit in which the program is embedded, for example a memory in the terminal 11, in the mobile equipment or in the smart card 100.

Abstract

Method for performing electronic payments between a mobile equipment and a payment terminal over a short distance wireless interface, comprising displaying an identification (for example T; T-id) on the display (110) of said payment terminal (11), manually entering said identification on the input means (103) of said mobile equipment, using said identification in an message to the payment terminal, said message used to start establishment of an extended mutual authentication, said extended mutual authentication establishing a shared secret key for encrypting confidential payment information exchanged between the terminal and the mobile.

Description

Method for transmitting payment information between a terminal and a third equipment
The present invention concerns an electronic payment method for goods and services. More specifically, the present invention concerns a method for effecting electronic payments using smart cards and short distance wireless communication technologies.
With the dramatic growth of communication networks (computer as well as telecommunication networks), electronic commerce is becoming a more and more popular idea among business and residential users. One aspect of electronic commerce is electronic payment for goods and services. Electronic payment systems promise more convenience and more security. The latter is based on the application of strong cryptography in order to prevent fraud.
The application of smart cards in user authentication enables the introduction of strong authentication, based on cryptographic techniques, because the smart card can perform cryptographic operations and store cryptographic keys for the user if) a tamper resistant zone. Using smart cards, however, requires smart card readers to be installed at the points of authentication and users to produce a smart card and to introduce it in an untrusted equipment.
Smart cards can also be inserted in the smart card slot of a user's mobile equipment, for example a personal digital assistant (PDA) or a mobile phone, in order to provide for a secure authentication in a telecommunication network, e.g. a mobile telecommunication network. The smart card may contain cryptographic computing means, for example a processor and a memory containing a program which can be executed by the processor for computing cryptographic functions, for securing sessions over the mobile network. Mobile stations including a short distance wireless interface, for example a radio or infrared interface, are known that allow for a data transfer and/or synchronization between the mobile station and other terminals or computers in the vicinity. Using the user terminal, for example the user mobile phone, as a smart card reader which can connect to fixed and public terminals (e.g., a PC or a POS terminal in a shop) via a short distance wireless interface has the following advantages:
• in general, the personal mobile equipment of the user allows the user to directly communicate with her smart card (the mobile equipment has a keypad and a display); if traditional smart card readers are used, then the user has to type on the keyboard of the terminal and the smart card can only display messages on the display of the terminal, thus a malicious terminal can alter the communication between the user and the smart card;
• in particular, the smart card is never inserted into an untrusted device, which could try to obtain more data from the smart card than it should; and
• the PIN code or secret that is assigned to the smart card is never typed into an untrusted device, which can misuse or steal it;
• furthermore, there is no need to install smart card readers everywhere and to adapt them to various card formats.
Using a mobile station connected over a wireless interface to a payment terminal poses some new security problems. The main one is the problem of mutual authentication between the smart card and the fixed terminal in the presence of other, potentially malicious users. Other security problems may also arise (e.g. problems related to integrity, confidentiality and privacy).
The main technical problem is that the communication channel between the personal mobile equipement (smart card reader) and the payment terminal (point of authentication) is not secure. When the card reader is built in or physically connected (with a short wire) to a fixed payment terminal, e.g. in a point-of-sale, then the messages and payment orders sent between the card and the terminal cannot be eavesdropped, modified, replayed, etc. by an attacker. This would require physical access to the terminal, the card reader, or the wire that connects them. Moreover, after initial mutual authentication, the card and the terminal can be sure that the messages they receive during the rest of the session come from the other party. When the communication between the smart card and the terminal is based on wireless technologies, then an attacker could eavesdrop and replay messages or payment orders between them, and the card and the terminal can never be sure whether the messages they receive come from the other party or from other smart cards and terminals which are potentially present.
The present invention is concerned with solutions for safely using the user mobile equipment (such as a mobile phone or a personal digital assistant) as the smart card reader, or more generally as cryptographic computing means for authenticating the user when he wants to use a payment terminal. More specifically, the present invention is concerned with solutions for connecting the user mobile station to payment terminals using short distance wireless communication (e.g. Bluetooth, HomeRF or infrared), and which avoid the above-mentioned drawbacks.
According to the invention, the security problems of the prior art are solved with a new protocol that builds a secure (authentic and/or confidential) logical channel between the cryptographic computing means on the user mobile side, the payment terminal and further to the billing server. The secure logical channel is based on a secret that is exclusively shared by the smart card in the mobile equipment and the terminal, and on the application of cryptographic techniques. The main job of the inventive protocol is the safe establishment of this shared secret by involving the user as an authentic channel between the terminal and the mobile station.
The inventive protocol assumes three business roles: the user, the merchant, and the billing server. Each user is registered with at least one billing server, which maintains a billing account for the user. The user is mobile, which means that she physically moves and visits various merchant sites (e.g., shops). The user can buy goods or services from the merchant. Instead of instant payment to the merchant, the appropriate amount is charged to the billing account of the user. The billing server collects charging updates from the merchants and regularly (e.g., at the end of every month) creates one single bill for each user, which contains all the purchases of that user. In a variant embodiment, the billing server debits the money from an electronic account in the user's smart card. The billing server then distributes the appropriate shares to the merchants.
This is not much different from how credit card payment works today. The novelty of the approach is the use of short distance wireless communication technology for the communication between the user (smart card in the user's mobile equipment) and the merchant (payment terminal, e.g. point-of-sale). In traditional credit card payment, the card is often handed over to the merchant, who can read all the information on the card and potentially misuse it. In the inventive approach, the card is plugged into the personal mobile station of the user and only payment information related to the current purchase is revealed to the merchant. Another advantage is that, while in traditional credit card systems billing is performed by banks and credit card companies, in the invention, anybody can become a billing service provider, in particular any telco who has competency in billing and reputation (which usually means trust).
According to an aspect of the invention, a new unique transaction identification and the terminal name is displayed on the display of said terminal or of the mobile equipment, and entered by the user on the input means of the other of one of said payment terminals or mobile equipments. The terminal name and transaction id is used for establishing a secure channel between the mobile equipment and the payment terminal.
According to another aspect of the invention, the secure channel that is established is an authentic channel. This means that the communication parties can be sure that if they receive a message on this channel, then it comes from the other party, and it is not a fake message sent by an attacker. The protocol can also be used to prevent eavesdropping (i.e. to establish an authentic and a confidential channel). According to another aspect of the invention, the user has a smart card and a personal mobile equipment, in which the smart card can be inserted, and which has short distance wireless communication capabilities. The inventive method would, however, work as well if the user has a personal digital assistant (PDA) which has short distance wireless communication capabilities. Thus, there is no real need for smart cards. A PDA can replace the smart card, because it can assist the user by performing cryptographic operations just as the smart card does.
According to another aspect of the invention, the problems of the prior art are solved by a method for transmitting payment information between a mobile station and a payment terminal (1 1) over a short distance wireless interface (101), comprising:
-displaying an identification on the display (1 10) of said payment terminal (1 1), -manually entering said identification on the input means (103) of said mobile station,
-using said identification in a first message for starting the establishment of an authentic and confidential channel between said mobile station and said payment terminal (1 1), said channel being used for exchanging confidential payment information between said payment terminal and said mobile station.
An important characteristic of an electronic payment system is whether it is online or offline. In an online payment system, the merchant contacts the bank of the user at each purchase in order to verify the solven- cy of the user. In an offline payment system, the bank is contacted only offline (e.g., once each day) in order to update the charging information of the user. Online systems are used for high value payments and when the merchant does not trust the user. For low value payments and when the merchant trusts the user, offline systems are more efficient. The inventive solution can be used with both types of applications, and let the merchant choose whether online verification of solvency is necessary or not. The invention will be better understood with the help of the following description, given as an example, and illustrated by the figure which show.
Figure 1 illustrates the principals and the channels of a system including a smart card inserted in a mobile phone or PDA, a payment terminal and a billing server.
Figure 2 illustrates the messages which are exchanged between two partners according to the ISO/IEC 9798-3 protocol.
Figure 3 illustrates the messages and keys which are exchanged between two partners in a modification of the ISO/IEC 9798-3 protocol.
Figure 4 illustrates the messages which are exchanged for authorizing a money transfer.
Figure 5 illustrates the messages which are exchanged between the principals over the various channels in a preferred embodiment of the invention.
Principals, channels, and goals
Figure 1 illustrates the principals and the channels among them.
The principals are:
■ U: the mobile user 1
■ C: her smart card 100, e.g. a SIM-card (subscriber identification card), WIM card (WAP identification card) or UlM-card (UMTS identification card). The smart card is introduced or may be a part of a mobile equipment, e.g. a mobile phone or a PDA (not shown). The mobile equipment including the smart card is called the mobile station. ■ T: the payment terminal 11 (point-of-sale) of the merchant.
■ S: the billing server 7, which may be operated by the operator of the mobile network or by a third instance.
The physical channels are:
■ md: the display 102 of the mobile equipment containing the card (C → U)
■ mk: the keypad 103 of the mobile equipment containing the card (U → C)
■ td: the display 110 of the payment terminal 11 (T → U)
■ wl: the wireless link 101 between the smart card 100 inserted in the mobile equipment and the payment terminal 1 1 (C <-> T)
■ net: the fixed network 70 between the payment terminal 11 and the billing server 7 (T e S)
The logical channels are:
■ Sigυ: the channel realized by the digital signature with the private key of the user 1.
■ Ku the channel implemented by the encryption with the public key of the user 1.
■ Sigτ: the channel realized by the digital signature with the private key of the payment terminal 1 1.
■ Kf. the channel implemented by the encryption with the public key of the payment terminal 11. Since normally the user 1 cannot use the keyboard of the merchant's payment terminal 11, there is no direct physical channel from the user to the terminal 11.
We make the following assumptions about the channels:
• The display 102 md of the mobile equipment is authentic and timely. Authenticity means that if the mobile equipment shows a message and states that this message comes from the smart card 100, then indeed the message comes from the smart card 100. Timeliness means that the mobile equipment does not maliciously delay messages originating from the smart card 100, but displays them as the card generates them. This, of course, means that the mobile equipment is trusted: the user believes that it has not been tampered by anybody and that it behaves correctly.
• The keypad 103 mk of the mobile equipment is authentic and timely. We assume that only the user 1 of the smart card 100 can send messages to the smart card via the keypad 103 of the mobile equipment. Requiring the user 1 to enter the PIN assigned to the smart card 100 when the card is inserted in the mobile equipment or before starting a payment transaction can ensure this. Furthermore, we assume that the mobile equipment does not maliciously delay the input from the user 1, but delivers it to the card 100 as the user enters it.
• The terminal display 110 td is authentic and timely. This means that messages displayed on the screen 110 of the terminal 1 1 originates from the terminal and at the time at which they are displayed. • The wireless link 101 wl between the mobile equipment and the fixed terminal 1 1 is insecure. We assume that passive attacks (eavesdropping) and active attacks (message modification, generation and replay) are possible on the wireless link between the mobile station and the terminal.
• Sigu is an authentic channel from the smart card 100, because only the smart card knows the private key of the user 1; thus, one can be sure that messages that are signed with this private key originate from the smart card 100.
• Ky is a confidential channel to the smart card 100, because only the smart card can decrypt messages that are encrypted with the public key of the user 1. Note that neither Sigu nor Ku is a timely channel, because neither the digital signature nor the encryption alone provides any freshness guarantees.
■ net is secure. We assume that the payment terminal 11 and the billing server 7 have the means to authenticate each other and communicate securely via the network. This protection can be based on other known cryptographic protocols and mechanisms that are not addressed in this description.
■ Sigτ is an authentic channel from the payment terminal 11, because only the terminal can generate messages that are signed with the private key of the terminal.
■ Kτ is a confidential channel to the terminal, because only the terminal can decrypt messages that are encrypted with the public key of the terminal.
An objective of the invention is to find a protocol that establishes an authentic and confidential (in order to hide payment information from eavesdroppers) logical channel between the terminal 11 and the smart card 100, and further to the billing center 7, using only the already existing physical and logical channels described above, and to find a payment protocol, in which the user 1 authorizes the billing server 7 to pay the merchant for the goods or services provided and to charge the corresponding amount to her billing account. The extended ISO/IEC 9798-3 protocol
Figure 2 shows the standardized ISO/IEC 9798-3 mutual authentication protocol. Figure 3 shows an inventive extension of this protocol with key establishment functions. The ISO/IEC 9798-3 protocol is based on public key cryptography, and assumes that both participating entities A, B have a public key certificate. This is consistent with our assumptions about the existing channels between the smart card and the terminal.
The ISO/IEC 9798-3 mutual authentication protocol is illustrated in Figure 2:
A → B: rA
The initiator of the protocol A generates a fresh random number ra, and sends it to the responder B.
B → A : certBf rB, A, Sigb(rBf tM\, A)
B also generates a fresh random number rβ, and digitally signs rβ, rA and A (the identifier of A). Then it sends a message to A which contains the public key certificate certB of B, the random number rt>, the identifier of A, and the digital signature SigB(rB, fΑ, A). Upon receiving this message, A verifies the certificate and the digital signature of B. If the verifications are successful, then B is authenticated. The rationale is that a valid signature can only be generated by someone who knows the appropriate private key (i.e., B), and the data, on which the signature has been generated, is fresh (because it contains the random number rA).
A → B : certA, B, S/g fø, rB, B)
A then digitally signs rA, rB and B, and sends a message to B which contains the public key certificate of A, the identifier of B, and the digital signature Sigaζr^ rBf B). Upon receiving this message, B verifies the certificate and the digital signature of A. If the verifications are successful, then A is authenticated for similar reasons as before.
In order to extend this protocol with key establishment functions, we modify only the last message of the protocol. Before sending the last message, A randomly generates a symmetric session key k, and encrypts it with the public key Kb of B. Only the responder B will be able to decrypt this encryption. A then digitally signs the random numbers rA and rBl the identifier of B, and the session key k. When receiving this message, B first decrypts the encrypted part, and then verifies the certificate and the signature of A. If the verifications are successful, then A is authenticated. Furthermore, A and B established a shared secret key k, which represents an authentic and confidential channel between them. The modified protocol is illustrated in Figure 3.
If the signature operation is such that it reveals the data which is signed, then we require that first a cryptographic hash value is computed from the data, and then this hash value is signed with the signature operation. In this way, k is not revealed to eavesdroppers.
The payment protocol
The design of a payment protocol is based on the observation that payment is equivalent with authentication if money is represented by accounts. This means that, in the inventive payment protocol, the payment will be an authentic statement of the payer (i.e., the user), which says that she is willing to transfer a given amount from her account to the account of the payee (i.e., the merchant). The authenticity of the statement is verified by the payee, as well as the entity that handles the accounts (i.e., the billing server). The protocol is illustrated in Figure 4 and described as follows:
msgl : A → B : cert^ A, B, T-info, P-info, SigA(A, B, T-info, P-info) The payer (user's smart card 100) A digitally signs her identifier A, the identifier B of the payee B (payment terminal 11), the transaction information T-info, and the payment information P-info. It is not specified explicitly what T-info and P-info are. Typically, T-info contains a unique transaction identifier, the identifier of the service that has been provided, the date and the time of the provision, the unit price, etc. P-info contains the identifier of the billing server, the amount to be paid, an expiry date until which the payee must present this message to the billing server, etc. Upon receiving the first message, B verifies the certificate and the digital signature of A.
msg2: B → A : certB, SigB( h(msgi) )
B generates a receipt of payment by computing a cryptographic hash value h(msgι) of the first message, and generating a digital signature on the result. He then sends his certificate and the signature to A.
msg3: B → S : cert^ A, B, T-info, P-info, SigA(A, B, T-info, P-info)
Finally, B contacts the billing server S (7), and sends the first message (i.e., A's statement that she is willing to pay) to it. S verifies the signature and checks that this payment has not been processed before. Then it transfers the appropriate amount to B and updates the billing account of A. S logs the payment into an internal database for further verification purposes.
Integrated solution - payment via the short distance wireless interface
Protocol description
Putting the extended ISO/IEC 9798-3 protocol and the payment protocol above together we get the following solution which is illustrated in Figure 5:
T → U : T, T-info
The payment terminal T (11) displays the identifier T of the terminal and the transaction information T-info on the display 102 of the terminal. The transaction information contains a unique (at least with respect to this terminal) transaction identifier T-id, the identifier of the service provided, the date and the time of the provision, the price, etc.
U → C : 7", T-id
The user U (1) types in the identifier of the terminal Tand the transaction identifier T-id on the keypad 103 of the mobile equipment, which sends this information to the smart card C (100).
C → T : f, T-id, rc
The smart card 100 generates a first fresh random number rc, and sends it to the payment terminal 1 1 together with T and T-id via the wireless link 101. The terminal 11 may receive several messages from other terminals 11 and smart cards 100 that are in its communication range while waiting for this message from the smart card. It handles only the message that contains its identifier 7" and the valid transaction identifier T-id. All other messages are discarded.
T → C : certτ, rτ, Sigτ(rτ, rG T, T-id) The payment terminal 11 generates a second fresh random number rτ. It signs the random number of the smart card rc, together with its own random number rT, its identifier T, and the transaction identifier T- id. It then sends its certificate certr, its random number rτ, and the digital signature to the smart card 100. The smart card verifies the certificate and the signature of the terminal. Besides having a valid signature on it, the certificate should contain the terminal identifier 7" that has been typed in by the user on the keypad of the mobile equipment. If the verifications are all successful, then the payment terminal 11 is authenticated.
C → T : certu, {k}κτ, Sigu(rG rτ, T, T-id, k)
The smart card 100 generates a random symmetric key k and encrypts it with the public key Kτ of the payment terminal 11. This public key is obtained from the certificate of the terminal. The smart card 100 signs the random numbers ty and rc, the identifiers T and T-id, and the freshly generated symmetric key k. Then it sends the certificate of the user certu, the encrypted symmetric key and the digital signature to the terminal. If the signature does not hide the data that is signed, then in a variant embodiment the signed data is hashed with a cryptographic hash function before being signed. The terminal decrypts the encrypted part and verifies the certificate and the signature of the smart card 100. If the verifications are successful, then the user's smart card is authenticated to the terminal. Furthermore, the smart card and the payment terminal established a shared symmetric session key k.
T → C : { T, T-info }k
The payment terminal 11 sends its identifier and the transaction information, which has been displayed to the user on the display 110 of the payment terminal 11, to the smart card 100. This messages is encrypted with the shared session key k. Since only the payment terminal 11 knows this key (apart from the smart card 100, of course), the smart card believes that this message is sent by the terminal. C → U : 7", T-info
The smart card 100 displays the received information on the display 102 of the mobile equipment. The user 1 verifies it and compares it to the information that is displayed by the payment terminal 11 on its display 110.
U → C : confirmation
If the information displayed by the mobile equipment matches the information displayed by the terminal 11, then the user 1 confirms (e.g., she pushes the OK button on the mobile equipment).
C → T : { U, T, T-info, P-info, Sigu(U, T, T-info, P-info) }k
The smart card 100 generates the payment message, which contains the identifiers of the user and the merchant's payment terminal, the transaction information, and the payment information, and it is digitally signed by the smart card 100 with the private key of the user. If the signature does not hide the data that is signed, then we require that first the data is hashed with a cryptographic hash function, and the hash value is signed with the private key of the user. The payment message is encrypted with the session key k, and sent to the terminal. This encryption hides the payment information from attackers. Upon receiving this message, the terminal 11 decrypts it, and verifies the digital signature.
T → S : verification
If the merchant does not trust the user 1 or the payment is a high-value payment, then the terminal 11 can now contact the billing server 7, or a certification revocation list server, to check the solvency of the user 1 (online solvency check).
T → C : {SigT(h( U, T, T-info, P-info, Sigu(U, T, T-info, P-info) ) )}k The terminal 11 generates a payment receipt by computing the cryptographic hash value of the payment message (without the encryption) using some publicly known cryptographic hash function h, and signing the hash value. The payment receipt is encrypted with the session key k, and sent to the smart card 100.
T → S : certu, U, T, T-info, P-info, Sigy(U, T, T-info, P-info)
Finally, the terminal 11 contacts the billing server 7, and presents the payment message received from the user 1. This message is sent via a channel 70 (net), the security of which is provided by means outside of the scope of this report. The billing server 7 verifies the certificate and the signature of the user. It then checks that this payment has not been processed before by looking up its internal log database. If the verifications are successful, then the billing server transfers the appropriate amount to the merchant and updates the billing account of the user. It also logs the transaction into its internal log database.
Certificate management
Public key infrastructure
The method preferably uses an underlying public key infrastructure. Public key certificates may be issued by certification authorities (CAs), which may be hierarchically organized. Revocated certificates may be listed on a certificate revocation list (CRL).
In a preferred embodiment, we use the following scheme:
■ for high value payments, the user checks the certificate of the merchant against the CRL;
■ for low value payments, the user does not perform any revocation checks; ■ for high value payments and for low value payments in case the merchant does not trust the user, the merchant checks the user's certificate against the online CRL via the fixed network;
■ for low value payments in case the merchant trusts the user, the merchant checks its local copy of the CRL that it updates regularly from the online CRL server.
Achievements
The terminal 11 (the smart card 100) believes that the smart card 100 (the terminal 1 1) has recently sent a message (repeated its random number), which means that both should be present (authentication). The smart card and the terminal believe that k is a shared secret key between them (key establishment). The terminal 11 and the billing server 7 believe that the user 1 authorized the payment. There is a subtle difference: the terminal 1 1 believes that the user's authorization is fresh (since it arrives encrypted with the fresh secret key), but the billing server 7 cannot be sure about the freshness of this authorization. That is why we require the server 7 to look at its internal log database and check that this authorization has never been processed before.
Conclusion
In this section, we presented a payment protocol that can be used to perform electronic payments over a short distance wireless interface. The protocol has two phases: (1 ) it establishes an authentic and confidential channel between the smart card of the user and the payment terminal of the merchant, and (2) it provides the means to authorize transfer of money from the account of the user to the account of the merchant. Accounts are managed by a trusted third party, which is called billing server. Implementation guidelines
The wireless link 101 between the smart card 100 in the user's equipment and the terminal 1 1 can be based on radio or infrared communications. We assumed the existence of an appropriate addressing scheme, which makes it possible to send a message directly to an intended receiver if its address is known, and an appropriate MAC (Multiple Access Channel) algorithm, which governs access to the shared radio channel. We did not assume, however, that a party knows the MAC address of another party when beginning a transaction with it. We designed the protocol in a way that it can perform address resolution functions seamlessly. For this reason, the first message that is sent over the wireless link 101 is a broadcast message, which is received by every payment terminal 1 1 within the communication range of the user's 1 mobile equipment. This first message always contains enough information for a receiver 1 1 to decide whether it has to take care of it, or whether it is a message for someone else. The intended receiver can, thus, recognize which broadcast message is sent to it and respond to it. Since the broadcast message can contain the MAC address of the sender, the receiver can send the response directly to the sender. The response can also contain the MAC address of its sender (the MAC address of the intended receiver of the broadcast message). Thus, after the first message exchange, both communicating parties know the address of the other and can send messages directly to each other.
The protocol may be implemented with software in the terminal 1 1 and in the smart card 100 implemented with current cryptographic libraries. On the terminal side an example is the ABA JCE library, which is a pure Java implementation of the JCE (Java Cryptography Extension) interface defined by Sun Microsystems Inc. On the smart card side an example is an implementation of the Java Card interface.
Random number generation
Both the smart card 100 and the payment terminal 1 1 must generate fresh random numbers. These numbers should be generated by the pseudo-random number generator (PRNG) available in the cryptographic library. This PRNG is represented by the SecureRandom class, which is part of the JCE interface. As the security of the method depends on the quality of the random number, seeding of the PRNG must be solved carefully.
Seeding the PRNG may be a problem on the smart card, because multi-threading is not allowed on most cards (i.e., self-seeding cannot be used) and capturing random events does not seem to be easy either. One solution can be that the mobile equipment creates the seed possibly using random events generated by the user.
Choice of the asymmetric key scheme
This choice is determined by the number of public and private key operations performed by the smart card. The smart card 100 performs 1 public key encryption, 3 digital signature verifications, and 2 digital signature generations. This means 4 public key and 2 private key operations. Therefore, we suggest a scheme in which public key operations require less computation than private key operations. Such a scheme is RSA, which can be used for both encryption and digital signature, and which is available in the cryptographic library. For digital signature, we suggest to use MD5 with RSA, which hides the data that is signed.
Choice of the symmetric key encryption algorithm
The protocol uses symmetric key encryption to protect payment information from eavesdroppers. Any kind of block cipher algorithm can be used for this purpose. We suggest to use IDEA in CBC mode. We will now describe an example of the pseudo-code which may be run by the computing means in the smart card 100 and by the payment terminal 11 in order to carry out this payment protocol. The one skilled in the art will be able to write the necessary modules in the smart card and in the terminal 11 which correspond to those pseudo-codes.
Pseudo-code run by the smart card 100
One time setup: initialize the PRNG with a truly random seed
1. Input the terminal ID and the transaction ID on the keyboard 103 of the mobile equipment: T, T-id
2. Get next random from the PRNG: rc
3. Broadcast T, T-id, rc >
4. Listen on the wireless interface 101 until a message arrives: M2
5. If M2 = cert, r, sig (M2 has the right format), then go to step 6, else listen further on the wireless interface until a message M2 with the expected format arrives. If a timeout occurs before M2 has been received, raise an exception and stop.
6. If cert is the certificate of 7" and it is correct, then go to step 7 else listen further on the wireless interface until a message M2 with a correct certificates arrives. If a timeout occurs before M2 has been received, raise an exception and stop.
7. If sig = Sigτ(rτ, rG T, T-id), then go to step 8, else listen further on the wireless interface until a message M2 with a correct signature arrives. If a timeout occurs before M2 has been received, raise an exception and stop.
8. Get next random from the PRNG: k 9. Extract the public key from cert Kγ
10. Encrypt k with Kτ: {k}κτ
11. Sign rG r, T, T-id, k : Sigυ(r rτ, T, T-id, k)
12. Send certu, {k}Kτ, Sigυ(r rτ, T, T-id, k) to the sender of M2
13. Listen on the wireless interface 101 until a message arrives: 4
14. Try to decrypt M4 with k: P4
15. If P4 = T, T-info, then go to step 16, else listen further on the wireless interface until a message M4 with the expected format arrives. If a timeout occurs before M4 has been received, raise an exception and stop
16. Display T, T-info on the display 102 of the mobile equipment
17. Wait until the user 1 responds on the keypad 103: resp
18. If resp = yes then go to step 19, else go to step 25
19. Sign U, T, T-info, P-info: Sigu(U, T, T-info, P-info)
20. Encrypt P5 = U, T, T-info, P-info, Sigυ(U, T, T-info, P-info) with k
21. Send {U, T, T-info, P-info, Sigυ(U, T, T-info, P-info)}k to the sender of M4
22. Listen on the wireless interface 101 until a message arrives: 6"
23. Try to decrypt M6 with k: P6 24. If P6 = SigT(h(P5)), then store P6 and go to step 25, else listen further on the wireless interface until a message M6 with the expected format arrives. If a timeout occurs before M6 has been received, raise an exception and stop.
25. End of protocol
Pseudo-code run by the payment terminal 11
One time setup: initialize the PRNG with a truly random seed
1. Display the terminal ID and the transaction information on the display 110
2. Listen on the wireless interface 101 until a broadcast message arrives: M1
3. If M1 = T, T-id, r, where 7" is the terminal ID and T-id is the current transaction ID, then go to step 4, else go to step 2
4. Get next random from the PRNG: rτ
5. Sign rτ, rG T, T-id : Sigτ(rτ, r, T, T-id)
6. Send certτ, rτ, Sigτ(rτ, r T, T-id) to the sender of M1
7. Listen on the wireless interface 101 until a message arrives: M3
8. If M3 = cert, C, sig (M3 has the right format), then go to step 9, else listen further on the wireless interface until a message M3 with the expected format arrives. If a timeout occurs before M3 has been received, raise an exception and stop. 9. If cert is correct, then go to step 10, else listen further on the wireless interface until a message M3 with a correct certificate arrives. If a timeout occurs before M3 has been received, raise an exception and stop.
10. Decrypt C with the private key of the payment terminal 11 : k
11. If sig = Sigu(r, rτ, T, T-id, k), then go to step 12, else listen further on the wireless interface until a message M3 with a correct signature arrives. If a timeout occurs before M3 has been received, raise an exception and stop
12. Encrypt the terminal ID and the transaction information with k: { T, T-info }k
13. Send { T, T-info }k to the sender of M3
14. Listen on the wireless interface 101 until a message arrives:/V75
15. Try to decrypt M5 with k: P5
16. If P5 = U, T, T-info, P-info, sig, then go to step 17, else listen further on the wireless interface until a message M5 with the expected format arrives. If a timeout occurs before M5 has been received, raise an exception and stop.
18. If sig = Sigu(U, T, T-info, P-info), then go to step 19, else listen further on the wireless interface until a message M5 with the a correct signature arrives. If a timeout occurs before M5 has been received, raise an exception and stop.
19. Check solvency of user by contacting the billing server 7 if necessary.
20. Compute the hash of PS and sign it: Sig-rf h(P5) ) 21. Encrypt the signature with k : {SigT(h(P5) )}k
22. Send { Sigτ( h(P5) )}k to the sender of M5
23. End of protocol
offline : Send certu, U, T, T-info, P-info, Sigu(U, T, T-info, P-info) to the billing server.
In the described embodiment, an authentic and confidential channel is established between the user's mobile equipment and the payment terminal by first displaying the terminal name and a new unique transaction id on the display of the payment terminal and then entering manually the terminal name and the transaction id on the keypad of the mobile equipment. The one skilled in the art will however understand that, when the user has access to the keyboard or other input means of the payment terminal, an authentic and confidential channel can be built by displaying the unique transaction id on the display of the mobile equipment and then entering manually the mobile id and transaction id in the payment terminal.
Although the embodiments of the invention described with reference to the drawings comprise equipments such as terminals, smart cards and mobile equipments, and methods performed in or by such equipments, the invention also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the invention into practice. The program may be in the form of source code, object code, a code intermediate source and object code such as in partially compiled form, or in any other form suitable for use in the implementation of the methods and protocols according to the invention. The carrier may be any entity or device capable of carrying the program.
For example, the carrier may comprise a storage medium, such as a ROM, for example a CD-ROM or a semiconductor ROM, for example an EEPROM, or a magnetic or optical recoding medium, for example a floppy disc, hard disk or smart card. Further, the carrier may be a transmissible carrier such as an electrical or optical signal which may be conveyed via electrical or optical cable or by radio or other means.
When the program is embodied in a signal which may be conveyed by a cable or other device or means, the carrier may be constituted by such cable or other device or means. Alternatively, the carrier may be an integrated circuit in which the program is embedded, for example a memory in the terminal 11, in the mobile equipment or in the smart card 100.

Claims

Claims
1. Method for transmitting payment information between a mobile equipment and a payment terminal (11) over a short distance wireless interface (101), comprising: -displaying an identification on the display (110) of said payment terminal (11),
-manually entering said identification on the input means (103) of said mobile equipment,
-using said identification in a first message (M1) for starting the establishment of an authentic and confidential channel between said mobile equipment and said payment terminal (11) said channel being used for exchanging confidential payment information between said payment terminal and said mobile equipment.
2. Method according to claim 1, said identification being used for verifying an electronic certificate subsequently sent by said payment terminal.
3. Method according to the preceding claim, wherein said identification comprises the payment terminal name and/or a transaction id
4. Method according to the preceding claim, wherein said transaction id (T-id) is generated in said payment terminal (11), said first message identified with said transaction id comprising a first random number (rc), said first random number assuring freshness in a mutual authentication exchange between said mobile equipment and said payment terminal (1 1) for exchanging an authenticated symmetric session key (k), said key being used for encrypting said payment information.
5. Method according to the preceding claim, further comprising: -preparing in said payment terminal (1 1) a second message
(M2) containing said transaction identifier (T-id) and a terminal random number 0τ), and signing it with the payment terminal private key (Sigτ), -sending this message to said mobile equipment over said wireless interface (101),
-verifying in said mobile equipment said transaction identifier (T-id) and the signature (Sigτ) of said payment terminal (11) with said identification , -using said terminal random number 0τ) for verifying the freshness of at least one subsequent message from said mobile equipment to said payment terminal (11).
6. Method according to the preceding claim, wherein said subsequent message authenticated with said terminal random number (r-r) comprises said symmetric session key (k).
7. Method according to one of the claims 5 or 6, wherein said message sent by said payment terminal further comprises said first random number (rc) generated in said mobile equipment.
8. Method according to one of the preceding claims, further com- prising a step of verifying the public key of the user with a user revocation list.
9. Method according to claim 1, wherein said authentic and confidential channel is established with the following steps:
-generating in said mobile equipment a first random word (rc), -sending said first random word (rc) to said payment terminal,
-generating in said payment terminal (1 1) a second random
Figure imgf000029_0001
-generating in said payment terminal (1 1) a first signature of said first random word, of said second random word, of the identifier of said payment terminal (T) and of the transaction id (T-id)
-sending to said mobile equipment a certificate of said terminal (certτ), said second random word (rτ) and said first signature,
-generating in said mobile equipment a session key (k) and encrypting it with the public key of said terminal (kγ), -generating in said mobile equipment a second signature of said first random word (rc), of said second random word (r-r), of the identifier of said terminal (T), of the transaction identifier (T-id) and of said session key (k),
-sending said encrypted session key, said second signature and a user certificate (certu) to said terminal, -decrypting said session key in said payment terminal (11),
-verifying in said payment terminal said certificate and the signature of the user,
-if the verifications are successful, using said session key (k) as a shared symmetric session key for securing ulterior messages between said mobile equipment and said payment terminal (11).
10. Smart card (100) having thereon a computer program comprising instructions to be executed by processing means in said smart card for causing the smart card to perform a process comprising at least the following steps: -waiting for an identification (for example T, T-id) to be manually entered in the mobile equipment containing the smart card and transmitted to the smart card,
-preparing an instruction for sending a first message (M1) containing said identification over a short distance wireless interface (101), -waiting for a second message (M2) received over said wireless interface,
-verifying if a certificate (certτ) contained in said second message contains said identification (T).
11. Smart card according to the preceding claim, wherein said second message (M2) further comprises a first random number (rc) used for verifying the freshness of subsequent received messages.
12. Smart card according to the preceding claim, wherein said process further comprises:
-generating a random session key (k), -encrypting said session key with the payment terminal public key contained in said payment terminal certificate,
-preparing an instruction for sending a third message (M3) comprising said encrypted session key over said short distance wireless interface.
13. Smart card according to the preceding claim, said third message further comprising a certificate (certu) of the user of said smart card.
14. Smart card according to the preceding claim, said third message (M3) further comprising a signature of said answer.
15. Smart card according to one of the claims 10 to 14, further comprising a GSM-part.
16. A computer program on a carrier and comprising computer executable instructions for causing a terminal (1 1) including a short distance wireless interface (101) to execute a process comprising the following steps:
-generating a transaction identifier (T-id), -displaying said transaction identifier,
-waiting for a first message (M 1) comprising said transaction identifier (T-id) over said short distance wireless interface,
-sending a second message (M2) containing a certificate of said terminal to the sender of said answer (M 1).
17. Computer program on a carrier according to the preceding claim, said process further comprising:
-extracting a first random number (rc) from said first message (M1),
-using said first random number in a mutual authentication exchange over said short distance wireless interface,
-extracting an authenticated symmetric session key (k) from a subsequent message, said key being used for encrypting payment orders exchanged over said short distance wireless interface.
18. Computer program on a carrier according to the preceding claim, wherein said second message (M2) further comprises a second random number (rr) said first random number (rc), said second random number (r-r) and said transaction identifier (T-id), said second message being signed.
19. Computer program on a carrier according to one of the claims 16 to 18, wherein said process further comprises:
-sending payment information exchanged with said sender to a billing server (7).
PCT/EP2001/004579 2000-04-28 2001-04-23 Method for transmitting payment information between a terminal and a third equipment WO2001084763A2 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP01943278A EP1277301B1 (en) 2000-04-28 2001-04-23 Method for transmitting payment information between a terminal and a third equipement
DE60104411T DE60104411T2 (en) 2000-04-28 2001-04-23 METHOD FOR TRANSMITTING A PAYMENT INFORMATION BETWEEN A TERMINAL AND A THIRD DEVICE
AT01943278T ATE271733T1 (en) 2000-04-28 2001-04-23 METHOD FOR TRANSMITTING PAYMENT INFORMATION BETWEEN A TERMINAL AND A THIRD DEVICE
AU65897/01A AU6589701A (en) 2000-04-28 2001-04-23 Method for transmitting payment information between a terminal and a third equipment

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP00109220 2000-04-28
EP00109220.4 2000-04-28

Publications (2)

Publication Number Publication Date
WO2001084763A2 true WO2001084763A2 (en) 2001-11-08
WO2001084763A3 WO2001084763A3 (en) 2002-03-28

Family

ID=8168586

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/EP2000/009121 WO2001084761A1 (en) 2000-04-28 2000-09-18 Method for securing communications between a terminal and an additional user equipment
PCT/EP2001/004579 WO2001084763A2 (en) 2000-04-28 2001-04-23 Method for transmitting payment information between a terminal and a third equipment

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/EP2000/009121 WO2001084761A1 (en) 2000-04-28 2000-09-18 Method for securing communications between a terminal and an additional user equipment

Country Status (6)

Country Link
US (1) US7409552B2 (en)
EP (2) EP1277299B1 (en)
AT (2) ATE472208T1 (en)
AU (2) AU2000275203A1 (en)
DE (2) DE60044586D1 (en)
WO (2) WO2001084761A1 (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1486022A2 (en) * 2002-03-19 2004-12-15 Mastercard International, Inc. Method and system for conducting a transaction using a proximity device
EP1695563A2 (en) * 2003-12-16 2006-08-30 Infocus Corporation Security for wireless transmission
US7311246B2 (en) 2004-11-26 2007-12-25 Sony Corporation Method and system for transmitting electronic value information
WO2009108523A2 (en) 2008-02-26 2009-09-03 Motorola, Inc. Method and system for mutual authentication of nodes in a wireless communication network
WO2012002852A1 (en) * 2010-06-29 2012-01-05 Telefonaktiebolaget L M Ericsson (Publ) Methods, server, merchant device, computer programs and computer program products for setting up communication
WO2013045743A3 (en) * 2011-09-28 2013-06-13 Onsun Oy Payment system
FR3026875A1 (en) * 2014-10-01 2016-04-08 Avencis METHODS FOR CONFIGURING A TERMINAL DEVICE CONNECTED TO A NETWORK TO ENABLE STRONG AUTHENTICATION OF A USER
US9672515B2 (en) 2000-03-15 2017-06-06 Mastercard International Incorporated Method and system for secure payments over a computer network

Families Citing this family (89)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6816968B1 (en) * 1998-07-10 2004-11-09 Silverbrook Research Pty Ltd Consumable authentication protocol and system
US7409543B1 (en) * 2000-03-30 2008-08-05 Digitalpersona, Inc. Method and apparatus for using a third party authentication server
US6824064B2 (en) * 2000-12-06 2004-11-30 Mobile-Mind, Inc. Concurrent communication with multiple applications on a smart card
US7975139B2 (en) * 2001-05-01 2011-07-05 Vasco Data Security, Inc. Use and generation of a session key in a secure socket layer connection
US7444513B2 (en) 2001-05-14 2008-10-28 Nokia Corporiation Authentication in data communication
US8209753B2 (en) * 2001-06-15 2012-06-26 Activcard, Inc. Universal secure messaging for remote security tokens
US20040218762A1 (en) 2003-04-29 2004-11-04 Eric Le Saint Universal secure messaging for cryptographic modules
US7571257B2 (en) * 2001-07-31 2009-08-04 Guthery Scott B Communications network with smart card
US7362869B2 (en) 2001-12-10 2008-04-22 Cryptomathic A/S Method of distributing a public key
ES2417479T3 (en) * 2002-02-13 2013-08-08 Passlogy Co., Ltd. User authentication procedure and user authentication system
WO2003077581A1 (en) * 2002-03-08 2003-09-18 Sony Ericsson Mobile Communications Ab Security protection for data communication
DE10216601A1 (en) * 2002-04-15 2003-10-30 Giesecke & Devrient Gmbh Program assurance procedures
EP1397014A1 (en) 2002-09-04 2004-03-10 SCHLUMBERGER Systèmes WIM (WAP Identification module) Primitives for handling the secure socket layer protocol (SSL)
US7853788B2 (en) 2002-10-08 2010-12-14 Koolspan, Inc. Localized network authentication and security using tamper-resistant keys
US7574731B2 (en) * 2002-10-08 2009-08-11 Koolspan, Inc. Self-managed network access using localized access management
US7325134B2 (en) 2002-10-08 2008-01-29 Koolspan, Inc. Localized network authentication and security using tamper-resistant keys
US7607015B2 (en) 2002-10-08 2009-10-20 Koolspan, Inc. Shared network access using different access keys
US7895443B2 (en) * 2002-11-05 2011-02-22 Safenet, Inc. Secure authentication using hardware token and computer fingerprint
EP1561301B1 (en) * 2002-11-08 2008-01-09 Nokia Corporation Software integrity test in a mobile telephone
US20040156367A1 (en) * 2003-02-11 2004-08-12 Magis Networks, Inc. Hierarchically distributed scheduling apparatus and method
CN1774687A (en) * 2003-04-14 2006-05-17 松下电器产业株式会社 Client end server authenticationn using challenge response principle
US8270609B2 (en) * 2003-06-13 2012-09-18 Broadcom Corporation Mechanism for secure transmission of signals in wireless communication devices
US20050021940A1 (en) * 2003-06-13 2005-01-27 Kenneth Ma Authentication mechanism for wireless communication devices
US7934005B2 (en) * 2003-09-08 2011-04-26 Koolspan, Inc. Subnet box
US7827409B2 (en) * 2003-10-07 2010-11-02 Koolspan, Inc. Remote secure authorization
US7725933B2 (en) * 2003-10-07 2010-05-25 Koolspan, Inc. Automatic hardware-enabled virtual private network system
KR100661313B1 (en) * 2003-12-03 2006-12-27 한국전자통신연구원 Multimedia communication system based on session initiation protocol capable of providing mobility using lifelong number
US7409715B2 (en) * 2003-12-10 2008-08-05 Alcatel Lucent Mechanism for detection of attacks based on impersonation in a wireless network
US7549048B2 (en) * 2004-03-19 2009-06-16 Microsoft Corporation Efficient and secure authentication of computing systems
US7853793B2 (en) * 2004-05-03 2010-12-14 Piotr Cofta Trusted signature with key access permissions
EP1747639A1 (en) * 2004-05-19 2007-01-31 France Telecom Method and system for generating a list signature
EP1622333A1 (en) * 2004-07-29 2006-02-01 Sun Microsystems France S.A. Method and apparatus for minimally onerous and rapid authentification
WO2006027430A1 (en) * 2004-08-16 2006-03-16 France Telecom Method for carrying out authentication between entities communicating with one another over a telecommunications network
JP4736398B2 (en) * 2004-10-22 2011-07-27 日本電気株式会社 Authentication method between secret terminals, secret information delivery method, apparatus, system, and program
US8117452B2 (en) * 2004-11-03 2012-02-14 Cisco Technology, Inc. System and method for establishing a secure association between a dedicated appliance and a computing platform
JPWO2006082907A1 (en) * 2005-02-04 2008-06-26 ソフトバンクＢｂ株式会社 Electronic money settlement system and electronic money settlement method
CN101120351B (en) * 2005-02-18 2010-10-06 Rsa安全公司 Derivative seeds distribution method
US9143323B2 (en) * 2005-04-04 2015-09-22 Blackberry Limited Securing a link between two devices
US7356539B2 (en) 2005-04-04 2008-04-08 Research In Motion Limited Policy proxy
US8316416B2 (en) 2005-04-04 2012-11-20 Research In Motion Limited Securely using a display to exchange information
ATE357098T1 (en) * 2005-04-04 2007-04-15 Research In Motion Ltd SECURING A COMMUNICATIONS CONNECTION BETWEEN DEVICES.
US7827376B2 (en) * 2005-06-27 2010-11-02 Lenovo (Singapore) Pte. Ltd. System and method for protecting hidden protected area of HDD during operation
US7836306B2 (en) * 2005-06-29 2010-11-16 Microsoft Corporation Establishing secure mutual trust using an insecure password
EP1752937A1 (en) 2005-07-29 2007-02-14 Research In Motion Limited System and method for encrypted smart card PIN entry
GB2435951A (en) * 2006-02-23 2007-09-12 Barclays Bank Plc System for PIN servicing
US8670566B2 (en) * 2006-05-12 2014-03-11 Blackberry Limited System and method for exchanging encryption keys between a mobile device and a peripheral output device
DE102006028938B3 (en) * 2006-06-23 2008-02-07 Siemens Ag Method for transmitting data
US7958368B2 (en) * 2006-07-14 2011-06-07 Microsoft Corporation Password-authenticated groups
US8341411B2 (en) * 2006-08-16 2012-12-25 Research In Motion Limited Enabling use of a certificate stored in a smart card
US20080046739A1 (en) * 2006-08-16 2008-02-21 Research In Motion Limited Hash of a Certificate Imported from a Smart Card
FR2910666B1 (en) * 2006-12-26 2013-02-08 Oberthur Card Syst Sa PORTABLE ELECTRONIC DEVICE AND METHOD OF SECURING SUCH A DEVICE
US8307411B2 (en) * 2007-02-09 2012-11-06 Microsoft Corporation Generic framework for EAP
KR100858146B1 (en) 2007-02-21 2008-09-10 주식회사 케이티프리텔 Method for personal authentication using mobile and subscriber identify module and device thereof
US20100293379A1 (en) * 2007-05-31 2010-11-18 Beijing Transpacific Ip Technology Development Ltd method for secure data transmission in wireless sensor network
US7907735B2 (en) 2007-06-15 2011-03-15 Koolspan, Inc. System and method of creating and sending broadcast and multicast data
US8348155B2 (en) * 2007-09-21 2013-01-08 Telefonaktiebolaget L M Ericsson (Publ) All in one card
CA2630388A1 (en) * 2008-05-05 2009-11-05 Nima Sharifmehr Apparatus and method to prevent man in the middle attack
EP2160030B1 (en) * 2008-08-27 2016-12-21 Irdeto B.V. Multi-vendor conditional access system
ES2365887B1 (en) * 2009-05-05 2012-09-03 Scytl Secure Electronic Voting S.A. METHOD OF VERIFICATION OF DEFRYING PROCESSES
DE102009027681A1 (en) * 2009-07-14 2011-01-20 Bundesdruckerei Gmbh Method and reading attributes from an ID token
EP2383955B1 (en) 2010-04-29 2019-10-30 BlackBerry Limited Assignment and distribution of access credentials to mobile communication devices
US8644515B2 (en) * 2010-08-11 2014-02-04 Texas Instruments Incorporated Display authenticated security association
DE102010035098A1 (en) * 2010-08-23 2012-02-23 Giesecke & Devrient Gmbh Method for authenticating a portable data carrier
US8839357B2 (en) * 2010-12-22 2014-09-16 Canon U.S.A., Inc. Method, system, and computer-readable storage medium for authenticating a computing device
US9589256B1 (en) 2011-04-07 2017-03-07 Wells Fargo Bank, N.A. Smart chaining
US9292840B1 (en) 2011-04-07 2016-03-22 Wells Fargo Bank, N.A. ATM customer messaging systems and methods
US9087428B1 (en) 2011-04-07 2015-07-21 Wells Fargo Bank, N.A. System and method for generating a customized user interface
JP5867875B2 (en) * 2011-07-11 2016-02-24 武 水沼 Signature verification program
US10263782B2 (en) * 2011-10-12 2019-04-16 Goldkey Corporation Soft-token authentication system
EP2611070A1 (en) * 2011-12-28 2013-07-03 Gemalto SA Method for establishing secure card history and audit for property hand-over
US9642005B2 (en) * 2012-05-21 2017-05-02 Nexiden, Inc. Secure authentication of a user using a mobile device
US20130311382A1 (en) 2012-05-21 2013-11-21 Klaus S. Fosmark Obtaining information for a payment transaction
JP2014048414A (en) * 2012-08-30 2014-03-17 Sony Corp Information processing device, information processing system, information processing method and program
US9398448B2 (en) * 2012-12-14 2016-07-19 Intel Corporation Enhanced wireless communication security
CN103208151B (en) * 2013-04-03 2016-08-03 天地融科技股份有限公司 Process the method and system of operation requests
JP6187251B2 (en) * 2013-12-27 2017-08-30 富士通株式会社 Data communication method and data communication apparatus
CN103987037A (en) * 2014-05-28 2014-08-13 大唐移动通信设备有限公司 Secret communication implementation method and device
US9609512B2 (en) * 2014-10-09 2017-03-28 Userstar Information System Co., Ltd. Wireless authentication system and wireless authentication method
US9317845B1 (en) 2014-12-23 2016-04-19 Mastercard International Incorporated Flexible electronic payment transaction process
EP3048776B2 (en) * 2015-01-22 2021-03-17 Nxp B.V. Methods for managing content, computer program products and secure element
DE102015006751A1 (en) * 2015-05-26 2016-12-01 Giesecke & Devrient Gmbh Method for providing a personal identification code of a security module
DE102015225792B3 (en) * 2015-12-17 2017-04-13 Volkswagen Aktiengesellschaft A method and system for secure communication between a mobile device coupled to a smartphone and a server
US10084797B2 (en) * 2016-10-03 2018-09-25 Extreme Networks, Inc. Enhanced access security gateway
CN109891416A (en) * 2016-10-27 2019-06-14 株式会社电装 For authenticating and the system and method for authorization device
CN106533669B (en) * 2016-11-15 2018-07-13 百度在线网络技术（北京）有限公司 The methods, devices and systems of equipment identification
CN111954878A (en) 2018-04-10 2020-11-17 维萨国际服务协会 System and method for secure device connection
KR102009863B1 (en) * 2018-12-05 2019-08-12 주식회사 후본 System for entrance security and method using the same
FR3092414B1 (en) * 2019-02-01 2021-01-08 Idemia Identity & Security France Authentication process, server and electronic identity device
JP7394867B2 (en) * 2019-05-10 2023-12-08 エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハー Methods and systems for device identification and monitoring

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999044114A1 (en) * 1998-02-25 1999-09-02 Telefonaktiebolaget Lm Ericsson Method, arrangement and apparatus for authentication through a communications network

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4637051A (en) * 1983-07-18 1987-01-13 Pitney Bowes Inc. System having a character generator for printing encrypted messages
US5001752A (en) * 1989-10-13 1991-03-19 Fischer Addison M Public/key date-time notary facility
DE69433509T2 (en) * 1994-10-27 2004-12-23 International Business Machines Corp. METHOD AND DEVICE FOR SAFE IDENTIFICATION OF A MOBILE PARTICIPANT IN A COMMUNICATION NETWORK
CA2192017C (en) * 1995-12-08 2000-04-25 Masayuki Ohki Ic card reader/writer and method of operation thereof
US6173400B1 (en) * 1998-07-31 2001-01-09 Sun Microsystems, Inc. Methods and systems for establishing a shared secret using an authentication token

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999044114A1 (en) * 1998-02-25 1999-09-02 Telefonaktiebolaget Lm Ericsson Method, arrangement and apparatus for authentication through a communications network

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
FRIEDRICHS B: "AUTHENTISCHE UND ZUVERLASSIGE MOBILKOMMUNIKATION FUR SICHERHEITSRELEVANTE ANWENDUNGEN AUTHENTIC AND RELIABLE MOBILE COMMUNICATION FOR SAFETY-RELATED APPLICATIONS PART 1: REQUIREMENTS AND BASIC ALGORITHMS" FREQUENZ,DE,SCHIELE UND SCHON GMBH. BERLIN, vol. 49, no. 1/02, 1995, pages 17-27, XP000503766 ISSN: 0016-1136 *
HAARTSEN J C: "THE BLUETOOTH RADIO SYSTEM" IEEE PERSONAL COMMUNICATIONS,IEEE COMMUNICATIONS SOCIETY,US, vol. 7, no. 1, February 2000 (2000-02), pages 28-36, XP000908653 NEW YORK ISSN: 1070-9916 *

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9672515B2 (en) 2000-03-15 2017-06-06 Mastercard International Incorporated Method and system for secure payments over a computer network
EP1486022A2 (en) * 2002-03-19 2004-12-15 Mastercard International, Inc. Method and system for conducting a transaction using a proximity device
EP1486022A4 (en) * 2002-03-19 2010-03-31 Mastercard International Inc Method and system for conducting a transaction using a proximity device
EP1695563A4 (en) * 2003-12-16 2010-12-29 Seiko Epson Corp Security for wireless transmission
EP1695563A2 (en) * 2003-12-16 2006-08-30 Infocus Corporation Security for wireless transmission
US7311246B2 (en) 2004-11-26 2007-12-25 Sony Corporation Method and system for transmitting electronic value information
WO2009108523A2 (en) 2008-02-26 2009-09-03 Motorola, Inc. Method and system for mutual authentication of nodes in a wireless communication network
US8001381B2 (en) 2008-02-26 2011-08-16 Motorola Solutions, Inc. Method and system for mutual authentication of nodes in a wireless communication network
WO2009108523A3 (en) * 2008-02-26 2009-10-22 Motorola, Inc. Method and system for mutual authentication of nodes in a wireless communication network
WO2012002852A1 (en) * 2010-06-29 2012-01-05 Telefonaktiebolaget L M Ericsson (Publ) Methods, server, merchant device, computer programs and computer program products for setting up communication
US10007904B2 (en) 2010-06-29 2018-06-26 Telefonaktiebolaget Lm Ericsson (Publ) Methods, server, merchant device, computer programs and computer program products for setting up communication
US10248946B2 (en) 2010-06-29 2019-04-02 Telefonaktiebolaget Lm Ericsson (Publ) Methods, server, merchant device, computer programs and computer program products for setting up communication
WO2013045743A3 (en) * 2011-09-28 2013-06-13 Onsun Oy Payment system
US9953319B2 (en) 2011-09-28 2018-04-24 Unito Oy Payment system
FR3026875A1 (en) * 2014-10-01 2016-04-08 Avencis METHODS FOR CONFIGURING A TERMINAL DEVICE CONNECTED TO A NETWORK TO ENABLE STRONG AUTHENTICATION OF A USER

Also Published As

Publication number Publication date
ATE271733T1 (en) 2004-08-15
EP1277301B1 (en) 2004-07-21
US7409552B2 (en) 2008-08-05
US20030041244A1 (en) 2003-02-27
DE60104411T2 (en) 2005-09-22
DE60104411D1 (en) 2004-08-26
WO2001084763A3 (en) 2002-03-28
WO2001084761A1 (en) 2001-11-08
AU2000275203A1 (en) 2001-11-12
DE60044586D1 (en) 2010-08-05
AU6589701A (en) 2001-11-12
EP1277299A1 (en) 2003-01-22
EP1277301A2 (en) 2003-01-22
EP1277299B1 (en) 2010-06-23
ATE472208T1 (en) 2010-07-15

Similar Documents

Publication Publication Date Title
EP1277301B1 (en) Method for transmitting payment information between a terminal and a third equipement
US7016666B2 (en) Method for verifying in a mobile device the authenticity of electronic certificates issued by a certification authority and corresponding identification module
US7362869B2 (en) Method of distributing a public key
CN101300808B (en) Method and arrangement for secure autentication
Hassinen et al. An open, PKI-based mobile payment system
EP2481230B1 (en) Authentication method, payment authorisation method and corresponding electronic equipments
EP2536062B1 (en) Improvements in communication security
US20190087814A1 (en) Method for securing a payment token
EP1984890A2 (en) A point-of-sale terminal transaction using mutating identifiers
CN101770619A (en) Multiple-factor authentication method for online payment and authentication system
EP1142194B1 (en) Method and system for implementing a digital signature
CN103944729A (en) Data security interactive method
JP2004247799A (en) Information system for access controlling using public key certificate
CN103944735A (en) Data security interactive method
CN113988828A (en) Payment method, payment system and security chip of digital currency
Hassinen et al. Strong mobile authentication
KR100349888B1 (en) PKI system for and method of using micro explorer on mobile terminals
KR100323138B1 (en) Electronic payment method for protecting trust information and computer-readable medium recording the method
KR100323137B1 (en) A SSL-based electronic payment method for protecting trust information and computer-readable medium recording the method
JP2003032742A (en) Method for preventing illegal use of portable telephone
KR20180089951A (en) Method and system for processing transaction of electronic cash
JP4148465B2 (en) Electronic value distribution system and electronic value distribution method
Assora et al. Using WPKI for security of web transaction
KR20040013403A (en) A payment system based on credit card on a wireless internet and method thereof
CN115310976A (en) Non-contact transaction processing method, device and system

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ CZ DE DE DK DK DM DZ EE EE ES FI 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 PL PT RO RU SD SE SG SI SK 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: A2

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 GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ CZ DE DE DK DK DM DZ EE EE ES FI 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 PL PT RO RU SD SE SG SI SK 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: A3

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 GW ML MR NE SN TD TG

WWE Wipo information: entry into national phase

Ref document number: 2001943278

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2001943278

Country of ref document: EP

WWG Wipo information: grant in national office

Ref document number: 2001943278

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: JP