Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:10:56
David P Jablon (dpj@world.std.com)
Fri, 7 Aug 1998 17:13:52 -0400
> On Fri, 7 Aug 1998, David P Jablon wrote:
> > I should have said that a fixed PIN-MAC key installed in
> > all ATM's is too-vulnerable to theft or disclosure.
> > And getting this key (by whatever means) enables a
> > trivial brute-force attack on every card ever used with
> > the system. This latter brute-force attack is on the
> > order of 2^13, the size of a 4-digit PIN, rather than
> > 2^56, or whatever.
Bram replied:
> Actually, that isn't true - if the PIN is salted - say by appending some
> bits of random garbage to the end of it, and the result of that is left
> encrypted on the card, then the result is reasonable secure. It's even
> better if it's public-key encrypted and signed.
>
> A bit of cleverness in a protocol can do wonderful things.
Your remarks are out of context.
I was pointing out the danger in keeping reference data for
*off-line* verification of a PIN stored on a magstripe card.
When the ATM does on-line verification with the bank, it
can retrieve salt, PIN verifier, and any other user-specific data.
There's no need for any PIN-associated data on the card.
As for exploring alternative systems ...
If you want to permit card+PIN transactions when your bank
is off-line, you're forced to rely on secret, long-lived,
widely-distributed keys in the ATMs. Otherwise, the card
exposes the PIN.
Having a public-key sealed PIN verifier on the card requires
the ATM to know a long-lived private key to unlock it.
In this context, I don't see that PK adds much value.
PK seems more valuable for protecting PIN verification over
the network, from ATM<-->bank, etc. Solutions here include
both cert-based solutions and PIN-authenticated PK exchange.
-- dpj
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:10:56