EP1295267A2 - Procede et systeme ameliores permettant d'effectuer des paiements securises sur un reseau informatique sans l'aide d'un numero de compte faux ou de substitution - Google Patents

Procede et systeme ameliores permettant d'effectuer des paiements securises sur un reseau informatique sans l'aide d'un numero de compte faux ou de substitution

Info

Publication number
EP1295267A2
EP1295267A2 EP01948539A EP01948539A EP1295267A2 EP 1295267 A2 EP1295267 A2 EP 1295267A2 EP 01948539 A EP01948539 A EP 01948539A EP 01948539 A EP01948539 A EP 01948539A EP 1295267 A2 EP1295267 A2 EP 1295267A2
Authority
EP
European Patent Office
Prior art keywords
mac
transaction
account number
authentication code
message authentication
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP01948539A
Other languages
German (de)
English (en)
Inventor
Edward J. Hogan
Carl M. Campbell
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mastercard International Inc
Original Assignee
Mastercard International Inc
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
Priority claimed from US09/809,367 external-priority patent/US9672515B2/en
Priority claimed from US09/833,049 external-priority patent/US7379919B2/en
Application filed by Mastercard International Inc filed Critical Mastercard International Inc
Publication of EP1295267A2 publication Critical patent/EP1295267A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/14—Payment architectures specially adapted for billing 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/22—Payment schemes or models
    • G06Q20/24—Credit schemes, i.e. "pay after"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • 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/403—Solvency checks

