CN1672180A - System and method for credit and debit card transactions - Google Patents

Abstract

A method and system for conducting secure credit and debit card transactions between a customer and a merchant. The customer is issued with a pseudorandom security string by a host computer, the security string being sent to the customer's mobile telephone. A cryptographic algorithm running in a SIM card of the mobile telephone performs a hash on the security string or the One Time Code extracted from the security string, a customer PIN and a transaction amount, these last two items being entered by way of a keypad of the mobile telephone. A three-digit response code is generated by the algorithm and then passed to the merchant. The merchant then transmits the response code, transaction amount and a customer account number (card number) to the host computer, where the pseudorandom security string and PIN are retrieved from memory. The host computer then applies the same algorithm to the security string, PIN and transaction amount so as to generate a check code, and if the check code matches the response code transmitted by the merchant, the transaction is authorised. Embodiments of the present invention make use of existing CVV2 security infrastructure, but provide a significantly greater degree of security. Embodiments of the present invention may be used with ordinary face-to-face or telephone transactions, and also in e-commerce (web-based) and m-commerce (mobile telephone-based) transactions.

Description

Systems and methods for credit and debit card transactions

The present invention relates to a system and method for improving security performance in transactions such as credit and debit cards.

Credit and debit card fraud (hereinafter "card fraud") is a growing problem, especially with respect to online ("e-commerce") transactions. Until more sophisticated methods are developed, the financial banking industry's response to this is to use short-term solutions to fend off fraud. This short-term solution is known as the "CVV2" method, which is relatively simple. The CVV2 code is a three-digit decimal number, usually printed on the back or on the credit card by the card issuer, separate from the card number ("PAN" or "Payer Account Number") and not stamped on a magnetic strip or embedded in a chip. The mode is electronically coded into the card (this helps prevent fraudsters from "skimming" the CVV2 code). The CVV2 code is printed on the card but cannot be read from the magnetic strip. After authentication by obtaining the card number from an online source, it is tested to determine if the given CVV2 code is correct. A merchant that processes cardholder off-site transactions (eg, online or telephone transactions) requires the cardholder's CVV2 number, PAN, card's expiration date, and shipping address. The merchant then conducts an on-line check to confirm that the above CVV2 code and the given cardholder shipping address are consistent with the details shared by the issuer of the card and the associated card with the given PAN so that a fraudulent transaction is attempted A user needs a PAN, cardholder address, card expiration date, and CCV2 code, so the CCV2 approach assumes that fraudsters don't know how to steal this information in the first place. The downside is that the CCV2 method is relatively easy to break because many of the techniques used to steal a PAN can generally be extended to steal CCV2 codes and cardholder addresses. So at best, CVV2 is a temporary measure to delay fraud.

The infrastructure needed to support the CCV2 approach is up and running. This means that business machine equipment (eg, EPOS and EFTPOS terminals, etc.) and computer ("IT") systems have been designed and adapted to require a three-digit decimal number as an additional security measure. Embodiments of the present invention are adapted to use these existing infrastructures to provide a higher level of anti-fraud security than approaches based on the use of new smart cards.

Improved methods and systems for verifying and identifying users, such as holders of credit and debit cards, are described in the applicant's co-pending UK Patent Application No. 0021964.2, International Patent Application No. PCT/GB01/04024 and U.S. Disclosed in Patent Application Nos. 09/663,281 and 09/915,271. These methods and systems involve sending a pseudo-random character string to a user's mobile phone prior to conducting a card transaction. Next, in a predetermined manner, the user applies a mask to a pseudo-random string of characters in the form of a personal identification number (PIN) for the purpose of generating a variable one-time transaction identifier that After being passed to the merchant machine, it is forwarded to the authentication server where it is checked against an independently calculated variable one-time identification number to confirm the cardholder's identity.

According to a first aspect of the present invention, there is provided a method for authorizing a secure transaction between a customer and a business machine, said method comprising the steps of:

i) storing customer information including customer account numbers and related personal identification numbers (PINs) in the computer host;

ii) generating a pseudo-random security character string in the host computer;

iii) sending said pseudo-random security string from said host computer to at least one remote electronic device operated by a client;

iv) entering said PIN and transaction amount into said electronic device when conducting a transaction between a customer and a merchant machine;

v) generating a response code in said electronic device by applying a predetermined encryption algorithm to said pseudo-random security string, PIN and transaction amount;

vi) transmitting the response code, transaction amount and customer account number to the computer host;

vii) In the host computer, retrieve the PIN and the pseudo-random security string using the customer account number, and then apply a predetermined encryption algorithm to the pseudo-random security string, PIN and transaction amount to generate a verification code;

viii) In said host computer, comparing said verification code with said response code and authorizing the transaction if they match each other.

According to a second aspect of the present invention, there is provided a secure transaction system for authorizing transactions between a client and a business machine, said system comprising a host computer and at least one electronic device operated by a client, characterized in that :

i) storing customer information including customer account number and related personal identification number (PIN) in the computer mainframe;

ii) the host computer generates a pseudo-random security string, and sends the pseudo-random security string to the at least one electronic device operated by the client;

