CZ472699A3 - Method of payment and apparatus for making the same - Google Patents

Abstract

The present invention relates to a method and apparatus for plafle using a smart card (1) that accesses a remote account at the card issuer (20) via the acquirer (18). A smart card is created as part of the payment method of cryptogramtransaction data and used by the terminal (6) as the key to encrypt the PIN inserted by the cardholder for transfer to the acquirer (18). The acquirer also creates cryptograms using transaction data sent terminal (6) and uses this cryptogram (which should be identical to the one created by the smart card) to decrypt encrypted PIN

Description

Technical field

The present invention relates to a method and apparatus for payment, in particular for use in financial transactions using integrated circuit cards (ICCs) or smart cards.

As part of a financial transaction using credit or debit cards, it is usually necessary for details of the transaction to be communicated to the card issuer or other appropriate person in order to authorize the transaction. Where a credit or debit card is in the form of a smart card, the card must maintain in its memory application software that is activated to fulfill the respective function of the credit or debit card. A single card may contain both a credit card application and a debit card application, as well as other financial functions, such as cash cards or non-financial functions. The present invention is primarily directed to the use of smart cards as debit and / or credit cards.

BACKGROUND OF THE INVENTION

Large credit card issuers Europay, MasterCard and Visa have jointly developed standards (known as EMV ICC Specifications for Payment Systems) for smart card based payment devices. Devices 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 this payment method, the cardholder can verify himself by entering his PIN (Personnel Identification Number). Where this method of cardholder authentication is used, the criterion for designing the device is to guarantee secure transmission of the PIN to the account setting up institution.

Access to the remote account is made through the terminal where the user inserts his / her card, which is usually the beginning of the transaction. The terminal is interconnected or capable of interconnecting in some way with the institution establishing the account so that messages can be exchanged. It is highly desirable that the terminal for executing a transaction using a smart card be a cheap device, • H

-2 * ..........

• · které které které ft ft ft které které které které které které které které které které které které které které které které které které které které které které které které které které které které které které které které které které které které které které které které které které které EMV applications are not well adapted to this purpose. They are usually part of an extensive infrastructure of nearby terminals with intruder-resistant encryption PIN blocks. For this reason, it is not appropriate to apply EMV standards in the usual way to meet the requirements of a smart card payment application.

Despite the unsuitability for a payment application with the purpose explained above, EMV applications have a number of required attributes, are well understood by the financial public, have been implemented and have fixed standards. Finding ways to use these applications without having to implement EMV-incompatible commands would bring significant benefits. It is therefore an essential object of the present invention to find a PIN encryption method that does not increase costs by using an intruder-resistant encryption PIN block. PIN encryption is not a standard EMV function since this is provided by the PIN block of the terminal.

SUMMARY OF THE INVENTION

The present invention seeks to find a payment method and a device capable of meeting the above-mentioned feature. Knowledge of the function of the EMV standards defined in "EMV'96 Integrated Circuit Card Specification for Payment Systems, version 3.0, dated June 30, 1996, is beneficial for a full understanding of the present invention. Although EMV and EMV applications are referred to throughout, the method is in principle applicable to any payment device using smart cards with similar commands. It is intended that the present invention covers all such implementations; EMV is used only as an example to explain its use.

A first aspect of the invention is to provide a payment method allowing secure communication between a smart card and a financial institution, said method comprising inserting a card into a smart card.

-3 9 9 «• · · · · ·

9 a reader forming part of a terminal for communication with said financial institution, entering transaction details and a PIN using the keyboard, creating a transaction data cryptogram comprising said transaction details using a first encryption key known or deliverable by the financial institution , then using said cryptogram to encrypt the PIN for secure transmission to the financial institution.

The financial institution may be a card issuer managing the account belonging to the card, probably an intermediary, commonly known as the acquirer, acting as a link between the terminal and the card issuer. More likely, the acquirer will act as an agent for multiple card issuers and will therefore be responsible for verifying that messages originating from any card of each card issuer are correctly forwarded to said card issuer.

The terminal is usually located in retail premises, allowing the cardholder to purchase goods using the card as a debit or credit card. For this purpose, the card is pre-equipped with an application program ensuring its required function. This application refers to the use of a second Encryption Key, referred to herein as a card key, which is stored on the card at the same time as the original application and is known to the financial institution.

The card key may coincide with the first key, but preferably the encryption key used to generate the cryptogram {i. first key) derived from the card key as a function of the transaction parameter, usually a transaction sequence number, encrypted with the card key. A transaction sequence number is any number that uniquely identifies a transaction. Usually, the transaction number is stored on the card and is increased by 1 at the beginning of each new transaction. The transaction number is sent to the financial institution as part of the payment process, so if necessary, the financial institution has the option to derive the encryption key used to create the cryptogram.