Definitions

  • This invention relates to a method and system for conducting secure financial transactions over a communications network and more particularly to a method and system for transmitting payments securely over a computer network, such as the Internet, and for transmitting sensitive information securely over public communication channels.
  • a computer network such as the Internet
  • sensitive information securely over public communication channels.
  • U.S. Patent No. 5,883,810 entitled “Electronic Online Commerce Card With Transaction Proxy Number For Online Transactions” and assigned to Microsoft Corporation, is directed to a system which provides for each transaction a temporary transaction number and associates it with the permanent account number; the transaction number looks like a real credit card number and the customer uses that transaction number and submits it to the merchant as a proxy for the customer account number. In this matter, the customer does not have to transmit over a public network his or her real credit card number.
  • the merchant passes along the transaction number to the issuing institution, which in turn uses the transaction number as an index, accesses the real customer account number and processes the authorization, sending the authorization reply back to the merchant under the transaction number.
  • risk is purportedly minimized not only because the customer only transmits a transaction number but also because the proxy number is good only for a single purchase — theft "would not greatly benefit a thief because it cannot be repeatedly used for other purchases or transactions.”
  • Col. 2 lines 60-61.
  • a "pseudo" account number is assigned to a customer and cryptographically linked to a consumer's payment account number.
  • the payment account number is an account number issued by a financial institution or other organization that a consumer may use to make a payment for goods and/or services.
  • the payment account number may be the account number from a payment card, such as a credit or debit card, or from a payment application, such as an electronic cash application stored on a consumer's computer.
  • the pseudo account number appears to be an actual payment account number to a merchant.
  • the pseudo account number has the same length as a valid payment account number and begins with a valid identification number (e.g., a "5" for MasterCard International Incorporated (“MasterCard”)).
  • the pseudo account number is used by the customer instead of the real account number for all of his or her on-line financial transactions.
  • all transactions based on pseudo account numbers are preferably cryptographically authenticated using a secret key that is unique for each account number.
  • the authentication may be based on the private key of a public-key pair ("public-key authentication"), or based on a secret key other than a private key (“secret-key authentication").
  • public-key authentication a public-key pair
  • secret-key authentication a secret key other than a private key
  • the service provider receives a first authorization request for the authorization of a transaction using a first payment account number, wherein: (i) the first payment account number has a BIN code associated with the service provider, and is associated with a second payment account number having a BIN code associated with an issuer of said second number;
  • the first authorization request includes an acquirer code associated with an acquirer
  • the first authorization request is routable through the payment network to the service provider based on the BIN code of the first payment account number.
  • the method further includes having the service provider respond to the first authorization request by transmitting a second authorization request for authorization of the transaction using the second payment account number, the second authorization request including an acquirer code associated with the service provider and being routable through the payment network to the issuer based on the issuer's BIN code (i.e., the BIN code of the second payment account number).
  • a response to the second authorization request is received by the service provider from the issuer, where the response includes the acquirer code associated with the service provider and is routable through the payment network based on that code.
  • a response to the first authorization request is then transmitted by the service provider to the acquirer based on the response to the second authorization request, and the response to the first authorization request preferably includes the acquirer code associated with the acquirer and is routable through the payment network based on that code.
  • a method is provided of conducting a transaction with a merchant using a first payment account number that is associated with a second payment account number, where the method comprises: (a) generating a message authentication code based on one or more transaction details; (b) transmitting at least the first payment account number and the message authentication code to the merchant; (c) requesting by the merchant an authorization for payment of the transaction using the first payment account number, the request being formatted as if payment were tendered at a point-of-sale terminal with a conventional magnetic-stripe payment card, the message authentication code being transmitted in a discretionary data field contained in a track of the type used in the magnetic stripe of the conventional payment card; (d) responding to the authorization request for the first payment account number by requesting an authorization for payment of the transaction using the associated second payment account number; and (e) accepting or declining the authorization request for the first payment account number based on the response to the authorization request for the second payment account number and the message authentication code.
  • This system can still be improved upon and security can still be
  • the authorization request message is routed over the payment network based on a special bank identification number corresponding to the check site.
  • Software is also preferably located at a user location for generating the secret key.
  • the authorization request message includes an expiration date field and the message authentication code is placed in the expiration date field.
  • the present invention is directed to a method and system for conducting secure electronic commerce (e-commerce) transactions using a payment account number, such as a credit card account number.
  • a payment account number such as a credit card account number.
  • the payment account number is a virtual payment account number, which is an ISO ("International Organization for Standardization") 7816 account number that is used in electronic transactions and is not necessarily linked to a physical ISO 7816-type card.
  • the payment account number may be a payment account number issued on a physical ISO 7816- type card, or the payment account number may be linked with an account number that is issued on a physical ISO 7816-type card.
  • one or more BINs or BIN ranges of payment account numbers are associated with secure e-commerce transactions. These BIN or BIN ranges are hereafter referred to as the "special" BINs or BIN ranges.
  • a payment account number having a special BIN is hereafter referred to as a "special" payment account number.
  • a holder of a special payment account number is provided a secret key ("Per-Card Key") that may be used to generate a message authentication code (MAC) when an e-commerce transaction is conducted using the special payment account number.
  • Per-Card Key a secret key
  • MAC message authentication code
  • at least one facility having a copy of the secret key which it may use to verify the MAC generated by the special payment account number holder. Such a facility is hereinafter referred to as a "Check Site”.
  • a consumer or holder of a special payment account number may be provided at his or her computer 10 with a secure special payment account number software application (SPANS A).
  • SPANS A maintains the secret key associated with the SPAN, which key is used to generate the MAC.
  • the MAC is sent to the originating merchant 12, which forwards an authorization request message (with MAC) to an acquirer bank 14 to start the authorization process.
  • the e-commerce transactions using the special payment account numbers are preferably authorized through a payment network 16.
  • the special payment account numbers are MasterCard credit card numbers, they may be authorized through MasterCard's Banknet payment network.
  • Authorization request messages and authorization response messages for the special payment account numbers are routed through the payment network 16 to the Check Site 18 based on the special BINs of the account numbers.
  • the computers of acquirer and issuing institutions that interface with the payment network 16 may contain look-up tables indicating that the special BINs correspond to the Check Site 18.
  • the computer or computers of the Check Site 18 that interface with the payment network would contain look-up tables indicating the issuers that correspond to the special BINs.
  • a Check Site 18 when a Check Site 18 receives an authorization request message, it may verify the MAC associated with the transaction using the secret key associated with the special payment account number. In addition, the Check Site 18 may relay the authorization request message to the issuer 20, i.e., the institution that issued the special payment account number. The Check Site 18 would respond to the authorization request message with the indication of whether the MAC was verified and/or with the authorization response from the issuing institution.
  • the Check Site may indicate to the issuing institution 20 whether the MAC was verified.
  • the Check Site could indicate, in its outbound Banknet or MasterCard Debit Switch debit message to the issuing bank, that it had verified the MAC.
  • This indicator could be a new defined value for the current security indicator field used in MasterCard's "0100/0200" type messages.
  • the Check Site may, on all transactions, wipe out and clear the incoming security level indicator field and, on output, post its derived security level result (i.e., whether the MAC was verified).
  • the issuing bank authorization response message routes back to the Check Site. If the authorization response message indicates approved, the Check Site 18 will indicate "approved” along with an indicator back to the acquirer that the MAC was verified. The acquirer 14 will in turn send a message back to the originating merchant 12. In this way, a merchant would know, through its acquirer, not only that the issuing bank has approved the transaction but also that the Check Site has validated the MAC, which means the transaction must have originated from the cardholder and can be a "guaranteed" transaction.
  • the SPANSA may be stored on the computer of a special PAN holder.
  • the application may be stored in a cellular phone or a personal digital assistant (PDA).
  • PDA personal digital assistant
  • the special PAN holder may request the application over the Internet from a website 22 (for example, an issuer's website or any other suitable location, including the Check Site).
  • This website preferably is coupled or has access to a hardware security module 24 with the ability to create an account-specific secret cryptographic key, such as a DES key.
  • Each security module preferably contains one or more "Derivation Keys" that are used to create and re-create the account-unique secret cryptographic keys.
  • the secure PAN application stored on the holder's computer may include a transaction sequence number (as described more fully below) and need not communicate with a Check Site or other support site on every transaction. Instead, the application stored on the special PAN holder's computer could communicate and synchronize its transaction sequence counter with a Check Site or other support site at whatever interval a particular issuing institution desires.
  • the present invention may also be used with a remote wallet server.
  • the secure PAN application is not stored, managed or maintained in a special PAN holder's computer system.
  • the present invention enables the use of a generic Internet browser by the special PAN holder, which browser is used to access the remote wallet server (which has the secure PAN application stored thereon).
  • the local system of the special PAN holder need not contain any additional software or functions beyond the generic Internet browser.
  • the present invention allows the use of a real virtual primary account number.
  • the present invention may be switched by an acquiring computer without translation and requires no changes to back-end switching or processing functions.
  • the present invention also: 1) simplifies all clearing processes by eliminating the need to send any clearing files to a central site; 2) eliminates the need for any chargebacks needing to be sent to a central site; 3) eliminates the need for all retrieval requests made by cardholders after transactions are posted to their billing statements from being sent to a central site system to translate to real account numbers. Cardholders are provided and use real account numbers for these transactions.
  • the present invention also eliminates the need to create and manage the storage of transaction logs needed to translate a special payment account number to a real account number.
  • the MAC may be transmitted to the Check Site in any number of ways. Examples of methods of transmitting the MAC to the Check Site follow.
  • the MAC is placed in the card expiration date field and acts as a "pseudo expiration date.”
  • the MAC generation is described more fully below.
  • the field, which would be used for this indicator, could be any currently supported field in normal bankcard authorization messaging POS systems.
  • a cardholder's computer or a remote wallet server maintains a log of merchant data related to the transaction.
  • the cardholder's computer or the remote wallet server could log:
  • This embodiment provides additional security in that, if the cardholder later tries to dispute a transaction as not having been initiated by the cardholder at that particular merchant, the log could provide sufficient data to refute such a claim.
  • the merchant website is unchanged.
  • the transaction MAC is placed in the card expiration date as in Option 1 or 4.
  • the MAC is generated based on a merchant-supplied data element.
  • the merchant-supplied data element would be passed to the cardholder or remote wallet server in an additional separate field, designed for the transport of the merchant supplied data needed to calculate the MAC.
  • One embodiment would be to link a data element that a merchant already holds, such as a merchant's SSL certificate serial number, into the data fields used in the MAC computation.
  • a MAC could be created using the following data elements: (a) the PAN,
  • This embodiment would involve changes to merchant electronic commerce sites.
  • the merchants would need to modify their systems to send their merchant certificate serial number in the outbound authorization request message.
  • this embodiment would supply key merchant identifying data linking the merchant to a particular transaction.
  • the MAC verification step computed by both the cardholder system and the Check Site would both have this additional merchant identifier field.
  • the Check Site saw that the incoming authorization request message had a merchant supplied certificate serial number, it would use it in the MAC computation to match the same process employed when the cardholder system generated the MAC.
  • the transaction MAC is placed in both the card expiration date field and in the CVC2 or equivalent field.
  • CVC2 refers to a three digit value that is printed next to the signature panel of some cards.
  • ISO 7816 payment cards have a static (at least) 3-digit code that is cryptographically generated by an issuer. In MasterCard payment cards, for example, this code is called CVC2.
  • This value is generated by an issuing bank using a secret cryptographic key and can be verified using this same key. This option enables the generation of a longer transaction MAC (i.e., the MAC output size is increased by 3 digits).
  • the CVC2 (or equivalent code) field would be dynamically generated and filled with the MAC. Merchant sites would need to support cardholder prompting and subsequent transport of the CVC2 or equivalent field.
  • the transaction MAC is placed in the CVC2 or equivalent field.
  • This embodiment enables the generation of at least a three-digit MAC.
  • the MAC is checked against the true or static CVC2 value (i.e., the CVC2 value generated by the issuing bank and issued with the payment card). If the generated MAC is equal to the static CVC2 value, the transaction counter of the secure PAN application is incremented, and a new MAC is generated. The new MAC is then compared to the static CVC2 value to determine whether the two values are equal. This process is repeated until the generated MAC value is not equal to the static CVC2 value.
  • the verification process compares the received CVC2 value that is sent with the transaction to the static CVC2 value expected for the payment card. If these values are equal, the verification process determines that a secure PAN application has not been used for the transaction, and a MAC has not been sent. If the received CVC2 value is different from the static CVC2 value, the verification process assumes that a secure PAN application has been used for the transaction and the CVC2 field contains a MAC. The verification process then attempts to verify the MAC value in the CVC2 field. It is not necessary for special payment account numbers to be used with this embodiment (although they may be used). Instead, as described above, the value in the CVC2 field may be used to determine when a secure PAN application is used with a transaction.
  • Cardholder authentication may be provided by any number of methods that are known in the art and may be designated by the issuer of the cardholder secure PAN application.
  • a method of authentication includes, but is not limited to, the use of a remote wallet server that is accessed by a cardholder's Internet browser, such as a Netscape or Microsoft Internet Explorer browser, through SSL technology.
  • the authentication technique could include the use of user ID and password access and/or the use of chip-card based digital ID authenticated access.
  • the present invention may also include a locally stored application managed and maintained on the cardholder system itself.
  • Transaction authentication in the present invention is provided by the creation of a MAC over transaction details, as described below.
  • Account number protection in the present invention may be further increased by the use of a virtual account number, which is of no value for magnetic stripe face-to-face transactions at point-of-sale terminals (because there is no magnetic stripe issued for a virtual account number).
  • a virtual account number which is of no value for magnetic stripe face-to-face transactions at point-of-sale terminals (because there is no magnetic stripe issued for a virtual account number).
  • the need for merchant authentication prior to a cardholder revealing his/her account number is obviated because the account number of the present invention is not usable without its associated transaction- specific MAC. Any attempted fraudulent use of an account number under the present invention, such as a replayed transaction with an old MAC without cardholder authentication, would be routed to the special Check Site, and would not verify for the attempted transaction. All attempted fraudulent replayed transactions thus would fail.
  • the cardholder may provide a password prior to downloading the secure PAN application or may select a password when the application is installed on the cardholder's PC. If a password is provided or selected, the cardholder will thereafter be required to enter this password in order to activate the application on his or her PC. The password selected by the cardholder may be used to encrypt, or otherwise alter, the secret key.
  • the secure PAN application may be downloaded as part of a digital wallet application.
  • the secret key that is embedded within the secure PAN application is unique for each special payment account number and is preferably derived within a security module using the special payment account number and a derivation key.
  • This derivation key may itself be derived within the same or other security module using a higher-level derivation key.
  • the derivation keys may be, for example, triple-length DEA keys. Any method of encryption known in the art may be used to generate the account-specific key with a derivation key.
  • the Check Site preferably is coupled to or has access to a security module with copies of the derivation keys therein. When the Check Site receives an authorization request for a special payment account number, the Check Site derives the key needed to verify the MAC by using the appropriate derivation key with the special payment account number.
  • a MAC may be generated and used according to the present invention.
  • the MAC may be placed in the expiration date field of a transaction.
  • the MAC then acts as a "pseudo" expiration date.
  • This pseudo expiration date is formatted MMYY as are all expiration dates.
  • the pseudo expiration date should fall within 48 months of the transaction.
  • the secure PAN application (hereinafter also referred to as the "secured application”) includes a transaction sequence number, which consists of 20 binary bits and is incremented for every transaction. Thus the number will not cycle from all one's to all zeros until 2 20 or about 1 million transactions have occurred.
  • the secure application may also include a four-bit "version number", which is a number that is unique to each PC or other device in which a secure application for a given account number is resident.
  • the transaction sequence number is first incremented.
  • the resulting 20-bit number, with the four-bit secure application version number concatenated to the left, is then left-justified in an 8-byte field, padded to the right with binary zeros, and triple-DEA encrypted using the double-length secure application Per-Card key.
  • the result is the 64-bit binary MAC.
  • the expiration date field of the transaction may then be obtained from the 64-bit binary MAC described above as follows: 1. Selected the left-most "one" bit in the "number of months indicator” (a binary number, explained in greater detail below) and count the number of bit positions from this bit position to the right-most bit (including the bit position of the left-most "one” bit). Call this number "N”. For example if the "number of months indicator" is 01010100 (decimal 84) the value "N" is seven. Having determined “N”, consider the 64-bit binary MAC, as groups of "N" bits each, ignoring any left-over right-most bits. Starting with the left-most group, select the first group encountered that is less than or equal to the "number of months indicator”. If no such group is found, select the left-most group, to this group add "number of months indicators” and from this sum subtract 2 N , and use this result (which will be > 0 and ⁇ "number of months indicator”) as the selected value.
  • Step 2 Divide the result of Step 1 by binary 1100 (decimal 12) producing a quotient and a remainder. Covert both the quotient and the remainder into decimal numbers. Add the remainder, as a decimal number (having a value in the range 00 to 11) to the two left-most decimal digits (MM) of the "reference date", also described in greater detail below. If the result is greater than 12, subtract 12 from the result and in either case use the result as the two left-most digits, MM, of the card expiration date for the current transaction. If obtaining the result required a subtraction of 12, increment (by one) the quotient.
  • Step 3 Add, mod-100, the two-decimal digit quotient from Step 2, possibly incremented as also indicated in Step 2, to the right-most two digits (YY) of the "reference date". Use the result as the two right-most digits, YY, of the card expiration date for the current transaction.
  • a MAC may be generated as described above or in any manner known in the art. Then, in addition to, or instead of, placing the MAC in the expiration date field, the MAC, or any portion thereof, may be placed in the CVC2 field or equivalent. Communication between Cardholder and Merchant
  • the cardholder uses the secure application for all Internet payments and the secure application provides the cardholder's special payment account number for all Internet transactions.
  • the fact that this is a secure application transaction is transparent to the merchant.
  • the account number is actually a special payment account number, and the expiration date may actually be a representation of a MAC
  • the merchant is unaware that this transaction is different from any other Internet SSL transaction it receives.
  • the secure application uses its embedded, secret key to create a Message Authentication Code (MAC) relating to the transaction, and places this MAC, and the data on which it is based, in a MAC field, which becomes a portion of the transaction.
  • MAC Message Authentication Code
  • the merchant formats a conventional authorization request for the acquirer. This authorization request preferably contains the MAC field as provided by the consumer's PC.
  • an acquirer When an acquirer receives an authorization request message from an Internet merchant, it looks up the issuer BIN in its BIN table.
  • MasterCard's payment system if the acquirer determines that the transaction's BIN corresponds to an issuer in another country, it causes the transaction to be routed to MasterCard over its Banknet system. If the acquirer determines that the transaction's BIN corresponds to an issuer in its own country, it may also cause the transaction to be routed to MasterCard via Banknet. Alternatively, in some cases where an issuer is in the same country as the acquirer, the acquirer may normally cause the transaction to be routed directly to the issuer designated by the BIN. In the case of a special payment account number transaction, the transaction preferably will be routed to a central processing facility, preferably to a MasterCard-authorized processing facility (i.e., a Check Site).
  • a central processing facility preferably to a MasterCard-authorized processing facility (i.e., a Check Site).
  • some countries may have a special security-module-equipped facility that handles domestic transactions.
  • Each such facility would preferably be set up only with MasterCard's approval and would hold only the cryptographic keys and account-number conversion data for the country whose transactions it processes.
  • countries with such a national check site facility all transactions will be sent this facility, so that same-country transactions need not leave that country.
  • a national check site facility to handle domestic transactions may be more efficient than causing all transactions to go through a central processing facility.
  • the secure application may be initiated during every transaction, immediately before the secure application-based payment is to be performed.
  • the secure application passes to a payment processing website, preferably to a MasterCard website or server, a request consisting (for example) of the 16-digit special payment account number, the four-decimal-digit expiration date of the payment account number, the four-bit secure application version number, the current value of its 20-bit transaction sequence number, and a 16-bit MAC (Message Authentication Code) based on these latter three values.
  • the MAC might be created by triple-DEA encryption, using the secure application-resident 16-byte Per-Card key, the 16-bit expiration date (as binary-coded-decimal) concatenated (left-to-right) with the four-bit secure application version number concatenated with the 20-bit transaction sequence number, left justified in a 64-bit field and padded to the right with binary ones, then selecting the 16-left-most bits of the resulting cipher-text.
  • the website uses a special security- module-equipped secure application system to verify the MAC on the expiration date, secure application version number and the transaction sequence number. If the MAC is verified, this system increments the transaction sequence number (it maintains) to create the "expected transaction sequence number" (ETSN) and causes an update of the ETSN for the special payment account number and secure application version number in question in the secure application authorization system (e.g., the Check Site) that processes secure application authorization requests for the BIN of the indicated special payment account number.
  • ESN expected transaction sequence number
  • This secure application authorization system (the Check Site) will reject the just-received ETSN if it is less than or equal to the highest-numbered ETSN previously received for this special payment account number and secure application version number.
  • This secure application authorization system (the Check Site) is also given the just-received expiration date, and updates the expiration date associated with this special payment account number if it is later than the expiration date currently on record.
  • This special secure application system preferably sends to the website, which in turn sends to the secure application in the cardholder's PC, the following two data values: 1) a date value referred to as the "reference date”, which is a four-digit decimal number with the format MMYY (and which is, in effect, this month's or next month's date), and 2) a data value referred to as the "number of months indicator", which is an eight-bit binary number with a maximum value less than (decimal) 256.
  • This data is also included in the information that is sent to the appropriate secure application authorization system (the Check Site).
  • the acquirer and payment network cause the transaction to be routed to a Check Site.
  • the Check Site stores, for each secure application version number and special payment account number, a record of the 20-bit highest-numbered ETSN received, along with an indication of whether or not the MAC has been verified for this transaction sequence number. In addition, it stores any "expected transaction sequence numbers" received within the past 48 hours for which the MAC has not yet been verified. Associated with each such expected transaction sequence number, the system also stores an indication of the "reference date” and the "number of months indicator" that apply to each expected transaction sequence number.
  • the "reference date” is a date value indicating the earliest expiration date that is acceptable in an authorization request message. By way of background, some merchants do not request authorizations immediately, but batch authorization requests together. Therefore, this date is typically one or two days ahead of the date when the transaction is initiated.
  • the "number of months indicator" indicates the number of months beyond the current date corresponding to the latest expiration date for which a payment card will be accepted. Typically, this number is 48 months.
  • the Check Site also has, is coupled to, or has access to a security module with the capability to determine the unique, secret 16 byte cryptographic key placed in the secure application of the cardholder's PC when registration occurred.
  • the processing performed by the Check Site is then as follows:
  • ETSN determine from this MAC an expiration date using the methodology defined above for secure application at the PC. If this expiration date equals the expiration date of the current transaction, the MAC has verified. The entry for this ETSN that resulted in the MAC verification is then marked as "MAC verified” if it is the highest-numbered ETSN for its associated secure application version number, or deleted if it is not the highest number ETSN for its associated secure application version number. The entry for any lower- numbered ETSN that is marked as "MAC verified" and is associated with the same secure application version number is now deleted. 3.
  • Step 2 If the MAC is verified in Step 2 (or Step 4), make an entry in "History Data" for this special payment account number unless it is known that the merchant of this transaction will never send a second authorization-request message for this same transaction. (Some merchants may send a second, or more, authorization-request message for the same transaction if they cannot ship all of the merchandise within a specified time after the transaction.)
  • This History-Data entry includes all of the data discussed above plus the identity of the merchant and the acquirer, and an "expiration date" for this entry. This entry expiration date is a specified time (e.g. 6 months) in the future.
  • Step 2 If the MAC did not verify in Step 2, then repeat the procedures defined in Step 2 for all other "expected transaction sequence numbers" that were received during the past 48 hours from the oldest to the newest that are not associated with already-verified MACs. Again, if, for any of these trials, the resulting date matches that in the current transaction, the MAC is considered to have been verified. If the MAC verifies, the 20-digit ETSN that resulted in the MAC verification is then marked as "MAC verified" if it is the highest ETSN for the associated secure application version number in question, or deleted if it is not the highest ETSN for the associated secure application version number in question. If the MAC is verified in this step, also perform Step 3.
  • Step 2 the "History Data" for the special payment account number in question is accessed. If there is an entry in this data for the same merchant and acquirer that produces the same expiration-date MAC, and this entry has not expired, then accept the MAC. (This is presumed to be an additional authorization-request message for an already-authorized transaction.) If the MAC is accepted because of this entry, the entry expiration date should be made about 2 months in the future if it is less than that, because this may be a "recurring payment” and there may be another authorization-request message for this same transaction in about another month.
  • Step 2 If the MAC does not verify in Step 2, Step A, or Step 5, the transaction must be rejected. In this case a "decline" response is sent to the acquirer and/or the fact that the MAC is not verified is indicated in a special field, such as the security field described above.
  • the Check Site notes the presence of the MAC field.
  • the Check Site determines the secret key (as described above), and uses this key to verify the MAC, using essentially the same procedure used in the PC to create the MAC.
  • the system also checks the transaction sequence number, and to do so must maintain transaction-sequence-number information for every version number of every special account number that it processes. It rejects a transaction if:
  • the transaction sequence number is smaller than (or equal to) the largest transaction sequence number for this version of this the secure application received at least 48 hours ago, or
  • the transaction sequence number matches any already-received transaction sequence number for this version of this the secure application. (This may be limited to the transaction sequence numbers received within the past 48 hours.)
  • this facility causes the transaction to be declined and/or indicates the verification failure in an appropriate field, such as the SET security field. If both the MAC and the transaction sequence number verify, this facility causes the transaction to be routed to the issuer.
  • the central processing facility, or check site formats an authorization request message for the issuer.
  • the authorization request message may include an indication of whether the MAC was verified.
  • MasterCard may replace the acquirer BIN in the transaction message with a special MasterCard BIN that serves as a "pseudo" acquirer BIN.
  • the acquirer BIN is replaced so that the issuer responds to MasterCard instead of to the acquirer. It is not necessary to perform this step if the payment network keeps a record of where the authorization-request message comes from and sends the authorization-response message back to the same place.
  • the pseudo acquirer BIN should correspond to the country in which the acquirer is located or to another country or region that will provide the same resultant interchange fees. If each country has a special BIN associated with it, MasterCard may replace the acquirer BIN with the special BIN associated with the acquirer's country. If an acquirer's country does not have a special BIN associated with it, a special BIN associated with another country may be selected that results in the same interchange fees.
  • MasterCard stores in a database the acquirer reference data received in the authorization request from the acquirer
  • original Acquirer Reference Data (hereinafter referred to as the "original Acquirer Reference Data").
  • MasterCard In formatting an authorization request message for the issuer, MasterCard replaces the original Acquirer Reference Data with "pseudo" Acquirer Reference Data that includes the pseudo acquirer BIN, an appropriate transaction-type indicator, and an index value that MasterCard can use to find the original Acquirer Reference Data.
  • the issuer authorizes the transaction just as it would any other transaction.
  • the authorization response back is routed back to the "pseudo" acquirer, namely the same MasterCard secure application authorization system or Check Site that initially received the special payment account number transaction.
  • the Check Site sends the authorization response to the acquirer with an indication of whether the MAC was verified. In turn, this message is sent from acquirer to merchant, just as for a normal MasterCard transaction. Authentication Using An Additional Field
  • the MAC of the present invention may also be placed in a separate MAC field of (for example) 3 decimal digits. These 13 digits might be as follows:
  • a "Version Indicator” field of one decimal digit This field normally contains the value " 1 " . However if the cardholder has more than one copy of the secure application for the same special payment account number, (e.g. on a desktop computer and on a laptop computer), additional versions of the secure application will have different numbers in the Version Indicator field. (The secure application transaction sequence numbers are unique to each such version of the secure application.)
  • the secure application transaction sequence number for this version of the secure application 6 decimal digits: This field increments for each the secure application transaction initiated at this particular computer. (Each computer has its own version of the secure application, and thus will have its own set of sequence numbers.)
  • Step 3 DEA-encrypt the result of Step 3 using as the encryption key the left-most 8 bytes of the Per-Card Key.
  • Step 4 Consider the 64-bit result of Step 4 as 16 hexadecimal digits of 4 bits each. Scan (from left-to right) these 16 hexadecimal digits, selecting the first 6 such digits with value less than or equal to hexadecimal "9". If 6 such digits are not found, find the remaining required digits by re-scanning the digits, this time selecting only digits greater than hexadecimal "9", and subtracting hexadecimal "A" from each.
  • Step 5 Use the result of Step 5 as the 6-decimal-digit MAC for this transaction.
  • the MAC is produced by the secure application in the cardholder's PC, and is to be verified in an appropriate MasterCard secure application facility or Check Site. When produced, the 6 decimal digits resulting from Step 6 are inserted into the MAC field as the actual MAC. When verified, the secure application facility performs the above 6 steps using the left-most 7 digits of the MAC filed, then compares the 6-digit result from Step 6 against the right-most 6 digits of the received MAC field. An exact match indicates an authenticated transaction. A non-match indicates a transaction that must be rej ected.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

