Comments on: Yet more banking industry censorship

By: Anonymous Coward

Anonymous Coward — Fri, 01 Feb 2013 16:15:12 +0000

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.

By: JAG

JAG — Fri, 18 Jan 2013 17:10:21 +0000

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.

By: Leigh Honeywell

Leigh Honeywell — Wed, 16 Jan 2013 17:07:16 +0000

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

By: Ian Harvey

Ian Harvey — Mon, 14 Jan 2013 10:51:05 +0000

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.

By: Martin Bonner

Martin Bonner — Sun, 13 Jan 2013 10:15:41 +0000

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

By: Mark Wooding

Mark Wooding — Sun, 13 Jan 2013 01:23:34 +0000

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.

By: K

Sun, 13 Jan 2013 01:11:50 +0000

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.

By: fatbloke

fatbloke — Sat, 12 Jan 2013 17:24:47 +0000

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.