Schneier on Security

Seiran • November 26, 2010 2:56 AM

@Dom De Vitto: Any bank that’s worth their Visa/MC license will have additional random data on the strip, often referred to as CVV or PVV. This number is not present in, and ideally not derived from, the human-readable information on the card. There are a few systems that do not verify the CVV, only sending the account number (PAN), Cardholder Name and the expiration through a web gateway. I presume they do not receive card-present rates.

@moo: That’s is exactly what they’re aiming for: shifting more liability to consumers. It is what happened in the UK. This move resulted in a decrease in accepted claims by customers (more profit for banks!)

@Jon: You should see the NCR ATMs. The card reader sinks into the ATM and glows green through translucent plastic (blue on some Chase machines). The dip reader is the most common one. There is also a motorized reader, one place you’ll see them is on some newer Wells Fargo EnvelopeFree ATMs. It has a lenticular hologram of a smiling padlock embedded into the plastic. When moving from side to side, the padlock shrinks and grows. NCR refers to this design as their FDI, Fraudulent Device Inhibitor.

The “anti-skimming” devices I’ve seen on many European ATMs look like garbage, one welded out of bare steel, some of them look like skimmers themselves. The Russian hackers will be in for a big surprise – and a big headache – when they see the latest ATM designs here.

@Richard, why would they? Patents = royalties. I absolutely abhor attempts by inventors real-or-imaginary to manipulate government, standards bodies, etc. as to coerce others into using their invention. A good analog is the SafetyPIN invention by Joe Zingher: enter your PIN backwards as a duress signal. To his credit, many times he offered to give the idea away, with no luck. It sounds like a good idea, it works on paper, and his intentions are honest. The problem is, it doesn’t do much help anyways (police response times are a joke in most major cities), it costs money even if the IP is free (implementation and testing is not cheap), and it takes additional user effort in a stressful situation.

We often look to the latest cutting-edge high-tech inventions to solve our security problems. Ironically, the magnetic strip itself was a “secure” medium until it became popularized, then the equipment was everywhere. Likewise, laminators were controlled through pricing and paperwork, then everyone had one, PVC card printers were hard to get for a while too. I imagine that the micro-hole system would be compromised as well. A similar system today is laser-personalized cards, currently considered the most secure system today. It allows for monochrome printing, raised text, even the clear micro-pores that I imagine is quite similar to the Citicorp invention. The thing is, lasers haven’t been “special” for a long time – and it’s only a matter of time before some hacker gets a used Epilog and modifies it to overlay data onto the lasercard.

New inventions in security are useful; simply because a new system is not perfect or uncompromisable doesn’t mean we shouldn’t adopt it, you can’t get away from the cat and mouse game. But new inventions typically don’t solve underlying problems.

@Geek Propher re: Kalman: Exactly my concern. There’s a good reason why cards have been embossed for a long, long, time. I hope that Chase does not discontinue the embossed numbers on my debit card. Only temporary and stored-value cards (and some student-ID-plus-payment combo cards) have the silly printed numbers, part of the reason is that the card is ELECTRONIC USE ONLY and they don’t want it to be usable for offline transactions. Having no embossed numbers makes me feel like some low-class Green Dot carrying member of the unbanked masses, not a customer of a classy traditional commercial bank.

By the way, those printed numbers probably aren’t secure. The raised version is a resin, a bit more resistant to certain organic solvents than the flat pigment-based one. I’ve had a piece of it flake off though, which makes me wonder if certain conditions cause the adhesion to fail. There’s a reason why it’s not being used.

@RH, Phillip: The smart phone can be made into and/or (preferably) contain a trusted display. I agree, having a trusted display is one of the things I advocate as part of an overall security overhaul for computing systems, including secure interfaces, trusted boot/initialization, onboard key storage, etc. I have also come to realized that separate hardware presents an adoption hurdle that is not readily accepted, even if paid for by someone else, unless the alternative is much worse. I draw upon the case of the American Express smart cards and the free card readers (both made by Gemplus), which turned out to be a huge flop. Other places have had more success with two-factor tokens, E*Trade has a SecurID deal with RSA, PayPal has Vasco and InCard(ICT) tokens through Verisign VIP, and Blizzard Entertainment has their own Vasco system for World of Warcraft (their WoW token is UGLY though). Penetration is still low. Even given the risk associated with account compromise and the time investment that many have put into their characters, I know high-level players who just don’t want the token because they’ll lose it, or won’t have it when they want to play.

I propose a Secure Mode feature for computing devices that uses an obvious indicator lamp to distinguish between a trusted application and a general-purpose application. There is prior art that reflects this usage for PIN keypads, also, research on the EV SSL green address bar reflects that consumers pick up quickly on security-assurance signals and notice if they are missing. A green glow around a handheld device (or for laptops, a green backlit keyboard) would appear whenever a trusted application is requesting input. This would be a hardware-controlled feature indicating execution path integrity leading to a curtained environment like Secure Desktop on recent releases of Windows. Only vendor-signed, code-vetted processes (such as login helpers) could receive input in this state. There isn’t so much a need for a trusted display as there is for a trusted execution path. If you can put a bank app on a phone, and can be reasonably sure that other userland applications can’t read its storage, then give the app a secret and you’ve got your secure device.

The biggest problem is when users lose their phone. This happened in the movie “Big Fat Liar”, and the results for the phone-loser weren’t pretty.