Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Iterative PIN Generation

IP.com Disclosure Number: IPCOM000060913D
Original Publication Date: 1986-Jun-01
Included in the Prior Art Database: 2005-Mar-09
Document File: 3 page(s) / 45K

Publishing Venue

IBM

Related People

Lennon, RE: AUTHOR [+4]

Abstract

This article describes a method of cryptographically generating and authenticating customer personal identification numbers (PINs) in a point-of-sale (POS) or electronic funds transfer (EFT) network. The method offers an improvement over existing methods by generating each customer's PIN as a function of the customer's unique nonsecret personal identifier (ID), a nonsecret customer-related PIN count value, and a secret PIN generation key which is the same for all generated PIN values. Ordinarily each customer's PIN value would be stored in a protected table at the issuing bank for the purpose of authorizing customer-requested transactions. In contrast, the present method allows the PIN values to be regenerated dynamically, when needed, for PIN checking purposes instead of being stored at all.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 47% of the total text.

Page 1 of 3

Iterative PIN Generation

This article describes a method of cryptographically generating and authenticating customer personal identification numbers (PINs) in a point-of-sale (POS) or electronic funds transfer (EFT) network. The method offers an improvement over existing methods by generating each customer's PIN as a function of the customer's unique nonsecret personal identifier (ID), a nonsecret customer-related PIN count value, and a secret PIN generation key which is the same for all generated PIN values. Ordinarily each customer's PIN value would be stored in a protected table at the issuing bank for the purpose of authorizing customer-requested transactions. In contrast, the present method allows the PIN values to be regenerated dynamically, when needed, for PIN checking purposes instead of being stored at all. The method is made robust by introducing a PIN count value, which allows new PIN values to be generated using the same PIN generation key held by the bank. Thus, a compromised PIN value does not invalidate the secret PIN generation key. Fig. 1 illustrates a customer/retailer/issuing bank relationship in which PIN checking is used to authorize POS/EFT transactions. PIN checking typically involves the following steps. A customer desiring service at a POS/EFT terminal enters his/her PIN value and magnetic stripe bank card, from which is read his/her identifier ID. A transaction request message containing the ID and PIN values is communicated to an issuing bank. The issuing bank is the bank which issued the bank card and PIN to the customer. Authorization of the transaction involves checking the supplied PIN value against a value generated at the bank dynamically when needed. The bank generates this value using an ID/PIN count table in which the count is unique for some but not all accounts. Based on this comparison, the bank sends a response message to the requesting terminal indicating that the transaction has been authorized or not authorized. Though not shown in Fig. 1, cryptography is employed to encrypt the transmitted PIN value. Cryptographic message authentication techniques are also used to maintain the integrity of the transaction request and response messages. Fig. 2 illustrates a method of dynamically generating PINs in the system of Fig. 1. The method of Fig. 2 utilizes a value, called the PIN count, stored at the issuing bank. Since a file of customer account information will already exist within the issuing bank's data base, this file of account records can be used conveniently to store each customer's PIN count value. The number of PINs that can be derived for each customer depends on the size of the PIN count field. For example, an 8-bit field would allow up to 256 different derived PINs. In practice, the vast majority of customers would require only a single PIN and have a count number of 1. A small number of customers would require a second PIN, and a still smaller number would require a third PIN, etc....