Payment security,indeed all security, involves a loop ofactivities:
- Begin: Assess thesituation
- 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 toassess what you’re protecting and how much you want to spendprotecting it. After that, there are three rules to follow. Andthen, you do it all over again because security is never a steadystate, “we’re done” condition. Someone is going to find a way tobreak what’s been put in place, whether it’s the physical locksused in CIA offices (that was done) or a smartcard-based encryptionapproach. That means what you put out into the field has to bebetter than what was last broken into, and that you deploy itcorrectly -with the full knowledge that even your latest andgreatest security step will eventually be compromised.
In this tale, operators ofTaipei’s EasyCard system violated Rules #1, #2, and #3. Theyexpanded a system designed for transit applications to take POSpayments at convenience stores, coffee shops, and other locationsin the city. The EasyCard smartcards used for the transit systemwere based on MIFARE “Classic” from NXP, an older smartcardapproach that was very publicly hacked three years ago. That wasthe Rule #1 violation. Rule #2 was violated because during thesystem deployment, back-end verification of what the smartcardreported was neglected. The security researcher was able to addvalue to the load on the smartcard and spend it without detectionby the back-end accounting system. Without validation checks, youcan’t be sure of proper, or improper, system function. This errorwasn’t a function of MIFARE; it was a poor deploymentchoice.
Today, the city governmentand EasyCard are now stuck with figuring out what to do. That’sRule #3. A scheme that is upgradable remotely is a good place tostart.
Practical security is notabout protection or invulnerability. It’s about economicallyreasonable solutions. In the EasyCard case, an updated cryptoapproach should have been used. That was a poor deployment decisiongiven the hacker’s low cost of exploiting the known weakness andthe EasyCard operator’s not inconsequential but obvious need toupgrade its cryptographic capabilities.
Violate Rule #2 and you getproblems, too. An “EMV breach” reported earlier in 2010 was a UKdeployment error that used a static CVV code from the magstripeside of the card rather than the dynamic value. No doubt anexpedient option that limited back-end changes, it was a poordeployment decision that was both easy to rectify and had nothingto do with EMV itself.
It is amazing how manysecurity issues have everything to do with deployment errors andnothing to do with the security technology itself. Of course, inthis EasyCard case, it’s more than that.
The city government and EasyCard know about theproblem, he said. Taiwanese researchers have tried to warn them,and the research is publicly available online. The problem iscompanies trying to rely on “security through obscurity” – usingproprietary but unsafe encryption – and trying to save money by notinvesting in solid security.
“It reminds me of 15 or 20 years ago, of manipulatingsaved game points on a PC,” he said. “It’s really not thatdifferent in this case, aside from the three-hour keycrack.”
His advice to companies and other organizationsinvesting in card technology in the future? Spend a bit more money,and use a stronger security algorithm. Implement verificationprocedures that will prevent cards from being manipulated sosimply. And when designing systems that are to last many years,build in room for software updates, once the inevitable flaws havebeen found.
Read more at the Wiredsite:http://www.wired.com/threatlevel/2010/12/unsmart-investments-in-smart-cards/