The real problem is not over-complexity in the means of EMV, but over-complexity in the goals. It simply tries to support far too many options and variations. To give an example: a lot of the on-card risk management is just a waste of time imho. A large proportion of our customers simply dont bother with that stuff, they look to use the default values, and I think they’d prefer if it wasnt there at all. And mastercard and visa busy themselves making little changes and deltas to make their spec own version, because they are too proud to agree. Hence we have a raft of super-specifications on top of EMV, and EMV has been explicitly designed to support this diversity. Diversity is bad (well, that throw away comment is a whole argument for another day). So my main gripe is with the aims, not with the means.

Now, it may be that the way EMV has turned out is the best one could possibly hope for a protocol designed and agreed between multiple interested parties with no clear dictator to lay down the way things are. But whilst that can explain problems, it cant annul them.

We are left with a situation where EMV sucks, I’m afraid. It’s true… BUT… it sucks in the same way that TCP/IP sucks. And just like TCP/IP, EMV is very successful, well at least in that it has achieved wide deployment and we rely upon it daily. Perfect, no? Good, debatable? Successful — yes!

End “throwaway comment”.

ASN.1, Track 2 and Track 1 are legacy. EMV just adopyted them as they are.

Compressed numeric items are not really numbers, such as track 2 that contains ‘D’.

So we are left with two numeric formats, BCD and binary. While two is twice as much as the theoretical minimum, it is far cry from the nine presented above.

I agree. Having a programmer make a mistake like this is probably unavoidable, so processes which stop the bug hitting production code are essential. I think software engineering quality would be significantly improved if companies felt able to talk about such failures openly, so that others could learn from their mistakes.

Indeed, the first few are from ASN.1 BER. However I would argue that implementing the decoder/encoder is not so trivial. Firstly, the EMV specifications are incomplete (e.g. they do not specify the endianness of multi-byte TLV field lengths). Secondly, unless great care is taken, an implementation will be vulnerable to buffer and/or integer overflows (as the various vulnerabilities in commercial ASN.1 decoders proves).

However, my main point was not so much about ASN.1, but about the huge variety of different encodings. Why is track one encoded differently from track two? Why is it possible to encode the amount of a transaction in either BCD or an unsigned binary integer? I think this complexity could be part of the reason we see implementation problems in EMV.

As for the two-digit years, that also surprised me given that the first version of EMV came out in 1996 when the Y2K bug was fairly well known. I’m not sure if there was any practical impact though, because as far as I know the first large-scale deployments of EMV were post-2000.

One of the most important characteristics of a good specification is that it should be implementable. The fact that otherwise competent programmers seem to be consistently unable to create secure ASN.1 implementations does point to a problem with the specification, in my opinion. Blaming programmers doesn’t make the problems go away.

This lesson has already been learned in the field of safety critical systems. Previously, when an accident happened, a person would be identified as responsible for the “human error”, and fired or perhaps re-trained. The problem with this “blame and train” attitude is that people kept on dying.

The more modern approach to accident analysis is to accept that to err is human, and design systems around this fact. By looking at the system as a whole, we can help people make fewer mistakes, and design processes to reduce the damage when they do. This is the motivation behind root cause analysis: finding all the ways in which an accident could have been prevented, not just finding a person to blame.

With respect to software, I think that lessons can be learned from this field. If the correctness of a system depends on a super-human ability to not make mistakes, then the design of the system is broken. Correcting this requires changes of many different types, including use of static analysis, safer programming techniques, as well as procedural improvements such as in testing. However, I think an important addition would be to design specifications which do not lend themselves to implementation blunders.