iii) When the customer is conducting a transaction with the merchant, the electronic device receives input from the customer, the input including the PIN and a transaction amount.

iv) said electronic device generates a response code by applying a predetermined encryption algorithm to said pseudo-random security string, PIN and transaction amount;

v) transmitting the response code, transaction amount and customer account number to the computer host;

vi) The host computer uses the customer account to retrieve the PIN and the pseudo-random security string, and then applies a predetermined encryption algorithm to the pseudo-random security string, PIN and transaction amount to generate a check code;

viii) The computer host compares the verification code with the response code, and if they match each other, the transaction is authorized.

Preferably, the response code generated by the electronic device is displayed on the display of the electronic device and sent verbally or otherwise to the merchant with which the customer is transacting. Alternatively, the above response codes can be sent directly from the electronic device operated by the user to the electronic device operated by the merchant via any suitable technology (e.g., Bluetooth® or other standard communication technology that typically uses modulated electromagnetic radiation signals). For example, EPOS or EFTPOS terminals). In the case of a transaction through a merchant machine website or the like, the response code is entered at an appropriate place on the website for transmission to the merchant machine.

For authorization, the above-mentioned response code, transaction amount and customer account number are usually sent by the business machine (not the customer) to the above-mentioned computer host, which can be via EPOS or EFTPOS terminal or any suitable computer device.

Preferably, the aforementioned electronic device is a mobile phone, personal digital assistant (PDA), pager or similar electronic communication device. The pseudo-random security string can be sent from the host computer to the electronic device via Short Message Service (SMS) protocol or other suitable communication protocols, including voice messaging, e-mail or otherwise.

To use the system and method of the present invention, a customer is first designated and assigned a credit or debit card in the usual manner. The account number unique to the customer is printed on the card. The customer registers the card with the authorized center maintaining the computer host, and registers the card number, mailing address (eg, customer mobile phone or PDA number, e-mail address, etc.) and PIN for the customer's electronic device. The above-mentioned PIN may be selected by the customer or assigned to him or her by the computer host, but the above-mentioned PIN will not be disclosed to a third party. The above-mentioned PIN is usually a decimal number, usually 4 digits in length, but can be of other lengths or can be an alphanumeric string. The above-mentioned customer account number, mailing address and PIN are stored in the computer host in an interrelated manner. Once the above operations are completed, the host computer sends the pseudo-random security string to the customer's electronic device, for example, sends the pseudo-random security string to the customer's mobile phone using the SMS protocol. The aforementioned pseudo-random security character string may be a randomly generated decimal number or alphanumeric string of n digits.

The systems and methods of the present invention can be used in e-commerce locations or more traditional shopping locations.

In an electronic commerce location, a customer selects goods and/or services from a merchant website in the usual manner. When arriving at the payment page on the website, the customer enters or provides his or her card number (customer account number) and determines the total amount to be paid. The total amount of the customer's bill is then entered into the above-mentioned electronic device together with his or her PIN, which is mixed with a pseudo-random security character string by a predetermined encryption algorithm, or is mixed with a pseudo-random security character string from the pseudo-random security character by a predetermined encryption algorithm The one-time codes extracted from the string are mixed together to generate the response code. In a specific preferred embodiment, the response code is a three-digit decimal number, which is in the same format as the existing CVV2-type coding format printed on the back of known credit and debit cards. However, the response code may be of any length and non-decimal or alphanumeric string, depending on the nature of the encryption algorithm used. It will be apparent to those skilled in the art that there are many suitable algorithms capable of performing the hashing function on the three-bit input in order to generate the appropriate response code, so no detailed attention is paid to the details of those algorithms. By way of implementation, however, the standard well-known SHA-1 cryptographic hash [FIPS PUB 180-1] algorithm can be used to generate a 160-bit value, and the remainder can be determined by dividing the above 160-bit value by 1000.

When the electronic device is a mobile phone, said encryption algorithm may be stored in a SIM (Subscriber Interface Module) card of the phone, or may be stored in memory means forming part of the mobile phone. Preferably, the encryption algorithm is run as an applet in the SIM card, which takes the pseudo-random security character received by the phone as one input, the above-mentioned total amount of payment as a second input, and the above-mentioned PIN as a second input. Three inputs. The second and third input can be entered manually via the keypad of the mobile phone in the usual way. Obviously, the encryption algorithm can be run in a similar manner on any suitable electronic device (eg, PDA, pager, personal computer, etc.) using standard storage and processing means.

After the above response code is calculated by the above algorithm, the response code can be displayed on the display of the electronic device. The customer may enter a response code in an appropriate data entry field of the website (which may be a standard CVV2 coded entry field currently applicable), and then take appropriate action to transfer the customer account number, transaction The amount and the response code of the merchant machine are transmitted to the merchant machine. Additional security information such as card expiration time and customer address may also be provided.

The merchant can obtain authorization for the transaction from the card issuer in the usual way by passing the customer account number, transaction amount, response code, and any other secure information to an authentication server operated by the card issuer. The verification server is able to determine from the customer account number whether the card being processed is registered with the host computer forming part of the invention, and then contacts the host computer to deliver the customer account number, transaction amount and response code.

