Review of HSM Alternatives

Melvin in the jPOS user Google Group asked about Hardware Security Module ("HSM") recommendations.  Here's my edited, updated reply which now includes an expanded list of viable options based upon feedback from jPOS super-user chhil...
---------
First, to narrow your selection set a bit:  don't even think about  asynch-connected (i.e., RS232-connected) models.  You want a box that uses TCP/IP connectivity (both for integration reasons as well as throughput reasons).

There are five good options for you:

• The Thales "HSM 8000" series (Thales bought Racal which is the brand name we're most familiar with in this industry).  See http://www.thales-esecurity.com/ProductsServices/HSM8000.shtml
  
  
• The IDS Key-Up II.  See http://www.keyup.biz/products.html
  
  
• The Atalla series of products (owned by H-P and generally  categorized with their "Non-Stop Computing" (i.e. Tandem) family of products).  See product description here.
  
  
• Jones Futurex - I don't have direct experience with this company, but they're on chhil's selection set list, which says a lot.  I do know from second-hand experience that MBNA is a customer, which also says quite a bit about Futurex's robustness and scalability (in our business, they don't come any bigger or mission-critical than MBNA).  The HSM product line is described here.

• Melvin in a follow-up asked about Eracom, and I added that they've been the dominant player in the Australian market for two+ decades, so the pedigree is certainly there.  [Note that in December 2005, SafeNet (a Maryland-based company) bought Eracom.]

I've been involved with jPOS-based products where we've successfully integrated the Key-Up for both Issuer and Acquirer functions.  We are in process of integrating the Thales HSM in an Acquirer role on another project.  I can't speak directly about the Atalla, but its track record in the industry speaks for itself.

The various features we've implemented are (presented in no particular order):

Perform "dynamic key exchange" with a Debit/EBT gateway (for you Thales/RACAL people out there, that means we can "accept a Zone PIN Key encrypted under a Zone Master Key and re-encrypt it under our Local Master Key").

Accept BDK-generated, DUKPT-enabled PIN blocks in "card set-up" requests and generate a "PIN offset" (which we store on our database encrypted under a PIN Key)  [BDK = Base Derivation Key; DUKPT = Dervived Unique Key Per Transaction]

We also have implemented PIN translation, in which we take the DUKPT-enabled PIN block from an incoming terminal request and use the HSM to provide a Triple DES-enabled PIN block using the current ZPK (as received and stored in 'a').

I've got two other pieces of advice, which are:

• Always ask your selected vendor for a field-by-field walkthrough of the commands you need to use.  First, because the vendor-provided books always consist of about 40 - 50 possible commands and you'll typically need about 3 of them.  So, you want to drill down on those and understand their nuances.  Second, because you'll hopefully get an experienced engineer on the call that will be able to cut to the chase for you.  You'll be fretting about some field and the guy/gal will tell you something like "you don't need to send anything beyond Field 9."
  

• Always insist on seeing trace examples.  These will be invaluable to you and will greatly elucidate points the spec tries to make.

Comments

[Marlon]

Hi,

We processed for encrypted values based on 3 ZCMK clear componants through our HSM. We unfortunaltely have lost one of the clear componants which is required to be enetered in another system. Is there anyway we could retrieve the clear value from the encrypted value??

[Andy Orrock]

No, there's no way to do that.

But I think you need to re-define your task: I believe you should be able to do some 'key transport' tasks to get the cryptogram from one environment to another (I'm assuming you're using the same vendor here as source and target - if not, you've got another level to your challenge).

For example, in the Thales environment, I think you should be able to:

1. Define a new 'key transport' key, i.e., define a new ZMK - specifically for this transport task - on the source and target boxes (I think the 'GG' command is used here on the Thales 8000).

2. Then export the 'problem' cryptogram using the transport key you created in Step 1 (command 'A8').

3. Import the cryptogram on the target box using the transport key (command 'A6').

Don't take any of that as the verbatim answer, but I think you should be thinking along those lines for your answer.

Note that you can even have different LMKs in play on the two boxes. [Obviously, were the same LMKs in play, you'd not face any challenge at all.]

[Todd Arnold]

You should also list the IBM HSMs, which have been sold since 1989. They are supported on all the IBM server platforms, including the System z mainframes where they are widely used in banking and payment systems - but also on System x (Windows and Linux), System p (AIX), and System i. The IBM HSMs are certified at FIPS 140 Level 4, one of the few that exist with this security rating.

[Todd Arnold]

I see that the URL I entered does not display in the post above, so here is the home page for the IBM HSMs: http://www.ibm.com/security/cryptocards. Questions can be sent to [email protected].

[Thomas Brandtstaetter]

Adding to Todd Arnold's posting, I want to add this link regarding SYNARGOS MX FINPIN Crypto-Servers (TCP/IP connected) based on IBM HSMs (i.e. IBM 4764-001).

http://www.synargos.com/web/index.php?id=38&L=9

This way, the choice for your application server OS and HW-plattform is widely open and the scalability of the MX FINPIN Crypto-Servers reduces HSM-costs, of course depending on your overall peak-load requirements in combination with the number of application servers in use.

As Todd Arnolds notes, IBM z mainframes support the same IBM HSMs.

Using the MX FINPIN Crypto-Servers based on IBM 4764 allows you to migrate to z mainframe at a later point in time, without major changes to your crypto-architecture and key-management infrastructure.

This growth-path scenario secures and re-uses your entry investments in crypto-components, -architecture and -know-how.

The MX FINPIN Crypto-Server system has been announced in 2000 based on the former IBM 4758, so it has been around for quite a while now. Early implementations of MX FINPIN, based on HSM IBM 4755, where launched back in 1994.

Commercial Switch and Authorisation Solutions like WINCOR PC/E (based on SUN / LINUX application servers) and eCMS (by dps-Engineering, which runs on z Mainframe) have integrated the MX FINPIN Crypto Server APIs in European Banking solutions in 2003/2004.

The MX FINPIN Crypto Server system complies to the German ZKA Banking standards, supports EMV Transactions, TDES, PIN-Formats and DUKPT.

In addition, MX RKL (Remote Key Load, alias SYNARGOS MX OPTimal) can be added to fulfill centralized key-distribution of EPPs based on the current German ZKA OPT standard. MX RKL supports the complete and secure lifecycle-managment of EPPs in a maximum-automated scenario.

Adding support for ANSI X9.24 initial TMK Load to MX RKL using asymmetric principles is in planning-phase for 3rd Q 2008.

In conjunction with IBM DKMS (Distributed Key Management), a Self-Service POS- oder ATM-Network secured with MX FINPIN and MX RKL achieves security requirements, complying to PCI-DSS objectives by far.

SYNARGOS has already sent general information on MX FINPIN to the JPOS team in 2007, who returned positive response.

SYNARGOS is currently aligning a channel-structure for international partners, who:

(A) intend to deploy the MX FINPIN as system-integrators in their corresponding home-country.

Hardware-supply can be be purchased locally, while MX FINPIN SW licences are provided by SYNARGOS. This way, MX FINPIN appliances can be totally controlled and certified according to the regulations of the local bodies and the end-customers IT-policies.

An additional advantage is the simplification of the import-settlement in general, as export and import of crypto-equipment is still accompanied by various bureaucratic processes.

(B) intend to purchase MX FINPIN Crypto Servers as road & ready appliances.

Here are some todos we currently work on:

1. Provide DEMO Integration SDK / APIs with HSM emulation, in order to enable integration tests at low-cost during development

2. Extend MX FINPIN product documentation (pre-sales and integration)

3. provide white paper on security concepts and guidelines, covering:
- overall integration scenarios
- key management principles and processes
- risk & security management topics according to ISO 27001 / PCI-DSS

4. Implement JAVA crypto-provider class for direct integration into JPOS

5. provide performance ratings / benchmarks

So much for today. In case of questions, please contact me directly at:

[email protected]

Kind regards,
Thomas Brandtstaetter
CEO

my current personal favorite in music: www.ericmongrain.com

[Kimberly]

Thank you very much for your rather informative article.

[mark neumann]

Does anyone have any experience with the HSM capabilities of the Sun 6000 Crypto Accelerator? It's considerably cheaper than the established players

[Nicholas Messaritis]

Hi,
I was reading all this about HSM and i have a question that is off the topic actually. What if i have develop an API that implements most of the HSM comamnds (build the command string that has to be send to the HSM), and i want to release it under GNU License. Is there any problem with that?
Regards

[sada]

hello,

How can we migrate ZPK from Eracom to Thales?

Regards