SK176199A3 - Payment process and system - Google Patents

Abstract

A payment process and system using a smart card (1) which accesses a remote account at a card issuer (20) via an acquirer (18). The card is read in a terminal (6) which is in two-way communication (17) with the acquirer (18). As part of the payment process, a cryptogram of the transaction data is made by the smart card and used in the terminal (6) as a key to encrypt the PIN, entered by the cardholder, for transmission to the acquirer (18). The acquirer also creates a cryptogram, using the transaction data sent to it by the terminal (6), and uses this cryptogram (which should be the same as that created by the smart card) to decrypt the encrypted PIN. In this way, the use of an expensive tamper-resistant encrypting PIN pad at the terminal (6) is avoided, whilst maintaining security.

Description

Payment process and system

Technical field

The present invention relates to a payment process and a system intended, in particular, for use in financial transactions by means of ICC integrated circuit cards or "smart cards".

BACKGROUND OF THE INVENTION

In a financial transaction using a credit card or debit card, it is normally necessary for the transaction data to be communicated to the card issuer or to another equivalent to authorize (authorize) the transaction. When the credit card or debit card is in the form of a smart card, the card will have in its memory application software that is activated to perform the function of credit card or debit card as necessary. One card can include both credit card and debit card applications as well as other financial features, such as a cash card feature, or even non-financial features. In particular, the present invention relates to the use of smart cards as debit and / or credit cards.

Important card issuers Europay, MasterCard and Visa have together developed standards (known as EMV ICC Specifications for Payment Systems) for smart card payment systems. Systems developed to these standards enable the cardholder to pay for goods and services by accessing a remote account at a bank or other financial institution. As part of such a payment process, the cardholder can authenticate against a financial institution by entering a PIN (Personnel Identification Number). When using this form of holder authentication, a critical aspect of the design of the system is the secure transmission of the PIN to the account management institution.

Access to the remote account is accessed through the terminal where the user slips their card, usually at the beginning of the transaction. The terminal is connected or is able to somehow connect with the account institution so that messages can be exchanged between them. It would be highly advantageous if the terminal used to manage the smart card transaction could be a cheap device, for example suitable for domestic use. EMC-compliant applications are not suitable for this purpose. They are built as part of large infrastructure terminals with encryption keyboards for entering PI N resistant to unauthorized interference. Therefore, it is not appropriate to use EMV standards in the usual way to meet the payment application requirements on a smart card.

Despite their unsuitability for a payment application for the purpose explained above, EMC-compliant applications have many of the required attributes, are well known in the financial community, are implemented and have stable related standards. It would be of great benefit to find a way to use such applications without the need for EMC-incompatible commands. It is therefore an essential object of the present invention to find a PIN encryption method without the cost of a tamper-resistant PIN keypad. PIN encryption is not a standard EMV function since it is assumed that this function is performed by the PIN keypad on the terminal.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide a payment process and system capable of achieving the above objective. For a full understanding of the present invention, it is preferable to know the function of EMV standards as defined in 96ν'96 Integrated Circuit Card Specification for Payment Systems ”version 3.0 of June 30, 1996. Although the EMV standard and EMV-compliant applications are mentioned herein, this technique is in principle applicable to any smart card payment system with similar orders. This patent application covers all such embodiments; EMC is used only as an example to explain this technique.

According to a first aspect of the invention there is provided a payment process allowing secure communication between a smart card and a financial institution, which process comprises placing the card in a card reader forming part of the terminal in communication with the financial institution, entering transaction data and PIN via keyboard, creating a data cryptogram transactions containing this transaction data, sending the first cryptographic key known or derivable by the financial institution, and then using this cryptogram to encrypt the PIN for secure transmission to the financial institution.

The financial institution may be the card issuer who holds the account corresponding to the card or is likely to be an intermediary, commonly called the acquirer, acting as a link between the terminal and the card issuer. The acquirer is very likely to act as an agent for several issuers and will therefore be responsible for ensuring that messages coming from any card of the issuer in question are properly directed to that issuer.

The terminal is usually located in retail premises, allowing the cardholder to purchase goods using a card such as a debit or credit card. The card therefore contains an application program that allows it to function as needed. This application is associated with a second cryptographic key, referred to herein as a card key, which card key is loaded into the card at the same time as the original application and known to the financial institution.