The PIN is decrypted by the financial institution immediately after the encrypted PIN has been sent to the institution. In a preferred embodiment of the invention, this process is carried out by mirroring in financial terms

-4 *. ·· ·····. ··················· · · «β * 0 00 · 0 0 · ·· transaction terminal technology, small units, institution, cryptograming from transaction data sent from terminal. To this end, a financial institution needs to know or be able to derive the first key mentioned above. Thus, the cryptogram created in this way must be identical to the one created in the card.

Transaction data means transaction-related data, including information entered via the keyboard, such as the amount and other information internally generated as the transaction date (assuming that the terminal is equipped with a built-in calendar). In fact, a cryptogram is a selection or summary of transaction data. In the DES encryption system, such cryptograms are sometimes referred to as “Message Authentication Codes (MAC). Methods for generating such cryptograms are known in the art. Briefly, transaction data is divided into, for example, 8 bits in length, and the units are each processed separately, starting, for example, at the beginning. Thus, each unit is encrypted using the same key and the same function with the encrypted output of each unit added to the next before encryption. After all the units making up the data have been processed, the resulting output is derived from all units; any change in transaction data during transmission, whether accidental or otherwise, results in the creation of a cryptogram different from the first, so that the change may be detected.

Preferably, the cryptogram is in fact an encryption key for encrypting the PIN during forward transmission in several encryption methods; however, the important thing to note is that the reconstructed PINs represent the PIN and the cryptogram of each other's exclusive OR operation, the output of which is a code from which it is not possible to deduce any of the components without knowing the other. The cryptogram is recreated at the financial institution as described above, and so if transmission errors do not occur, the PIN can then be derived. The fact that the PIN is correct for the managed account used as Theoretically is that · Snoopers are disabled separately and the cryptogram. According to the preferred embodiment, the dispenser is not yet known at this time. 9 9 ♦ · cem výd výd cem cem cem cem cem cem,, However, after the PIN has been checked and marked as correct, the transaction can be executed.

A second aspect of the invention is to provide a payment device providing secure communication between a smart card and a financial institution, said device comprising a terminal provided with a reader for reading said smart card and a keypad allowing insertion of transaction details, said card being programmable to form a cryptogram containing transaction data including transaction details embedded by a keyboard, using an encryption key known or deliverable by said financial institution, said terminal comprising means for using said cryptogram for encrypting the PIN embedded from the keyboard and means for transmitting the encrypted PIN to the financial institution.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the present invention, its embodiment will now be described by way of example only and with reference to the following figures, in which Fig. 1 is a schematic drawing of a smart card for use in the method and payment device of the present invention. suitable for use in the method and payment device of the present invention, and Fig. 3 is a block diagram illustrating a general remote payment device using a smart card.

DETAILED DESCRIPTION OF THE INVENTION

Fig. 1 shows a smart card 1 provided on one side with a contact field 2 comprising several separate electrical contacts by means of which an external power supply can be connected to power the card and a serial communication channel can be established for transmitting messages and data to the card and from the card. The card further comprises a microprocessor 2, non-volatile memory 4 such as read-only memory (ROM) or electrically erasable programmable read-only memory (EEPROM), and RAM 5.

- 69 9 9 9

9 9 9 ·

9 · 9 9 9 • 999 99 99

9 «9 • 9 9 9 • 9

The non-volatile memory 8 comprises one or more applications defining the function of the card and the associated encryption keys. An application is a program with appropriate data files that, for example, assigns a card to a debit, credit, or both card function.

In order to use the card in the payment device, it is inserted into a reading device forming part of the payment terminal, which allows communication with the card holder's account at a remote location. A simplified block diagram of a suitable payment terminal 6 is shown in Fig. 2.

Referring to FIG. 2 comprises a microprocessor terminal 7 having a non-volatile memory 83, such as ROM or EEPROM, RAM 9 and optionally a display 10, connected by means of the interface circuitry 11. User input is via a keyboard 12 connected to the microprocessor by means of the interface circuitry 13. said reader is shown under reference 14 and connected to the card via contact field 2. The communication circuit 15 provides two-way communication of the terminal with the rest of the device, whether on a permanent or on demand basis, via an input / output port 16.

The operation of the terminal 6 is primarily controlled by the microprocessor 7 and its associated circuitry, most of which are not shown here for the sake of simplicity, but which are well known to those skilled in the art. The terminal forms part of the payment device shown in the form of a block diagram in Fig. 3.