La présente invention concerne un procédé qui permet d'effectuer une transaction électronique avec un numéro de compte sur lequel existent des fonds disponibles, au moyen d'un réseau de paiement et d'un « site de vérification ». le procédé comprend les étapes suivantes: (a) la génération d'une clé privée associée au numéro de compte pour le paiement; (b) l'utilisation de la clé privée pour générer un code d'authentification de message ('CAM') spécifique à la transaction; (c) la génération d'un message de demande d'autorisation comprenant le code d'authentification de message; (d) la transmission du message de demande d'autorisation sur le réseau de paiement au site de vérification pour vérifier l'authenticité du CAM; (e) la vérification du code d'authentification de message par le site de vérification au moyen de la clé privée; (f) la réponse au message de demande d'autorisation sur le réseau de paiement en fonction des fonds disponibles et du montant de la transaction.
EP01948539A 2000-06-22 2001-06-21 Procede et systeme ameliores permettant d'effectuer des paiements securises sur un reseau informatique sans l'aide d'un numero de compte faux ou de substitution Withdrawn EP1295267A2 (fr)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US21332500P 2000-06-22 2000-06-22
US213325P 2000-06-22
US22516800P 2000-08-14 2000-08-14
US225168P 2000-08-14
US09/809,367 US9672515B2 (en) 2000-03-15 2001-03-15 Method and system for secure payments over a computer network
US809367 2001-03-15
US09/833,049 US7379919B2 (en) 2000-04-11 2001-04-11 Method and system for conducting secure payments over a computer network
US833049 2001-04-11
PCT/US2001/019754 WO2001099071A2 (fr) 2000-06-22 2001-06-21 Procede et systeme ameliores permettant d'effectuer des paiements securises sur un reseau informatique sans l'aide d'un numero de compte faux ou de substitution

