Note: Descriptions are shown in the official language in which they were submitted.
CA 02295032 1999-12-21
WO 99/00775 PCT/GB98/01865
1
"PAYMENT PROCESS AND SYSTEM"
This invention relates to a payment process and system
particularly intended for use with financial transactions involving integrated
s circuit cards (ICUs), or "smart cards".
As part of a financial transaction involving a credit card or a
debit card, it is normally necessary that details of the transaction be
communicated to the card issuer or other equivalent body for authorisation
of the transaction. Where the credit card or debit card takes the form of a
to 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
is smart cards as debit andlor 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
?o services by accessing a remote account at a bank or other financial
institution. As part of such a payment process, the card holder may
authenticate himself to the financial institution by entry of a PIN (personal
identification number). Where this form of card holder authentication is
used then a critical aspect of the system design is ensuring the secure
~s transport of the PIN to the account holding institution.
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
3o 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
CA 02295032 1999-12-21
WO 99/00775 PCT/GB98/01865
2
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.
Despite its unsuitability for the payment application for the
purpose explained above, 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
to 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.
is This patent application seeks to provide a payment process
and system capable of achieving the above object. A knowledge of the
operation of the EMV standards as defined in the document "EMV'96
Integrated Circuit Card Specification for Payment Systems" Version 3.0
dated 30 June 1996 is advantageous for a full understanding of the present
2o invention. However, although the EMV standard and EMV-compliant
applications are referenced throughout, the technique is, in principle,
applicable to any smart card oriented payment system with similar
commands. It is intended that this patent application covers all such
implementations; EMV is used, as an example only, to clarify the
2s technique.
According to a first aspect of the invention there is provided 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
3o 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
CA 02295032 1999-12-21
WO 99/00775 PCT/GB98/01865
3
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
s 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.
io 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
is 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
2o 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
2s 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 P1N to the institution. In a preferred
3o embodiment of the invention, 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. For this purpose, the financial
institution
CA 02295032 1999-12-21
WO 99/00775 PCT/GB98/01865
4
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.
By transaction data is meant data relating to the transaction
and includes some information entered at the keypad, such as the amount
a 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. In the DES encryption system such cryptograms are
sometimes referred to as Message Authentication Codes, or MAC's. The
to 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
Is encryption. When all the units making up the transaction data have been
cycled through, 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.
2o Preferably the cryptogram is used, in effect, as a
cryptographic key to encrypt the PIN for onward transmission. In theory
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. In the
2s preferred embodiment 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. At the
financial institution the cryptogram is re-created as mentioned above and
therefore, assuming no transmission faults, the PIN can be derived.
3o 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.
CA 02295032 1999-12-21
WO 99/00775 PCT/GB98/01865
According to a second aspect of the invention there is
provided 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
to transmitting the encrypted PIN to the financial institution.
In order that the invention may be better understood, an
embodiment thereof 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 a
is payment process and system according to the invention;
Figure 2 is a block diagram of a payment terminal suitable for
use in the payment process and system according to the invention; and
Figure 3 is a block diagram showing a generic system for
remote payments using a smart card.
2o Referring firstly to Figure 1 there is shown 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
2s 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.
The memory 4 holds one or more applications, which define
the function of the card, and their associated cryptographic keys. An
3o 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.
CA 02295032 1999-12-21
WO 99/00775 PCT/GB98/01865
6
In order to use the card in a payment system, 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
s Figure 2.
Referring to 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. User input is via a keypad 12
to 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
1 ~ inputloutput port 16.
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
2o diagram form in Figure 3.
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
2~ 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
~o 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
CA 02295032 1999-12-21
WO 99/00775 PCT/GB98/01865
7
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
s 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
to 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. in payment systems of the type discussed herein, a symmetric
is cryptographic system, such as the DES system, is conventionally used.
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. In practice, the card key is a function of cardholder identification
data,
such as account number, encrypted with the master key of the acquirer.
2o 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.
As part of the payment transaction, 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
2s 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
3o 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. Details
CA 02295032 1999-12-21
WO 99/00775 PCT/GB98/01865
8
of this EMV command, including its operation and parameters, are given in
the EMV specification referred to above. In practice 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
to 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,
is to the appropriate issuer 20. The key used to re-encrypt the P1N 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
2o 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.
2s Once the transaction data and re-encrypted PIN arrives at the
issuer 20 the issuer checks the PIN supplied by the cardholder and, if
correct, checks that the account is in funds, or that any credit limit is not
exceeded, and then returns a message authorising the transaction back to
the terminal 6, via the acquirer 18.
3o For the purpose of the present invention, it is assumed that
the key pad in terminal 8 is not capable of encryption or, if it is, the
encryption is not being used. In accordance with an embodiment of the
CA 02295032 1999-12-21
WO 99/00775 PCT/GB98/01865
9
invention PIN encryption is performed by the terminal after receiving the
cryptogram back from the card by using the cryptogram as a cryptographic
key. Thus the microprocessor 7 and its associated circuitry derives a
function of the PIN encrypted with the cryptogram. An example of a simple
s Logic function which will achieve this is the exclusive OR function. In
other
words, 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. To do this, the acquirer
Io 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
is 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. If the PIN does not check out at the issuer, this may
2o 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.
In theory several methods can be used for encrypting the
2s PIN, using the cryptogram as a key. In practice however many possible
methods are excluded because the data item which is transmitted from the
terminal 6 to the acquirer 18 must not allow for an eavesdropper to
reconstruct the PIN and cryptogram separately.
It will be seen that the above-described techniques enable the
3o PIN to be encrypted without using an encrypting PIN pad and in a way
which is transparent to the EMV application on the card. Thus the terminal
6 makes the payment transaction appear to the EMV-compliant application
CA 02295032 1999-12-21
WO 99/00775 PCT/GB98/01865
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.
So far it has been assumed that the personalisation service
(PServ) 21 is associated with the acquirer 18. However, the techniques
which are the subject of this patent application are equally applicable when
to PServ 21 is associated with the issuer 20. In this case 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. if it is important for current standard payment
is authorisation message formats to be maintained, then a simple issuer
based conversion utility could front end the issuer authorisation systems.
In this alternative model the personalisation service PServ
could either be issuer specific, or could be supported by a service provider
on behalf of several issuers.