After receiving this information, the host computer uses the customer account number to retrieve the pseudo-random security code and customer PIN originally issued to the customer electronic device since they are both stored in the host computer. Then it is a simple matter for the computer host to operate the same predetermined encryption algorithm used by the above-mentioned electronic device to operate on the above-mentioned pseudo-random security string, transaction amount and customer PIN to generate the verification code. Then, the above-mentioned computer mainframe compares the verification code with the received response code to confirm whether they match, and if they match, report to the card issuer's verification server that the transaction is authorized. The card issuer then debits the customer's card and credits the merchant's account in the usual manner.

If the verification code and response code do not match, the transaction will not be authorized, and the card issuer's authentication server can then decline the transaction. If attempts to initiate a transaction on a particular customer account do not complete the authorization process more than a predetermined number (e.g., three times), the customer's account will be locked by the host computer and, optionally, verified by the card issuer. The server locks because repeated authorization failures indicate that the card has been stolen and is being used by an unauthorized person who does not know the customer PIN or pseudo-random security string. Only after further contact by the customer/cardholder with the card's issuer and/or verification center will the customer account be unlocked, possibly resulting in the customer being given a new card with a new account number.

If the transaction is authorized by the computer host, said computer host generates a new pseudo-random security string and sends it to the customer's electronic device as previously described. The customer can then conduct further transactions in the same manner with the same or a different business machine. However, because the aforementioned pseudo-random security string is different for each transaction, it is very difficult for fraudsters and hackers to use any intercepted communications to break into the system. The new pseudo-random security string is transmitted as part of a message including further information (eg, details of recent transactions, account balances, remaining credit limit, etc.).