The card key may be the same as the first key, but preferably the cryptographic key used to generate the cryptogram (i.e., the first key) is derived from the card key using a transaction parameter function, preferably a transaction sequence number, encrypted with the card key. A transaction sequence number is any number that uniquely identifies a transaction. The transaction number is preferably stored on the card and increased by 1 at the beginning of each new transaction. The transaction number is transmitted to the financial institution as part of the payment process, so that if necessary, the financial institution is able to derive the cryptographic key used to create the cryptogram.

The financial institution shall decrypt the PIN after the encrypted PI N is transmitted to that institution. In a preferred embodiment of the invention, the process is performed in a financial institution by mirroring the creation of a cryptogram from the transaction data transferred to it from the terminal. To this end, the financial institution needs to know or be able to derive the first key mentioned above. The cryptogram created in this way should therefore be identical to the cryptogram created with the card.

Transaction data means transaction-related data that includes certain information entered via the keyboard, such as the transaction amount, and certain information generated internally by the terminal, such as the transaction date (assuming the terminal has a built-in calendar). A cryptogram is actually a summary or summary of transaction data. In the DES encryption system, such cryptograms are sometimes referred to as Message Authentication Codes or

MAC. Techniques for generating such cryptograms are known in the art. Briefly, transaction data is divided into small units, for example 8 bit length, and units are processed one by one, starting at the beginning. Each unit is thus encrypted using the same key and the same function, with the encrypted output of each unit being added to the next before encryption. When all the units constituting the transaction data are recycled, the final output is derived from all units; any change in transaction data during the transaction, whether random or otherwise, will result in the generation of a cryptogram that differs from the first, so that the fact that the change occurred can be ascertained.

Preferably, the cryptogram is used as a cryptographic key to encrypt the PIN for transmission. In theory, several encryption methods can be used; however, it should be noted that any method is used, the intercepting person must not be able to reconstruct the PIN and cryptogram separately. In a preferred embodiment, the PIN and the cryptogram form the respective inputs to an exclusive logical OR operation that produces a code from which none of its components can be derived without knowing the other. At the financial institution, the cryptogram will be re-created as above, and therefore a PIN can be derived if the transmission is flawless. It is of course not yet known whether the PIN corresponds to the account held by the issuer at this time. However, once the PIN is verified, the transaction can continue.

According to a second aspect of the invention there is provided a payment system for facilitating secure communication between a smart card and a financial institution, said system comprising a terminal with a card reader for reading said smart card and a keyboard for enabling transaction data entry, said card being programmable to from the transaction data containing the transaction data entered via the keyboard to a cryptogram using a cryptographic key known or derivable by the financial institution, and said terminal further comprising means for using the cryptogram to encrypt the PIN entered via the keyboard and means for transmitting the encrypted PIN to the financial institution.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to better understand the invention, its embodiment will now be described by way of example only and with reference to the accompanying drawings, in which:

Figure 1 is a schematic diagram of a smart card for use in the payment process and system of the invention;

Figure 2 is a block diagram of a payment terminal suitable for use in the payment process and system of the invention;

Figure 3 is a block diagram illustrating a general smart card remote payment system.

Figure 1 shows a smart card I with a contact surface 2 on one side comprising a plurality of separate electrical contacts to which an external power supply can be connected to power the card and through which a serial communication channel can be established to transmit messages and data to and from the card. The card further comprises a microprocessor 3, a non-volatile memory 4, such as a read-only memory (ROM) or an electrically erasable programmable read-only memory (EEPROM), and a random access memory (RAM) 5.

Memory 4 contains one or more applications that define the function of the card and their respective cryptographic keys. An application is simply a program with appropriate data files, and it can, for example, give the card the function of a debit card, credit card, or both.

To be used in a payment system, the card is inserted into a card reader forming part of a payment terminal that can communicate with the cardholder account at a remote location. A simplified block diagram of a suitable payment terminal 6 is illustrated in Figure 2.

Referring to Figure 2, the terminal 6 comprises a microprocessor 7 with a non-volatile memory 8, such as ROM or EEPROM, a write / read memory 9, and optionally a display 10 coupled via interface circuitry 11. The user input is via the keyboard 12 connected to the microprocessor via the interface circuitry 13. The above card reader is shown under number 14 and has contact with the card via the contact surface 2. The communication circuit 15 serves to establish two-way terminal communication with the rest of the system, either permanently or via I / O port 16.

The operation of the terminal 6 is basically controlled by the microprocessor 7 and its associated circuits, most of which are not shown for the sake of simplicity, but which are well known to those skilled in the art. The terminal forms part of a smart card payment system, shown as a block diagram in Figure 3.

