Today, Finextra (a financial technology news website), has published a video interview with me, discussing my research on banks using card readers for online banking, which was recently featured on TV.
In this interview, I discuss some of the more technical aspects of the attacks on card readers, including the one demonstrated on TV (which requires compromising a Chip & PIN terminal), as well as others which instead require that the victim’s PC be compromised, but which can be carried out on a larger scale.
I also compare the approaches taken by the banking community to protocol design, with that of the Internet community. Financial organizations typically develop protocols internally, and so are subject to public scrutiny late in deployment, if at all. This is in contrast with Internet protocols which are commonly first discussed within industry and academia, then the specification is made public, and only then is it implemented. As a consequence, vulnerabilities in banking security systems are often more expensive to fix.
Also, I discuss some of the non-technical design decisions involved in the deployment of security technology. Specifically, their design needs to take into account risk analysis, psychology and usability, not just cryptography. Organizational structures also need to incentivize security; groups who design security mechanisms should be responsible for failure. Organizational structures should also discourage knowledge of security failings from being hidden from management. If necessary a separate penetration testing team should report directly to board level.
Finally I mention one good design principle for security protocols: “make everything as simple as possible, but not simpler”.
The video (7 minutes) can be found below, and is also on the Finextra website.
I like your comment on “simplicity”. That’s spot-on. In the protocol design, people often like to make it unnecessarily complex as they think a complex protocol looks more impressive. But complexity invites all sorts of attacks.
Nice work (and also Kudos to Saar), though I’m not less sure whether there are still banks willing to issue new cards with the name “S.J. Murdoch” on 🙂
Nice work Steven! Just one comment on the standardization of Internet protocols. You seem to suggest that there is always a specification before a protocol is implemented. In the IETF this is often the other way around. There exist public implementations of the protocol (“running code”) based on drafts even before the specification (the RFC) is made public. So experience with actual implementations feeds back into the standardisation process.
@Sebastian
You are of course correct. What I was more thinking of is that there generally is a public RFC before widespread deployment of the protocol it implements.
I think the idea of “running code” is a very good one, and I’d prefer if the IETF were even more strict about requiring multiple independent interoperable implementations than they currently are.
Not only is this good for improving the robustness of the protocol and clarity of the specification, it also encourages simplification. If the protocol designers need to build what they specify, unnecessary complication and risky corner-cases can be eliminated at an early stage.
Steve,
Your face is getting seen all over the place, you’ll be doing adverts next 😉
Protocols with public or private scrutiny do fail for a variety of reasons.
Unfortunatly a lot are designed on the backs of other protocols either for compatability or because the desigers patchwork their protocol together from other protocols.
As has recently been seen with TLS/SSL even longstanding protocols fail when used in a way that the original designers did not envisage.
Which was why I was surprised not to see “fault analysis” up on your list.
One of the reasons Chip-n-Spin got bad press (deservadly so) was the way the protocol fell back to mag stripe.
Arguably it was done for “customer conveniance”, which is the reason a lot of other security protocols fail (think expensive hotels where there is little or no checking when a person claims to be locked out of their room).
I expect to see a large number of privately developed protocols to fail to the desire for “conveniance” in a business not technicaly driven arena.