The present invention operates in a manner similar to that used in traditional transaction venues, for example, where customers make purchases at stores and stores or conduct transactions over the phone. In these places, instead of contacting business machines through websites, transactions are conducted face-to-face or by telephone. When a customer wants to shop, he or she requests the transaction amount from the business machine, and after inputting the transaction amount together with the PIN into the electronic device, transmits the above-mentioned calculated response code to the above-mentioned business machine. By presenting the credit or debit card to the merchant for it to pass through an electronic card reader (such as an EPOS or EFTPOS machine), the customer also passes the customer account number and optional security details (such as the card's expiration date) to the merchant machine. The above-computed response code may be submitted orally to the merchant machine, or electronically transmitted directly from the electronic device to, for example, an EPOS or EFTPOS machine. Then the business machine uses EPOS or EFTPOS machine etc. to transmit the above-mentioned customer account number, transaction amount and response code to the verification server operated by the issuer of the card in a usual way, and carry out the processing process of verification and authorization as described above.

Even where the business machines do not have EPOS or EFTPOS terminals, the system and method of the present invention can still be conveniently applied. It is also known to have the merchant authorize the card by telephone and orally submitting details of the customer's account number and transaction amount to the verification center. Therefore, it is easy for the merchant to do this (authorization) as usual and provide a response code submitted by the customer. Authorization and authentication are handled as previously described.

In order to enumerate some beneficial effects of the present invention, some security issues will be discussed below with reference to existing card verification protocols.

card skimming

In terms of security, such an attack involves a criminal obtaining a credit card number (customer account number) (perhaps by hacking a merchant's website or picking up a discarded transaction receipt containing the card number) and attempting to make a fraudulent transaction. In the present invention, such an attack is less likely to succeed because the criminal has to guess a valid response code (eg, the chance of successfully guessing a three-digit decimal code is 1:1000). After a predetermined number of failed attempts to conduct a transaction (eg, three), the host computer blocks the card (possibly notifying the cardholder via SMS message, etc.) and notifies the issuer of the card. The issuer of the card engages in a session with the cardholder to unlock the card.

Man-in-the-middle

This attack involves criminals obtaining credit card numbers and valid response codes. For example, a criminal may be a waiter at a restaurant (or a website that is undercover) and gain access to a customer's account number and response codes. A criminal waiter can make fraudulent transactions for the same amount authorized by the customer, just not complete the real transaction. This means that the criminal waiter can make a shopping transaction for an amount exactly equal to the total amount of the restaurant's meal bill, however, the restaurant transaction will fail. This kind of fraud is easy to detect (restaurateurs will quickly find out that they are out of money), so this is an unlikely scenario.

Shoulder-surfing

The attack involves the criminal peeking over the cardholder's shoulder at the key code the customer is typing into the electronic device to gain access to the customer's PIN. In order to carry out a successful fraudulent transaction, the criminal needs the credit card number and also needs to be in possession of the cardholder's electronic device (eg, a mobile phone). It's a tangible crime: Criminals need to peek at the PIN to steal credit cards and electronic devices. By increasing the security of the PIN and/or by advising cardholders to take relevant security measures (e.g., cardholders should never store their cards with electronic devices and do not allow anyone else to see when entering their PIN), this problem can be overcome.

Response code calculation

This attack involves the criminal obtaining a credit card number and then calculating a valid response code. In order to calculate the response code, the criminal needs to know the PIN and the current pseudo-random security string. The method of inferring the PIN relies on obtaining a large number of response codes, inferring perhaps through a surreptitious website frequently visited by the cardholder. However, deriving the PIN requires knowledge of the security string (the string is actually a one-time pad consisting of a random number on a dotted tear-off paper, which is the entire security field for each message paper torn off. known encryption techniques). In order to obtain the security string, the criminal needs to attack the encryption in the network GSM, needs to attack the host computer directly, or attack the link between the host computer and the SMS Message Center (SMC) associated with the mobile network operator. To successfully implement computational attacks on response codes, criminals need to be able to attack the security infrastructure while intercepting transactions (in the case of face-to-face or e-commerce). Therefore, such an attack is extremely unlikely to be successful or worth the time.

Embodiments of the present invention provide a secure system and method for verifying credit and debit card transactions with some or all of the benefits described below:

• No new merchant and cardholder infrastructure is required. Assuming the merchants are running the CVV2 protocol, they do not even need to know whether the customer card is registered with the computer host as defined in the context of the present invention. Since no smart card is required, the cost of card issuance is low.

●The transaction amount is confidential. This means that the merchant cannot perform unauthorized transactions or increase the potential cost of transactions.

● Automatically inform cardholders of each transaction via SMS messages etc.

● The cardholder needs a mobile phone or equivalent electronic device. However, no special mobile phone or device is required. What the cardholder needs is a SIM card in a mobile phone programmed with applets including predetermined encryption algorithms. Some mobile phone users are able to program the installation of appropriate applets into existing SIMs using an "over-the-air (OTA)" format. The applets suitable for use with the present invention are very simple and therefore do not require much space on the SIM card.

● At the point of sale, no mobile phone coverage is required. What the cardholder needs is to be able to receive SMS messages or similar between transactions (and thus must be covered between transactions).

● There is no need to store a cardholder-specific PIN, key code or certificate in the SIM card in the mobile phone. Providing the cardholder with the necessary means does not require programming of the SIM (unlike the aforementioned applets installed in the SIM). Thus the process of reissuing the card (eg due to loss or denial of service attack) does not require changes to the SIM card.

As discussed above, some embodiments of the present invention require that a new pseudo-random security string be used for each transaction (actually, the security string is a one-time pad as previously defined. The pseudo-random security character The string can be sent after each transaction by SMS message etc. However, in some cases, in order to carry out the next transaction (for example, the cardholder still has to carry out more than one transaction in a store not covered by the mobile phone) , it is inconvenient for the cardholder to have to wait for a new SMS message, etc. To handle this situation, embodiments of the invention may be adapted to allow multiple transactions.

The principle is simple: when a customer activates his or his card by registering with the computer host, the computer host sends a single set of m pseudo-random security strings to the electronic device (where m is an integer, such as 12) information (for example, SMS messages). Applet consumes (consumes) strings of each transaction processed one by one. In order to notify the applet in the electronic device to move to the next security string, the cardholder may need to select the "confirm" menu item (this is the opposite of what the present invention was described in the previous embodiment, where Confirmation is implicitly selected by receiving a new SMS message with a single security string).

When a predetermined nth transaction (n is less than the total number of security strings m originally sent to the electronic device, for example, n is 6) is authorized by the computer host, a new message further comprising a set of security strings is issued by The computer host sends to the electronic device. This method allows the cardholder to carry out m purchase transactions without receiving any transmissions from the host computer, which is useful, for example, when there is no mobile phone coverage or the like. After each transaction is completed, a simple message is sent by the host computer to the cardholder's electronic device as a confirmation and mini-statement (marking the merchant, transaction amount, current balance and remaining balance).

One possibility of this approach is that the applet running on the electronic device and the computer mainframe can stop the processing step when the first merchant machine fails to complete processing the transaction at the point of purchase, thus preventing subsequent merchant machines from processing subsequent transactions. Of course, the first business opportunity has no incentive to do this since the transaction cannot be completed later (eg, user aborts with an incorrect response code). However, this situation can be handled by resetting the card at the host computer (perhaps after the cardholder or the merchant calls the authorization center). The host computer can then send a new set of secure strings to restart processing.

When (or if) the first business machine finishes processing the transaction, the computer host will most likely be able to determine whether to accept or decline the transaction. When the reset is triggered, there are between n and m outstanding security strings (that is, strings that have not yet been used to validate the transaction). The computer host has a record of those security strings, and a transaction from the first business machine can be run against the oldest outstanding security string to see if there is a match. There are two possibilities for matching failures: (i) the transaction failed (was fraudulent, or the cardholder made an error, or the merchant made an error) or (ii) more than one transaction was not processed in a timely manner. In case (ii), the host computer can try to run the transaction with a different security string. Of course, the transaction can be rejected outright provided the business machine fails to follow the correct process steps.

Application of a mobile phone or similar as an EPOS or EFTPOS terminal

Employing the present invention changes the security status of the information being processed in a transaction (eg, knowing the card number and response code is not sufficient to conduct a fraudulent transaction). This means that alternative methods of providing the host computer with the required transaction information (card or customer account number, response code, transaction amount, etc.) can be used.

Mobile phones or PDAs etc. provide an excellent way for a business machine to access the system in progress. Transactions can be described in the format of SMS messages or similar (using a predetermined format) and sent to phone numbers (devices) established by the appropriate acquiring network. The acquisition network receiving the message extracts the transaction information (inferring the merchant identity from the source phone number such as a mobile phone) and processes the transaction in the normal way (checking credit limit, accessing computer host, etc.). Acceptance or rejection of the transaction is sent back to the business machine and the original mobile phone or the like via an SMS message or the like.

This approach provides a low cost method of making the merchant a part of the card processing network and is especially useful for small business transactions with little investment capital. It allows card processing in areas where access to fixed line infrastructure is difficult, such as in taxis.

In order to better understand the present invention and illustrate how the present invention is implemented, the following will be described by way of example with reference to the accompanying drawings, wherein:

Figure 1 shows a schematic diagram of the basic architecture of an embodiment of the present invention.

In Fig. 1, a computer host 10 is shown, acting as an authorization server. When the card issuer issues the card to the client, the client must at first register from the host computer 10, and the registered details include the client's account number (card number), PIN, mobile phone number, etc. name and address). Once registered, the host computer 10 generates at least one pseudo-random security string and sends it through step 1 to the mobile communication device 11 operated by the client, which may be a mobile phone, PDA, pager, etc. Sending 1 can be via SMS message, e-mail, etc. The host computer 10 associates the above-mentioned at least one pseudo-random security string located in its memory with the customer account number and PIN.

When a customer wishes to conduct a transaction with the merchant machine 13, the customer inputs the transaction amount and PIN into the mobile communication device 11 via a keyboard or the like. The applet running inside the SIM card or similar (which is located in the device 11 and programmed with a one-way cryptographic hash algorithm 12) extracts in step 2 the transaction amount entered by the user, the PIN and the aforementioned pseudo-random security string, And the information is mixed (hash) to generate a 3-digit response code, and the above-mentioned response code is transmitted to the business machine 13 via step 3. The above-mentioned response code may be given to the business machine 13 orally in a face-to-face or telephone transaction, or the above-mentioned response code may be given to the business machine 13 via the business machine website when conducting an electronic commerce transaction.

Simultaneously, the business machine 13 receives the customer account number and the transaction amount by scanning the card at the EPOS or EFTPOS terminal or other appropriate means, and then transmits the above-mentioned response code together with these information to the card buyer's network server via step 4 in a known manner ( CANS-Card Acquirer Network Server) 14. The merchant 13 also passes the merchant identity information to CANS 14 via step 4, thus enabling CANS 14 to associate the transaction with the merchant 13, and with the customer (via the customer account number).

CANS 14 then transmits customer account number and transaction amount and response code to host computer 10 via step 5 in a known manner. Next, host computer 10 uses the customer account number received from CANS 14 to retrieve the customer PIN and pseudo-random security string (initially passed to mobile communication device 11 in step 1) from memory, and in addition to algorithm 12 in host computer 10 Outside of running time, the pseudo-random security string, customer PIN and transaction amount are entered into the one-way cryptographic hash algorithm 12 (like the algorithm running in the applet of the mobile communication device 11). Since the algorithm 12 running in the computer host 10 will operate on the same input as the algorithm 12 running in the applet of the mobile communication device 11, the algorithm outputs a check code of 3 digits, the 3 digits The verification code matches the response code given when the transaction was valid. Therefore, when the given response code and the calculated verification code are found to match by the host computer 10, the transaction is authorized, and an authorization signal is sent from the host computer to CANS 14 via step 6.

As an option, if the given response code does not match the calculated verification code, the host computer 10 will reject the transaction, and a rejection signal is sent to the CANS 14 via step 6.

If the CANS 14 receives an authorization signal from the host computer 10, the customer's card account is debited in the usual way along with the transaction amount, which is associated with the CANS 14 identity of the merchant 13. In addition, CANS 14 credits the business machine account number with the transaction amount in the usual way. CANS 14 also passes an authorization signal to the business machine 13 via step 7, and the business machine informs the customer via step 8 that the transaction has been authorized.

At this time, once the computer mainframe 10 authorizes the transaction, it sends a new pseudo-random security string to the customer's mobile communication device 11 via step 1 together with optional information for confirming the transaction authorization, transaction amount and card account balance.

If the transaction is not authorized because the host computer 10 finds that the given response code does not match the calculated verification code, the above-mentioned CANS 14 passes a rejection signal to the merchant 13 via step 13, and the card account will not Debited or business machine account numbers will not be credited. After receiving the rejection signal, the merchant machine 13 can decline the transaction, or request a further response code from the customer. If the three consecutive response codes provided by the customer do not match the calculated verification code in the host computer 10, the host computer 10 can block the customer's account and send the result to the CANS 14, so that between the customer and the operator Prevent further use of the card until the host computer's authorization center is contacted. It is possible that a customer's card has been stolen and is being used fraudulently by a third party without knowledge of the PIN and pseudo-random string, so that a new card may need to be issued.

In order to further describe the beneficial effects of the present invention, a typical scenario is now described.

Alice decides that she needs to obtain the card used in the present invention. She is so for two reasons. First, she wants to make sure she can shop safely on the Internet (she's read how easily hackers can break into websites and steal credit card numbers, names, addresses, phone numbers, and more). Second, she needs the card and no one else can give her one: Alice is 15, too young to get a credit card. However, several banks are going to issue prepaid protected cards to teenagers because the cards protected by the present invention can prevent the merchant 13 and the cardholder from mutually incorrect operations.

While at school, Alice accesses her bank's website (using her internet bank account) and requests a card, she also tells the bank her mobile phone number (and who her mobile operator is) and selects a PIN. She ticks the option to have a special picture on her card, then uploads a digital photo from her PC (her card is not embossed since her card will not be read on carbon paper later) .

The bank starts the process of applying for a card, and the bank checks whether the mobile operator uses a SIM programmed with the appropriate applet used by the present invention. The bank then creates a card for Alice and passes the card number, Alice's PIN and her mobile phone number to the host computer 10 operated by an independent authorization center (the host computer 10 does not require any other information).

A few days later, Alice's card arrived in the mail. Alice accesses her internet bank account to notify that the card has been received. Alice transfers £150 to the card. A few seconds later, a text message is received (step 1) on her phone 11 informing her that her card is ready to use (the message also contains 12 security strings, but she doesn't have to know these).

Alice is shopping online and wants to buy her mother a birthday present. She visits website 13, which sells garden gear, and finds the ideal gift: a gold-plated watering can. The cost including postage is £50. She goes to the "Pay Bills" web page, takes out her card and pays the bill. The aforementioned website asked for the last three digits on her card. On her card, the last three digits are marked " ^*** ". She looked closer and saw that the card included the words "use response code ^*** " which she remembered was on the information leaflet sent to her with the card. She takes out her mobile phone 11, selects "pay by card" from the menu (this activates the applet), enters (step 2) her PIN, and presses the "OK" key. She then enters (step 2) the transaction amount number 50 and presses "OK". The above applet running in the SIM card of the phone 11 applies the algorithm 12 to the PIN, transaction amount and security string (given in step 2) to generate a 3-digit response code, the phone 11 displays "Response code: 132 ", she enters "132" into the input unit requesting 3 digits of the above-mentioned website 13. The aforementioned website 13 then displays "Processing order....".

The above-mentioned website's merchant server submits the transaction details (card number, amount, Alice's address, and a three-digit code, which appears to be the CVV2 code) to the card processing computer (the website's merchant uses the service company to process the card transaction). The computer then looks at the card and contacts the appropriate Card Acquirer Network Server (CANS) 14 (step 4) and submits the same transaction details to the CANS.

The above CANS14 checks that there is (whether) enough money in the card to pay the bill. The check passes (card's account has £150, transaction amount is £50). CANS 14 calls (step 5) to host computer 10 with card number, amount and three digit response codes then. The host computer 10 uses the card number to look up Alice's PIN and security string issued to Alice's mobile phone 11. The host computer 10 runs the same cryptographic hash algorithm 12 (using a secure string and PIN that looks up the transaction amount submitted by the lender by CANS 14) as is running in the SIM card of Alice's mobile phone 11. The host computer 10 calculates a check code corresponding to the response code 132 that Alice reads from her mobile phone. The calculated verification code matches the response code given by the CANS 14 to the host computer 10, and therefore the transaction is considered valid and authorized.

Host computer 10 notifies (step 6) that CANS 14 safety detection passes and establishes new safe character string. CANS 14 notifies host computer 10 of the identity of merchant 13 and the current balance on her card. The host computer 10 gets this information and sends it to Alice's mobile phone 11 in a text message along with the new security string (step 1), CANS 14 notifies the card processing computer that the transaction has been settled. The above-mentioned card processing computer notifies the network business machine server 13 of these information. The web merchant server 13 notifies Alice that the payment has been accepted. A few seconds later, Alice receives a text message from the computer host 10 on her mobile phone (step 1). The text message is "Currently spending (PresentsDirect) £50 with a balance of £100".

Alice comes to town for more shopping. At her favorite bookstore, she found that she couldn't use her mobile phone 11 to call her friends because there was no signal (strange, she thought, because there was signal outside the store, but she didn't know the store was in reinforced concrete Framed with a steel frame and clad in metal, thus blocking mobile phone signals). She finds a book she really likes and wants to pay the bill. At the cashier, the clerk told her the total amount was £20.55. She hands over her card to the clerk and takes out her cell phone 11 . She selects "Pay by Card" from the menu (this activates the applet), enters (step 2) her PIN, and presses the "OK" key. She then enters (step 2) the transaction amount number 20.55 and presses "OK". The above applet takes one of the 12 security strings initially given as a third input, and calculates a response code via Algorithm 12. The above-mentioned telephone 11 displays "response code: 451".

At the same time, the above-mentioned clerk swipes Alice's card at the EPOS machine 13, the machine 13 reads the card number and calls the CANS 14 used by Alice's bank (step 4), and the CANS 14 at the other end of the telephone call requests the EPOS machine 13 to read Amount of the transaction. The above clerk types in 20.55. The CAN server 14 then requests a response code. The aforementioned clerk asks Alice for the response code, and Alice tells the clerk "451". The above-mentioned clerk inputs the above-mentioned response code to the EPOS machine 13, and the above-mentioned response code is passed to the CANS14 (step 4).

CANS 14 checks whether there is enough money in the card to pay the bill and calls the computer host 10 with the card number, amount and response code (step 5). The main computer 10 calculates a check code matching the response code 451 read from the display of Alice's mobile phone. The above-mentioned calculated verification code and the response code given by the CAN server 14 to the host computer 10 are found to match, so the transaction is valid. Above-mentioned computer host notification (step 6) CANS 14 security checks pass and produces new security character string. CANS 14 notifies host computer 10 of the identity of the business machine and Alice's current balance on the card. The host computer 10 receives these messages and sends them to Alice's mobile phone 11 in the form of a text message together with the new security string (step 1).

CANS 14 notifies (step 7) EPOS machine 13 that the transaction has been closed, EPOS machine 13 displays an "OK" message to let the clerk know that the transaction has been closed, and said clerk hands Alice the card and the bag containing the book. After Alice left the store, she found that it was raining heavily. She decides to take a taxi home and walks across the street. By the time she reaches the other end of the street, a message is obtained on her phone 11 (step 1) with the message "Acme book £20.55, balance £79.45". What she does not see is that the above message also enters the new security string into her phone 11 for the next time she uses the card.

When she got home, the taxi driver told her the fare would be £22.50. She tells the driver to give him £25 including tip, gives him his card and selects "Pay by Card" from the menu on her mobile phone 11, enters (step 2) her PIN, presses "OK". She then enters (step 2) the transaction amount number 25 and presses "OK". The phone 11 applies the above algorithm 12 to the PIN, the transaction amount and the security string, then it will display "Response code: 722", while the taxi driver has started writing a new message in his mobile phone 13. He enters Alice's card number and the transaction amount of 25.00. Next, he asks Alice for a response code, Alice tells him "722" (step 3), he enters 722 into the message, and sends it (step 4) to the mobile number of CANS 14 (stored in his phone 13 in your address book).

After CANS 14 receives this message. It looks up the sender's phone number and finds that it is registered to a taxi driver (he is a one-man company). CANS 14 checks that there is enough money in the account of Alice's card to cover the transaction (£79.45 still in the account, the transaction amount is £25). CANS 14 then contacts host computer 10 and submits (step 5) the card number, amount (£25) and response code (722). The host computer 10 checks whether the response code is valid by comparing the response code with an independently calculated verification code, and then indicates to the CANS 14 that the transaction was successful (step 6). CANS 14 sends (step 7) the SMS message that shows that the transaction has been successfully completed to the taxi driver's phone 13, and informs the host computer 10 of the above-mentioned business machine's identity and the new card balance (54.45 pounds).

The above-mentioned taxi driver receives (step 7) a text message from CANS 14: "transaction authorized". He tells Alice that it is OK to pay the bill (step 8), and Alice gets out of the taxi. A few seconds later a text message is received in her mobile phone 11 (step 1) with the message "John's taxi £25.00, balance £54.45". Alice returns home.

Alice was in town the next day when she discovered her card was missing. The taxi driver must have forgotten to return the card to her. She called the bank and told them. They told Alice it was okay and they would send another card to her home soon. The next day, the new card arrived in the mail. The bank doesn't have to bother changing the card number or creating a new PIN for Alice. The bank knows that the criminal cannot use the old card to complete the payment. Alice is satisfied: she doesn't want the hassle of changing all the details of her card and having to remember a new PIN. The banks are happy, too: They don't have to do anything more than print another copy of the card and mail it.

Embodiments of the present invention are thus a major improvement over the existing CVV2 protocol. They prevent all fraud. For example, cardholders are protected from erroneous merchant (or its employees) operation, and merchants can be protected from stolen cards or fraudulent cardholder use.

Embodiments of the present invention provide cardholders with the immediate benefit of avoiding the hassle of replacing a lost or stolen card, as can eliminating card fraud (a benefit to card issuers and merchants). The hassle of scrutiny of card claims is no longer important.

The security properties of embodiments of the present invention enable further improvements in the infrastructure domain. For example, the adoption of mobile phones as a low-cost and easy way of introducing business tools means that the use of cards can be expanded into areas where it is not feasible today (ironically, many developing countries have excellent wireless infrastructure, but fixed The phone lines are poor). This method even offers ordinary people the possibility to pay bills with their card (very useful for making high value items such as paying for used cars and computer equipment).

One of the most important benefits of embodiments of the present invention is that those benefits are achieved without a major infrastructure investment, and thus, the present invention presents an excellent opportunity to open up the personal finance industry while reducing fraud. new possible situations.

The preferred features of the invention are applicable to all aspects of the invention and may be used in any combination.

In this detailed specification and claims, the words "comprise" and "contain" and variations of the above words, such as "comprising" and "comprise", mean " includes but not limited to", and does not exclude other components, combinations, sub-components, additional components and steps.

Claims (25)

1. one kind is carried out the Secure Transaction authorization method between client and commercial machine, and described method comprises the steps:

I) storage comprises the customer information of customer accounting code and relevant PIN (PIN) in main frame;

Ii) in described main frame, produce the pseudorandom security string;

Iii) send described pseudorandom security string at least one far-end electronic installation by client's operation from described main frame;

