At 16:30 10/17/96 +0100, Adam Back wrote:
[added cc cypherpunks also]
Sameer Parekh <sameer@c2.org> writes:
Peter Trei <trei@process.com> writes:
Ideally, this should be a DEMO case of a real world encrypted application, in which we have a cryptotext, and a known plaintext, each at least one 8-byte block long.
I'd like to get in touch with a bank who can provide us some sample ciphertext for an ATM transaction or something like that. I initially thought we should hit SWIFT, but that would be very illegal. =)
If someone can dig up a selection of banking protocols (some of these things must be standardised), perhaps we can simulate the same thing without the legal implications.
Of course you'd need the person constructing the challenge to be trustworthy to the tune of $10k, or whatever the prize fund pans out to be. For that matter the NSA, or anyone else with a hardware breaker would be able to cheat, but then they help our cause, which is to demonstrate how weak DES is :-)
Tell me what you need. A large part of my job is providing hardware security modules to banks to secure (among other things) their ATM networks (Automated Teller MAchines, not Async Transfer Mode). Do you need PIN encryption formats, transmission message protocols, or what? Just LMK. G.C.G. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Geoffrey C. Grabow | Great people talk about ideas. | | Oyster Bay, New York | Average people talk about things. | | gcg@pb.net | Small people talk about people. | |----------------------------------------------------------------------| | PGP 2.6.2 public key available at http://www.pb.net/~wizard | | and on a plethora of key servers around the world. | | Key ID = 0E818EC1 | | Fingerprint = A6 7B 67 D7 E9 96 37 7D E7 16 BD 5E F4 5A B2 E4 | |----------------------------------------------------------------------| | That which does not kill us, makes us stranger. - Trevor Goodchild | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Geoffrey C. Grabow wrote:
Tell me what you need. A large part of my job is providing hardware security modules to banks to secure (among other things) their ATM networks (Automated Teller MAchines, not Async Transfer Mode). Do you need PIN encryption formats, transmission message protocols, or what? Just LMK.
It would be nice to get some confirmation that PINs are generated using a DES encryption of the account number. Gary -- "Of course the US Constitution isn't perfect; but it's a lot better than what we have now." -- Unknown. pub 1024/C001D00D 1996/01/22 Gary Howland <gary@systemics.com> Key fingerprint = 0C FB 60 61 4D 3B 24 7D 1C 89 1D BE 1F EE 09 06
(I've deleted 7 out of the 8 recipients, including 2 of the 3 mailing lists. Aren't we letting cross-posting get a bit out of hand?) At 12:36 AM -0400 10/18/96, Geoffrey C. Grabow wrote:
Tell me what you need. A large part of my job is providing hardware security modules to banks to secure (among other things) their ATM networks (Automated Teller MAchines, not Async Transfer Mode). Do you need PIN encryption formats, transmission message protocols, or what? Just LMK.
Wow! If we could get you to get all the ATM terminals to contribute spare CPU cycles to DES-busting, this'd be really great! I doubt customers would mind having to wait an extra second or two while the ATM finishes whatever it's doing. (And maybe if the DES bust is successful while a customer is waiting, he could be awarded with an extra $20 bill.) Better than a DES-busting screensaver. --Tim May "The government announcement is disastrous," said Jim Bidzos,.."We warned IBM that the National Security Agency would try to twist their technology." [NYT, 1996-10-02] We got computers, we're tapping phone lines, I know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^1,257,787-1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."
On Fri, 18 Oct 1996, Geoffrey C. Grabow wrote:
Tell me what you need. A large part of my job is providing hardware security modules to banks to secure (among other things) their ATM networks (Automated Teller MAchines, not Async Transfer Mode). Do you need PIN encryption formats, transmission message protocols, or what? Just LMK.
It would be best to attack something that has broader use than just a single pin. At best, that would allow an hostile to clean out a single account. A target that would allow one to attack, say an account held *by* a bank would be more attractive. --Lucky
"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!
On 18 Oct 1996, Andreas Bogk wrote:
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.
We have a winner! This target is attractive for two reasons: 1. A single key cracked can compromise the entire system. 2. It is a non-US target. Once the key is cracked, the EC-Card system would most likely move to 3DES. And the US seems to have no desire to allow the export of 3DES. --Lucky
Lucky Green <shamrock@netcom.com> writes:
On Fri, 18 Oct 1996, Geoffrey C. Grabow wrote:
Tell me what you need. A large part of my job is providing hardware security modules to banks to secure (among other things) their ATM networks (Automated Teller MAchines, not Async Transfer Mode). Do you need PIN encryption formats, transmission message protocols, or what? Just LMK.
It would be best to attack something that has broader use than just a single pin. At best, that would allow an hostile to clean out a single account. A target that would allow one to attack, say an account held *by* a bank would be more attractive.
Account transfers was what I had in mind also, the higher value transactions that they are used for, and the more widely used the better. So being able to break the authentication on transmission message protocols, might be enough, if being able to forge the authenticed payment transfer requests would be possible. Any protocols you can point us to involving inter-bank or international transfers would be great, if there are any which are still using DES rather than 3DES. Hope these protocols use include known plaintext, either fixed message parts, or predictable (account numbers), or use an integrity check which we can also (ab)use. (Netscape's SSL used (is this still present in SSL3.0?) such an integrity check and this was the toe hold for the SSL brute force.) (As a fall back, ATMs might be useful if the protocol used the same key to encrypt all PINs. However, one might hope that the protocols use diferent DES keys for different PINs.) Some time ago, there was a Russian guy with some other accoplices who got caught transferring several millions out of some US banks, this was in the news, and some news clips were posted to cypherpunks, but I've never seen the details of how he did it discussed. Was this an inside job, or was it black cryptanalysis? Adam -- print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
participants (6)
-
Adam Back -
Andreas Bogk -
Gary Howland -
Geoffrey C. Grabow -
Lucky Green -
Timothy C. May