Cloud-based FIPS 140-2 Level 4 crypto service

Locks, keys, and data security

Yesterday, I got my hands on a FIPS 140-2 Level 4 cloud-based crypto service. If you are asking "what's that and what can I do with it?" you should continue to read. It is a dedicated HSM (Hardware Security Module) to manage encryption keys and offered as IBM Hyper Protect Crypto Services on IBM Cloud (HPCS). Here is what I learned while using the service.

Data Encryption and Key Management

In the past, I had already blogged about Key Protect as  cloud service to provision and manage encryption keys on IBM Cloud. The Key Protect service uses HSMs, too, and is "only" FIPS 140-2 Level 2 certified. Still, this is really a high degree of security, but the service - for cost reasons - is a multi-tenant offering. Key Protect allows you to bring your own key (BYOK) by importing root and standard keys. Hyper Protect Crypto Services goes one step further (and so you have to, too :) in that you need to initialize the HSM and load master key registers: Keep your own keys (KYOK). Master keys control the key storage within the service, the so-called "root of trust". Thus, you own and control the key management which makes some of the differences between FIPS 140-2 Level 2 and Level 4.

Initialize the root of trust

With Key Protect, a user provisions the service and thereafter can start to import or create keys. Hyper Protect Crypto Services is different. After provisioning the service, I had to step through the process of initializing and imprinting the service. Once I had created key parts and signatures for the administrator(s), I was ready to load the master key registers:

$ ibmcloud tke cryptounit-mk-load

KEYNUM   DESCRIPTION              VERIFICATION PATTERN  
1        Henrik - random part 1   d13c576731809f02a44826b31031b635  
                                  ab6473c25e12516dda31b78c745f635a  
2        Henrik - random part 2   09b8078dde9878ffdbdb3073ea13a850  
                                  92393f1ed8a15cfe383763c862646a14  

Enter the KEYNUM values of the master key parts you wish to load.
2 or 3 values must be specified, separated by spaces.
> 1 2
Enter the password for the current signature key file:
>
Enter the password for key file 1
>
Enter the password for key file 2
>
OK
The new master key register has been loaded in the selected crypto units.

NEW MASTER KEY REGISTER
SERVICE INSTANCE: 5c6c7dbe-33ab-4b80-b344-ef50b7b7cbda
CRYPTO UNIT NUM   STATUS             VERIFICATION PATTERN  
1                 Full Uncommitted   a79371d87e51dafff34b02e62d626a89  
                                     8a87e40d0fa926f74a34f905b471b6a5

As you may have spotted above, I needed to type in passwords for my signature file and for the individual key parts. Make sure to choose passwords wisely and to manage them in a smart way...

Thereafter, I needed to commit the new keys, then to activate them. Finally, I was the master of my own (kind of) FIPS 140-2 Level 4 certified crypto module. Because HPCS integrates with the Key Protect API and supports the Key Protect CLI for the key management tasks, once initialized, everything else was as usual. When I tested deleting my HPCS instance it was different again. First, I had to wipe the crypto module ("ibmcloud tke cryptounit-zeroize"), only then I could remove it. By wiping the keys, all encrypted data using any keys previsouly managed by the instance is rendered useless.

More resources

If you want to learn more about the deployed security module, take a look at the related NIST certification page and documents linked there. Or go to the IBM product page for IBM Systems cryptographic hardware products.


Was this post too cryptic...? If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik) or LinkedIn.