When iv) between client and commercial machine, concluding the business, described PIN and dealing money are imported described electronic installation;

V), produce answer code at described electronic installation by predetermined cryptographic algorithm being applied to described pseudorandom security string, PIN and dealing money;

Vi) transmit described answer code, dealing money and customer accounting code to described main frame;

Vii) in described main frame, utilize described customer accounting code to retrieve described PIN and described pseudorandom security string, then described predetermined cryptographic algorithm is applied to described pseudorandom security string, PIN and dealing money, thereby produce check code;

Viii) in described main frame, more described check code and described answer code are if they mate authorized transactions then mutually.

2. the method for claim 1 is characterized in that, described far-end electronic installation is mobile phone, personal digital assistant or pager.

3. method as claimed in claim 1 or 2 is characterized in that, described answer code passes to described commercial machine by described client, and described then commercial machine passes to described main frame with described answer code, dealing money and customer accounting code in step in vi).

4. method as claimed in claim 3 is characterized in that, described answer code is passed to described commercial machine by described client via commercial machine website.

5. method as claimed in claim 3 is characterized in that, described answer code is passed to described commercial machine by described client with the form of oral or written message.

6. method as claimed in claim 3 is characterized in that, described answer code is passed to described commercial machine from described electronic installation with the form of electric transmission information by described client.

