5

In the UK it's common to use a smart card and reader to log in to online banking. You insert the card, enter the PIN and get back an 8-digit code from the reader to enter into the online bank website. Note that it's not seeded in anyway from the bank, all you need is the card and the PIN.

I'd always thought that the 8-digit code returned wasn't very random (in particular the first two digits were the same), so I started keeping track. Basically the 8-digit code is monotonically increasing by about 60,000 to 90,000 each time.

This doesn't seem right based on how I understood this to work. Obviously there's very low entropy in seeding the identification algorithm (only uses an internal counter on the card if I understand things right) but I thought the 3DES on the card would result in a noise-like sequence of 8 digit codes.

Is this really how the system is supposed to work?

| improve this question | |
  • It might not matter very much - you usually get a very limited number of attempts to enter the correct value, so even if it increased by a random value between 1 and 100, it would be difficult for an attacker to guess the correct value, since they'd be locked out after 3 tries. – Matthew Jun 30 '17 at 11:06
  • I agree it's not likely in practice, but the chances of guessing should be 1 in 100 million as implied by the 8-digits, not the ~1 in 20,000 it appears to be – holidaymonkey Jun 30 '17 at 11:18
3

The protocol is discussed in Optimised to Fail: Card Readers for Online Banking - Drimer, Murdoch and Anderson 2009

The paper shows images of readers from Natwest & Barclays as well as mentioning HBOS. Visually they are also identical to readers used by Nationwide, Coop and i'm sure others. As far as I am aware these devices have not changed since 2009 - I have one from back then that still works.

The bit filter seems to vary based on the bank. The first few bits seem to be the "Cryptogram Identification Data(CID) type code" which i imagine would be constant accross transactions. The next few bits (the number of which vary) seem to come from the "application transaction counter (ATC)" - which you would expect to increment with each transaction. I expect this is where the large increment you see comes from.

The Issuer Application Data is also not a source of entropy.

This leaves the "Application Cryptogram (AC)". This is a MAC (a form of hash - usually 3DES CBC) involving a session key on the card. It looks like 10-20 bits of this are taken which would be the primary source of entropy.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.