Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!accuvax.nwu.edu!nucsrl!telecom-request
From: Randal Schwartz <merlyn@iwarp.intel.com>
Newsgroups: comp.dcom.telecom
Subject: Re: ATM at Retailers (was: Voice Mail Passwords)
Message-ID: <12485@accuvax.nwu.edu>
Date: 24 Sep 90 00:14:10 GMT
Sender: news@accuvax.nwu.edu
Reply-To: Randal Schwartz <merlyn@iwarp.intel.com>
Organization: Stonehenge; netaccess via Intel, Beaverton, Oregon, USA
Lines: 32
Approved: Telecom@eecs.nwu.edu
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 10, Issue 671, Message 1 of 12


In article <12469@accuvax.nwu.edu>, motcid!king@uunet (Steven King)
writes:

| >You are not giving your PIN number to the merchant.  The PIN is
| >encrypted (mixed with your bank card number) in a ONE WAY algorithm by
| >a chip that is in the PIN pad itself.  The plaintext PIN never sees
| >the light of day.

| A one way algorithm?  Pray, how does the bank decode it to verify you?
| A gigantic lookup table?

| I really am curious about this, the sarcasm is just a side-effect.  :-)

One algorithm is a query-response ... Bank sends QUERY (a random
number) to merchant box.  Merchant box sends QUERY to keypad.  You
enter PIN into keypad.  Chip in keypad computes oneway (QUERY,PIN) as
RESPONSE, sends that to merchant box.  Merchant box sends RESPONSE to
bank.  Bank computes oneway (QUERY,PIN), compares it with RESPONSE, and
says yay or nay.

See... the PIN is both at the bank, and in the keypad, but nowhere
else.  And recording the traffic for later replay won't help.

(Yes, there are *other* ways.)

Just another security weenie,

Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 
on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III
merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn