[Gllug] [ot] borked net transaction

[Daniel P. Berrange]

On Sat, May 07, 2005 at 10:31:45AM +0100, Matthew Thompson wrote:
> >Err, no.  If it were trivial to discover then there would be  
> >absolutely no
> >point in chip and pin cards at all.
> >
> >The point is, the card may know what the PIN is but it has no  
> >option to
> >allow the PIN to be read.  All it will allow is for a proposed PIN  
> >to be
> >checked.  The banks may not be perfect but they're not stupid.
> >
> >There are lots of potential problems with chip and PIN cards but  
> >this - at
> >the current levels of technology - isn't one of them.
> 
> Agreed - I don't believe that the chip and pin cards contain the pin  
> at all - I think that they contain a public key based signature which  
> can be used to verify the PIN offline.

Indeed, the PIN is not typically stored on the card - it is transmitted 
from the ATM straight to the secure server for verification, over a 
channel encrypted with the ATM's master key. Decryption key is kept in
physically tamper proof hardware at the bank, so all operations on the
'clear' PIN were secure. When you change you PIN for your card, you're
not actally changing the real PIN either - you're merely changing a PIN
offset value.

The weak spot in all this is clearly the end terminal where you are
entering your PIN. Previously ATM terminals were considered to be
trusted devices - but with enourmous proliferation of ATMs over the
90's and the expansion of use of debit cards to all retail locations
means that cards & PINs are now being used in highly untrusted devices.
There have been no significant changes to PIN verification protocol
since it was designed in the 70s to address this usage in untrusted
environments, so while it may be better than signatures, its not
exactly the pinacle of security.

Ross Anderson (top-dog security professor at Cambridge) has a very
interesting book talking about all these kind of things

http://www.amazon.co.uk/exec/obidos/ASIN/0471389226/qid=1115458987/sr=1-1/ref=sr_1_10_1/026-8415144-9298823

It also has amuzing tales of things that have gone wrong with 
implementations of credit/debit cards systems. Its intersting to see
that while designed with serious security back in the 70s, ATM pin
protocol has been often compromised in the name of convenience.

eg, at one time, several banks thought up a check-digit scheme to
    allow PINs to be verified offline - without communication to
    the secure server. For exmaple, they're make all PINs such that
    the first + 4th diigt would equal the second plus 3rd digit.
    Does take a genius to figure out you could then use any stolen
    card by entering the PIN  4455. This was a british bank...

eg it was common in the 80s to let ATMs process transactions without
   verifying the PIN, if the network was down for maintenance. Crooks
   in Italy and England exploited this extensively such that all bnaks
   reverted to online only verification.

eg. as a test sequence, one bank's ATMs would output 10 banknotes
   whenever a special 14 digit pin was entered. This 14 digit pin
   was printed in the manual sent to all branches. You guess what
   the result was...

So, while banks are not stupid when designing their credit/debit 
systems, they most certainly do make tradeoffs in security vs
convenience. Guess you have to at the same time trust them, because
you have no choice but to use them, but always check your statements
because shit happens.

Regards,
Dan.
-- 
|=-            GPG key: http://www.berrange.com/~dan/gpgkey.txt       -=|
|=-       Perl modules: http://search.cpan.org/~danberr/              -=|
|=-           Projects: http://freshmeat.net/~danielpb/               -=|
|=-   berrange at redhat.com  -  Daniel Berrange  -  dan at berrange.com    -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20050507/491e93f0/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug