Recovering encrypted volumes from an invalid secure key

Edit online

This recovery scenario is only possible if the clear key that was used to generate the secure key is still available in a binary file. This can be the case in environments where you intentionally want to save the clear key due to your security policy. Use this approach only if you kept your clear key absolutely safe in a clean room environment, where it is protected against being exposed to non-authorized persons. A secure key that contains an encrypted insecure clear key is of no added value compared to the insecure clear key.

Procedure

Generate a new secure key from a binary clear key input file on the new cryptographic coprocessor. Use the zkey generate command with option --clearkey.
Store the new secure key in the secure key repository.
To generate a secure key on a specific APQN, use option --apqns with the zkey generate command and specify the desired APQN. This is only possible when generating secure keys in the secure key repository. Also, you can already associate the affected volumes with the new secure key. For example, enter:
```
# zkey generate --name new_secure_xtskey --clearkey old_clearkey.bin \
                --key-type CCA-AESCIPHER --xts --apqns <card.domain> \
                --volumes /dev/mapper/disk<n>:enc-disk<n> \
                --volume-type LUKS2 --sector-size 4096
```
Because the new secure key contains the same old clear key, the volume needs not be re-encrypted, but the new created secure key must be set as the LUKS volume key.
Use the zkey-cryptsetup setkey command to set the new LUKS2 volume key.
For example, enter:
```
# zkey-cryptsetup setkey /dev/mapper/disk<n> \ 
--master-key-file /etc/zkey/repository/new_secure_xtskey.skey
Enter passphrase for '/dev/mapper/disk<n>': disk<n>pw
```
You can retrieve information about the secure key file using the zkey list command. To limit the returned list to the desired secure key, use option --name to specify the secure key name. You find the secure key file name indicated by: Key file name (see Listing AES secure keys contained in the secure key repository).

If you had set a verification pattern into the LUKS2 header of the volume using the zkey-cryptsetup setvp command, this pattern is used to ensure that the new volume key contains the same clear key. If no verification pattern is available, then you are prompted to confirm that the specified secure key is the correct one.
Important: If you set an incorrect secure key you will lose all the data on the encrypted volume.

For details see zkey-cryptsetup - Managing LUKS2 volume keys.
Reset the pbkdf option like follows:
```
          --pbkdf argon2i --pbkdf-memory 32 --pbkdf-force-iterations 4         
          or             
          --pbkdf pbkdf2          
        
```
This step is not required when using the zkey-cryptsetup tool from an s390-tools package upstream version 2.9.0 or later.

Setting a new LUKS2 volume key with zkey-cryptsetup sets the value of option pbkdf of the key slot with the interactive passphrase to the default Argon2i password-based key derivation function (PBKDF), no matter which value you had set before.

Using the Argon2i key derivation function without further options may cause an out-of-memory error when opening a LUKS2 volume. To avoid such an error during automatic unlocking of the encrypted volume at system startup, use the shown options or use --pbkdf pbkdf2. For more information, read Out-of-memory errors when opening a LUKS2 volume.
```
# cryptsetup luksConvertKey 
--pbkdf argon2i --pbkdf-memory 32 --pbkdf-force-iterations 4 \
/dev/mapper/disk<n>
Enter passphrase for keyslot to be converted:
disk<n>pw
 
```
Remove the old cryptographic coprocessor and start using the new one.
If you had stored the old secure key in the secure key repository, remove it now. For example, enter:
```
# zkey remove --name old_secure_xtskey
```
For details see Removing AES secure keys and Changing AES secure keys.

Results

Your affected volumes are ready for use, exploiting the new cryptographic coprocessor.