|
search / subscribe / upload / contact |
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
| RSS-Feed Depeschen |  |
|
|
||
|
||
Date: 1998-08-09
Pin Code Wizards-.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- "some banks are still doing utterly stupid things" sagt Rabid Wombat, der sich im deutschsprachigen Pin/Raum schwer auszukennen scheint. relayed by Michael "MacManiac" Grinner m.grinner@mail.gis.at -.-.- --.- -.-.- --.- -.-.- --.- by wombat@mcfeely.bsfs.org: It probably can be assumed that all large-scale ATM systems (e.g., the European "eurocheque logo" ATM cards; the world-wide Cirrus/Maestro and Plus networks; and credit card ATM withdrawals) rely on online PIN verification: The relevant data from the magnetic stripe together with the amount of the transaction and the PIN entered by the customer is sent -- hopefully, using strong encryption -- to the appropriate authorization centre, where the PIN (and the account balance) can be checked; the centre authorizes the transaction if everything is O.K. and says "no" otherwise (e.g., when three incorrect PINs have been tried previously). On a local scale, other PIN verification schemes are possible; e.g., keyed PIN derivation from the data on the card (wich has the disadvantage that the same secret key must be known to several ATMs, embedded in some security module). Here in Germany, the first ATMs were installed in 1981. Back then, PIN verification was always done offline. (Thus, by resetting the incorrect-PIN counter on the magnetic stripe, three more guesses at a different ATM became possible -- and, if necessary, another three at the next ATM, etc.) Until some years ago, at least some ATMs were occasionally operated offline. One common scheme for PIN generation was defined (although not all banks used it): A DES plaintext formed from the account number and similar data contained on the magnetic stripe was encrypted under a DES key known only to the respective bank; the PIN was then extracted from the resulting ciphertext according to certain rules. For PIN _verification_, one common DES key was known to all offline ATMs. The PIN encryption scheme used for this purpose basically amounts to using the account number etc. as an IV for a one-block CFB encryption (the encrypted four-digit PIN was stored on the magnetic stripe) with some brain-damaged changes to the usual CFB computations. (ATMs of the bank which issued the card could alternatively employ the PIN _generation_ scheme for verification, using the bank's key.) Most customer's PINs staid the same all the time, but starting in 1997, the whole scheme is being changed. Now, no encrypted PIN is stored on the magnetic stripe. Also, everyone either already has a new PIN (hopefully created by a more secure algorithm than before) or will get it this year or in 1999. The old scheme had several weaknesses: * The brain-dead PIN generation/verification algorithms used a primitive conversion from hex digits (as included in the DES output) into decimal digits: 0 -> 0, ..., 9 -> 9, A -> 0, B -> 1, ..., F -> 5. While the hex digits in the DES output are reasonably equally distributed, the decimal digits resulting from this conversion obviously aren't. For the PIN system as originally described (where the PIN should be stored encrypted under three different DES keys, presumable in order to facilitate changing one of the keys [which never happened]), this meant that the success probability for guessing the PIN of a random card in three attempts could be improved to about 1 : 150, whereas it should be 1 : 3333 in a well designed system. * DES keys are much too insecure. In 1981, attacking them may have been infeasable. But this argument is definitely not valid for the nineties: For a brute force key search, you'd need the data (magnetic stripe data and PINs) of only five different cards -- which is easy to obtain -- and an appropriately fast search engine. Large criminal organizations could have built one. Also, there surely were Eastern intelligence agencies with the needed equipment; and it is known that Russia has severe problems at paying wages to governmental employees -- the possible connection should be obvious. * Because the keys must be present at lots of ATMs, they can relatively easily be leaked. Also, they possibly could be retrieved from security modules of, e.g., stolen ATMs -- most bits remain intact after power-off (see one of Ross Anderson's papers for practical experience with this). * And, even for a pure offline PIN verification scheme, everything hinges on the security measures at the PIN generation/authorization centres. The brain-dead PIN scheme design is not at all reassuring regarding the competence of those responsible for the security of all this ... Now that this old system is obsoleted, neither a common PIN generation algorithm nor a commond PIN verification algorithm is defined (verification is only possible online, unless a bank still uses card-data-derived keys for its own customers). However: * Some banks are still doing utterly stupid things: - At one bank (in Berlin, I think), the ATMs accepted _arbitrary_ PINs. (This was in 1997, if I rember correctly.) - One large bank (Commerzbank or Dresdener Bank) gave all its customers new PINs in 1997, and at most a few weeks later, gave them all new PINs again -- the earlier new PINs were "not as secure as intended", it was explained (no further details were given; maybe they again used the old hex -> decimal map). * Most new Germany ATM cards not only have a magnetic stripe, but are also smart-cards. (By "ATM cards", I mean eurocheque cards and compatible bank cards -- usable, amongst other things, at ATMs and also as a debit card for paying in stores [POS = point of sale], using the PIN for authentication.) While, since 1997, no PIN information is contained on the magnetic stripe, the PIN is now stored on the chip in order to allow offline POS. This provides a new goal for attacks (note that the attacker may destroy the chip, because the magnetic stripe is enough for ATMs). -.-.- --.- -.-.- --.- -.-.- --.- TIP Download free PGP 5.5.3i (Win95/NT & Mac) http://keyserver.ad.or.at/pgp/download/ -.-.- --.- -.-.- --.- -.-.- --.- - -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- edited by published on: 1998-08-09 comments to office@quintessenz.at subscribe Newsletter - -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- 
|
|
|
 |
CURRENTLY RUNNING |
q/Talk 1.Juli: The Danger of Software Users Don't Control
|
|
|
!WATCH OUT! |
bits4free 14.Juli 2011: OpenStreetMap Erfinder Steve Coast live in Wien
|
|