With OpenSSL 4.0.0 function X509_cmp_current_time() is deprecated and
should be replaced by X509_check_certificate_times().
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Normalize the man page source to UTF-8/US-ASCII and remove a mojibake
artifact that could not be represented cleanly.
Documentation only, no functional changes.
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Polensky <japo@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add kernel module phmac_s390 to the initramfs hook and dracut config file
to ensure that the PHMAC cipher is available during early boot, in case
the root disk is integrity protected via PHMAC.
Also load phmac_s390 via modules-load.d to ensure that the PHMAC ciphers
are available.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
In case the volume is integrity protected, and the integrity algorithm is
PHMAC, then the convert command also checks the integrity key part of the
volume key, and then uses the secure integrity key, and sets the
verification pattern to the verification-pattern token.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
In case the volume is integrity protected, and the integrity algorithm is
PHMAC, then the reencipher command also reenciphers the integrity key part
of the volume key.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
In case the volume is integrity protected, and the integrity algorithm is
PHMAC, then the setkey command also checks the integrity key part of the
volume key, and then sets the key into a new key slot, and sets the
verification pattern to the verification-pattern token.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
In case the volume is integrity protected, and the integrity algorithm is
PHMAC, then the setvp command also adds the verification pattern of the
integrity key into the token.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
In case the volume is integrity protected, and the integrity algorithm is
PHMAC, then also validate the integrity key and print its validation
status.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
In case the volume is integrity protected, and the integrity algorithm is
PHMAC, then the verification-pattern token as well as the reencipher-token
contain the verification pattern of the integrity key as well.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Use 'u8 *' instead of 'char *' for pointers to key blobs everywhere.
This saves a lot of casts.
The libcryptsetup API still uses 'char *' as pointer type for volume keys,
so a few casts are required when passing those pointers to libcryptsetup
API functions.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The commands 'zkey cryptsetup' generates commands for formatting and
opening volumes of type PLAIN and LUKS2.
For LUKS2, if there exists an HMAC key that is associated to the same
volume as the AES key, generate a 'cryptsetup luksFormat' command for
combined encryption and integrity protection. This uses the '--integrity'
and '--integrity-key-size' options of the 'cryptsetup luksFormat'
command to specify the integrity settings.
The volume key specified with '--master-key-file' must contain the
encryption key and the integrity key concatenated to each other. The
size of the volume key specified with '--key-size' however must be the
size of the encryption key only, in bits. The 'cryptsetup luksFormat'
command will internally read the whole file, use the first part as
encryption key, and the second part as integrity key. The size of the
second part must be specified with the '--integrity-key-size'.
Note: This requires 'wrapped integrity key' support in the cryptsetup
package, as well as in the dm-crypt kernel module.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The commands 'zkey integritytab' generates /etc/integritytab entries for
volumes of type INTEGRITY.
The 'zkey integritysetup' generates integritysetup commands for formatting
and opening volumes of type INTEGRITY.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The commands 'zkey crypttab' and 'zkey cryptsetup' should only operate on
AES-type keys, but not on HMAC keys.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
You can only set a sector size for an HMAC key of a volume of type
INTEGTRITY. For combined integrity protection with encryption, the
sector size of a LUKS2 volume must be set on the AES key, but can
not be set on the HMAC key.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
For combined integrity protected with encryption, a LUKS2 volume can be
associated to exactly one AES type key and also to exactly one HMAC type
key.
For other volume types, a volume can only be associated to exactly one
key, either an AES type key, or an HMAC type key.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Although HMAC keys can be associated to volumes of type 'LUKS2', the dummy
passphrase can only be set to AES-type keys, i.e. to keys that encrypt the
volume.
Reject trying to set a dummy passphrase for an HMAC key with a volume type
of 'LUKS2'.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Keys of type PVSECRET-HMAC can be associated to volumes of volume type
'INTEGTRITY' or 'LUKS2'.
Volumes of type 'INTEGTRITY' are set up for standalone dm-integrity via
the 'integritysetup' tool. Volumes of type 'LUKS2' are setup for combined
encryption and integrity using the 'cryptsetup' tool using the integrity
option.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Similar as for AES keys, a verification pattern is calculated from an HMAC
key by MACing an all zero message of 64 bytes. The first 32 bytes of the
result is the verification pattern.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add the definitions and utility functions for the PVSECRET-HMAC key type.
A PVSECRET-HMAC key token contains the secret id of a protected
virtualization secret. It does not contain the key material, just a
reference to the key in the ultravisor.
When such a key token is used to perform HMAC operations later on, the
PHMAC kernel cipher will obtain the protected key belonging to this secret
id with the help of the pkey kernel module.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
For supporting integrity protected volumes with dm-integrity,
cryptsetup of version 2.8.2 or later is required.
Make cryptsetup of version 2.8.2 a build requirement for zkey, not
only for zkey-cryptsetup. Although zkey could be built with an older
cryptsetup version, the commands that it generates might not work
with older cryptsetup versions.
This makes the compile switch HAVE_LUKS2_SUPPORT superfluous, since
cryptsetup v2.8.2 always includes LUKS2 support. Remove the ifdefs
from the code and update the man pages to not mention LUKS2 support.
Also, starting with cryptsetup version 2.5.0 the luksFormat command
accepts option '--volume-key-file' to specify the volume key file
instead of --master-key-file'. Thus, use '--volume-key-file' in
cryptsetup commands generated by zkey.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The key check value (KCV) is the first 3 bytes of the ENC-ZERO key
verification pattern of a key. ENC-ZERO encrypts an all zero block with
the key using AES-ECB and returns the result truncated to 3 bytes as
key check value.
Report the KCV of a KMS generated key as part of its label. This is
especially useful for AES-XTS keys, where the KCV is reported on each
of the 2 individual AES keys that an AES-XTS key is built of. It allows
users to compare the KCV displayed by zkey with the KCV displayed by
the key management system where the key was generated on. If the KCV
value is the same, then the key values are the same, too.
The key verification pattern reported by zkey is also an ENC-ZERO
key check value, but for AES-XTS keys it is built by encrypting
the all zero block with AES-XTS, which produces a KCV for the complete
AES-XTS key, but does not allow to check the individual key parts.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When registering a zkey client at the EKMFWeb server, validate the
certificate if it's public key matches with the identity key of
the zkey client.
Only allow registration when the certificate matches. This helps to
prevent users from erroneously registering a wrong or outdated
certificate for a zkey client.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
A KMS login may prompt the user for its credentials. Users may abort that
prompt by Cntl-C. Do not make any permanent changes to a key before the
KMS login, because those changes can not be undone when the user has
aborted during KMS login, leaving the key in a potentially inconsistent
state.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The variable filename was freed inside the loop and then incorrectly
used in the subsequent warnx() call. Replacing it with directory
reflects the indented context and avoids use after free.
Fixes: f25aaf32b8 ("zkey: Add support for key management system plugins")
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Polensky <japo@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Fix a potential compile error when symbol
EKMF_SUPPORTS_RSA_PSS_CERTIFICATES is defined. With this symbol support
for RSA-PSS can be enabled for the EKMFWeb plugin. Currently this symbol
is never defined.
Fixes: c570f51f5f ("zkey-ekmfweb: Generate certificate or CSR with identity key")
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Normally, secure keys generated by zkey are intentionally export
restricted. Export restricted keys can not be wrapped with a key
encrypting key (KEK).
However, keys that are generated inside a Secure Execution for Linux
guest that shall also be used outside of the Secure Execution for Linux
guest can only be transported to outside the Secure Execution for Linux
guest by wrapping them with a KEK and unwrapping them outside of the
Secure Execution for Linux guest. For that such keys must be exportable.
Add an option to generate and import exportable secure keys, which then
can be wrapped, and thus transported to outside of a Secure Execution for
Linux guest.
This applies to keys of type 'CCA-AESCIPHER' and 'EP11-AES'. Keys of type
'CCA-AESDATA' are always exportable, and can not be export restricted.
For keys of type 'EP11-AES' additionally allow to set the
'wrap-with-trusted' attribute. This restricts the key so that it only can
be wrapped with a trusted key encrypting key.
For keys of type 'EP11-AES' to be exportable, the access control point
(ACP) XCP_CPB_ALLOW_COMBINED_EXTRACT must be 'ON' on all APQNs used. This
access control point is only supported on newer EP11 firmware levels. If
the access control point is 'OFF' or not supported by the EP11 firmware,
then the IOCTL to generate the key fails with a generic error
(Input/output error - EIO). The zkey tool prints an appropriate error
message in that case.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Provide a dracut config file that ensures that the required drivers and
executables, as well as the zkey repository is included into the initramfs.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The zkey tool might be configured to use plugins. Include the plugins also
into the initramfs, otherwise zkey might not be usable at early boot time,
when it is configure to use a plugin.
Update the list of driver to include, pkey_sysfs does not exist, its built
into the pkey base driver.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Re-enciphering an EP11 secure key may fail with an error message like:
"zkey-cryptsetup: Failed to re-encipher the secure volume key for device
'<device>'"
or
"zkey: Failed to re-encipher '<key>' from CURRENT to NEW master key"
or similar.
The verbose messages show the following debug message:
"Command XCP_ADM_REENCRYPT failed. rc = 0x20"
This is due to uninitialized variables, which might cause the EP11 admin
request to contain garbage data, causing it to fail with CKR_DATA_INVALID
(0x20).
Fixes: 0be7efc956 ("zkey: Add support for re-enciphering EP11 secure keys")
Fixes: 4e2ebe0370 ("libseckey: Fix re-enciphering of EP11 secure key")
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Newer CCA versions might report the version string with CSUACFV or CSUACFQ
with keyword STATCCA using a different indicator character after the
version information. Ignore the indication character and the remaining
data entirely. Only the version information as such is of interest.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The 'convert' command converts a LUKS2 volume that uses a clear volume key
and the 'aes' cipher to use a secure volume key and the 'paes' cipher.
Optionally, the volume can use the integrity option with LUKS2 using a
clear key integrity key.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Jorg Schmidbauer <jschmidb@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Starting with cryptsetup version 2.5.0 the luksFormat command accepts
option '--volume-key-file' to specify the volume key file. Option
'--master-key-file' is still accepted as an alias to '--volume-key-file'.
Follow this pattern with the zkey-cryptsetup tool and also accept both
options '--volume-key-file' and '--master-key-file'. The short option
form stays '-m' for compatibility reasons (cryptsetup does not have a
short option for that).
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Jorg Schmidbauer <jschmidb@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Messages from libcryptsetup for logging level CRYPT_LOG_DEBUG
may or may not include an EOL, dependent on the cryptsetup version:
Between libcryptsetup version 2.1 and 2.2 debug messages do not
include an EOL character, but since 2.2 they do.
Append an EOL only if the message does not already end with EOL.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Jorg Schmidbauer <jschmidb@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Keys of type PVSECRET-AES can also be verified via the pkey IOCTL
PKEY_VERIFYKEY2, but the card and domain fields must be zero, because such
a key does not use a crypto card. Also XTS keys of type PVSRCRET-AES are
not represented by 2 concatenated keys but by just one key of type
PVSECRET-AES. Thus, special handling is required for XTS keys.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Jorg Schmidbauer <jschmidb@de.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Keys of type PVSECRET-AES can not be reenciphered using 'zkey reencipher'
or 'zkey-cryptsetup reencipher'. Reject that with a proper error message.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Jorg Schmidbauer <jschmidb@de.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Keys of type PVSECRET-AES can not be generated using 'zkey generate'.
Furthermore, APQNs can not be associated with keys of type PVSECRET-AES
via 'zkey change'. Reject that with a proper error message.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Jorg Schmidbauer <jschmidb@de.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
The 'pvsecrets import' command imports a protected virtualization secret
into the zkey key repository. Like other key import or key generation
commands, additional information can be associated with the imported key,
such as a textual description, the volume to encrypt with together with
the volume type, the sector size, and a dummy passphrase. You can not
associate a set of APQNs, since a protected virtualization secret does
not need or use a crypto card.
This command only works when running in a secure execution guest.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Jorg Schmidbauer <jschmidb@de.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Add the definitions and utility functions for the PVSECRETS-AES key type.
A PVSECRETS-AES key token contains the secret id of a protected
virtualization secret. It does not contain the key material, just a
reference to the key in the ultravisor.
When such a key token is used to perform crypto operations later on, the
PAES kernel cipher will obtain the protected key belonging to this secret
id with the help of the pkey kernel module.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Jorg Schmidbauer <jschmidb@de.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
The 'pvsecrets list' command lists the available protected virtualization
secrets. By default, only those pvsecret types are listed, that can be used
with zkey. If option '--all/-a' is specified, then all pvsecret types are
listed. Nevertheless, pvsecret types not supported by zkey can not be used
with zkey.
This command only works when running in a secure execution guest.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Jorg Schmidbauer <jschmidb@de.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Add functions to interface with the ultravisor device (/dev/uv) when
running in a secure execution guest to retrieve a list of available
secrets.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Jorg Schmidbauer <jschmidb@de.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
With the recent changes in the pkey kernel module to split it up into
sub-modules, as well as the addition to support Secure Execution
retrievable secrets, an update to the list of modules to copy to
initrd is required.
Besides the pkey module itself, all its sub-modules must be copied.
Furthermore, sub-module pkey_uv requires the uvdevice modules, so copy
this, too.
While at it, remove the old drivers zcrypt_cex2a and zcrypt_pcixcc,
those are not provided anymore since at least 2 years.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Acked-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Ensure that all hyphens in command options and examples are escaped properly.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
For LUKS2 volumes, zkey generates 'cryptsetup luksFormat' commands with
options '--pbkdf argon2i --pbkdf-memory 32 --pbkdf-force-iterations 4'
for low memory and time requirements. Using the default Argon2i options
might cause out-of-memory errors when multiple encrypted volumes are
unlocked automatically at boot through /etc/crypttab.
When the system runs in FIPS mode, which is indicated by file
/proc/sys/crypto/fips_enabled containing '1', the Argon2i password based
key derivation function might be disabled by a policy, and such
'cryptsetup luksFormat' commands might fail.
Generate '--pbkdf pbkdf2' instead if the system runs in FIPS mode.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
