Browse Prior Art Database

Transaction Response Message Authentication (Des/Kp)

IP.com Disclosure Number: IPCOM000047695D
Original Publication Date: 1983-Dec-01
Included in the Prior Art Database: 2005-Feb-08
Document File: 2 page(s) / 15K

Publishing Venue

IBM

Related People

Lennon, RE: AUTHOR [+3]

Abstract

This article discloses an authentication protocol for transaction response messages in an EFT (Electronic Fund Transfer) system which uses intelligent secure cards. In an environment where EFT terminals are connected to their owning host processors in local networks and where the processors are connected via one or more switches in an interchange network, the institution at which the user opens his account is called the issuer and the institution which first acts on information entered at the terminal is called the acquirer. (The issuer and the acquirer may be the same.) In such a system, each customer is provided with an intelligent secure user card which has an installed DES algorithm and storage for data and key variables, whereas the terminal has no cryptographic algorithm and stores no keys in support of cryptography.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 49% of the total text.

Page 1 of 2

Transaction Response Message Authentication (Des/Kp)

This article discloses an authentication protocol for transaction response messages in an EFT (Electronic Fund Transfer) system which uses intelligent secure cards. In an environment where EFT terminals are connected to their owning host processors in local networks and where the processors are connected via one or more switches in an interchange network, the institution at which the user opens his account is called the issuer and the institution which first acts on information entered at the terminal is called the acquirer. (The issuer and the acquirer may be the same.) In such a system, each customer is provided with an intelligent secure user card which has an installed DES algorithm and storage for data and key variables, whereas the terminal has no cryptographic algorithm and stores no keys in support of cryptography. Card holders are authenticated on the basis of an authentication parameter (AP) which is derived by enciphering the user's identifier (ID) under control of a cipher key composed of a personal key (KP) modulo 2 added (O) to the user's personal identification number (PIN). The authentication parameter AP may then be expressed as AP = EKPO(+PIN(ID)). A copy of AP is stored in a verification table under the user's identifier ID in the issuer's processor. Alternatively, the table can be eliminated by defining a personal authentication code (PAC) as a function of AP and an authentication key KA such that PAC = EKA(AP), which would be stored on the user's card and the issuer need only store KA. Message authentication between the user and the issuer and between the issuer and the originating terminal is based on a message authentication code (MAC) computed from the message using a transaction key (KTR). KTR is computed dynamically on the card as a function of KP, PIN and ID, i.e., KTR = DKPO(+PIN(ID)). A copy of each user's KTR is also stored in the issuer's verification table.

Since KTR is a one-way function of KP and PIN, there is no practical way to devise KPs and PINs that could be used to gain entry to the system. At the time a transaction is initiated, the customer entered PIN is transferred to his card and modulo 2 added to KP to produce (PINO(+KP)), which, in turn, is used to produce AP and KTR by enciphering and deciphering the ID, respectively, as previously described. A transaction request message is then formed in the terminal, which consists of a time stamp supplied by the acquirer's processor, a message sequence number supplied by the user card, the user's account number, the user's AP, the terminal's ID, the transaction type and the transaction data. The time stamp allows the issuer to check the timeliness of the transaction request message.

The message sequence number, which is returned in the transaction response message, allows the terminal to associate the response with the corresponding request as well as insuring the timeliness of the response. Th...