Payment security, indeed all security, involves a loop of activities:
Begin: Assess the situation
Security Technology Rule #1: Deploy security mechanisms you know are strong
Security Technology Rule #2: Deploy them properly
Security Technology Rule #3: Be prepared for the time it gets hacked
Loop back to Rule #1
At the beginning, you have to assess what you’re protecting and how much you want to spend doing it. After that, there are three rules to follow. And then, you do it all over again because security is never a steady state, “we’re done” condition. Someone is going to find a way to break what’s been put in place, whether it’s the physical locks used in CIA offices (that was done) or a smartcard-based encryption approach. That means what you put out in the field has to be better than what was last broken into, that you deploy it correctly, and with the full knowledge that even your latest and greatest security step will eventually be compromised.
In this tale, operators of Taipei’s EasyCard system violated Rules #1, #2 and #3. They expanded a system designed for transit applications to take POS payments at convenience stores, coffee shops and other locations in the city. The EasyCard smartcards used for the transit system were based on MIFARE “Classic” from NXP, an older smartcard approach that was very publicly hacked three years ago. That was the Rule #1 violation. Rule #2 was violated because the system deployment neglected to do back end verification of what the smartcard reported. The security researcher was able to add value to the load on the smartcard and spend it without detection by the back end accounting system. Without validation checks, you can’t be sure of proper, or improper, system function. This error wasn’t a function of MIFARE; it was a poor deployment choice.
Today, the city government and EasyCard are now stuck with figuring out what to do. That’s Rule #3. A scheme that is upgradable remotely is a good place to start.
Practical security is not about protection or invulnerability. It’s about economically reasonable solutions. In the EasyCard case, an updated crypto approach should have been used. That was a poor deployment decision given the hacker’s low cost of exploiting the known weakness and EasyCard operator’s not inconsequential but obvious need to upgrade its cryptographic capabilities.
Violate rule #2 and you get problems. Too. An “EMV breach” reported earlier in 2010 was a UK deployment error that used a static CVV code from the magstripe side of the card rather than the dynamic value. No doubt an expedient option that limited back end changes, it was a poor deployment decision that was both easy to rectify and had nothing to do with EMV itself.
It is amazing how many security issues have everything to do with deployment errors and nothing to do with the security technology itself. Of course, in this EasyCard case, it’s more than that.
The city government and EasyCard know about the problem, he said. Taiwanese researchers have tried to warn them, and the research is publicly available online. The problem is companies trying to rely on “security through obscurity” — using proprietary but unsafe encryption — and trying to save money by not investing in solid security.
“It reminds me of 15 or 20 years ago, of manipulating saved game points on a PC,” he said. “It’s really not that different in this case, aside from the three-hour key crack.”
His advice to companies and other organizations investing in card technology in the future? Spend a bit more money, and use a stronger security algorithm. Implement verification procedures that will prevent cards from being manipulated so simply. And when designing systems that are to last many years, build in room for software updates, once the inevitable flaws have been found.
Read more at the Wired site: http://www.wired.com/threatlevel/2010/12/unsmart-investments-in-smart-cards/