Archive for emv

When infallible does not mean infallible…

Posted in technology with tags , , , , , , on March 9, 2009 by newideasconsult

One of the most lively discussions I had in years was about EMV or to be more precise Chip & PIN as implemented in the UK.  I remember a person asking a question about this technology, and in many of the responses, engineers close to the product made claims of high security and almost infallibility.  I felt compelled to write and refute some of the statements made, and was promptly shot down.  I again responded that my point about EMV or Chip & PIN is from the CONSUMER’s point of view, and does not focus on the actual chip technology and how wonderful that little piece of engineering is, or the beautiful way the terminal may be enabled to communicate with this chip and the magnetic strip on the card, but rather focuses on the entire system as proposed to consumers by their banks.

It has been sold to them as such an infallible system that consumers now must take responsibility for when fraud occurs on their card, because a compromised PIN is surely the only way Chip & PIN could be breached.  My argument was based on the fact that the system as a whole can be compromised, making the promise to the consumer, and therefore the shift in accountability, a false one.  To this day I stand by this, though I realize many engineers who designed the standards on which the solution is based, may be offended by my stance.

In fact the way this technology and the systems based on it has been sold to bank customers is the issue I have.  It is wrong to promise a customer during the initial phases of commissioning, up and until they accept the new product as their own, that it is for THEIR protection as it is infallible, have them then fall for that promise and accept the change, and then turn around and blame them when fraud occurs after the system has been rolled out and sold to them.

As a bank you are blindly believing your own hype, and therefore changing the way your staff handles any enquiries by bank customers as simply not possible.  Since 2005 it has been repeatedly proven that the system is indeed open to fraud, and that a customer cannot be held responsible just because the hype says so.  Chip & PIN is only as strong as its implementation, and it is here that the ‘system’ fails most often.  Yes, it takes an enormous amount of effort and processing power to break down the encrypted chip and steal the data, but that was never the issue.  Fraudsters have simply worked around the chip, and so the system has shown it is not infallible and can be compromised.

With such technology, specifically in high risk industries like banking, my input is always to be cautious with the manner in which our clients, the people who buy our systems or technology, sells the product on to their customers.  Though as an engineer we may smugly believe we can claim absolute security or infallibility when referring to the component within the product, service or system that we specifically designed, it is in the commissioning of the whole that the problems most often pop up, issues we engineers seldom thought of before.

So again, as with that Chip & PIN questions and answers group on Linked In, I caution fellow engineers and system designers that we educate clients and their customers correctly about what we mean when we state our product or service is infallible.  The above example is just one of many in the world today, so please don’t think I am picking on it specifically.  I am in the payment industry and the debates around Chip & PIN just gave me the perfect example to my argument.

My suggestions:
1. Don’t promise absolutes for something that has not yet been tested in the field.
2. Don’t change liabilities for that same thing if you have not subjected it to real world customers and exposed it to the market for a proper pilot phase.
3. Certainly do not change your staff’s approach to customers using this new technology if you have not done any of the above points first.
4. Don’t assume!  It gets me every time when I hear something stated as fact, and then investigate to find that the person, organization or company stating the ‘facts’ have indeed done so on the back of assumptions and not first hand knowledge.  Hearing from someone else that something technical is infallible, is not the same as testing the product for infallibility yourself!