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).
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.
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.
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.
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.)
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.
“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.
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.
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.