Hi,
a few comments on what was said below:
to set a master key in an EP11 adapter you always need a TKE, even if
you want to do it via z/OS, in which case a TKE must be connected to a
z/OS image.
Unless a domain of an adapter has been configured by the TKE to be only
manageble using signed commands, you can use panel.exe to manage the
master keys of adapter domains of which the adapter id and usage +
control domain id is attached to the guest. On z/VM guests, attaching a
(usage) domain to a guest with APDED always implies to also attache the
control domain to the guest.
The CCA tool panel.exe is meant as a simple key admin tool with limited
functionality that works best when operating on the default adapter and
default domain. It is described here:
https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.wskc.doc/wskc_c_utilities.html
You can provide arguments to address specific adapters but be aware that
this may be tricky because the way the tools from the CCA host package
counts adapters and the way the kernel identifies adapters may differ.
There is no easy way to define the domain to which a panel.exe command
shall be addressed. Some tricks are possible (e.g. setting the
environment variables CSU_DEFAULT_DOMAIN, or or setting the
/sys/bus/ap/ap_domain) but I no not know whether panel.exe can actually
address a control domain that is not equal to the usage domain. I will
do some research to get you an answer on this.
In general, when you need to do master key management in more complex (>
single node) environments the TKE is the tool of choice. Besides being
more secure (access control via smart cards) and master key parts being
stored on smart cards, the smart cards with key parts allow you to
restore a master key (in case an crypto card got lost/zeroized/damaged).
In addition, the TKE can manage multiple crypto adapters connected to
multiple LPARs/guests, located on multiple CECs. TKE simplifies some
complex functions like distributing the same master key to a set of
adapter domains as needed for redundant/HA/DR set ups.
-Reinhard
On 15.01.20 21:20, Alan Altmark wrote:
On Saturday, 01/11/2020 at 01:25 GMT, marcy cortes
<[email protected]> wrote:
First, my understand of virtualizing crypto is that if any of the cards
are
defined as accelerators then CRYPTO APVIRT in the directory will give
linux an
accelerator. If you want linux to have a coprocessor, you’d have to
dedicate
one. If you want a lot of servers to have coprocessors (more than the
HW
cards to dedicate), you’d get rid of the accelerators and make them all
coprocessors. Is my understanding correct?
(I'm gonna take another run at this, hopefully with something more
coherent than my prior post.)
Not quite, no. With recent updates, CP gives you control over what is in
the APVIRT pool. If you don't give CP any instructions, then CP will
choose. The only restriction is that all cryptos in the APVIRT pool must
be from the same generation and must be either in accelerator or
coprocessor (CCA) mode. EP11 can't be used for APVIRT. Only CLEAR key
operations can be performed using APVIRT.
For a guest to use SECURE keys, you must use APDEDICATED. If the guest
wants to convert a SECURE key to a PROTECTED key for use with CPACF (as
you would want for an encrypted file system or other symmetric
encryption), then the guest must have access to APDEDICATED.
And to do the AES master key load, it has generally been done from z/OS
here.
It looks like for my z/vm only boxes TKE is required, but I could use
the CCA
package to generate some for a test only scenario.
In coprocessor (CCA) mode, the keys can be loaded by TKE or by the
panel.exe app in the Linux CCA package. In EP11 mode, TKE is required
(unless you have z/OS laying around).
I recommend TKE for z/VM environments due to the ability of any guest with
access to the domain to be able to manage it by default. With TKE, the
domain can be configured such that only TKE-signed requests can alter the
domain configuration.
(And to answer Rick's question, yes, a secure key is indeed encrypted by
the 256-bit master key using AES.)
If I do want to try that CCA key load on a non prod box, I’m thinking I
would
have to dedicate all of the coprocessors to a Linux guest and create
them
there. Then undedicate and then any guest with an APVIRT would find
valid
master keys and would then be able to “zkey generate” a secure key for
use in
each disk.
Am I on the right track?
Reinhard will have to comment on this. I don't know if panel.exe lets you
load keys into domains other than the one Linux is actively using. If you
have multiple APs (you should), you will have to load the keys for each AP
the Linux guest will have access to. Switching domains may require
unloading and reloading the device driver after detaching and attaching
the "next" domain to the guest.
My understanding is that using TKE ensures that the guest cannot alter the
master keys of the domain it is using without a properly signed request
from TKE. (No rogue key managers!)
Alan Altmark
Senior Managing z/VM and Linux Consultant
IBM Systems Lab Services
IBM Z Delivery Practice
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
[email protected]
IBM Endicott
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390
