Interview with Steven Murdoch on Finextra
November 11th, 2009 at 16:07 UTC by Steven J. Murdoch
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.
Launch in external player (19 MB)
Entry filed under: Academic papers, Banking security, Hardware & signals, News coverage, Security engineering
4 comments Add your own
1. Feng Hao | November 11th, 2009 at 19:26 UTC
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
2. Sebastian | November 11th, 2009 at 23:41 UTC
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.
3. Steven J. Murdoch | November 12th, 2009 at 12:18 UTC
@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.
4. Clive Robinson | November 13th, 2009 at 14:08 UTC
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.
Leave a Comment
Some HTML allowed:<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Subscribe to the comments via RSS Feed