Publications (1)

Publication Number Publication Date
EP1295267A2 true EP1295267A2 (fr) 2003-03-26

Family

ID=27498926

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01948539A Withdrawn EP1295267A2 (fr) 2000-06-22 2001-06-21 Procede et systeme ameliores permettant d'effectuer des paiements securises sur un reseau informatique sans l'aide d'un numero de compte faux ou de substitution

Country Status (5)

Country Link
EP (1) EP1295267A2 (fr)
JP (1) JP4903346B2 (fr)
AU (2) AU7001201A (fr)
CA (1) CA2413882A1 (fr)
WO (1) WO2001099071A2 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6732270B1 (en) * 2000-10-23 2004-05-04 Motorola, Inc. Method to authenticate a network access server to an authentication server
US8650103B2 (en) 2001-10-17 2014-02-11 Ebay, Inc. Verification of a person identifier received online
KR101100385B1 (ko) * 2004-03-22 2011-12-30 삼성전자주식회사 인증서 폐지 목록을 이용한 디지털 저작권 관리 방법 및장치
DE102009024984A1 (de) * 2009-06-16 2010-12-23 Giesecke & Devrient Gmbh Verfahren zur Durchführung einer elektronischen Transaktion, insbesondere einer elektronischen Banktransaktion
US11538055B2 (en) * 2012-06-15 2022-12-27 Edatanetworks Inc. Systems and method for incenting consumers

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2168514A (en) * 1984-12-12 1986-06-18 Ibm Security module
JPH01243175A (ja) * 1988-03-24 1989-09-27 Nippon Ginkou 電子決済システムの決済確認方法
JP3367675B2 (ja) * 1993-12-16 2003-01-14 オープン マーケット インコーポレイテッド オープンネットワーク販売システム及び取引トランザクションのリアルタイムでの承認を行う方法
GB9416595D0 (en) * 1994-08-17 1994-10-12 British Telecomm User authentication in a communications network
JP3599493B2 (ja) * 1996-09-10 2004-12-08 日本銀行 発行機関分離型番号登録式電子現金方法および利用者装置
WO1998018251A2 (fr) * 1996-10-23 1998-04-30 Philips Electronics N.V. Mecanisme de paiement pour service de telecommunication mobile
JP3435682B2 (ja) * 1997-08-15 2003-08-11 日本電信電話株式会社 電子現金預け入れ方法、その装置およびプログラム記録媒体
US5883810A (en) 1997-09-24 1999-03-16 Microsoft Corporation Electronic online commerce card with transactionproxy number for online transactions
US6000832A (en) * 1997-09-24 1999-12-14 Microsoft Corporation Electronic online commerce card with customer generated transaction proxy number for online transactions
US6102287A (en) * 1998-05-15 2000-08-15 International Business Machines Corporation Method and apparatus for providing product survey information in an electronic payment system
GB2338381A (en) * 1998-06-10 1999-12-15 Barclays Bank Plc Cryptographic authentication for internet using two servers
EP1028401A3 (fr) * 1999-02-12 2003-06-25 Citibank, N.A. Méthode et système pour exécuter une transaction avec cartes bancaires
AU2001243658B2 (en) * 2000-03-15 2005-12-15 Mastercard International Incorporated Method and system for secure payments over a computer network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
D. O'MAHONY, M. PIERCE, H. TEWARI: "Electronic Payment Systems", 1997, ARTECH HOUSE, BOSTON, LONDON, 236620 *

