[Gllug] OT - chip & pin

[Daniel P. Berrange]

On Mon, Apr 03, 2006 at 01:20:25PM +0100, Paul Rayner wrote:
> 
> On 3 Apr 2006, at 12:03, Benedikt Heinen wrote:
> 
> >>I have to admit that I believe the notion of a simple 4-digit number 
> >>as a
> >>means of security is somewhat flawed.  A random number of characters 
> >>using
> >>a 'old style telephone' keypad with letters on each numeric key would 
> >>seem
> >>much better, since users could then use a more-easily remembered word 
> >>as a
> >>PIN  !
> >
> >What I found more worrying, is that apparently you don't need to have 
> >the full/correct PIN to decrypt all important data from the card. When 
> >I lived in Switzerland a few years back I also got a swiss EC card 
> >(which had a 6 digit code on it). The first time I went back home to 
> >Germany (where, like here, 4 digit codes are the norm), I tried to 
> >withdraw money from a cash machine, but (inadvertently) entered a 
> >wrong last digit for the pin - nevertheless, the machine let me 
> >withdraw money from my account. I tried it again to see where the 
> >problem was - and apparently, the machine correctly waited for 6 
> >digits to be entered - but only checked the first 4!
> >
> >
> >I would have assumed, that the banks / credit card companies would 
> >have opted for a scheme, where the pin code is part of the 
> >en-/decryption code for the card data - so that without the proper 
> >code, you can't read the correct data on the card... :-(
> 
> The PIN (in encrypted form) *is* stored on the card (as not all readers 
> can always be online - you can see this by the number of readers that 
> return "PIN OK" immediately). I've always thought this makes a bit of a 
> mockery of the security of the PIN (three strikes and you're out etc.) 
> because all a crook would have to do is hack (or make) a terminal so 
> that it allowed unlimited tries whilst offline. Brute forcing a 4 digit 
> code when you have immediate validation isn't exactly hard!

Long term practice for ATMs & mag stripe cards has been a trusted path from
the ATM keypad through to the bank's central computer, with tamperproof
hardware and unique encryption keys for each ATM. In such a system the
PIN is never stored anywhere & verified remotely on the mainframe 
computer. Now what *can* be stored locally on teh ATM card itself is a
PIN offset - basically when issued it starts off at 0, and when you change
you're PIN, you're not actually changing the PIN, but rather changing
the offset stored on the card. So when you then use the card, the offset
is used to adjust whatever you type in before its sent to the remote
system for verification.

Perhaps with the advent of chips, banks have decided that the chip is
secure enough to store the PIN, but I'd be pretty surprised if that
turned out to be the case, because it could allow trivial brute force
attack. Even UK banks aren't normally that cavalier with security ;-)

> Whilst a strong motive for the introduction of chip & PIN is the fact 
> that the card issuer removes a chunk of their fraud liability, if you 
> look after your card and report it immediately if it's stolen you 
> *will* be safer under chip & PIN because whilst cloning a magstripe 
> takes 30 seconds, I've not heard (although would the banks be likely to 
> announce it?) of an easy way to clone a chip, so a would-be thief needs 
> either the physical card, or magstripe + PIN, as opposed to just a 
> swipe of the magstripe. The stripe has a code which states whether the 
> card should contain a chip, so ATMs will reject cards with a stripe 
> which should also contain a chip but don't. A TV (can't remember the 

While the stripe does contain a code to say whether there is a chip present,
if the chip is unusable (eg, damaged by static shock - accidental or delibrate),
then the ATM will fallback to using the mag stripe. This makes a nice easy
attack vector. See chapter 3 in this PDF  http://chipandspin.co.uk/spin.pdf

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: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: Digital signature
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20060403/48636ac3/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug