Project direction

Coordinator
Nov 28, 2011 at 3:21 PM

After a few years of slow improvement, I feel that it is time to get some feedback and see what's next for Thales simulator. During this period, we've tried to expand the simulator as best as we could. Sometimes we've been successful, others less so.

The main impediment that usually hampers our efforts is the lack of an actual HSM device that can help us sanity check our implementation in a consistent manner. Some times, we're lucky enough to have contributing members and project users with access to a physical HSM give up some of their free time to test our implementation and in that way they provide benefit to all users. Quite a few problems have been found and resolved in this way. However, this happy state of affairs doesn't happen often and the core problem remains.

As you may know, the simulator is written to mirror the behavior of an 8000-series HSM as closely as possible. We're slowly seeing an increasing number of users running software for the newer PayShield 9000 HSM. This is backwards compatible with the 8000, but changes that this project doesn't support are slowly introduced by the new HSM.

To be honest, we haven't got the big picture about what users find most useful in the simulator and what they miss most from the simulator. We've satisfied some requests in the past, mostly about implementing some command or other, but is that enough? Should we add support for more commands? Going forward, should we be compatible with the 9000 while retaining compatibility with the 8000? Should we migrate the code base to C# and VS 2010 - do users care about the implementation details anyway? Should we try to target mono more methodically to give users a chance to run the simulator in other non-Windows platforms other than Open SUSE as well? Is a user interface required or would users be happy with just a console view?

Under this light, I would be grateful if project users could share their ideas about how to best move forward with the simulator.

Dec 2, 2011 at 4:37 AM

1. RSA is also becoming more and more prevalent for both PIN Block encryption and, even moreso, Remote Key Loading to ATMs. It is only a matter of time before it will be a necessary feature. Even now Remote Key Loading is becoming a compliance requirement in some countries. I suspect you'll have your hands full for awhile implementing RSA. I believe implementing RSA functionality should be a short term to mid-term goal.

2. Through the grapevine I understand that the 8000 will be End-Of-Life'd soon (not end of support, but will no longer be sold). For the project to avoid falling into obscurity over time I would suggest that emulation of the PayShield HSMs (Thales 9000s) become a priority. I personally know of RG6000s that are still in production use even though they have been end of life for almost 20 years. This means that while 9000s will become dominant in the next 10 years, the 8000s will still be around for a long while. What I'm getting at is that you should start the 9000 support through a different 9000 operating mode and it's own set of command implementations where there are behavior differences between them. This way you can adequately simulate behavior of both models independently. Of course you could always simplify your own life and fork into two separate projects, one for 8000 and one for 9000.

3. Separate the server and the GUI. The server should run as a service so it can be used independently of the UI and therefore become more practical in multi-user or high availability environments. I would personally have great interest in this modification.

4. If you have access to documentation for version 3.0 or later of the RG8000 firmware, you know of some new features available on the 8000s including up to 4 distinct LMKs, and an entirely different mode of operating, Enhanced Key Block (ANSI TR-31).

5. AS2805 support for Australia. Thales has a firmware build for AS2805 that is a compliance requirement in Australia and possibly elsewhere. It is very much the same as what you're familiar with, but CBC is used when encrypting double length keys.

6. Low on the list because it is probably more work than it is worth, investigate the potential benefit of making your cryptographic calls FIPS 140-2 level 1 compliant by making use of something like the Crypto++ DLLs (www.cryptopp.com). Combined with the above and storage of the LMK in something like a TrueCrypt volume or secure token (which would be implementation specific, not necessarily built into your code) this simulator could find conceivably its way into limited production systems like processing for gift cards. I'm no VB developer so I honestly have no idea if it can be accomplished.

Coordinator
Dec 2, 2011 at 2:36 PM

Interesting thought, I certainly appreciate the feedback.

I would never expect #3 but it's certainly doable. If this is implemented, it could be done with a fat client or a web-based GUI. Your thoughts about that?

I gather that you have more experience on fielding HSMs than myself, and that's the reason I was surprised by #6. Would you go for such an implementation in a production environment? Even if you can secure the LMKs using a secure token, the software part can still be manipulated/hacked to oblivion.