Also Published As

Publication number Publication date
CA2413882A1 (fr) 2001-12-27
AU7001201A (en) 2002-01-02
WO2001099071A2 (fr) 2001-12-27
AU2001270012B8 (en) 2006-11-16
JP4903346B2 (ja) 2012-03-28
WO2001099071A3 (fr) 2002-05-30
JP2003536181A (ja) 2003-12-02
AU2001270012B2 (en) 2006-09-28

Similar Documents

Publication Publication Date Title
US7177848B2 (en) Method and system for conducting secure payments over a computer network without a pseudo or proxy account number
US6990470B2 (en) Method and system for conducting secure payments over a computer network
US7379919B2 (en) Method and system for conducting secure payments over a computer network
US7983987B2 (en) System and method for conducting secure payment transaction
US6915279B2 (en) System and method for conducting secure payment transactions
ZA200207410B (en) Method and system for secure payments over a computer network.
CA2406375C (fr) Procede et systeme ameliores pour effectuer des paiements en toute securite sur un reseau informatique
AU2001257019A1 (en) An improved method and system for conducting secure payments over a computer network
AU781671B2 (en) An improved method and system for conducting secure payments over a computer network
AU2001270012B2 (en) An improved method and system for conducting secure payments over a computer network without a pseudo or proxy account number
AU2001270012A1 (en) An improved method and system for conducting secure payments over a computer network without a pseudo or proxy account number
AU2002254513B8 (en) System and method for conducting secure payment transactions
AU2002254513A1 (en) System and method for conducting secure payment transactions
ZA200300114B (en) An improved method and system for conducting secure payments over a computer network without a pseudo or proxy account number.
AU2007216920B2 (en) An improved method and system for conducting secure payments over a computer network
AU2012201255B2 (en) An improved method and system for conducting secure payments over a computer network
EP1921579A2 (fr) Procédé et système améliorés pour réaliser des paiements sécurisés via un réseau informatique
ZA200201382B (en) An improved method and system for conducting secure payments over a computer network.
ZA200307558B (en) System and method for conducting secure payment transactions.
ZA200208248B (en) An improved method and system for conducting secure payments over a computer network.

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20030117

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

17Q First examination report despatched

Effective date: 20040831

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20051231

REG Reference to a national code

Ref country code: HK

Ref legal event code: WD

Ref document number: 1054608

Country of ref document: HK