All Your HSM-management Are Belong To Us!

The other day I've been using SoftHSM to test a few simple PKCS#11 functions written in C code and decided to containerise the HSM simulator so I can pull and use them anytime across any of my kubernetes environments.

I'd much prefer to automate, centralise and make all operations re-usable as much as I can, to save my own precious time for another day.

One of the major benefits of Fortanix Self-Defending KMS is the ability to provide native Load Balancing, High Availability and Self-Healing capabilities through a webscale clustered architecture. Policy-based management of keys and cryptographic services are in-built into the software and can be extended beyond to systems provided outside of Fortanix eco-system as well. They call this the "HSM Gateway" feature and it was originally featured on one of the webinars presented months ago: https://fortanix.com/blog/2020/04/modernizing-your-hsms/

https://fortanix.com/blog/2020/04/modernizing-your-hsms/

The idea is relatively simple: if a non-Fortanix HSM can be accessed by PKCS#11, then it can be managed by Fortanix Self-Defending KMS using the HSM Gateway feature.

So I decided to put this to test!

---

According to the support matrix, SoftHSM is not a supported HSM for Fortanix Self-Defending KMS HSM Gateway (and understandable). That being said, Vishal Gupta (who is a Principal Product Manager at Fortanix) mentioned that since all comms are via PKCS#11, it should work as long as the standard PKCS#11 functions are available.

I decided to install the HSM Gateway binary on the same container where SoftHSM was already installed (so I save time).

First, get the link to the download (https://support.fortanix.com/hc/en-us/articles/360051330351-HSM-Gateway):

I opted for the DEB package since I'm using an Ubuntu container for my SoftHSM (tutorial on how to setup SoftHSM is here: https://www.cooltym.com/post/pkcs-11-test-with-softhsm). Downloading the package and installing the package was relatively simple:

# wget <link to download>

# dpkg -i <package name>.deb

Upon installing the HSM Gateway, I now need to start the HSM Gateway daemon. But before that, I need to setup the configuration parameters first. There are couple of ways to do this.

Setup the /etc/default/ftx-hmg file. The most important ones are:

# This file contains configuration for the Fortanix HMG service

# Path to the pkcs12 cert. This provides TLS communication with Self-Defending KMS
CERT_FILE=/etc/fortanix/pki/cert.p12

# The network port for the HMG to listen on. Default is 4442
HMG_LISTEN_PORT=4442

# The location to the PKCS11 Library for SoftHSM
PKCS11_LIB_PATH=<path_to_libsofthsm2.so>

Or set as a environment variable:

# export PKCS11_LIB_PATH=<path_to_libsofthsm2.so>
# export CERT_FILE=/etc/fortanix/pki/cert.p12
# export HMG_LISTEN_PORT=4442

Then, start the HSM Gateway service:

# /opt/fortanix/bin/hmg-start.sh
Started HMG on port 4442

Now we're ready to manage the SoftHSM via HSM Gateway. Jumping back to the Self-Defending KMS UI, I created a new group and selected to link with an external HSM (Fortanix have kindly advised CloudHSM should work with SoftHSM for this test):

Copy or upload your CA Certificate for the HSM Gateway and also fill out the IP address, Port, Slot number and also the PIN for the HSM Gateway and the SoftHSM:

Yipee! We're connected!

Save the group and click Sync Keys. You'll now see some new key added:

Browsing through the Security Objects, I now find exactly 3 x keys were added as virtual keys from my SoftHSM:

And even when I do check via pkcs11-tools, I can find them as well:

# pkcs11-tool --module /usr/local/lib/softhsm/libsofthsm2.so -L -p 1234 -O | grep -i label
Using slot 0 with a present token (0x5c861143)
  token label        : Test Token
  label:      Test GJ Key
  label:      Test RSA Key
  label:      frank-test-key
  label:      Test RSA Key

Duplicate of Test RSA Key due to the public/private key in PKCS#11, so all good.

So far during my tests:

• Creating keys via Self-Defending KMS on the SoftHSM works out of the box

• Rotating keys via Self-Defending KMS for keys on the SoftHSM works

• Deactivating keys via Self-Defending KMS for keys on the SoftHSM works as well

Curious to see if anyone has any other test cases I can try, but what was promoted as a consolidated external HSM management seemed quite easy to deploy.

Let me know if you'd like me to test more!