Blog article
See all stories »

An article relating to this blog post on Finextra:

Millions of German bank cards hit by Y2K timebomb

Millions of German bank cardholders have been hit by a Y2K-hangover bug which prevents card chips supplied by French technology company Gemalto from recognising the year 2010 change.


See article

Encoding integers in the EMV protocol

On the 1st of January 2010, many German bank customers found that their banking smart cards had stopped working. Details of why are still unclear, but indications are that the cards believed that the date was 2016, rather than 2010, and so refused to process a transaction supposedly after their expiry dates. This problem could turn out to be quite expensive for the cards’ manufacturer, Gemalto: their shares dropped almost 4%, and they have booked a €10 m charge to handle the consequences.

These cards implement the EMV protocol (the same one used for Chip and PIN in the UK). Here, the card is sent the current date in 3-byte YYMMDD binary-coded decimal (BCD) format, i.e. “100101″ on 1 January 2010. If however this was interpreted as hexadecimal, then the card will think the year is 2016 (in hexadecimal, 1 January 2010 should have actually been “0a0101″). Since the numbers 0–9 are the same in both BCD and hexadecimal, we can see why this problem only occurred in 2010*.

In one sense, this looks like a foolish error, and should have been caught in testing. However, before criticizing too harshly, one should remember that EMV is almost impossible to implement perfectly.

Read more at Light Blue Touchpaper...

5291

Comments: (3)

A Finextra member
A Finextra member 19 January, 2010, 15:50Be the first to give this comment the thumbs up 0 likes

Good theory, but EMV cards don't perform the Expiry Date check; it's actually done by the terminal or ATM. The card's expiry date is read by the terminal in order to perform the check. If the cards were issued using the new Common Payment Application (CPA) specification, then they can optionally perform some internal checks using the current date, such as the number of days that the card can remain offline without contacting the host, so if the card were to interpret the current date wrongly, all that should happen is that the transaction would be forced online, and since most if not all transactions in Germany are online anyway, that doesn't explain why transactions failed. In any case, it seems unlikely that over 23 million cards have been issued using the CPA spec. The mystery deepens....

Steven Murdoch
Steven Murdoch - University College London - London 19 January, 2010, 17:12Be the first to give this comment the thumbs up 0 likes Hi Nigel,

Thanks for your comment.

"then they can optionally perform some internal checks using the current date, such as the number of days that the card can remain offline without contacting the host"
One possibility along these lines is that the card thinking the current date was 2016 led to an overflow when computing the number of days since the last online transaction. I'm not convinced by this though, because if the card used 8 bit arithmetic problems would be hit in one year, and 16 bit arithmetic would handle dates well past 2016.

It could be, of course, that the 2016 idea is a red-herring because I haven't heard it from any reputable source. I hope we do find out what the problem is in the end, because it will be a very useful lesson for the industry and should be examined in more detail.

Stephen Wilson
Stephen Wilson - Lockstep Group - Sydney 19 January, 2010, 21:38Be the first to give this comment the thumbs up 0 likes

Steve Murdoch apparently set out to slur EMV by describing a "foolish error" but later admitted that the year 2016 theory did not come from "any reputable source". 

"However, before criticizing too harshly, one should remember that EMV is almost impossible to implement perfectly"

This throw away line contains all sorts of red herrings:

  • It's almost trivial to state that any particular complex scheme XYZ cannot be implemented "perfectly".  This is really quite an unprofessional criticism for him to make.  Security is never about perfection; it is about fitness for purpose.
  • In respect of fitness for purpose, there have indeed been and will continue to be errors in EMV implementation, and it's good that the likes of the Cambridge boys continue to pound away and publish the errors they find.  But the constructive response is not to damn all of EMV as they do, but rather to press for better certification. [A parallel example is the sensationalised attacks they've mounted by tampering with EMV terminals.  These results are really unsurprising: if organised crime can tamper with merchant terminal equipment, then the sky's the limit.  But the clear lesson is that terminal manufacture quality controls need to be looked at, not that the payments system is all of a sudden broken.]
  • In terms of testability, EMV probably utilises simpler technologies than FIPS-201, for which there are elaborate testing and certification schemes.  The challenge of correctly implementing EMV is not great compared to other security programs.  It may require greater care and investment than we've seen from issuers to date, but that's the way security economics tends to work: businesses under-invest at first, and catch up later.  The scheme itself is not broken.
  • The year 2016 date error doesn't seem to me to relate directly to EMV at all, but looks like an elementary software error in some other module in the smartcard and/or the terminal.  The charge that this error reflects badly on the EMV program at large is drawing a long bow, and comes across as another example of the Cambridge boys over-reacting as part of their anti-EMV agenda.

Security and cryptography are careful and precise disciplines.  I wish that security practitioners would exercise commensurate care and precision in the way they publicise their findings. We all decry security sensationalism on the part of politicians with agendas, but politicians are not the only offenders.

 

Steven Murdoch

Steven Murdoch

Royal Society University Research Fellow

University College London

Member since

01 Jul 2009

Location

London

Blog posts

9

Comments

35

More from Steven

This post is from a series of posts in the group:

Information Security

The risks from Cyber cime - Hacking - Loss of Data Privacy - Identity Theft and other topical threats - can be greatly reduced by implementation of robust IT Security controls ...


See all