FIG. 3 shows a terminal 6 connected via a two-way communication channel 17 to the acquirer 18. The acquirer is the object responsible for executing the entire payment transaction and usually functions as an agent for multiple 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 the present description is considered to have issued the card 1 and which manages the card holder's account. The acquirer 18 is responsible for transmitting messages from the terminal to the corresponding card issuer for the purpose of authorizing payment. However, it is possible, as will be described below, to terminal 6

J * • »oval oval oval oval oval oval oval oval komunik oval komunik oval komunik oval oval oval oval komunik komunik komunik komunik oval komunik komunik komunik oval komunik komunik oval komunik komunik komunik komunik komunik komunik komunik komunik komunik komunik komunik komunik komunik komunik komunik komunik komunikφ φ it is also possible that, in the case of the simplest installations, the acquirer does not even exist.

The card 1 is set up using the address service (PServ) 21, which is usually part of the acquirer but may also be part of the card issuer (see below). Setting up the card is accomplished by preparing a specific application - namely, code, data, and encryption key - and uploading that particular application and key to the card. Thus, the application and its associated encryption key are stored in non-volatile memory 4 of the card as described above. The settings are transferred to new cards before they can be used or can be transferred to existing cards to update them or add card functionality. The encryption key referred to below as the card key is used by the encryption device to ensure secure data transfer to and from the card. In payment devices of the type described herein, a symmetric encryption system, such as a DES system, is usually used. The latter uses a secret encryption key known only to the JL card and the acquirer 18 to encrypt the data transmitted between them. In fact, the card key is a function of the cardholder data, such as the account number, encrypted with the acquirer's master key. Thus, the card key is unique to each card and can be derived by the acquirer from the identity of the cardholder and the master key held by the acquirer.

As part of the payment transaction, the PIN is entered by the user using the keypad on terminal 6. If a normal intruder-resistant block encryption PIN is used, the PIN will be encrypted using an encryption " terminal key known only to the terminal and the acquirer. Meanwhile, the transaction data, including details such as date and transaction amount, is transferred to the card and a cipher is created from the transaction data within the card itself using an encryption transaction key to form a cryptogram. After it has been created, the cryptogram is returned to terminal 6. In an EMV application, this cryptogram would be created by receiving a "Generate Application Cryptogram" issued by the terminal. Details of this EMV command including its operation and parameters are given above

-8 EMC technical description. In fact, the transaction data is a parameter of the Generate Application Cryptogram command that is issued by the terminal and the cryptogram is sent back to the terminal as the command output parameter.

The transaction key used to create the cryptogram is derived inside the card as a function of the Transaction Serial Number (which is different for each transaction) encrypted with the card key. The transaction sequence number is also sent back to the terminal as an output parameter of 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 compares the transaction data with the cryptogram, decrypts the PIN, and then re-encrypts the PIN for forwarding together with the transaction data towards the corresponding issuer 20. known to the certifying issuer.

In fact, the cryptogram is the selection of transaction data, and any data corruption, whether intentional or accidental, can be ascertained by the acquirer or the issuer by comparing the received transaction data with its cryptogram. Transaction data is usually long, while the encrypted selection is much shorter, usually only 8 bits. The manner in which the cryptogram is assembled is well known in the art and will not be described in further detail below.

When the transaction data and the newly encrypted PIN arrive at dispenser 20, the dispenser checks the PIN entered by the cardholder and, if correct, checks that the account is covered and that the amount limit is not exceeded and then returns the transaction entitlement message terminal 6.

For the purposes of the present invention, it is understood that the keypad at the terminal 8 is not capable of encryption and, if it is, encryption is not used. In accordance with an embodiment of the invention, PIN encryption is performed by the terminal upon receipt of the cryptogram back from the card using the cryptogram as the encryption key. Thus, microprocessor 7 and its associated circuitry derive a cryptogram-encrypted PIN function. An example of a simple logic function that accomplishes this is the exclusive OR function. In other words, PIN encryption is performed by creating an exclusive OR cryptogram and PIN function.

-9 in the terminal circuitry and this data item is sent to the acquirer 18 together with the transaction data as was mentioned. At the acquirer 18, the PIN must be decrypted. To this end, the acquirer basically recreates the cryptogram from the transaction data received from the terminal. Then, it uses this cryptogram to decrypt the PIN, the PIN is now re-encrypted using a key known between the acquirer and the issuer and is sent to the issuer for PIN verification. The new encryption can be performed by the acquirer, inside the intruder-resistant device, so that the IN will never appear in its "real form" outside the encryption areas established between the terminal 6 and the issuer 20. If the PIN is correct, the transaction data is queried and the account checked . If everything is OK, the appropriate authorization message is sent back to terminal 6. If the PIN at the dispatcher does not match, it may mean that the PIN has not been entered correctly from the keypad or that the transaction data has been corrupted in some way on the way to the acquirer. In any case, the transaction continues.

