Securing a workload in the cloud

IBM Secure Execution keys

Every IBM z15 or LinuxONE III server is equipped with a private host key that is specific to that server. The key is protected by hardware and firmware. The cloud provider cannot access or manipulate the private host key. Cloud providers who run their cloud on z15® or LinuxONE III obtain a host key document from IBM®. The host key document contains the public key associated with the private host key of that server. The cloud providers can distribute a host key document to cloud customers who want to run their workload in a z15 or LinuxONE III based cloud environment.

As a workload owner, you encrypt files that are necessary for booting by using the host key document of the cloud provider. The ultravisor uses the private host key, that is embedded in the hardware, to decrypt these files for the guest to boot in the cloud environment. These concepts are illustrated in Figure 1

Your application data is already encrypted, for example, with dm-crypt that uses LUKS volumes. This publication assumes that the data is encrypted with a symmetric key for faster encryption and decryption. The boot image that accesses the data needs access to the LUKS passphrase to use the data. Hence, you must copy the passphrase to the boot image.

IBM Secure Execution uses a cascade of encryption keys to ensure the security of the boot image. You only need to encrypt the data and use a command to secure the boot image. The cascade is shown in Figure 3, and explained in the following.

Verify the host key document

Verifying the host key document is essential to ensuring the chain of trust for your workload, as shown in Figure 2. The verification has two steps: first the host-key-signing-key certificate certificate must be verified using the CA certificate. If that was successful, you can verify the host key document with the public key from the successfully verified host-key-signing-key certificate certificate. Then you can be sure that the host key document is valid.

These steps are done automatically for you when using the genprotimg and pvattest commands.

Encrypt the boot image

The boot image consists of the kernel, the kernel parameters and the initial RAM file system. The initial RAM file system contains the initial secrets needed to access the system, such as credentials needed for disk or file system encryption, password hashes, or SSH certificates. It also contains secrets that allows the system to identify itself, such as private SSH keys.

The secure execution technology uses the efficient crypto acceleration of CPACF to encrypt the entire boot image. Because it is encrypted, a boot image can hold secrets of any size at any location. An encrypted boot image also hides the nature of the workload, thus minimizing the attack surface for crypto analysis.

The symmetric key that you used to encrypt your data volume would now be in the clear on the boot image. The boot image must also be encrypted with another symmetric key, the image encryption key. To run the image, this key must be included in the IBM Secure Execution header.

Because the initial RAM file system is protected, you can in general keep secrets there, such as workload-specific keys, or network traffic protection keys.

When you secure the image header, the command you use for securing, genprotimg, creates an image encryption key for you and copies it to the correct location in the IBM Secure Execution header. Optionally, you can provide your own key as an argument to the command.

Encrypt the IBM Secure Execution header

The image encryption key, in turn, is now in the clear on the IBM Secure Execution header. To protect it, use the host key document to encrypt the IBM Secure Execution header. The only environment that can now decrypt and run the IBM Secure Execution header is the trusted hardware.

Figure 3 shows a simplified view of the keys that are involved in all stages of securing the workload. The key used to encrypt the boot image can be automatically created and handled by the securing tool.