0

We are implementing safety-critical system, where the FIPS 140-2 compliant HSM (hardware security module) is required to generate and store key material, perform encryption/decryption and run custom code with the following requirements set for the custom module:

  • Module is available over RPC
  • Module has access to all HSM keys and services
  • Module has in-memory and persistent storage (1+ MB both)
  • Module memory is secured (FIPS 140-2 level 3+)

As for the HSM services itself, it is required to:

  • Support AES, RSA and HMAC
  • Has aliases for keys
  • Generate new keys with alias over the PKCS11 interface
  • Retrieve public key and certificate with alias over the PKCS11 interface
  • Delete keys with alias over the PKCS11 interface

As there is very little information available about HSM products due the NDA, it is very hard to evaluate the requirements and options. Are these requirement met by any standards, or by vendor specific solutions, such as Utimaco?

Tuomas Toivonen
  • 15,414
  • 22
  • 98
  • 170
  • 1
    Any reasonable general purpose HSM will meet the requirements. Question: when you are talking about 'module', are you talking about custom code running -on- the HSM? or are you talking about an application library that talks -to- the HSM? These are entirely different use cases. And as vlp says in hir answer, as soon as you load custom code into an HSM, you invalidate any FIPS 140-2 certificate the HSM has. If you need to run custom code, and be in FIPS 140-2 mode, you will need (at a minimum) to perform a delta certification. – rip... Oct 20 '18 at 19:33
  • 1
    Also, take anything I say with a grain of salt :) I train people to write custom code for the Utimaco line of general purpose HSMs (the SDK mentioned in vlp's answer). – rip... Oct 20 '18 at 19:35

1 Answers1

3

If you really need to run custom code inside the HSM device you have several choices across several vendors:

SafeNet ProtectServer (and SafeNet Luna Network/PCIe HSM since version 7.4)

SafeNet ProtectServer HSMs offer a unique level of flexibility for application developers to create their own firmware and execute it within the secure confines of the HSM. Known as functionality modules, the toolkits provide a comprehensive facility to develop and deploy custom firmware.

Thales nShield (CodeSafe)

Most nShield HSMs also support the unique ability to host critical applications within the hardened security boundary, so you can establish tamper-resistant business processes in addition to protecting cryptographic operations.

Utimaco CryptoServer (SDK)

The CryptoServer Software Development Kit (SDK) is the professional development environment for all Utimaco Hardware Security Modules. It enables integrators and end-users to create specific applications, e.g. proprietary algorithms, custom key derivation procedures or complex protocols that run in the tamper-proof environment of the CryptoServer Hardware Security Module. As the SDK provides full access to the Utimaco base firmware, custom firmware modules can be developed in a very short time frame.

My bet is that if you really need FIPS 140 certification you would need to certify your custom code running inside HSM as well (as such code is very powerful and can e.g. bypass access control, extract keys in plain text... -- thus it breaks any security assumptions easily).

Your requirements should be fulfillable by any of the products (even without running custom code inside the HSM -- it depends on the level of control your application needs).

Good luck!

Disclaimer: I am no crypto expert, so please do validate my thoughts.

vlp
  • 6,063
  • 2
  • 18
  • 44
  • "even without running custom code inside the HSM". Nope, this means the confidential data is would be exposed in plain text inside unprotected memory. The HSM basically decrypts, process and re-encrypts the data in-memory. – Tuomas Toivonen Oct 21 '18 at 05:44
  • @TuomasToivonen Ok, it depends on what exactly your process does. In simple cases you can combine [key derivation mechanisms](https://www.cryptsoft.com/pkcs11doc/v211/) to perform basic operations without the key material leaving the HSM (note that there are some issues regarding those key derivation methods, see e.g. [here](https://cryptosense.com/blog/the-untold-story-of-pkcs11-hsm-vulnerabilities/)). If your bandwidth is low you may consider using a smardcard (e.g. [Java Card](https://en.wikipedia.org/wiki/Java_Card)) as a cheaper solution...Good luck! – vlp Oct 21 '18 at 10:19
  • @TuomasToivonen Correct link for key derivation mechanisms is [here](https://www.cryptsoft.com/pkcs11doc/v211/group__SEC__12__41__MISCELLANEOUS__SIMPLE__KEY__DERIVATION__MECHANISMS.html)... – vlp Oct 21 '18 at 12:55