7. any described method in the claim as described above is characterized in that, step vi) in, described answer code, dealing money and customer accounting code are transferred to described main frame via intermediate server.

8. any described method in the claim as described above is characterized in that, step vi) in, described answer code, dealing money and customer accounting code are transferred to described main frame via Internet connection.

9. as any described method in the claim 1 to 7, it is characterized in that, step vi) in, described answer code, dealing money and customer accounting code are via being transferred to described main frame by the EPOS of described commercial machine operation or EFTPOS device.

10. as any described method in the claim 1 to 7, it is characterized in that, step vi) in, described answer code, dealing money and customer accounting code are via being transferred to described main frame by the mobile phone of described commercial machine operation, personal digital assistant or analog.

11. any described method in the claim is characterized in that as described above, step I ii) in, a plurality of pseudorandom strings are transferred to described electronic installation from described main frame simultaneously.

12. any described method as in the claim 2 to 11 is characterized in that, described algorithm form with applet in being installed on the SIM card of described electronic installation is moved.

13. any described method in the claim is characterized in that described answer code and described check code are the tens digits of three bit digital as described above.

14. one kind is used for affaris safety trade system that the transaction between client and the commercial machine is authorized, described system comprises main frame and at least one electronic installation by client's operation, wherein:

I) customer information that comprises customer accounting code and relevant PIN (PIN) is stored in the described main frame;