In Figure 3, terminal 6 is shown to be connected via a two-way communication channel 17 to the acquirer 18. The acquirer is the entity that is responsible for managing the overall payment transaction and is likely to act as an agent for several card issuers. For example, the acquirer may be a bank or other financial institution.

The acquirer is connected via a two-way communication channel 19 to the card issuer 20, which, for the purposes of this explanation, is considered to be the card issuer 6 and holding the cardholder account. The acquirer 18 is responsible for routing messages from the terminal 6 to the appropriate card issuer for payment authorization. However, as will be explained below, it is possible for the terminal 6 to communicate directly with the card issuer to bypass the acquirer; in the simplest system, it is even possible that no acquirer exists in the system.

The configuration of the card 6 is performed by the personalization service (PServ) 21, which is actually part of the acquirer but may also be part of the card issuer (see below). The card is configured by preparing an instance of the application — namely, code, data, and cryptographic key — and loading that instance and key into the card. The application and its corresponding cryptographic key are then stored in non-volatile memory 4 on the card, as discussed above. Configuration is done on new tabs before they are used, or can be done on existing tabs to update or add a feature card. The cryptographic key, hereinafter referred to as the card key, is used with the cryptographic system to ensure secure data transfer to and from the card. A symmetric cryptographic system such as DES is commonly used in payment systems of the type discussed herein. This uses a secret cryptographic key known only to card 6 and the acquirer 18 to allow encryption and decryption of the data sent between them. In practice, the card key is a function of the cardholder identification data, for example an account number encrypted by the master key of the acquirer. Thus, the card key is unique to the card and can be derived by the acquirer from the identity of the cardholder and the acquirer's master key.

In the payment transaction, the user enters his / her PI N via the keypad at terminal 6. If a normal type of encryption key is used to enter an unauthorized PI N, the PIN will be encrypted using a cryptographic "terminal key known only to the terminal and the acquirer. Meanwhile, transaction data that contains information such as the date and amount of the transaction is transferred to the card and a cryptogram is generated from the transaction data in the card itself using a cryptographic transaction key. Once created, the cryptogram will return to terminal 6. In an EMV-compliant application, the cryptogram would be prepared by the card upon receiving the “Generate Application Cryptogram” command issued by the terminal. Details of this EMV command, its function and parameters are given in the EMV specification above. In practice, the transaction data is passed as a parameter of the “Generate Application Cryptogram” command issued by the terminal, and the cryptogram is returned to the terminal as the return parameter of the command.

The transaction key used to create the cryptogram is derived on the card as a function of the transaction sequence number (which differs for each transaction) encrypted with the card key. The transaction sequence number is also returned to the terminal as a return parameter for the “Generate Application Cryptogram” command.

The cryptogram is then passed along with the transaction data and the encrypted PIN to the acquirer 18. The acquirer checks the transaction data against the cryptogram, decrypts the PIN, and then re-encrypts the PIN for transmission to the appropriate issuer 20 along with the transaction data. The key used to re-encrypt the PIN is known to the authorizing issuer.

Consequently, the cryptogram is an encrypted summary of transaction data and allows the acquirer or issuer to detect any interference in the data, whether intentional or accidental, by comparing the received transaction data with its cryptogram. Transaction data will usually be quite long, while the encrypted summary or cryptogram will be much shorter, usually only 8 bits. The method for preparing the cryptogram is well known in the art and will not be further described.

Upon receipt of transaction data and re-encrypted by the PIN by the issuer 20, the issuer checks the PIN entered by the cardholder and, if correct, checks the adequacy of the account balance or exceeds any credit limit and then returns the transaction authorizing message back to terminal 6 via the acquirer 18.

For the purpose of the present invention, it is assumed that the keyboard at terminal 8 is not capable of encrypting, or if it is, is not used. According to an embodiment of the invention, PIN encryption is performed by the terminal after receiving the cryptogram back from the card using the cryptogram as a cryptographic key. The microprocessor 7 and associated circuits thus derive a cryptogram-encrypted PIN function. An example of a simple logic function that achieves this is the exclusive OR function. In other words, PIN encryption is performed by creating an exclusive OR cryptogram and PIN at the terminal, and this data item is transmitted to the acquirer 18 along with the transaction data as described above. At the acquirer 18, the PIN must be decrypted. To do so, the acquirer rebuilds the cryptogram from the transaction data it received from the terminal. It then uses this cryptogram to decrypt the PIN. The PIN is then re-encrypted using a key known between the * acquirer and the issuer and sent to the issuer for a PIN check. The re-encryption can be performed by the acquirer within the tamper-proof device so that the PIN never appears unencrypted outside the cryptographic domains existing between the terminal 6 and the issuer 20. If the PIN is correct, the transaction data is examined and the account checked. If everything is OK, the appropriate authorization message is passed back to terminal 6. If the Acquisition PIN check turns out negatively, this may indicate that the cardholder PIN was not entered correctly on the keypad, or it may indicate that the transaction data was in some way on the road to the acquirer damaged. Either way, the transaction will not continue.

