ABSTRACT :

This whitepaper reinforce to conglomerate protected key , secure guest and encrypted disk .This solely focuses the implementation Of pervasive encryption in a secure encryption .To secure data with a certain doctrine of encryption is under obligation to adhere  end to end journey from os on IBM Z mainframe and beyond . This document  provision the in-depth probing of  data protection , key related inquisition and comprehensive analysis of disks and guests in IBM Z Lpar . We are performing the overall operation on zKVM guests . In IBM's virtualization environment, a "zKVM guest" refers to a virtual machine that runs as a guest operating system within an IBM  zKVM hypervisor . 

DATA AT REST IS DATA AT RISK :

"Data at rest" refers to data stored in a non-volatile state, and is not actively being transmitted or used. Data can’t be jeopardised ;It faces the risk of discovery or exposure by a malicious party. Protecting data at rest is  indispensable  for maintaining data confidentiality , integrity and availability .Data at rest is prone to cyber-attacks , data can be under severe threat if storage is compromised .

In this white paper we will acquaint with  the end to end encryption in a secure guest .

In Linux, the most popular method for end-to-end data at-rest encryption is full volume encryption using the dm-crypt kernel component. dm-crypt reads encrypted sectors from a block device (disk, partition, or logical volume), decrypts the data in the sector, and writes it to the reading component.

The challenge is to manage the cryptographic keys needed to open an encrypted volume:

• How can these keys be stored securely?
• How can these keys be protected from being discovered while they are in use?
• How can these keys be protected from being stolen by an intruder?
• How can these keys be protected from discovery by a service engineer that analyses a system dump? 

 To manage the challenge of storing cryptographic keys and associating these keys with the volume they encrypt, the Linux cryptsetup utility applies the Linux Unified Key Setup (LUKS) volume format. This format provides protection by passphrases and stores passphrase-protected volume keys in the header of the volume. The cryptsetup utility uses LUKS to store information (for example about the used cipher and the volume key) for setting up and configuring dm-crypt. On opening a LUKS formatted volume, a passphrase is required. This might be a valid procedure for personnel computers and laptops, but is not a viable solution to manage a server farm with hundreds of volumes.

The motivation of protected volume encryption is to provide end-to-end encryption of data at-rest in a way that the keys needed to decrypt or encrypt your data are inherently secure. That means that the keys must be masqueraded by objects that cannot be used as keys outside of your system.

         Fig: Diagram for pervasive disk encryption

IBM SECURE EXECUTION :

 IBM Secure Execution for Linux is a continuation and expansion of well-known security features of IBM Z . It supplements pervasive encryption, which protects data at-rest and data in-flight, to also protect data in-use. With IBM Secure Execution for Linux, it is possible to securely deploy workloads in the cloud. The data of the workload can be protected everywhereone of the benefits of IBM Secure Execution for a secure guest is that the workload owner can securely pass secret information to the ultra visor, which is used to process the secret information, and only the workload owner can access the data.

The below section provides command references for pvapconfig, pvattest, pvextract-hdr, secure Execution and pvsecret.

                          Figure: IBM Secure Execution protects guest memory and state

KVM guests that run in IBM Secure Execution mode on IBM z16 with firmware bundle S30 can use Crypto Express domains. 

. A maximum of 12 AP queues per secure guest can be configured.

A secure Execution guest can now use crypto express adapters in EP11 or accelerator mode but not with CCA .

Feature details :

A Secure Execution guest can now use Crypto Express adapters in EP11 or accelerator mode. To protect secure keys, secure keys can be bound to an association secret maintained by the ultra-visor on behalf of the secure guest. Therefore, you can now insert secrets. To provide structured and enhanced security.

Each AP queue must be bound to and associated with an association key .

Prerequisites : 

You need a secure-execution boot image that supports the insertion of secrets into the ultra visor.

The need of appropriate firmware bundles is a must without it , it’s not feasible to facilitate the functionality , Secure AP passthrough after  z16  firmware bundle 31b or later.

We use KVM host as trusted host .

Encryption of kvm guest using protected key :

Encrypted disks on a secure KVM guests using a protected key. we will be concerned about the guest based encryption. The unencrypted disk is attached to the guest and encrypted on the guest. A separate crypto adapter/domain must be attached to each guest as a mediated device. Guest-based encryption requires them all to be assigned as mediated devices.

