Encoding integers in the EMV protocol

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....

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"

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.

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.