Theoretically, several ways can be used to encrypt a PIN using a cryptogram as a key. In practice, however, many possible ways are avoided because the data item that is transmitted from the terminal 6 to the acquirer 18 must not allow the eavesdropper to reconstruct the PIN and the cryptogram separately.

It will be understood that the techniques described above allow for encryption of the PIN without the use of an encrypting keyboard for entering the PIN and in a manner that is transparent to the EMV application on the card. The terminal 6 thus ensures that the EMV application on the card sees the payment transaction as a standard EMV payment transaction.

The present invention enables this approach by providing a method of encrypting the PIN for transmission to the issuer through the acquirer so that confidentiality during transmission is completely secured. This is not provided by any existing EMV application because, as mentioned above, PINs are normally encrypted in the terminal, not in the card.

So far, it has been assumed that the personalization service (PServ) 21 is associated with the acquirer 18. However, the techniques that are the subject of this patent application are equally applicable when PServ 21 is associated with the issuer 20. In this case, an encrypted message containing the PIN would pass through without any translation. The acquirer could not decrypt the message containing the PIN because only the applications on card 6 and the issuer 20 would have the necessary keying relationship. If it is important to keep the current standard payment authorization message formats, then the issuer's conversion utility could be a simple interface to the issuer's authorization systems.

In this alternative model, the PServ personalization service could either be issuer-specific or be supported by a service provider for several issuers.

Claims (13)

PATENT CLAIMS 1. A payment process allowing secure communication between a smart card and a financial institution, comprising placing a card in a card reader forming part of a terminal in communication with said financial institution, entering transaction data and a PIN via a keyboard, creating a cryptogram of transaction data containing such transaction data, the sending of the first cryptographic key known or derivable by the financial institution, and then the use of this cryptogram to encrypt the PIN for secure transmission to the financial institution. The payment process of claim 1, wherein said card comprises a second cryptographic key associated with the card and known to the financial institution, and wherein the first cryptographic key is generated during the payment process by encrypting a transaction parameter that is unique to an ongoing payment transaction using second cryptographic key. The payment process of claim 2, wherein the transaction parameter is a transaction sequence number, which is a number that identifies the transaction and automatically increases between transactions. The payment process of any one of claims 1, 2 or 3, wherein the PIN is encrypted using a cryptogram as a cryptographic key. The payment process of claim 4, wherein the PIN encryption is performed by creating an exclusive OR cryptogram and PIN. Payment process according to any one of the preceding claims, characterized in that the cryptogram is created in the card upon receipt of a command from the terminal. The payment process of claim 6, wherein the transaction data is passed to the card as a command parameter, and the cryptogram is returned to the terminal as a command return parameter. Payment process according to either of claims 6 or 7, characterized in that the smart card comprises at least one application program which gives the card its function and in that said application program is EMV-compatible. A payment process according to any preceding claim, wherein the encrypted PIN is decrypted in the financial institution by transmitting said transaction data along with the encrypted PIN, wherein said financial institution generates a cryptogram of the transmitted transaction data using said first cryptographic key and PIN. decrypts using the currently created cryptogram. The payment process of claims 2 and 9, wherein before the cryptogram is created in the financial institution, the first cryptographic key is derived by decrypting the transaction number using the second cryptographic key. 11. A payment system for facilitating secure communication between a smart card and a financial institution, characterized in that said system comprises a terminal with a card reader for reading said smart card and a keyboard for allowing transaction data to be entered, said card being programmable to from the transaction data containing the transaction data entered via the keyboard to a cryptogram using a cryptographic key known or derivable by the financial institution, and said terminal further comprising means for using the cryptogram to encrypt the PIN entered via the keyboard and means for transmitting the encrypted PIN to the financial institution. The payment system of claim 11, wherein the financial institution has means for creating a cryptogram of transaction data transmitted from an encrypted PIN terminal using said first cryptographic key. The payment system of claim 12, wherein said financial institution further has means for deriving said first cryptographic key by decrypting the transaction number using a second cryptographic key.