The protected key device driver provides functions for generating and verifying protected keys.

Protected keys are encrypted with wrapping keys that, for Linux in LPAR mode, are specific to the LPAR. For guests of  KVM, the wrapping key is specific to the guest. Both the wrapping keys and the clear key values of protected keys are invisible to the operating system. Protected keys are designed for accelerated encryption and decryption with CPACF.

The following secure key functions require a Crypto Express adapter:

·       Generate a secure key from random data, then generate a protected key from the secure key.

·       The secure key must be available to create a new version of the protected key whenever the current protected key is invalidated.

·       Generate a secure key from a clear key, then generate a protected key from the secure key.The clear key must be in memory when the protected key is generated. Thereafter, the clear key can be deleted.

·       The secure key must be available to create a new version of the protected key whenever the current protected key is invalidated.

The following functions do not require a Crypto Express adapter: 

·       Generate a protected key from a clear key. The clear key must be in memory when the protected key is generated. 

The clear key must also be available to create a new protected key if the existing protected key is invalidated.

·       Generate a protected AES key from random data. The effective clear key is never exposed in memory.

Functional steps :

Set up a crypto adapter with an association secret on a secure KVM guest, and added a "protected disk" (aka Pervasive Encryption Data Volume).

These actions are performed on the KVM guests:

1. On a secure KVM guest, attach at least one crypto adapter/domain

2. Set up the association secret:

  a. Create an association secret and add it to the guest (pvsecret create, pvsecret add)

  b. Verify with `lszcrypt -V` that the crypto adapter is "SESTAT: usable"

Then, add a protected disk:

3. Attach a LUN (not the "root" disk) to the guest

4. Configure the LUN as a protected disk (as documented in https://www.ibm.com/docs/en/linux-on-systems?topic=encryption-pervasive-data-volumes):

  a. Create zkey: zkey generate --name key1 --keybits 256 --xts --apqns {{ crypto_adapter_id }}.{{ crypto_domain_id }} --volumes {{ lun_device }}:enc-disk1 --volume-type LUKS2 --key-type {{ zkey_type }}

  b. Format disk in LUKS2 format and add key to LUKS header: zkey cryptsetup --volumes {{ lun_device }} --run

  c. Open encrypted disk and map to /dev/mapper/encdisk1: zkey cryptsetup --volumes {{ lun_device }} --open --run

  d. Create a keyfile to add to LUKS header: dd if=/dev/urandom of={{ luks_key_file }} bs=1024 count=4

  e. Add key slot to key file: cryptsetup luksAddKey --pbkdf pbkdf2 {{ lun_device }} {{ luks_key_file }}"

  f. Get line to add to /etc/crypttab: zkey crypttab --volumes {{ lun_device }} --key-file {{ luks_key_file }}

  g. Add to /etc/crypttab (example): enc-disk1       /dev/disk/by-path/ccw-0.0.0004                 /etc/luks_keys/disk1.key                Luks

  h. Create filesystem and mount the disk (ie "/protected_disk")

5. Reboot the guest. 

8.) Read the test file after reboot

Before these can run, a master key must be loaded into each crypto domain for each card that is online to the KVM host. This is a one-time task that can be performed using a TKE workstation .

Limitations :

* Encryption is only supported on block devices, so qcow is not supported.

* Root volumes cannot be encrypted, so the boot disk can be either qcow or LUN.

* The Reboot does make the guest to go in a hung state .

Functional Usage :

This white paper does focus on achieving the  end to end encryption . Pervasive encryption is a system-wide solution .  Encryption is performed by dedicated cryptographic hardware . pervasive encryption requires significantly less effort for secured encryption, and it is more cost effective than traditional software encryption solutions.
With pervasive encryption, data is always secure. Applications and even operating system cannot access key which encrypt data.  Key is generating and encrypted by hardware. It safeguard the security .

References :

1.)

https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/ashish-vardhan/2024/07/31/kvm-secure-ap-passthrough?CommunityKey=9476eac0-4605-4c10-906d-01a95923ae0b

2.) 

https://www.ibm.com/docs/en/order-management-sw/10.0?topic=considerations-encrypting-data-partitions-using-luks