For secure keys of type CCA-AESCIPHER the CCA verb CSNBKTC2
(Key Token Change2) is used. CCA-AESDATA keys will continue
to use CCA verb CSNBKTC (Key Token Change).
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add support for validating secure keys using the new pkey
IOCTLs. This allows to validate secure keys of type CCA-AESDATA
as well as CCA-AESCIPHER.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add support for generating secure keys using the new pkey
IOCTLs. This allows to generate secure keys of type CCA-AESDATA
as well as CCA-AESCIPHER, either by random inside the crypto
card, or from a given clear key.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The new IOCTLs are based on list of APQNs that they try to send
the request to. Add some helper functions to build such lists
of APQNs based on the key type, and optionally a given mkvp.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
By default the new pkey IOCTL are used. In case the pkey device does not
support the new IOCTLs (i.e. errno ENOTTY is returned), then the wrapper
falls back to the old IOCTLs. The old IOCTLs only support secure keys of
type CCA-AESDATA.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add definitions and helper functions to support the new
CCA-AESCIPHER key type. Also enhance existing helper functions
to support CCA-AESCIPHER keys.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Introduce helper functions and definitions to allow key type
independent code in the keystore implementation
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The zkey generate command allows to specify the --key-type|-K
option to specify the key type. If not specified, then the
default is CCA-AESDATA.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The zkey list command now accepts option --key-type|-K type
to filter the displayed keys by key type. If not specified,
then all key types are displayed.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
For the 'zkey list', 'zkey validate' and 'zkey-cryptsetup validate'
commands, display the key type.
As of today there is only one possible key type (CCA-AESDATA),
but in the future there might be additional key types.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
To allow better control about the secure AES volume key re-enciphering
with 'zkey-cryptsetup reencipher', add options '--to-new' and '--from-old'
to specify if a re-enciphering from CURRENT to NEW, or OLD to CURRENT master
key registers is to be performed. If these options are not specified, then
it is auto-detected, based on the master key that the secure key is currently
re-enciphered with.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When re-enciphering secure AES keys, select the correct APQN for used
with the CCA host library. Re-enciphering a secure key requires the use
of the CCA host library. The APQN is selected based on the master key
verification pattern obtained from the secure key to re-encipher.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add a utility function to select an APQN that is set up with
a specific master key for use with the CCA host library. The
selection is based on the master key verification pattern, which
is typically obtained from an existing secure AES key.
The function iterates over a set of APQNs to find one that is setup
with the desired master key in the CURRENT or OLD master key register,
and optionally has a new master key loaded. It then selects the found
APQN for use with the CCA host library.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Some operations require the CCA host library to be used, such as
re-enciphering a secure key. The CCA host library uses a different
approach to select the APQN it operates with. To ensure that the
desired APQN is used for an operation, a utility function is added
to select a specific APQN for usage with the CCA host library.
The CCA host library allows to set environment variables to override
the default CCA APQN selection. The environment variables are inspected
during CCA host library initialization only. To select a specific
domain for CCA, the CSU_DEFAULT_DOMAIN environment variable is set,
and then the CCA host library is un-loaded and re-loaded again.
Furthermore, the 'Cryptographic Resource Allocate' verb of the CCA
host library is used together with the 'Cryptographic Facility Query
function' verb to iterate over the crypto cards known by the CCA host
library, and to identify the desired crypto card based on its serial
number. That way, a specific APQN can be selected for use with
subsequent CCA verbs.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Perform a cross check of the APQNs when the APQN association of a
secure AES key in the key repository is changed. When adding new APQNs,
or associating a new set of APQNs to a secure key, then the APQNs are
cross checked. If all associated APQNs are removed, then all currently
available APQNs are cross checked. If a master key mismatch is detected,
then the change is rejected.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Perform a cross check of the APQNs when an existing secure AES key is
imported into the key repository. When a set of APQNs are associated to
the imported secure key, these APQNs are cross checked. If no APQNs are
associated to imported secure key, then all currently available
APQNs are cross checked. If a master key mismatch is detected, then
the key import is rejected.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Perform a cross check of the APQNs when a secure AES key is validated.
When a set of APQNs are associated to a secure key, these APQNs are
cross checked. If a secure key is validated outside of the key repository,
or no APQNs are associated to a secure key inside the key repository,
then all currently available APQNs are cross checked. If a master key
mismatch is detected, then an error message is issued.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Perform a cross check of the APQNs when a new secure AES key is
generated. When a set of APQNs are associated to a new secure key,
these APQNs are cross checked. If a new secure key is generated
outside of the key repository, or no APQNs are associated to a secure
key generated inside the key repository, then all currently available
APQNs are cross checked. If a master key mismatch is detected, then
the key generation is rejected.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Display the master key verification pattern of a secure key while
'zkey validate' and 'zkey-cryptsetup validate'
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
A secure AES key token contains the master key verification pattern
of the master key it is encrypted with. Add a function to obtain the
master key verification pattern of a secure key token.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add a utility function to cross check the master keys of a set of
APQNs. It checks for valid master keys in the CURRENT and OLD
master key registers, as well as newly loaded master keys in the NEW
register. It issues information and warning messages for various
findings and also indicates improper master key setup to the caller.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add a utility function to print the master key verification patterns
of a set of APQNs. This allows the user to visually check which
master keys are set on which APQNs.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add a utility function to iterate over all available APQNs of
type CCA-Coprocessor. This function is required for various
future enhancements.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
With recent changes in the zcrypt device driver, the master key verifi-
cation patterns of the AES master key of am APQN can be obtained by
reading the sysfs attribute 'mkvps' of an APQN device of type CCA-
Coprocessor. The sysfs attribute can be found under
'/sys/devices/ap/cardnn/nn.mmmm/', where nn specifies the card number
in hex, and mmmm specifies the domain number on hex.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
With recent changes in the zcrypt device driver, the serial number of
a crypto card can be obtained by reading the sysfs attribute 'serialnr'
of a crypto card device of type CCA-Coprocessor. The sysfs attribute
can be found under '/sys/devices/ap/cardnn/', where nn specifies the
card number in hex.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
As preparation for future changes, move a sysfs specific functions
into a separate source file (utils.c).
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
As preparation for future changes, rework the loading of the
CCA host library so that the exported symbols are not passed
individually to the functions that use it. Pass a structure
that contains all entry points of all loaded CCA functions
instead. This will make it easier to add further CCA functions
at a later time.
Also add a version query for the CCA host library since some
future functions might be dependent on the library version.
While at it, separate the CCA related functions and definitions,
and move them into a separate source file (cca.h/cca.h).
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Show '[y/N]' on all user confirmation prompts to give the user a
hint what to reply. Also indicate that the operation was aborted
on a negative confirmation.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The volume type of a secure key is not really case sensitive,
but for better usability store and display it in uppercase always,
regardless in whatever case it was specified.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When 'zkey generate' is used with options '--clearkey <file>' and
'--xts', but without the '--keybits <bitsize>' option, then the
auto-detection of the bitsize of the specified clear key fails.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The validate command should allow to specify the --no-apqn-check
option even when --apqns is not specified.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Testing whether a file is a directory by masking the struct stat field
st_mode with S_IFDIR is wrong. Depending on the values of the macros
S_IF* block special devices might be considered as directories.
The file type encoded in the struct stat field st_mode is actually an
enumeration. To test whether a file is a directory either extract the
file type from st_mode using the mask S_IFMT and compare it against
S_IFDIR or simply use the macro S_ISDIR().
Fixes: c944f23d7e ("zkey: Add keystore implementation")
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Acked-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add option --no-apqn-check to the generate, import, change, and
validate commands to disable checking of the specified APQNs.
With this option a currently non-existing APQN can be associated
with a key. This is useful to associate APQNs that exist only on
other systems, such as disaster recovery systems, but not on the
current system. When generating keys, at least one of the specified
APQNs must be available to generate the key.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When a 'zkey change' command is used to change (i.e. set) the volume
association of a key, and the new volume association contains a volume
that is already assigned to the key to be changed, the command fails
with an error that the volume is already associated to the key.
This commit fixes the problems and allows to set such a volume
association. When setting a new association the current association of
the key to be changed is of no relevance, since the set operation
replaces the current association with the new association.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When re-enciphering or setting LUKS2 volume keys using zkey-cryptsetup,
allow to specify the --batch-mode|-q option to suppress confirmation
questions.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
For LUKS2 volumes the cryptsetup command currently generates
'cryptsetup luksFormat' commands, but for plain mode volumes it
generates 'cryptsetup plainOpen' commands.
With the --open option it can now also generate 'cryptsetup luksOpen'
commands for opening LUKS2 volumes. With the --format option you can
limit the generated commands to only generate 'cryptsetup luksFormat'
commands for LUKS2 volumes, and skip plain mode volumes.
The default behavior (i.e. if none of the two options specified),
remains the same as before.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When generating crypttab entries for LUKS2 volumes, allow to
specify common passphrase options like --key-file, --keyfile-offset,
--keyfile-size and --tries and pass those to the generated crypttab
entries.
Note that not all distributions support the keyfile-offset and
keyfile-size options in crypttab entries.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Remove 'hash=plain' option for plain type entries, add 'none luks'
for LUKS type entries.
Note that the format of a crypttab entry is distribution specific.
On some distributions only the first 2 fields are required, the
remaining are optional, on other distributions all 4 fields are
required. With this patch correct crypttab entries are generated
for all distributions.
Closes: https://github.com/ibm-s390-tools/s390-tools/pull/55
Fixes: https://github.com/ibm-s390-tools/s390-tools/issues/57
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
With libcryptsetup version 2.1 a new debug level was introduced
to log the JSON structures when adding key slots, digests, etc
into the LUKS2 header.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Messages from libcryptsetup for logging level CRYPT_LOG_DEBUG
do not include an EOL.
Prior to libcryptsetup version 2.1 debug messages were not printed
through the log callback, but using printf directly within
libcryptsetup. Now they are also printed through the log callback,
but without an EOL terminating the text.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
For zkey-cryptsetup commands reencipher and setkey, use the
same password-based key derivation function (PBKDF) when
creating unbound key-sots that the key slot uses, which was
unlocked through the specified passphrase. That way the
unlocked key slots created by these commands inherit the
PBKDF from the existing key slot.
This feature requires libcryptsetup version 2.1 or later.
If an older libcryptsetup version is available at compile
time, then PBKDF2 is used for newly created unbound key slots.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
LUKS2 encrypted volumes use Argon2i as default password based key
derivation function (PBKDF). Argon2i is a so-called memory-hard
function. It requires a certain amount of physical memory to make
dictionary attacks more costly.
Unfortunately, when multiple encrypted volumes are unlocked
automatically during system startup via /etc/crypttab, the use of
Argon2i will most likely cause an out-of-memory error in systemd.
To avoid the out-of-memory error, use PBKDF2 instead. Because PAES
uses secure keys as volume keys, the security of the key derivation
function used to derive the key to encrypt the volume key in the LUKS
key slots is of less relevance. Thus it is safe to use a weaker key
derivation function.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
LUKS2 encrypted volumes use Argon2i as default password based key
derivation function (PBKDF). Argon2i is a so-called memory-hard
function. It requires a certain amount of physical memory to make
dictionary attacks more costly.
Unfortunately, when multiple encrypted volumes are unlocked
automatically during system startup via /etc/crypttab, the use of
Argon2i will most likely cause an out-of-memory error in systemd.
To avoid the out-of-memory error, use PBKDF2 instead. Because PAES
uses secure keys as volume keys, the security of the key derivation
function used to derive the key to encrypt the volume key in the LUKS
key slots is of less relevance. Thus it is safe to use a weaker key
derivation function.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