Ii) described main frame produces the pseudorandom security string, and sends described pseudorandom security string to described at least one electronic installation by client's operation;

Iii) the client when concluding the business with commercial machine, described electronic installation receives the input from the client, described input comprises described PIN and dealing money;

Iv) described electronic installation is by applying to predetermined cryptographic algorithm described pseudorandom security string, PIN and dealing money, thereby produces answer code;

V) described answer code, dealing money and customer accounting code are transferred to described main frame;

Vi) described main frame utilizes described customer accounting code to retrieve described PIN and described pseudorandom security string, then described predetermined cryptographic algorithm is applied to described pseudorandom security string, PIN and dealing money, thereby produces check code;

More described check code of viii) described main frame and described answer code are if they mate authorized transactions then mutually.

15. system as claimed in claim 14 is characterized in that, described far-end electronic installation is mobile phone, personal digital assistant or pager.

16. as claim 14 or 15 described systems, be applicable to such situation, that is, described answer code can pass to described commercial machine by described client, and described commercial machine can pass to described main frame with described answer code, dealing money and customer accounting code in v) in step.

17. system as claimed in claim 16 also comprises being applicable to the commercial machine website of reception from described client's described answer code.

18. system as claimed in claim 16 is characterized in that, described electronic installation is applicable to described answer code is passed to described commercial machine with the form of electric transmission information.

19. any described system as among the claim 14-18 also comprises intermediate server, step v) in, described answer code, dealing money and customer accounting code are transferred to described main frame via described intermediate server.

20. as any described system among the claim 14-19, be adapted to step v) in, described answer code, dealing money and customer accounting code are transferred to described main frame via Internet connection.

21. any described system as in the claim 14 to 19 also comprises EPOS or EFTPOS device, its be applicable to step v) in, described answer code, dealing money and customer accounting code are transferred to described main frame.

22. as any described system in the claim 14 to 19, also comprise mobile phone, personal digital assistant or analog by described commercial machine operation, its be applicable to step v) in, described answer code, dealing money and customer accounting code are transferred to described main frame.

23. any described system as in the claim 14 to 22 is characterized in that described main frame is applicable at step I i) in, a plurality of pseudorandom strings are transferred to described electronic installation simultaneously.

24. any described system as in the claim 14 to 23 is characterized in that, the form with applet in the SIM card of described algorithm in being loaded on described electronic installation is moved.

25. any described system as in the claim 14 to 24 is characterized in that described answer code and described check code are the tens digits of three bit digital.