Re: Cypherpunks defeat?

[Adam Back <aba@dcs.ex.ac.uk>]

Christopher Petro writes on cypherpunks:
> 	That being the case, I'd say a penny is just right. Enough to make
> one think, but not too hard.

Make it 1/100 of a penny; then if someone wants to charge 1p they can
charge 100 of them, the other way is not as easy to arrange.

> >>But for the scheme to be successful, we need many token
> >>issuers
> >Is there existing open software available for this?
> 
> 	The problem isn't issueing the tokens, it's the wallets. Token
> generation would be relatively straight forward, it's the user end.

The biggest problem is buying ecash, instantly.  It has to be instant,
and accountless, because otherwise people are going to walk off in
disgust and try somewhere else.

You want to buy ecash tokens with plastic.  Ideally you want to be
able to buy ecash tokens with an ATM card because you don't want to
incur any withdrawal fee (ATM withdrawals incur no transaction fee the
UK, US may be different.)

Buying ecash tokens with a credit card is going to result in the cash
advance minimum fee, plus unwanted (and typically double digit APR)
interest on the "advance".

Debit cards are a bit cheaper, but still incur some fee (unless a bank
could be persuaded to waive it for this class of transaction).


Due to the instant, accountless requirement, you need to say implement
it as a signed java applet, which implements a protocol allowing you
to authenticate yourself to the ATM network with your PIN and card
number.

Problem: it's rather easy to hack, would take some fraction of a
second to try all 10,000 pin numbers, although if the check is online,
they could disable the card after 3 tries or so.

Still the problem persists: attacker obtains (or generates) valid (or
possibly valid) credit card numbers, uses up the 3 tries on each card
number, and moves onto the next number.  They will get a sucess every
3,333 card numbers on average.  (This attack is as a by-product going
to annoy a lot of people who have their cards disabled as a result.)

Artificial delays won't work because the attacker can parallelise via
multiple IP addresses on card numbers and PINs in randomised
sequences.

So because of the inherent naffness of ATM security, you are stuffed.

David Birch suggested that the European smart card based credit/debit
cards (EMV cards) would be better because they are more secure.
However this has the start up cost of a smart-card reader, and
violates the requirement for instant, accountless (and especially
hardwareless) use.

Ideas for beefing up ATM PIN based security using existing hardware
(deployed Cards and PINs), to get it to an acceptable level of
security with a low enough user interaction overhead.

Adam