From: Alex Butcher 
Subject: Re: chip & pin - could this happen?
Date: Mon, 13 Feb 2006 19:29:19 +0000
Message-Id: 
Newsgroups: uk.finance

On Sun, 12 Feb 2006 14:17:25 +0000, Alex wrote:

> At 12:15:34 on 12/02/2006, Alex Butcher delighted uk.finance by
> announcing:

[snip]

>> If I were designing C&P, I'd have the terminal send the chip on the card
>> the pin requiring validation and a timestamp. If the PIN was valid, I'd
>> then have the chip reply after a random delay of upto a minute or so
> 
> And you'd end up having wasted all your efforts.  Who do you think is
> going to be content waiting a minute or so for every transaction to be
> authorised?

You must have missed my 'or so' - the period of a minute would be
determined by usability testing prior to standardisation and
implementation.

>> (fixed and defined in the specification, naturally) with a the timestamp
>> and 'yes', and have that reply signed with private key (i.e. embedded in
>> the chip, inaccessible) whose corresponding public key (also on the
>> chip, but retrievable by the terminal) is signed with the issuing bank's
>> key.
> 
> So, the way it currently works then.

Good.

>> If
>> the PIN was invalid, no reply will be sent from the chip.
> 
> Then how does the terminal know that the chip got its request?

Does it care? If it doesn't get a response back within the maximum
specified time for a reply, either resend, or ask the user to enter
another PIN. After some period of time, have the terminal decline the
card, either because it's faulty, or because the user can't provide a
successful PIN.

>> The random delay
>> would mean that an attacker attempting to brute force the pin would have
>> to wait the maximum reply time for every attempt - i.e. 10000 minutes
>> (just under 7 days) for a standard four digit PIN (should be long enough
>> for the customer to notice his card missing, report it, and have it
>> cancelled). I'd make that random delay longer if I thought it would be
>> acceptable to customers in a busy supermarket.
> 
> What?  You only get 3 attempts at a PIN.  And the current specifications
> are for an average of 1 PIN entry every 30 seconds (one implementation
> being the token bucket method).

I was working on the assumption that the chip, being cheap enough to put
on millions of credit cards, would be stateless between transactions.
If the chip is sophisticated enough to have the capability to maintain
state between transactions, great - have the chip self-block after three
failed attempts within a given time period instead.

Anyway, this was all minutiae for the benefit of explaining the essentials
of how C&P works so I could outline the two main technological attacks one
could use to clone live chips.

Best Regards,
Alex.
-- 
Alex Butcher      Brainbench MVP for Internet Security: www.brainbench.com
Bristol, UK                      Need reliable and secure network systems?
PGP/GnuPG ID:0x5010dbff