Theoretically, several ways of encrypting a PIN using a cryptogram as a key may be used. However, in practice, a number of possible methods must be avoided because the data item sent from the terminal 6 to the acquirer 18 must not allow the prisons to reconstruct the PIN and the cryptogram separately.

It will be shown that the methods described above allow the encryption of the PIN without using the encryption PIN block and in a manner open to the EMV application on the card. Thus, terminal 6 causes the payment transaction to appear to the EMV application as on the card as a standard EMV payment transaction. The present invention enables this approach by providing a method of encrypting the PIN for transmission to the dispenser through the acquirer in a manner that ensures absolute confidentiality during transmission. None of the existing EMV application functions does this because, as mentioned above, PINs are usually encrypted by the terminal, not the card.

It has hitherto been assumed that the address service (PServ) 21 is associated with the acquirer 18. However, the methods of the present invention are equally applicable if the PServ service is associated with the dispenser 20. In this case, the message

-10 «encrypted PIN passes through the acquirer without any transfer . Of course, it will not be possible for the acquirer to decrypt the PIN message, since only the applications on the card 1 and the dispenser 20 will have the necessary keying relationship. If it is important to maintain the format of authorization messages for current standard payments, the dispensing authorization device can be preceded by a simple transfer utility depending on the issuer.

In this alternative model, the PServ address service may be dispenser-specific or may be supported by a multi-dispenser service provider.

Claims (13)

PATENT CLAIMS A method of payment enabling secure communication between a smart card and a financial institution, said method comprising inserting a card into a reading device forming part of a terminal for communicating with said financial institution, entering transaction details and a PIN using a keyboard, creating a transaction data cryptogram comprising said transaction details using a first encryption key known or deliverable by a financial institution, subsequently using said cryptogram to encrypt the PIN for secure transmission to the financial institution. The payment method of claim 1, wherein said card has a second encryption key assigned to said card and a known financial institution, wherein the first encryption key is created during payment by encrypting a transaction parameter that is unique to said financial transaction by a second encryption key. The payment method of claim 2, wherein the transaction parameter is a transaction sequence number, which is a number that identifies the transaction and is automatically changed between transactions. Payment method according to at least one of claims 1, 2 or 3, characterized in that the PIN is encrypted using a cryptogram as an encryption key. Payment method according to claim 4, characterized in that the encryption of the PIN is performed by creating an exclusive OR function from the cryptogram and the PIN. Payment method according to at least one of Claims 1 to 5, characterized in that the cryptogram is formed inside the card on the basis of an instruction order issued by the terminal. The payment method of claim 4, wherein the transaction data is sent to the card as a command parameter and the cryptogram is returned to the terminal as an command output parameter. The payment method according to at least one of claims 6 or 7, characterized in that the smart card has at least one stored therein. fc fc fc fc · fc ♦ · fc fcfcfcfc fcfc · ♦ ···· fcfc ·· -12 an application program that assigns a function to the card and wherein said application program is EMV compatible. Payment method according to at least one of Claims 1 to 8, characterized in that the encrypted PIN is decrypted in the financial institution by transmitting the transaction data with the encrypted PIN, creating a cryptogram of the transmitted transaction data in said financial institution using the first encryption key and decrypting the PIN using just generated cryptogram. The payment method according to claims 2 and 9, wherein said first encryption key is derived by decrypting the transaction number using a second encryption key before the cryptogram is created in the financial institution. 11. A payment device for securely communicating between a smart card and a financial institution, said device comprising a terminal provided with a reader for reading said smart card and a keyboard allowing the insertion of transaction details, said card being programmable to form a cryptogram; comprising transaction data including transaction details embedded by a keyboard, using an encryption key known or deliverable by said financial institution, said terminal comprising means for using said cryptogram for encrypting a PIN embedded from the keyboard and means for transmitting the encrypted PIN to the financial institution, The payment device of claim 11, wherein the financial institution has means for creating a cryptogram of transaction data sent by the PIN terminal encrypted using the first encryption key. 13. The payment device of claim 11, wherein said financial institution further has means for deriving said first encryption key by decrypting the transaction number using a second encryption key.