Classifications

• • G—PHYSICS
  • G07—CHECKING-DEVICES
  • G07F—COIN-FREED OR LIKE APPARATUS
  • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
  • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
  • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
  • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/606—Protecting data by securing the transmission between two devices or processes
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
  • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
  • G06Q20/401—Transaction verification
  • G06Q20/4012—Verifying personal identification numbers [PIN]
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
  • G06Q20/409—Device specific authentication in transaction processing
  • G06Q20/4093—Monitoring of device authentication
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
  • G06Q20/409—Device specific authentication in transaction processing
  • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
  • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor

Definitions

• This invention relates to a payment process and system particularly intended for use with financial transactions involving integrated circuit cards (ICC's), or "smart cards”.
• ICC's integrated circuit cards
• the card issuer or other equivalent body for authorisation of the transaction.
• the credit card or debit card takes the form of a smart card
• the card will hold in its memory application software which is activated to carry out the credit card or debit card function, as appropriate.
• One card may hold both credit card and debit card applications, as well as other financial functions, such as cash cards, or even non-financial functions.
• the present invention is concerned primarily with the use of smart cards as debit and/or credit cards.
• the major card issuers Europay, MasterCard and Visa have jointly developed standards (known as the EMV ICC Specifications for Payment Systems) for smart card based payment systems.
• Systems developed to these standards enable a card holder to pay for goods and services by accessing a remote account at a bank or other financial institution.
• the card holder may authenticate himself to the financial institution by entry of a PIN (personal identification number).
• PIN personal identification number
• Access to the remote account is achieved via a terminal into which the user inserts his or her card, usually at the start of the transaction.
• the terminal is coupled, or able to be coupled, in some way to the account holding institution so that messages can be exchanged between the two. It is very attractive if the terminal used for managing the transaction with the smart card can be a low cost device which would, for example be suitable for home use.
• EMV compliant applications are not well suited to this purpose. They are intended as part of a large infrastructure based round terminals with tamper resistant encrypting PIN pads. It is thus not appropriate to use the EMV standards in a normal way to fulfil the requirements for a payment application on a smart card.
• EMV compliant applications do have many of the required attributes, are well understood in the financial community, have been implemented, and have stable associated standards. There are significant benefits if a way can be found of using such applications, without in any way introducing non-EMV compatible commands.
• the principle object of the present invention is thus to find a way of encrypting the PIN, without incurring the expense of a tamper resistant encrypting PIN pad at the terminal.
• PIN encryption is not a standard EMV function, as this function is assumed to be carried out by the PIN pad at the terminal. This patent application seeks to provide a payment process and system capable of achieving the above object.
• a payment process enabling secure communication between a smart card and a financial institution, said process comprising placing the card in a card reader forming part of a terminal in communication with said financial institution, entering details of the transaction and a PIN into a keypad, creating a cryptogram of transaction data, including said transaction details, using a first cryptographic key known to or derivable by the financial institution, thence using said cryptogram to encrypt the PIN for secure onward transmission to the financial institution.
• the financial institution may be the card issuer, holding the account which corresponds with the card, or more likely will be an intermediary, commonly known as an acquirer, which acts as a link between the terminal and the card issuer. Very likely the acquirer will act as agent for a number of card issuers and is thus responsible for ensuring that messages originating in any one particular issuer's card are properly routed to that issuer.
• the terminal is typically situated at a retail premises to enable the cardholder to purchase goods, using the card as a debit or credit card. To this end, the card is pre-loaded with an application program which enables it to function as required. This application is associated with a second cryptographic key, referred to herein as the card key, which card key is downloaded to the card at the same time as the original application, and is known to the financial institution.
• the card key may be the same key as the first key, but preferably the cryptographic key used to create the cryptogram (i.e. the first key) is derived from the card key by taking a function of a transaction parameter, conveniently the transaction sequence number, encrypted by the card key.
• the transaction sequence number is any number which uniquely identifies the transaction. Conveniently, the transaction number is stored in the card and is sequenced by 1 at the start 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 PIN is decrypted by the financial institution following transmission of the encrypted PIN to the institution.
• this process is carried out by mirroring, at the financial institution, the creation of the cryptogram from the transaction data transmitted to it from the terminal.
• the financial institution needs to know, or be able to derive the aforesaid first key.
• the cryptogram thus created should thus be identical to that created at the card.
• transaction data is meant data relating to the transaction and includes some information entered at the keypad, such as the amount of the transaction, and some information generated internally by the terminal, such as the transaction date (it being assumed that the terminal has a built-in calendar).
• a cryptogram is, in effect, a digest or summary of the transaction data.
• such cryptograms are sometimes referred to as Message Authentication Codes, or MAC'S.
• the techniques for creating such cryptograms are known in the art. Briefly, the transaction data is divided into small units, for example of 8 bits length, and the units operated on one at a time, starting, for example, 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 prior to encryption.
• the resultant output will be derived from all of the units; any change, accidental or otherwise, in the transaction data during transmission will result in the generation of a cryptogram which is different from the first so the fact that a change has been made can be detected.
• the cryptogram is used, in effect, as a cryptographic key to encrypt the PIN for onward transmission.
• several encryption methods can be used; however, this is subject to the important caveat that, whatever method is used, it is not possible for an eavesdropper to reconstruct the PIN and cryptogram separately.
• the PIN and the cryptogram form respective inputs to an exclusive OR operation which produces code from which neither of the constituent parts can be derived without knowledge of the other.
• the cryptogram is re-created as mentioned above and therefore, assuming no transmission faults, the PIN can be derived. Whether the PIN is correct for the account held by the issuer is still not, of course, known at this time. Once the PIN has been checked as correct, however, the transaction can proceed.
• a payment system for enabling secure communication between a smart card and a financial institution, said system comprising a terminal having a card reader for reading said smart card, and a keypad for enabling entry of transaction details, said card being programmable to create, from transaction data including transaction details entered at the keypad, a cryptogram using a cryptographic key known to or derivable by said financial institution, said terminal further comprising means for using said cryptogram to encrypt a PIN entered at the keypad and means for transmitting the encrypted PIN to the financial institution.
• Figure 1 is a schematic diagram of a smart card for use in a payment process and system according to the invention
• FIG. 2 is a block diagram of a payment terminal suitable for use in the payment process and system according to the invention
• Figure 3 is a block diagram showing a generic system for remote payments using a smart card.
• a smart card 1 having on one surface a contact pad 2 carrying several separate electrical contacts whereby an external power source may be connected to power the card and a serial communication channel may 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 ROM (read-only memory) or EEPROM (electrically erasable programmable read-only memory), and a random access memory 5.
• ROM read-only memory
• EEPROM electrically erasable programmable read-only memory
• the memory 4 holds one or more applications, which define the function of the card, and their associated cryptographic keys.
• An application is simply a program with associated data files and may, for example, be such as to give the card the functionality of a debit card or a credit card, or both.
• it is inserted into a card reader forming part of a payment terminal which can communicate with the card holder's account at a remote location.
• a simplified block diagram of a suitable payment terminal 6 is illustrated in Figure 2.
• the terminal 6 comprises a microprocessor 7 having non-volatile memory 8, such as ROM or EEPROM, random access memory 9 and, optionally, a display 10 connected via interface circuitry 11.
• non-volatile memory 8 such as ROM or EEPROM
• random access memory 9 and, optionally, a display 10 connected via interface circuitry 11.
• User input is via a keypad 12 connected to the microprocessor through interface circuitry 13.
• the aforementioned card reader is shown under reference 14 and makes contact with the card via the contact pad 2.
• a communications circuit 15 is provided to enable the terminal to establish two-way communication with the rest of the system, either on a permanent or as-needed basis, via an input/output port 16.
• Terminal 6 Operation of the terminal 6 is primarily under the control of the microprocessor 7 and its associated circuitry, much of which is not shown for simplicity, but which is well known to those skilled in the art.
• the terminal forms part of a smart card payment system shown in block diagram form in Figure 3.
• the terminal 6 is shown connected, via a two way communication channel 17, to an acquirer 18.
• the acquirer is the body which is responsible for managing the overall payment transaction and will probably act as an agent for several card issuers.
• the acquirer might, for example, be a bank or other financial institution.
• the acquirer is connected via a two-way communication channel 19 to a card issuer 20 who, for the purposes of the present explanation, is assumed to be the body who issued the card 6 and who holds the card holder's account.
• the acquirer 18 is responsible for routing messages from the terminal 6 to the appropriate card issuer for payment authorisation. However, as will be explained below, it is possible for the terminal 6 to communicate directly with the card issuer, thus bypassing the acquirer; it is even possible, in the simplest system, for there to be no acquirer at all.
• Configuration of the card 6 is carried out by a personalisation service (Pserv) 21 which is, in effect, part of the acquirer, but could be part of the card issuer (see below).
• Configuration of the card is realised by preparing an instance of an application - namely code, associated data, and a cryptographic key - and downloading that instance and key to the card.
• the application and its associated cryptographic key is thence stored in the card's non-volatile memory 4, as discussed above.
• Configuration is carried out on new cards, before they can be used, or may be carried out on existing cards in order to update or add functionality to the card.
• the cryptographic key referred to hereafter as the card key is used with a cryptographic system to ensure secure transmission of data to and from the card.
• a symmetric cryptographic system such as the DES system
• This uses a secret cryptographic key, known only to the card 6 and the acquirer 18 to enable encryption and decryption of data sent between the two.
• the card key is a function of cardholder identification data, such as account number, encrypted with the master key of the acquirer. The card key is thus unique to the card and can be derived by the acquirer from the cardholder's identity and the master key held by the acquirer.
• the user types his PIN into the keypad on the terminal 6. If the normal type of tamper resistant encrypting PIN pad is in use, the PIN will be encrypted, using a cryptographic "terminal" key known only to the terminal and the acquirer. Meanwhile, the transaction data, including such details as the date and amount of the transaction, is passed to the card, and a cryptogram is created from this transaction data within the card itself, using a cryptographic transaction key to form a cryptogram. Once created, the cryptogram is returned to the terminal 6. In an EMV-compliant application this cryptogram would be prepared by the card upon receiving a "Generate Application Cryptogram" command which is issued by the terminal.
• EMV command Details of this EMV command, including its operation and parameters, are given in the EMV specification referred to above.
• the transaction data is passed as a parameter of the "Generate Application Cryptogram" command which is issued by the terminal and the cryptogram is passed back to the terminal as a return parameter of the command.
• the transaction key used to create the cryptogram is derived in the card as a function of a transaction sequence number (which is different for each transaction) encrypted with the card key.
• the transaction sequence number is likewise passed back to the terminal as a return parameter of the "Generate Application Cryptogram" command.
• the cryptogram is next forwarded, together with the transaction data and 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 onward transmission, with the transaction data, to the appropriate issuer 20.
• the key used to re-encrypt the PIN is one known to the authorising issuer.
• the cryptogram is, in effect an encrypted digest of the transaction data and is such that any tampering with the data, either deliberate or accidental, can be detected by the acquirer or issuer by comparing the received transaction data with its cryptogram.
• the transaction data will usually be quite long whereas the encrypted digest, or cryptogram, will be much shorter, typically only 8 bits.
• the manner in which the cryptogram is prepared is well-known in the art and will not be described further.
• the key pad in terminal 8 is not capable of encryption or, if it is, the encryption is not being used.
• PIN encryption is performed by the terminal after receiving the cryptogram back from the card by using the cryptogram as a cryptographic key.
• the microprocessor 7 and its associated circuitry derives a function of the PIN encrypted with the cryptogram.
• An example of a simple logic function which will achieve this is the exclusive OR function.
• PIN encryption is performed by creating, in the terminal circuitry, the exclusive OR of the cryptogram and PIN, and it is this data item which is transmitted to the acquirer 18, together with the transaction data, as before. At the acquirer 18 the PIN needs to be decrypted.
• the acquirer essentially recreates the cryptogram from the transaction data which it has received from the terminal. It then uses this cryptogram to decrypt the PIN.
• the PIN is now re-encrypted, using a key known between acquirer and issuer, and is sent to the issuer, for checking of the PIN. Reincryption can be carried out at the acquirer within the confines of a tamper resistant device so that the PIN never appears "in clear" outside the cryptographic domains established between the terminal 6 and issuer 20. If the PIN is correct, the transaction data is interrogated and the appropriate account checked. If all is well, an appropriate authorisation message is passed back to the terminal 6.
• the PIN does not check out at the issuer, this may mean that the PIN was not correctly entered at the keypad by the cardholder, or it may mean that the transaction data was corrupted in some way in its passage to the acquirer. Either way, the transaction proceeds no further.
• the above-described techniques enable the PIN to be encrypted without using an encrypting PIN pad and in a way which is transparent to the EMV application on the card.
• the terminal 6 makes the payment transaction appear to the EMV-compliant application on the card as a standard EMV payment transaction.
• the present invention makes this approach possible by providing a way of encrypting the PIN for transmission to the issuer, via the acquirer, so that its confidentiality is totally assured in transit. No existing EMV-compliant application function does this because, as mentioned above, PINs are conventionally encrypted by the terminal, not the card.
• PServ 21 the personalisation service 21 is associated with the acquirer 18.
• the techniques which are the subject of this patent application are equally applicable when PServ 21 is associated with the issuer 20.
• the encrypted PIN message would pass through the acquirer without any translation. Indeed it would not be possible for the acquirer to decrypt the PIN message as only the application on the card 6 and the issuer 20 would have the requisite keying relationship.
• a simple issuer based conversion utility could front end the issuer authorisation systems.
• the personalisation service PServ could either be issuer specific, or could be supported by a service provider on behalf of several issuers.

Landscapes

• Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• Physics & Mathematics (AREA)
• Accounting & Taxation (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• General Business, Economics & Management (AREA)
• Strategic Management (AREA)
• Finance (AREA)
• Computer Hardware Design (AREA)
• General Health & Medical Sciences (AREA)
• Bioethics (AREA)
• Software Systems (AREA)
• Health & Medical Sciences (AREA)
• General Engineering & Computer Science (AREA)
• Microelectronics & Electronic Packaging (AREA)
• Computer Networks & Wireless Communication (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
• Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)
• Credit Cards Or The Like (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Priority Applications (15)

Applications Claiming Priority (2)

Publications (1)

Family

ID=10815113

Family Applications (1)

Country Status (22)

Cited By (6)

Families Citing this family (11)

Citations (3)

• 1997
  • 1997-06-27 GB GBGB9713743.4A patent/GB9713743D0/en active Pending
• 1998
  • 1998-06-26 NZ NZ501887A patent/NZ501887A/en unknown
  • 1998-06-26 AU AU81225/98A patent/AU8122598A/en not_active Abandoned
  • 1998-06-26 WO PCT/GB1998/001865 patent/WO1999000775A1/en not_active Application Discontinuation
  • 1998-06-26 ZA ZA985628A patent/ZA985628B/xx unknown
  • 1998-06-26 KR KR1019997012365A patent/KR20010014257A/ko not_active Application Discontinuation
  • 1998-06-26 EP EP98930951A patent/EP0992026A1/en not_active Withdrawn
  • 1998-06-26 BR BR9810486-1A patent/BR9810486A/pt not_active Application Discontinuation
  • 1998-06-26 MX MXPA99011836A patent/MXPA99011836A/es unknown
  • 1998-06-26 PL PL98337533A patent/PL337533A1/xx unknown
  • 1998-06-26 JP JP50538099A patent/JP2002507297A/ja active Pending
  • 1998-06-26 EA EA200000073A patent/EA200000073A1/ru unknown
  • 1998-06-26 HU HU0003227A patent/HUP0003227A2/hu unknown
  • 1998-06-26 EE EEP199900598A patent/EE9900598A/xx unknown
  • 1998-06-26 CN CN98806376A patent/CN1260894A/zh active Pending
  • 1998-06-26 SK SK1761-99A patent/SK176199A3/sk unknown
  • 1998-06-26 TR TR1999/03243T patent/TR199903243T2/xx unknown
  • 1998-06-26 CA CA002295032A patent/CA2295032A1/en not_active Abandoned
  • 1998-07-08 TW TW087111040A patent/TW411427B/zh active
• 1999
  • 1999-12-17 IS IS5307A patent/IS5307A/is unknown
  • 1999-12-23 BG BG104041A patent/BG104041A/xx unknown
  • 1999-12-27 NO NO996488A patent/NO996488L/no not_active Application Discontinuation

Patent Citations (3)

Also Published As

Similar Documents

Legal Events