Infrastructure concepts
You can exploit the infrastructure for protected volume encryption for transparently encrypting and decrypting Linux® block devices using secure and protected keys. For Linux on Z, block devices can be, for example, partitions of ECKD disks (also referred to as DASDs), SCSI disks or partitions, logical volumes, NVMe volumes, loopback devices, or network block devices.
The infrastructure for protected volume encryption makes use of both secure keys and protected keys:
- Secure keys are processed in a Crypto Express cryptographic coprocessor configured in CCA mode (shortly referred to as CCA coprocessor) or configured in EP11 mode (EP11 coprocessor). Secure keys are persistent key objects that can be safely stored on unprotected media, because they are protected by a FIPS 140-2 Level 4 certified hardware security module. Using these keys requires access to a domain of a CCA or EP11 coprocessor where a specific AES master key is activated.
- Protected keys are volatile keys encrypted by the IBM® firmware master key of an LPAR or a virtual machine.
They are created by a specific instance of an LPAR or a z/VM® guest and can only be used by the instance of the
operating system that created the protected key. Also, they are only valid as long as the LPAR or
the virtual machine that generated the key is running. The operating system has no access to the
plain values of protected keys, and protected keys are useless on any other system.
Protected keys support high performance AES cryptography using the acceleration of cryptographic operations provided by the IBM Z® Central Processor Assist for Cryptographic Functions (CPACF), which is implemented in the IBM Z CPUs.
In the infrastructure for protected volume encryption, a protected key can securely be derived from a secure key using a CCA or EP11 coprocessor. The coprocessor and the IBM Z mainframe then cooperate to perform the required re-wrapping operation.
Therefore neither secure nor protected keys are of any use outside their system. Even if stolen, they cannot be used to decipher data stored in the storage system or in transit through the SAN from a system owned by adversary persons.
The secure key, which is stored on the volume (for example, in the LUKS2 header) is actually the effective key wrapped by the tamper-proof master key of the domain. When the volume contents need to be accessed, the secure key is unwrapped from the master key by the cryptographic coprocessor to obtain the effective key. The effective key is passed through a secure channel to the CPACF where it is re-wrapped by a temporary firmware master key specific to the LPAR or virtual guest. This re-wrapped key is called the protected key. The effective key inside the protected key cannot be discovered by the operating system. The effective key is unwrapped from the protected key inside the CPACF and used in cryptographic functions performed by the CPACF whenever the Linux kernel (dm-crypt) reads and writes data to the disk volumes.
The infrastructure for protected volume encryption consists of the following components:
- The IBM Z cryptographic
hardware:
- Crypto Express cryptographic coprocessors configured as CCA coprocessors or as EP11 coprocessors.
- CPACF
- The Linux kernel with:
- The paes_s390 module supporting protected key AES cryptography (also called the PAES cipher)
- The pkey module for generating secure keys and deriving protected keys from secure keys
- dm-crypt, preferably supporting LUKS2
- The Linux cryptsetup utility managing the LUKS on-disk format for volumes, preferably supporting LUKS2, to store cryptographic information to set up and configure dm-crypt. Such volumes are referred to as dm-crypt volumes in this documentation.
- The zkey and the zkey-cryptsetup utilities from the s390-tools package to generate and manage secure keys.
Figure 2 illustrates the setup of the infrastructure for protected volume encryption. It presents a view on the installed Linux components and shows how they cooperate to implement the functionality of the infrastructure for protected volume encryption with an end-to-end encryption of volumes. An end user can transparently encrypt or decrypt the data of an application without any further interaction.
This document mainly explains how to set up and manage dm-crypt volumes encrypted with the PAES cipher using the LUKS2 format. Alternatively, it is possible to use the plain format together with the PAES cipher. This is described in Encrypting volumes without LUKS.
The IBM Z cryptographic hardware
The concepts and features of the infrastructure for protected volume encryption solely work within the IBM Z cryptographic hardware environment. This environment is a combination of hardware components and processing infrastructures that provide a rich array of cryptographic capabilities and functions. Among these, especially the functions for encrypting or decrypting data and for managing keys are exploited by the infrastructure for protected volume encryption.
The core hardware component of the IBM Z cryptographic hardware environment are devices that are called cryptographic coprocessors. Sometimes you can read the synonymous terms cryptographic adapter or cryptographic card.
An IBM Z cryptographic hardware environment can consist of several cryptographic coprocessors. For the infrastructure for protected volume encryption, use at least two of them to provide the reliability that is expected from an IBM Z mainframe. Crypto Express cryptographic coprocessors are partitioned into multiple domains, where each of the domains maintains a domain-specific master key.
To access and securely manage multiple cryptographic coprocessors with their domains and master keys, you require a Trusted Key Entry workstation (TKE) providing the following features:
- Loading and maintaining master keys and operational keys into the cryptographic coprocessor.
- Providing a cryptographic hardware migration feature. The TKE allows you to collect data from one cryptographic coprocessor and apply the data to another coprocessor.
A TKE comprises the following components:
- The hardware: a workstation with a cryptographic coprocessor
- Smart card readers and smart cards.
The TKE version is closely associated with the host platforms that it supports.
The PAES cipher
The PAES cipher is used by the infrastructure for protected volume encryption to enable the utilization of a protected key for the AES algorithm. The PAES cipher converts a secure key into a protected key for enhanced performance using the pkey module.
For more information, see Cipher mode considerations.
cryptsetup
The Linux cryptsetup open source utility allows you to manage dm-crypt volumes. In particular it supports formatting volumes with LUKS1 or LUKS2 and also supports managing formatted dm-crypt volumes.
LUKS (LUKS1 and LUKS2)
LUKS stands for Linux Unified Key Setup. By providing a standard on-disk-format, it does not only facilitate compatibility among distributions, but also provides secure management of multiple user passphrases. LUKS stores all necessary setup information in the volume header, enabling users to transport or migrate their data seamlessly. The LUKS volume encryption key (LVEK), which is the key with which the volume is encrypted, is also stored as part of the header. Of course, the LVEK is not stored in clear, but is encrypted by a key derived from a user's passphrase.
A LUKS header contains multiple key slots. Each key slot can contain the LVEK encrypted by a user passphrase. The user must enter the correct passphrase to open the key slot. Alternatively, a key file that contains the passphrase can be used for an unattended opening of a key slot (for example, at Linux startup).
The cryptsetup utility manages the LUKS header and requests the passphrase to decrypt the LVEK and to create a logical device using the dm-crypt device mapper target.
LUKS2 is a new header format introduced with cryptsetup version 2.0. It covers all possibilities of the previous LUKS version (LUKS1) and additionally provides various extensions.
To format a device with a LUKS2 header, use cryptsetup together with the luksFormat subcommand and the LUKS2–type option as shown in Creating a volume for pervasive encryption. When opening an encrypted volume, the LUKS format is automatically recognized.
For more information about LUKS, read the following documentation:
LUKS1 On-Disk Format SpecificationLUKS2 On-Disk Format Specification