Encrypt your cloud data with your own keys for more security.

Whether as consumers or developers, most of us use cloud services. In this blog post, I look at the developer side of securing data stored in cloud services. By default (and following best practices), cloud service providers encrypt stored data (“data at rest“). Encryption is performed with system keys. I, as a developer, don’t need to set or enable anything for that baseline protection.

With some configuration and starting from that baseline, I can transform my cloud account into a highly secured environment. I can use my own keys for data encryption. For that, I can even tap into the concept of BYOK (bring your own key); in other words, importing keys that I generated somewhere else, like in an on-premises key management system (KMS). IBM Cloud even has two KMSs — the IBM Key Protect for IBM Cloud service provides FIPS 140-2 Level 3 security and IBM Cloud Hyper Protect Crypto Services is even a FIPS 140-2 Level 4 certified security service.

In the following, I give an overview of encrypting data with your own keys and where to find the long list of supported services. Thereafter, I show what it takes to add your keys, both for creating and rotating root keys:

Encrypt with your own keys

As a security best practice, all stored data should be encrypted; therefore, cloud providers encrypt all data at rest. By default, data is encrypted with system keys controlled by the cloud provider. To increase the security level, you should take control of the encryption keys. Typically, this is done by provisioning a key management system (KMS), creating your own root keys and configuring the data processing services to take your keys instead of the system root keys to encrypt the data.

IBM Cloud has two KMS offerings: IBM Key Protect for IBM Cloud and IBM Cloud Hyper Protect Crypto Services (HPCS). Both of them integrate with a long — but still growing list — of services (e.g., list of services for Key Protect, list of integrations for HPCS). The services have many similarities and even share the same CLI (command line interface) commands and API (Application Programming Interface), but they differ on the level of security. Key Protect is a KMS service on shared hardware (Hardware Security Module, HSM) whereas HPCS is a dedicated KMS and HSM offering. The result is different FIPS 140-2 certification levels (see above) and what the services provide: BYOK vs. KYOK.

In addition to generating new root keys in the KMS, you can import your own keys into that KMS. The KMS is backed by special tamper-proof hardware for performing cryptographic operations — the HSM. Before a HSM can be utilized, it needs to be initalized, the crypto unit imprinted, the master key loaded and the so-called root of trust established. For shared services like Key Protect, the cloud provider already has initialized the HSM and therefore owns the root of trust. Thus, as a user, you can bring your own key (BYOK), but you kind of hand it over to the cloud provider who manages the KMS.

To really keep your own key (KYOK), you need to control the HSM and initialize it. This can only be done when utilizing a dedicated HSM like, for example, IBM Cloud Hyper Protect Crypto Services. After provisioning the service, you or your crypto administrators have to perform the setup steps. As a result, you own the root of trust and, when importing your existing keys, can keep your own keys.

Securely import your keys

To utilize the BYOK/KYOK feature, you have to import your existing key (“key material”) when creating a key in the KMS. The actual transfer of that key material over the network, by default, is secured using the usual SSL/TLS encryption. That level of encryption might be ok for test environments and prototyping. For production systems, you should use an import token to protect your key material. The token is part of a cryptographic handshake protocol to both encrypt the key material and to make sure it originates from you. 

The process of securely importing a key involves a couple of steps:

• Generate the import token consisting of a public/private key pair
• Retrieve the public key and a nonce (i.e., a unique one-time passcode)
• Encrypt your key material with the retrieved public key
• Encrypt the retrieved nonce with your key (material) and create an initialization vector (IV)
• Upload everything (encrypted key material, encrypted nonce, IV) to create or rotate the key

All those steps can be performed with the IBM Cloud CLI and the Key Protect plugin. Because you love automation like I do, I created two scripts that put the above steps for either creating or rotating a key together. Check them out for details on how to encrypt the required parts for the handshake.

Conclusions

Data encryption is key to cloud security. As a user, you can take control of encryption by replacing system-generated keys with your own keys. Depending on your required level of security and, hence, the provisioned key management system, you can either bring your own keys or even keep your own keys. When doing so, make use of import tokens for highest security. There are few steps involved, but they are easy to follow. See my scripts in the GitHub repository cloud-key-security for details.

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