Add support to integrate the external key management systems based
on the KMIP protocol (KMIP: OASIS Key Management Interoperability
Protocol) into zkey by providing a zkey KMS plugin for KMIP. The
plugin communicates with KMIP servers using libkmipclient over a
TLS or HTTPS connection.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When the compiler flags are overridden, the build of zkey may fail with:
kms.c:44:2: error: #error KMS_PLUGIN_LOCATION must be defined
44 | #error KMS_PLUGIN_LOCATION must be defined
| ^~~~~
The Makefile uses CFLAGS variable for defining the KMS_PLUGIN_LOCATION,
but it should rather use ALL_CFLAGS.
Also use ALL_CPPFLAGS for defining HAVE_LUKS2_SUPPORT.
Fixes: https://github.com/ibm-s390-linux/s390-tools/issues/108
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
zkey-ekmfweb.so requires libekmfweb.so. If libekmfweb.so can not be built
due to missing build requirements, then zkey-ekmfweb.so can't be built
either.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Building zkey-ekmfweb.so will also trigger to build libekmfweb.so,
which requires OpenSSL. So, skip zkey-ekmfweb.so if HAVE_OPENSSL=0.
zkey-cryptsetup also has a dependency on OpenSSL, so skip it also
if HAVE_OPENSSL=0
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add support to integrate the external key management system EKMF Web
(IBM Enterprise Key Management Foundation - Web Edition) into zkey by
providing a zkey KMS plugin for EKMF Web. The plugin communicates
with EKMF Web using libekmfweb via a RESTful API.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add the following sub-commands for key management system plugin
handling:
- configure: Configure a KMS plugin
- reencipher: Re-encipher secure keys used by a KMS plugin
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add support to integrate external key management systems into zkey
by using a plugin concept. Add helper functions to load, bind, and
unbind a key management system plugin.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
EP11 secure keys require a certain firmware version. Enhance
the APQN cross check to not only check for a minimum card level,
but also for a minimum firmware version.
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 new source file that contains EP11 specific helper routines.
These routines require to load the EP11 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>
Different crypto card types use different master key verification patterns
(MKVPs). Generalize the handling of MKVPs so that the majority of the
code does not have to care about the card type when dealing with MKVPs.
Also generalize messages about the crypto card's master keys to not
mention a specific card type.
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 adding support for EP11 secure keys,
generalize the code to support different crypto card 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>
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>
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>
The .o.d make targets in common.mak do not expect that
header files are generated by a make target. When a new header
file is generated, the .o.d targets will be rebuilt on the
next make invocation, because that new header file is then
detected, and is then treated as a new dependency of all .o.d
targets.
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>
The zkey-cryptsetup tool is used to validate and re-encipher
secure AES volume keys of volumes encrypted with LUKS2 and
the paes cipher.
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>
Create the default keystore directory '/etc/zkey/repository'
and the user group 'zkeyadm' during make install.
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>
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>
To reduce the size of the zkey.c source file, all routines that
deal with secure keys are moved to a new source file pkey.c.
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>
The integrity support for the properties file routines use
SHA-256 to build a hash of the keys and values of a property file.
The codes uses the EVP_DigestInit_ex, EVP_DigestUpdate, and
EVP_DigestFinal from the libcrypto library (OpenSSL).
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>
In preparation for a new feature, introduce property file
handling routines. A property file stores key value pairs
in a text file. Optionally a hash of all keys and values
contained in the properties file can be generated to
ensure integrity of the properties file and to detect
manual modifications.
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>
The LDFLAGS content is added before the object files causing unresolved
symbol dereferences during the build. This actually happens so far on
Debian/Ubuntu instances.
Hence, use LDLIBS instead.
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
This commit is based on the s390-tools-1.39.0 version.
Changes on top of s390-tools-1.39.0:
- Add MIT license to all source files
- Add LICENSE file
- Transform REAMDE to README.md (markdown)
- Add AUTHORS.md file
- Add CONTRIBUTING.md file
- Move changelog from README to CHANGELOG.md file
Reviewed-by: Stefan Haberland <sth@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
