Yet more banking industry censorship

January 12th, 2013 at 17:03 UTC by Ross Anderson

Yesterday, banking security vendor Thales sent this DMCA takedown request to John Young who runs the excellent Cryptome archive. Thales want him to remove an equipment manual that has been online since 2003 and which was valuable raw material in research we did on API security.

Banks use hardware security modules (HSMs) to manage the cryptographic keys and PINs used to authenticate bank card transactions. These used to be thought to be secure. But their application programming interfaces (APIs) had become unmanageably complex, and in the early 2000s Mike Bond, Jolyon Clulow and I found that by sending sequences of commands to the machine that its designers hadn’t anticipated, it was often possible to break the device spectacularly. This became a thriving field of security research.

But while API security has been a goldmine for security researchers, it’s been an embarrassment for the industry, in which Thales is one of two dominant players. Hence the attempt to close down our mine. As you’d expect, the smaller firms in the industry, such as Utimaco, would prefer HSM APIs to be open (indeed, Utimaco sent two senior people to a Dagstuhl workshop on APIs that we held a couple of months ago). Even more ironically, Thales’s HSM business used to be the Cambridge startup nCipher, which helped our research by giving us samples of their competitors’ products to break.

If this case ever comes to court, the judge might perhaps consider the Lexmark case. Lexmark sued Static Control Components (SCC) for DMCA infringement in order to curtail competition. The court found this abusive and threw out the case. I am not a lawyer, and John Young must clearly take advice. However this particular case of internet censorship serves no public interest (as with previous attempts by the banking industry to censor security research).

Entry filed under: Banking security, Cryptology, Internet censorship, Legal issues, News coverage, Protocols, Security economics, Security engineering

8 comments Add your own

  • 1. fatbloke  |  January 12th, 2013 at 17:24 UTC

    It’s slightly disingenuous to say that this is “yet more banking industry censorship”. Lots of industries & organisations use HSMs, not just banks. This has very little to actually do with banking.

  • 2. K  |  January 13th, 2013 at 01:11 UTC

    Thales’s HSM business used to be the Cambridge startup nCipher

    It’s a bit more complicated than that. Before Thales bought nCipher, they already had their own line of HSMs and line encryptors and whatnot. The Zaxus (formerly Racal) 7000 is one of them.

    It intrigues me as to why they’re doing this now given the material has been online for so long.

  • 3. Mark Wooding  |  January 13th, 2013 at 01:23 UTC

    Finance HSMs are a rather different kind of thing from the HSMs used by certificate authorities, TLS accelerators or whatever. There’s an existing crazy mess of prescribed key roles and bits of cryptography made out of string, sellotape and single DES. The HSMs under discussion are ones which implement these unutterably grim standards.

    Just to lay the irony on a bit thicker, Thales has directly benefitted from this research because nCipher took careful note of its analysis when designing their own payments-processing system (`payShield’).

    I’m pretty sure the Thales HSMx000 range is a descendent of the old Racal modules rather than being based on payShield — but I never was very good at keeping track of other groups’ products.

  • 4. Martin Bonner  |  January 13th, 2013 at 10:15 UTC

    Mark is correct. The current Thales finance HSMs are called “Payshield” but they are based on the HSMs from Long Crendon, rather than the nCipher product.

    (Note that I’m sure that the current Thales HSMs have taken careful account of the research too. The problem is that everyone is trying to thread a path through a minefield formed by the standards.)

  • 5. Ian Harvey  |  January 14th, 2013 at 10:51 UTC

    Er, hasn’t it been established, by two extremely expensive teams of attack lawyers, that APIs themselves are not subject to copyright protection? In which case Thales can, at best, have their words describing that API replaced with someone else’s words describing that API.

  • 6. Leigh Honeywell  |  January 16th, 2013 at 17:07 UTC

    “It intrigues me as to why they’re doing this now given the material has been online for so long.”

    I bet they had a customer (who doesn’t understand the Streisand effect) complain about it.

  • 7. JAG  |  January 18th, 2013 at 17:10 UTC

    Interesting how many of the respondents to this thread are ex-nCipher…

    In any case I would point out for the readers that in the spirit of improvement back in the period mentioned in paragraph 3 we (nCipher, where I worked at the time but don’t anymore) provided our own products and internal APIs for the good folks of the research community too.

    Making no comment at all about the recent acts in question I wonder how well we can ‘version’ or date such resources as their number, age, and range of quality grows. These manuals are very old though and while the payments industry forces a lot of the conformity to these keyroles/interfaces they don’t represent the current generation of products which makes them much less valuable for either security research or openness (AKA emulation) purposes.

  • 8. Anonymous Coward  |  February 1st, 2013 at 16:15 UTC

    It’s not clear what “break the device spectacularly” means, particularly from a security standpoint.

    The current Thales payShield product can be made to lock up when doing heavy performance/load testing, for example, rapid TCP connections. It’s fairly clear that these devices are intended to run in a protected, “friendly” network environment. Fuzz testing might turn up some really interesting results.

    There are very few players in the current “payments HSM” market, and there seems to be little pressure to improve. The market seems ripe for real competition or a disruptive solution.

Leave a Comment

Required

Required, hidden

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


Calendar

January 2013
M T W T F S S
« Dec   Feb »
 123456
78910111213
14151617181920
21222324252627
28293031