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>
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>
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>
When a user that is in the zkeyadm group, but is not the owner
of the key file changes a key in the zkey repository, then
error "Operation not permitted" occurs. This is due to a superfluous
call to chmod on the key file. When key files are changed then the
permissions of that file are retained anyway.
Also fix a typo in the error message when chmod fails.
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 using 'zkey cryptsetup' with the '--run' option,
it might not find the executable to execute when those
are in /sbin.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Print a meaningful reason when the keystore can not be
accessed, e.g. because the user is not allowed to access
the keystore directory.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Allow to specify a volume-type for a key. This applies to all
associated volumes. The volume type can be either 'plain' or
'luks2'. New keys created will default to 'luks2', but existing
keys that do not have a volume-type property default to 'plain'
for compatibility reasons.
The volume type 'luks2' is only available when the define
HAVE_LUKS2_SUPPORT is set in the makefile. This is set only
when libcryptsetup version 2.0.3 or newer is available
at build time. If the define is not set, the volume-type
option is not available to the user, and the volume-type of
a key defaults to 'plain'.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Store a verification pattern in the properties file along
with the secure key. The verification pattern allows to identify
the inner key even when the secure key is no longer valid.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When a volume or APQN association is made while generating or
importing a key, and a duplicate association is detected, then
this may leave the key in an inconsistent state.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When a zkey generate or change command is used to associate one
or multiple APQNs the command succeeds, but no key is generated
and no APQNs are associated, because the return code returned by
_keystore_apqn_check() is wrong.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The APQN check routine as well as the properties helper functions
do not free all memory that they allocated.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add a keystore implementation that stores secure AES keys in a
key repository, located in a directory, e.g. '/etc/zkey/repository'.
The keystore allows you to generate, validate, re-encipher, modify,
list, delete, etc secure keys.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
