From: Andreas Bogk <andreas@artcom.de>
Date: Fri, 18 Oct 1996 01:47:20 -0700 (PDT)
To: Lucky Green <shamrock@netcom.com>
Subject: Re: DES cracker.
In-Reply-To: <Pine.3.89.9610172224.A7082-0100000@netcom9>
Message-ID: <y8apw2gfyqr.fsf@hertie.artcom.de>
MIME-Version: 1.0
Content-Type: text/plain


>>>>> "Lucky" == Lucky Green <shamrock@netcom.com> writes:

    Lucky> It would be best to attack something that has broader use
    Lucky> than just a single pin. At best, that would allow an
    Lucky> hostile to clean out a single account. A target that would
    Lucky> allow one to attack, say an account held *by* a bank would
    Lucky> be more attractive.

The EC-Card system, the European standard for ATM cards, is based on
DES. A single recovered key would suffice to calculate all PINs every
current EC card, the number of which runs into the tens of millions.

That would be especially interesting considering that peeple in
Germany consistently lost suits against their banks in cases of stolen
EC cards, the courts believed the banks' claim that DES is
unbreakable.

The PIN verification breaks down like this:

On the card (which is a standard ISO magnetic stripe card with some
bells and whistles to detect forgeries) are between others the
following data:

- the account number (10 digits)
- the bank number (8 digits)
- a card serial number (1 digit)
- three offset values (4 digits each)

The last five digits of the bank number, the account number and the
serial number are concatenated. If I had an account at Deutsche Bank,
this could look like this:

- bank number: 10070000
- account number 0004943918
- serial number: 1 (it's my first card).

Concatenation is: 7000000049439181. Now this number is viewed as a hex
number and DES ECB encrypted: res = E(0x7000000049439181).

The 3rd to 6th letter of the result viewed as hex is extracted:

res == 0x8d6b477bd7a83b7c
           vvvv
	   6b47

and every digit is taken modulo 10:

           6b47
           vvvv
           6147

This is basically the PIN, wich is requested from the user and
compared to that value.

Now things get a little complicated. There are different keys used in
the DES encryption, institute keys and pool keys. Every ATM either
tries the institute key, which is specific to the bank owning the ATM,
or, if the card was given out by another bank, a pool key, which is
common to all EC Card vendors. This latter case is where the offset
fields come in play, the contents of the offset field is added to the
encryption result before comparing to the entered PIN. 

I'm citing all this from memory, and I'm a little unsure about the
specific way the offset is added into the result, and about the
presence of three different offset fields. My guess is that the pool
key is changed every year, as the maximum validity for EC Cards is two
years. I'll try to dig out all the details if you consider this target
interesting.

Andreas

-- 
Besides: Simulating reality creates too high a polygon count!