It seems that the majority of commercially available hardware HSMs are only designed to allow authenticated users to generate, store, and use cryptographic keys with various cryptographic algorithms implemented within the firmware of the HSM.

Reading the datasheets it looks like I can use the provided API to make my (external) application interact with the HSM and use its cryptographic muscles, maybe using keys generated/stored within the HSM. But, it seems that long term storage of the data/objects cryptographically processed by the HSM within the HSM boundary is not available.

Why aren’t there any HSMs that allow for user code and user data to be persistently stored and managed within the physically protected memory space of the HSM?

Does anybody have experience with HSMs and could point me towards a commercially available hardware HSM solution that at the least allows me to store some registers beyond cryptographic keys?

Ideally I would like my application to be stored at rest in the HSM boundary, executed by the same processor that runs the crypto provided by the HSM and to persisytently store a few registers within the HSM's protected area.


4 Answers 4


The Thales nShield HSM (previously nCipher) allow for generic programming. This is a rather expensive option; it must first be enabled in the HSM (through a "feature file" which is signed by Thales and specific to the serial number of a HSM), and then the extra code can run as long as it is signed with a key known to the HSM for such usage.

With that option, you will get a C compiler with a reduced C library, and some API which give access to the HSM features. The internal OS allows for one process (but multi-threaded) and cryptographic operations are done with transactions; there are also transactions to exchange arbitrary binary blobs with the external world (the host PC). The core CPU is not very powerful (think 60 MHz ARM or PowerPC) but there is some substantial RAM (megabytes, even dozens of megabytes).

Thales/nCipher HSM do not have a lot of permanent storage features (there are a few kilobytes of EEPROM but that's all). Actually, the HSM only stores a master key (which you cannot access), and everything, including the "keys" which are "in the HSM" are off-loaded, with encryption. You can do the same: store your data stored on the host, sent back to your internal module; the data is encrypted with one of the keys (which are virtually "in the HSM"), and your code in the HSM does the decryption.

  • 3
    Resources available for application development: • 16MB standard RAM, • 32 MB RAM for JVM development • 8 KB non-volatile RAM for secure user memory • Real-time clock
    – Drew Lex
    Commented Nov 28, 2012 at 0:36
  • Does anybody know the approximate cost for the development tools and HSM?
    – Drew Lex
    Commented Dec 6, 2012 at 22:07
  • 2
    Thales would probably be eager to respond to you, but the order of magnitude would be 10000$ (I am not entitled to give prices, but don't expect it to be as cheap as a PC, even a big one). Commented Dec 7, 2012 at 1:04
  • @ThomasPornin would there be any recommendations against using a (way cheaper) TPM and use its sealed storage feature? Commented Aug 21, 2014 at 13:49
  • Since you mention the prices, can you please give an educated estimate for the Luna, nShield/nCipher and the Luna Pin-Entry Device, according to current prices? Commented Jun 30, 2023 at 7:49

The Utimaco/Sophos HSM has got plenty of FLASH for internal storage of keys, which you can manage via (for instance) the PKCS#11 interface.

If you want to develop your own cryptographic algorithms or security protocols , there is also an SDK available. The CPU is a bit exotic (Texas Instruments DSP), but it is fully programmable in C and comes with a simulator. Code loading is simple and very well-thought through, with proper authentication and possibly code encryption.

Bonus point: certain models have partial support for FIPS 140-2 Level 4 (that is, active zeroization of root secrets in case of physical attack), if that sort of stuff makes your boat float. Of course, keep in mind that if you develop your own firmware, the FIPS certification is not valid anymore.

  • What was the price of the SDK, if you are aware of it? Also, why do you mention FIPS 140-2 Level 4 specifically and not also Level 3. Lastly, why "partial" Level 4 support and not "full" support? Commented Jun 30, 2023 at 8:04
  • CryptoServer CSe have FIPS 140-2 level 4 for physical security, level 3 overall. CryptoServer Se have FIPS 140-2 level 3. Both CSe and Se come in different performance envelopes (ie, "Se52" and "Se500" are both Se, but different speeds.
    – rip...
    Commented Jul 16, 2023 at 19:56

Most HSM's allow for using custom code, but in general you have to ask the specific vendor, it's not something that they advertise. Often it breaks certification. On the other hand, running applications that can e.g. validate the input can make for a much more secure experience. Generally these applications are sandboxed and need to be signed. Of course, if you are a big enough customer it's also possible to talk about customization by the vendor itself.

You should expect vendor specific API's and weird architectures.

There was a Java based HSM from SafeNet that was specifically targeting development of signed applications to run on the HSM, but I understood that it was discontinued (it was sufficiently expensive that I haven't even laid eyes on it).

  • What was the name of the HSM you mentioned. Commented Jun 30, 2023 at 7:54

SafeNet HSMs allow for the loading of custom code into the module. Depending on the requirements, there are different options available.

  • 1
    Mark, welcome to Information Security. If you have a commercial relationship with a vendor you are referring to, it is considered good form to disclose this relationship in your answer. See the FAQ...
    – AviD
    Commented May 30, 2013 at 9:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .