 |
Description  |
|
|
FIELD OF THE INVENTION
This invention relates generally to point of sale and electronic funds transfer systems and in particular to the personal verification of users of such systems.
Electronic funds transfer (EFT) is the name given to a system of directly debiting and crediting customer and service suppliers' accounts at the instant of confirmation of a transaction. The accounts are held at a bank, or credit card company's
central processing system, which is connected to a dedicated network of retailers or service suppliers' data processing equipment. In this way no cash or check processing is required for the transaction.
Point of sale (POS) is the name given to retailers' data processing systems in which check-out or sale point tills are connected directly to a data processing system. Details of current transactions can then be used for stock control, updating
customer accounts held locally and monitoring the retailers flow of business. A POS terminal can include the function required for an EFT terminal and be connected to an EFT network as well as the local retailers data processing system.
In a simple application each band or credit card company has its own network and each customer of the bank has a credit card which can only be used on that network, such a network is described in European Patent Publication No. 32193.
BACKGROUND OF THE INVENTION
European Patent Publication No. 32193 (IBM Corporation) describes a system in which each user and retailer has a cryptographic key number--retailer's key Kr and user's key Kp--which is stored together with the user's account number and retailer's
business number in a data store at the host central processing unit (cpu.). The retailer's key and the user key are used in the encryption of data sent between the retailer's transaction terminal and the host cpu. Obviously only users or customers with
their identity numbers and encryption keys stored at the host cpu can make use of the system. As the number of users expands there is an optimum number beyond which the time taken to look up corresponding keys and identity numbers is unacceptable for
on-line transaction processing.
The system described is only a single domain and does not involve using a personal identification number (PIN). Verification of the user's identity is at the host and without a PIN there is no bar to users using stolen cards for transactions.
European Patent Publication No. 18129 (Motorola Inc.) describes a method of providing security of data on a communication path. Privacy and security of a dial-up data communications network are provided by means of either a user or terminal
identification code together with a primary cipher key. A list of valid identification codes and primary cipher key pairs is maintained at the central processing unit. Identification code and cipher key pairs, sent to the cpu are compared with the
stored code pairs. A correct comparison is required before the cpu will accept encoded data sent from the terminal. All data sent over the network is ciphered to prevent unauthorised access using the relevant user or terminal key.
The system described is a single domain in which all terminal keys (or user keys) must be known at a central host location. Hence, the ideas described in the patent do not address a multi-host environment and thus are not addressing the
interchange problem either.
UK Patent Application No. 2,052,513A (Atalla Technovations) describes a method and apparatus which avoids the need for transmitting user-identification information such as a personal identification number (PIN) in the clear from station to
station in a network such as described in the two European Patent Publications mentioned above. The PIN is encoded using a randomly generated number at a user station and the encoded PIN and the random number are sent to the processing station. At the
processing station a second PIN having generic application is encoded using the received random number and the received encoded PIN and the generic encoded PIN are compared to determine whether the received PIN is valid.
This system does not use a personal key and as a consequence for a sufficiently cryptographically secure system, it is necessary to have a PIN with at least fourteen random characters (four bits each). This is a disadvantage from the human
factor point of view as users will have difficulty remembering such a long string of characters and the chances of inputting unintentionally an incorrect string is very large. If a phrase, which a user can easily remember, is employed for a PIN, about
28 characters are required. Although remembering the information is not a problem, inputting such a long string of data still presents a human factors problem.
The EFT system made possible by the systems described in the above patent applications is limited to a single host cpu holding the accounts of all users, both retailers and customers.
An EFT system in which many card issuing organisations (banks, credit card companies, etc.) are connected and many hundreds of retail organisations are connected through switching nodes such as telephone exchanges, brings many more security
problems.
PCT publication No. Wo 81/02655 (Marvin Sendrow) describes a multi-host, multi-user system in which the PIN is ciphered more than once at the entry terminal. The data required to validate and authorise the transactions is transmitted to a host
computer which accesses from its stored data base the data that is required to decipher and validate the transaction, including the ciphered PIN. A secret terminal master key must be maintained at each terminal. A list of these master keys is also
maintained at the host computer.
The maintaining of lists of terminal master keys at each of the card issuing organisation's host computers is obviously a difficult task, in a complex system where the terminal keys are not controlled and, therefore, not known by the card issuing
host.
European Patent Publication No. 55580 (Honeywell Information Systems) seeks to avoid the necessity of transmitting PIN information in the network by performing PIN verification at the entry point terminal. This is achieved by issuing each user
with a card that has encoded in the magnetic stripe the bank identification (BIN), the user's account number (ACCN) and a PIN offset number. The PIN offset is calculated from the PIN, BIN and ACCN. The user enters the PIN at a keyboard attached to the
terminal, which also reads the PIN offset, BIN and ACCN from the card. The terminal then recalculates a PIN offset from the user's entered PIN, the BIN and ACCN. If the re-calculated PIN offset is the same as the PIN offset read from the card then
verification of the PIN is assumed. This approach has the disadvantage in that the system is not involved in the validation and that knowing that the PIN offset is calculated from the PIN, the BIN and ACCN, anyone having knowledge of the process can
manufacture fraudulent cards with valid PINS.
Advances in microcircuit chip technology has now led to the possibility that user cards instead of having user data stored on a magnetic stripe can contain a microprocessor with a read only sotre (ROS). The microprocessor is activated when the
card is placed in an EFT terminal and the appropriate power and data transmission interface connections are made. The microprocessor on the card is controlled by control programs stored in the ROS. The users and issuers identification can also be
stored in the ROS together with other information.
Examples of such cards including a microprocessor are shown in United Kingdom patent applications Nos. 2,081,644A and 2,095,175A.
European patent application No. 82306989.3 (IBM) describes a method and apparatus for testing the validity of personal identification numbers (PIN) entered at a transaction terminal of an electronic funds transfer network in which the PIN is not
directly transmitted through the network. The PIN and the personal account number (PAN) are used to derive an authorisation parameter (DAP). A unique message is sent with the PAN to the host processor where the PAN is used to identify a valid
authorisation parameter (VAP). The VAP is used to encode the message and the result (a message authentication code MAC) transmitted back to the transaction terminal. The terminal generates a parallel derived message authentication code (DMAC) by using
the DAP to encode the message. The DMAC and MAC are compared and the result of the comparison used to determine the validity of the PIN.
In such a system the generation of DAP as well as VAP is based on a short PIN only and is therefore cryptographically weak. Furthermore, the EFT transaction terminal has access to all the information carried on the identity card which may be
regarded as a security weakness in the system. The present invention seeks to overcome such deficiencies by storing personal key data in a portable personal processor carried on a card and only processing the key data on the card.
In any multi-domain communication network where such domain includes a data processor and in which cryptographically secure transmission takes place it is necessary to establish cross domain keys. A communication security system in which cross
domain keys are generated and used is described in U.S. Pat. No. 4,227,253 (IBM). The patent describes a communication security system for data transmissions between different domains of a multiple domain communication network where each domain
includes a host system and its associated resources of programs and communication terminals. The host systems and communication terminals include data security devices each having a master key which permits a variety of cryptographic operations to be
performed. When a host system in one domain wishes to communicate with a host system in another domain, a common session key is established at both host systems to permit cryptographic operations to be performed. This is accomplished by using a
mutually agreed upon cross-domain key known by both host systems and does not require each host system to reveal its master key to the other host system. The cross domain key is enciphered under a key encrypting key at the sending host system and under
a different key encrypting key at the receiving host system. The sending host system creates an enciphered session key and together with the sending cross-domain key performs a transformation function to re-encipher the session key under the cross
domain key for transmission to the receiving host system. At the receiving host system, the receiving host system using the cross-domain key and the received session key, performs a transformation function to re-encipher the received session key from
encipherment under the cross domain key to encipherment under the receiving host system master key. With the common session key now available in usable form at both host systems, a communication session is established and cryptographic operations can
proceed between the two host systems.
Reference to the following publications are included as giving general background information in encryption techniques and terminology:
1. IBM Technical Disclosure Bulletin, Vol. 19, No. 11, April 1977, p. 4241, "Terminal Master Key Security" by S. M. Matyas and C. H. Meyer.
2. IBM Technical Data Bulletin, Vol. 24, No. 1B, June 1981, pp. 561-565, "Application for Personal Key Crypto With Insecure Terminals" by R. E. Lennon, S. M. Matyas, C. H. Meyer and R. E. Shuck;
3. IBM Technical Data Bulletin, Vol. 24, No. 7B, December 1981, pp. 3906-3909, "Pin Protection/Verification For Electronic Funds Transfer" by R. E. Lennon, S. M. Matyas and C. H. Meyer;
4. IBM Technical Disclosure Bulletin , Vol. 24, No. 12, May 1982, pp. 6504-6509, "Personal Verification and Message Authentication Using Personal Keys" by R. E. Lennon, S. M. Matyas and C. H. Meyer;
5. IBM Technical Disclosure Bulletin, Vol. 25, No. 5, October 1982, pp. 2358-2360, "Authentication With Stored KP and Dynamic PAC" by R. E. Lennon, S. M. Matyas and C. H. Meyer.
SUMMARY OF THE INVENTION
The present invention uses a time variant key which is based upon a card users personal account number (PAN), personal key (KP) and a transaction variable. When a issuer host receives a message including a message authentication code generated
using the time variant key (identification as KSTR1 in the preferred embodiment) then the issuer is assured that when the message was formed then a user with a valid PAN and a valid KP was involved and that the message does not originate from a
potentially fraudulent source.
Another source of fraudulent attack is guarded against by the encipherment of the transaction variable under the key KS and using this quantity in the calculating of the message authentication code. When a message is received by the user
including the session key enciphered under a cross-domain key then if the enciphered session key has been changed for any reason, the message authentication code calculated on the changed session key will not be the same as the received message
authentication code (MAC). This MAC check therefore not only validates the part of the message in which the MAC was calculated, but also the correct reception of the enciphered session key.
The use of the transaction variable generated at the EFT terminal and the personal key (KP) held only on the card also ensures that the transaction variable cannot be produced separately by a potentially fraudulent user, terminal operator or even
a potentially fraudulent issuer.
According to the invention there is provided an electronic funds transfer system in which EFT terminals are connected through a local data processing centre (acquirer) to a public switch system (switch), a plurality of card-issuing agencies' data
processing centres are also connected to the public switch system and each user of the EFT system has a personal secure intelligent bank card on which is stored a personal account number (PAN) and a personal key (KP), the system including means at each
local data processing centre to generate session keys (KS) for each of its locally attached terminals, and to transmit an associated session key to a respective terminal, at each terminal means to store the session key, means to encipher sensitive data
(PAN) under the session key whenever a transaction request message is generated, means to generate a transaction variable for each transaction initiated at the terminal and to transfer the transaction variable to the card, means to transfer a message
request including the transaction variable enciphered under KS to the users card and means on the card to generate a message authentication code using a time-variant key (KSTR1) based upon the users PAN, KP and the transaction variable, means at each
local data processing centre to encipher the appropriate msession key under a cross-domain key whenever a transaction request message is received and to add the enciphered key to the message, means at each processing node of the public switch system to
translate the enciphered session key from encipherment under a received cross-domain key to a transmission crossdomain key, means at the card issuing agency's data processing centre to decipher the enciphered session key and to use the key to decipher
any sensitive data contained in the request message, and means to regenerate the message authentication code using KSTR1 which is generated from parameters based upon the PAN and KP and the received transaction variable for comparison with the message
authentication code included in the received message.
In order that the invention may be fully understood a preferred embodiment thereof will now be described with reference to the accompanying drawings:
BRIEF DESCIPTION OF THE DRAWINGS
FIG. 1 is a block schematic showing the component parts of a EFT network;
FIG. 2 is a block schematic of the retail store components of the EFT network;
FIGS. 3-9 illustrate enciphering techniques used in the preferred embodiment;
FIGS. 10-12 are flow charts illustrating the steps of the method of the preferred embodiment.
FIGS. 13-17 illustrate the message formats used in the preferred embodiments.
TABLE OF ABBREVIATIONS
In the designation of the preferred embodiment, the following abbreviations are used:
AP=authentication parameter (generated from PAN, KP and PIN)
BID=bank or card issuer's identity
KI=interchange key
KP=personal key
KM0=host master key
KM1=first variant of host master key
KM2=second variant of host master key
KM3=third variant of host master key
KMT=terminal master key
KS=session key
KST1=transaction session key one (generated from Tterm,card and KTR1)
KSTR2=transaction session key two (randomly or pseudo-randomly generated)
KSTR3=transaction session key three (generated from Tiss,term,card and KTR2)
KTR1=transaction key one (generated from PAN and KP)
KTR2=transaction key two (generated from PAN, KP and PIN)
MAC=message authentication code
PAN=primary account number
PIN=user's personal identification number
Tcard=time-variant information generated by bank card
Tiss=time-variant information generated by issuer
Tterm=time-variant information generated by terminal
Tterm,card=time-variant information generated from Tterm and Tcard using a one-way function
Tiss,term,card=time-variant information generated from Tiss and Tterm,card
TAP1=time-variant authentication parameter (generated from Tterm,card and AP)
TAP2=time-variant authentication parameter (generated from Tiss,term,card and TAP1
TID=terminal ID
SEQterm=terminal sequence number
SEQiss=issuer sequence number
PREFERRED EMBODIMENT OF THE INVENTION
Referring now to FIG. 1 an EFT network is shown in which card issuing agencies' data processing centres 10 are connected through a packet switched communication network 12 through network nodes 14 to retail store controllers 16. Each store
controller 16 is connected directly to the store's EFT transaction terminals 18 which have an interface including power and input-output means for communicating with a portable microprocessor 20 contained on a personal identity card issued by one of the
card issuing agencies.
The store controller 16 may also be directly connected with the retailers own data processing centre 22.
The retail store components of the network are expanded in FIG. 2. The EFT transaction terminal may include a point of sale checkout terminal 24 including an EFT module 26 and having a consumer module 28 connected so that a user can key-in data
on the module. The store computers can also include an enquiry station which is an EFT module 30 and consumer module positioned so that users can communicate directly with the card issuing agency asking for example for the current balance or credit
limit on their accounts before making a purchase.
The consumer modules 28 are a twelve button key pad with, for example, a liquid crystal display such as are now in common use for other application, hand calculators, remote TV selectors, etc.
The EFT modules and point of sale terminals each have their own microprocessor and encryption-decryption modules together with read only and random access storage devices. The network nodes have a larger capacity processor such as the IBM Series
1 processing unit, (IBM is a Registered Trade Mark).
In the preferred embodiment of the invention a card issuing agency prepares individual user cards for each user. The cards include a personal portable microprocessor, a read only store (ROS) a random access memory (RAM) and an encryption device. The ROS for each user includes a personal encryption key (KP) a user identity code or personal account number (PAN) and a card issuer's identity code (BID). The KP, and PAN, are also stored at the issuing agency's data processing centre together with a
personal identification number (PIN). BID is a code that identifies the issuing agency's data processing centre to the EFT network.
Each unit in the network has an identity code which is used for routing messages through the network.
The EFT modules also include a microprocessor, RAM and ROS stores and an encryption device. Depending upon the further encryption techniques employed in the network, the store controllers and packet switched network nodes contain data processing
and encryption devices.
When the EFT network is set up in order for secure transmission of transaction messages to take place it is necessary to generate identity numbers and encipherment keys used at the various nodes of the network. These pregenerated quantities are:
AP--generated at card issuing agency; defined as: E.sub.PIN.sym.KP (PAN).sym.PAN.
KI--generated at switch; issuer, acquirer
KP--generated at issuing agency;
KM0--generated at issuer, acquirer, switch
KMT--generated at acquirer
KTR1--generated at issuer; defined as: D.sub.KP (PAN).sym.PAN.
KTR2--generated at issuer; defined as: D.sub.PIN.sym.KP (PAN+1).sym.(PAN+1).
PAN--generated at issuer
PIN--generated at issuer
TID--generated at acquirer
Where .sym. denotes modulo 2 addition and + denotes modulo 2.sup.64 addition.
At initialisation of the system the KP, PIN and PAN quantities are used to generate AP, KTR1 and KTR2, which are unique to each user card. The quantities AP, KTR1 and KTR2 are stored at the issuer's data processing centre enciphered under the
second variant (KM2) of the issuer's master key and associated together and enclosed by the PAN for the user. The quantities PAN, PIN and KP for each user are also stored offline for backup purposes (e.g., in a safe or vault) and are erased from main
memory once AP, KTR1 and KTR2 have been generated.
For each card, a unique PAN and KP are stored in the cards ROM.
Each user must store separately or remember the unique PIN.
A unique TID and KMT are stored in each terminal and at the associated acquirer.
A unique KM0 for each processing node is stored at that node, i.e., issuer, acquirer and switch.
During the course of a transaction, some of these values and others based upon stored values are generated dynamically at locations in the network.
The FIG. 1 configuration of the system shows a complete organisation in which a large retail outlet has its own "in-store" data processing system. In this case, the retailer's data processing system is regarded as the acquirer and the PSS node
as the switch.
In a simpler organisation where a small retailer may have only one terminal connected directly to the PSS node, then the function of the acquirer and switch are combined and there is no cross-domain translation required between acquirer and
switch.
The following cryptographic operatiaons are available at the host system of the issuer, acquirer and switch.
Encipher Data (ECPH):
ECPH: [E.sub.KM0 K, X.sub.1, X.sub.2, . . . ,X.sub.n ].fwdarw.E.sub.K X.sub.1, E.sub.K (X.sub.2 .sym.E.sub.K X.sub.1), . . . , E.sub.K (X.sub.n .sym.E.sub.K X.sub.n-1)
Decipher Data (DCPH):
DCPH: [E.sub.KM0 K,Y.sub.1,Y.sub.2, . . . , Y.sub.n ].fwdarw.D.sub.K Y.sub.1, D.sub.K (Y.sub.2).sym.Y.sub.1, . . . , D.sub.K (Y.sub.n).sym.Y.sub.n-1
Set Master Key [SMK]:
SMK: [KMO]--Write Cipher Key KM0 in Master Key Storage
Encipher Under Master Key (EMK0):
EMK0: [K].fwdarw.E.sub.KM0 K
Re-encipher From Master Key (RFMK):
RFMK: [E.sub.KM1 KN, E.sub.KM0 K].fwdarw.E.sub.KN K
Re-encipher To Master Key (RTMK):
RTMK: [E.sub.KM2 KN, E.sub.KN K].fwdarw.E.sub.KM0 K
Translate Session Key (TRSK):
TRSK: [E.sub.KM3 KN1, E.sub.KN1 KS, E.sub.KM1 KN2].fwdarw.E.sub.KN2 KS
European Patent Application No. 8211108/49 describes a system for performing the TRSK function.
The following cryptographic operations are available at the terminal:
Load Key Direct (LKD):
LKD: [K]--Load Cipher Key K into Working Key Storage
Write Master Key (WMK):
WMK: [KMT]--Write Cipher Key KMT In Master Key Storage
Decipher Key (DECK):
DECK: [E.sub.KMT K]--Decipher E.sub.KMT K under the terminal master key KMT and load recovered cipher key K into the Working Key Storage
Encipher (ENC):
ENC: [X.sub.1, X.sub.2, . . . , X.sub.n ].fwdarw.E.sub.KW X.sub.1, E.sub.KW (X.sub.2 .sym.E.sub.KW X.sub.1), . . . , E.sub.KW (X.sub.n .sym.E.sub.KW (X.sub.n-1))
Where KW is the current working key in the working key storage.
Decipher (DEC):
DEC: [Y.sub.1, Y.sub.2, . . . , Y.sub.n ].fwdarw.D.sub.KW (Y.sub.1), D.sub.DW (Y.sub.2).sym.Y.sub.1, . . . , D.sub.KW (Y.sub.n).sym.Yn-1
Where KW is the current working key in the working key storage.
Encipher Data (ECPH):
ECPH: [E.sub.KMT K, X.sub.1, X.sub.2, . . . , X.sub.n ].fwdarw.E.sub.K (X.sub.1), E.sub.K (X.sub.2 .sym.E.sub.K (X.sub.1)), . . . , E.sub.K (X.sub.n .sym.E.sub.K (X.sub.n-1))
Decipher Data (DCPH):
DCPH: [E.sub.KMT K,Y.sub.1, Y.sub.2, . . . , Y.sub.n ].fwdarw.D.sub.K (Y.sub.1), D.sub.K (Y.sub.2).sym.Y.sub.1, . . . , D.sub.K (Y.sub.n).sym.Y.sub.n-1
At this point is is useful to realise that quantities held at the issuer are stored enciphered under the processor master key KM0 or a master key variant KM2. The general decipher-encipher sequence is illustrated in FIG. 3. A sensitive quantity
(Q) is held in store encipher under KM2 (E.sub.KM2 Q). The enciphered value is deciphered using KM2 as the key and Q is used as the key to decipher a further variable KEY stored enciphered under key Q (E.sub.Q KEY). The deciphered KEY is then
enciphered using the master key KM0 as the key and the result is E.sub.KM0 (KEY). This first operation is called a RTMK function.
To use KEY to encipher a further quantity Q2 then E.sub.KM0 KEY is deciphered using KM0 as the key and the deciphered KEY is used as the key in enciphering Q2 giving E.sub.KEY Q2. This second operation is called an ECPH function.
These operations all take place in the cryptographically secure hardware circuits (defined cryptographic facility or security module) and consequently while Q and KEY appear in the clear, they are not available outside the secure hardware.
FIG. 4 illustrates the RFMK sequence. A key KI stored enciphered with KM1 as E.sub.KM1 (KI) is deciphered using KM1 as the key recovering KI in the clear. A second key KEY stored under encipherment of KM0 as E.sub.KM0 KEY is deciphered using
KM0 as the key. The result of this decipherment (KEY) is then enciphered using KI as the key giving E.sub.KI KEY.
As part of the system initialisation process, the acquirer (or other node) generates a series of terminal master keys (KMTi) for all the terminals associated with the acquirer system. These keys are protected by being enciphered under the first
variant (KM1acq) of the acquirer master key (KM0acq) by an Encipher Master Key function (EMK1) to produce the result set forth by the following notation:
KMK1: [KMTi].fwdarw.E.sub.KM1acq KMTi.
The enciphered terminal keys are stored at the acquirer in a cryptographic data set until required for use in a cryptographic operation. Each terminal stores its own KMTi generated by the acquirer in a secure store.
When a session is to be established between the acquirer and a requesting terminal, it is necessary to establish a common session key (KS) between the acquirer and the terminal for secure data communication. Thus, the acquirer causes a pseudo
random or random number to be generated which is defined as being the session key enciphered under a secondary file key KNFacq, i.e., E.sub.KNFacq KS and is retained at the acquirer for cryptographic operations during the communication session. In order
to securely distribute the session key to the requesting terminal, the acquirer performs a transformation function which re-enciphers the session key from encipherment under the acquirer secondary file key to encipherment under the terminal master key,
i.e., from E.sub.KNFacq KS to E.sub.KMTi KS. This transformation function may be defined by the notation:
TRSK: [E.sub.KMH3acq KNFacq, E.sub.KNFacq KS, E.sub.KMH1acq KMTi].fwdarw.E.sub.KMTi KS
Since KS is now enciphered under KMTi, it may be transmitted over the communication line to bind the requesting terminal to the acquirer for a communication session.
When the EFT network is set up and the initialisation is complete, i.e., the pregenerated values are stored at the respective locations, EFT transactions may occur. Each terminal has a sequence number counter which provides SEQterm for each
transaction message initiated at that terminal. Each host also has a sequence number counter which provides SEQiss for each transaction message (Mresp) generated at the host data processing centre. These SEQ numbers are provided for audit purposes and
do not relate directly to the invention.
The preferred method of testing the validity of messages in the network is as follows:
A transaction is initiated at a POS terminal when a customer's user card is inserted in the EFT module. Insertion of the card couples the power and data bus connections to the personal portable microprocessor (p.p.m).
At the ppm (20 FIG. 1):
Step C1--Generate Tcard and transfer this variable to the EFT terminal together with card issuer identification (BID), personal account number (PAN). Other information such as credit limit may be passed at this time.
Tcard is a time variant quantity and the method employs a system of time variant quantities in contrast to a universal time reference such as a time-of-day clock. This approach avoids synchronisation problems among the several generators of the
desired time-variant information. Each node (ppm (20), EFT terminal (18) and card issuer host (10)) generates its own time variant quantity, Tcard, Tterm and Tiss, respectively, (If desired, time-of-day clock values may be included for auditing
purposes).
At the different nodes time variant quantities are obtained by combining various ones of the three individual quantities using an encipher function.
At the EFT terminal (18 FIG. 1):
Step T1--Generate Tterm and the combined Tterm,card based upon Tcard and Tterm. The generation of Tterm,card is illustrated in FIG. 5. The variable Tcard is ciphered using the variable Tterm as an encryption key. To accomplish this Tterm is
loaded as the working key using a Load Key Direct (LKD) operation and then Tcard is enciphered under Tterm using an Encipher (ENC) operation, as follows:
LKD: [Tterm]--load Tterm as the working key.
ENC: [Tcard].fwdarw.E.sub.Tterm Tcard--The result, i.e., E.sub.Tterm (Tcard) is referred to as Tterm,card and stored in the terminals RAM.
Step T2--Receive and store other transaction data (Card issuing agency BID, PAN, etc.)
Step T3--Formulate a message request (Mreq) having a format shown in FIG. 13 which at this time includes the combined time variant data Tterm,card generated at the terminal, the stored card information, TID and other transaction data.
The Mreq is formed in a buffer store portion of the terminals RAM and includes message address information BID.
Step T4--Transfer the transaction request (TR) portion of Mreq and Tterm to the personal portable microprocessor.
At the ppm:
Step C2--Using the received Tterm generate Tterm,card of reference using the technique shown in FIG. 5.
Step C3--Generate and store a transaction session key (KSTR1) using KP and Tterm,card. KSTR1 is used as the end to end key between the card and the issuer and is generated from PAN and KP read from the card and the card generated (Step T2)
Tterm,card.
The generation of KSTR1 is illustrated in FIG. 6. Using the user's personal key (KP) as the key the PAN is deciphered and then exclusively OR'd with the result to produce a time invariant transaction key KTR1. Tterm,card is then deciphered
using KTR1 as the key to produce the first transaction session key KSTR1.
Step C4--Store in the ppm RAM both KSTR1 and Tterm,card.
Step C5--Compute a message authentication code (MAC1 card,iss) on the TR portion of Mreq which will include Tterm,card and using KSTR1.
The generation of a message authentication code (MAC), which uses the Encipher Data (ECPH) operation, is illustrated in FIG. 7. The method used is the standard cipher block chaining (CBC) mode of DES. The inputs defined as X1, X2 . . . Xn are
64 bit blocks of the request message. The initialising vector ICV is set equal to zero in this process.
The result of the first XOR is then enciphered under the key K. In Step C5 the key K=KSTR1 is used. The second block X2 is then XOR'd with the result of the first encipherment and the | | |
