[Bug 2028936] Comment bridged from LTC Bugzilla

Thu Dec 14 13:29:51 UTC 2023

------- Comment From ifranzki at de.ibm.com 2023-12-14 08:13 EDT-------
hm no.... The soft token does not use the pkey module. So you won't be testing pkey nor the PKEY_TYPE_EP11_AES key type of it.

Instead, a possible test case could be run the libzpc testcases. But
make sure to use the very latest from the libzpc master branch, since
there have been fixes in libzpc to support that key type. You may talk
to Joerg Schmidbauer about libzpc.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to s390-tools-signed in Ubuntu.
https://bugs.launchpad.net/bugs/2028936

Title:
  [24.04 FEAT] [SEC2340] zkey: support for key type PKEY_TYPE_EP11_AES
  (s390-tools)

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in s390-tools package in Ubuntu:
  In Progress
Status in s390-tools-signed package in Ubuntu:
  Fix Committed
Status in s390-tools source package in Mantic:
  New
Status in s390-tools-signed source package in Mantic:
  New
Status in s390-tools source package in Noble:
  In Progress
Status in s390-tools-signed source package in Noble:
  Fix Committed

Bug description:
  SRU Justification:
  ==================

  [ Impact ]

   * The EP11 key type PKEY_TYPE_EP11 supported by zkey is incompatible with
     session bound keys.

   * In particular such keys generated in a secure guest (which are implicitly
     bound to a supervisor session) cannot be used.

   * Therefore zkey needs to be extended to support ep11 keys of the type
     PKEY_TYPE_EP11_AES.

  [Fix]

   * 1b044b8 1b044b8a40ab59e4f5ffe66e3ad81499b0beccce "zkey: Support
  EP11 AES keys with prepended header to retain EP11 session"

  [ Test Plan ]

   * An Ubuntu Server 23.10 installation with access to a CryptoExpress
     adapter in EP11 mode (CEX7P or later) is required.

   * Generate an AES key with zkey using key type EP11-AES:
     # zkey generate --name test1 --key-type EP11-AES --apqns <EP11-APQN(s)>

   * Have a look at the hex dump of the generated key:
     # xxd /etc/zkey/repository/test1.skey
     00000000: 0000 0100 0300 0100 0000 0000 0000 0000 ................
     00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
     00000020: ef92 899e be57 291e c8e8 716d 850e e2f7 .....W)...qm....
     00000030: 0000 0000 0020 8d26 0000 0000 0000 0001 ..... .&........
     00000040: 1234 d2ae cfff aa9d 15cd d2ad 9a7b 082b .4...........{.+
     ....
     The first 16 bytes are a header indicating the type of the key.
     Above example is a version 3 key (see offset 4).
     This is what you get WITHOUT the fixes.

   * A key generated with the fixes present would look like this:
     # xxd /etc/zkey/repository/test1.skey
     00000000: 0000 0110 0600 0100 0000 0000 0000 0000 ................
     00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
     00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
     00000030: ef92 899e be57 291e c8e8 716d 850e e2f7 .....W)...qm....
     00000040: 0000 0000 0020 8d26 0000 0000 0000 0001 ..... .&........
     00000050: 1234 c393 b33e fcdd 1c8f ecb6 3230 186d .4...>......20.m
     ...
     Here, its a version 6 key (see offset 4, PKEY_TYPE_EP11_AES = 6).
     With the fixes present, you should always get version 6 keys.
     So if you see a version 6 key, then the fix is present and working.

   * FWIW: The 32 bytes following the 16 bytes header are the
     session ID of the key.
     Unless you are in a secure execution environment they are zero.
     If you are in a secure execution environment they would be non-zero.
     For a version 3 key, the session ID would be the very first 32 bytes,
     but it is overlayed (and thus destroyed) by the 16 bytes header
     information.
     So version 3 keys can not be session bound, but version 6 keys can be
     session bound.
     Thus, only version 6 keys can be used in a secure execution environment.

   * To test if the key is usable, run a validate command:
     # zkey validate --name test1

   * Furthermore, setup a dm-crypt volume using such a version 6 key
     by following the steps described here:
     https://www.ibm.com/docs/en/linux-on-systems?topic=volumes-creating-volume-pervasive-encryption

   * If you can successfully open that dm-crypt volume then it ensures that
     also the pkey/paes_s390 kernel modules contains the required fixes
     and can work with such a key.

  [ Where problems could occur ]

   * A parameter in select_ep11_apqn_by_mkvp struct was changed and renamed,
     in case the renaming is not overarching, the code will break.
     This can be checked by a test build.

   * In case the content of the ep11key_blob is not decomposed properly,
     the two different types PKEY_TYPE_EP11 and PKEY_TYPE_EP11_AES
     might be mixed up, which will break pkey handling.

   * If the sizeof calculation of the headers is wrong, a wrong
     header/PKEY_TYPE might be assumed.

   * The setup of the new EP11 token header was redone. In case of issues
     here the EP11 token header might be wrong, hence later not properly
     detected and/or unusable.

   * Code was added to check if the pkey module supports keys of type
     TOKEN_VERSION_EP11_AES_WITH_HEADER, since older kernels may not support
     such keys.
     This can be faulty, which may lead to wrong assumptions about the support.
     Or the conversion to TOKEN_VERSION_EP11_AES type can be erroneous.

   * Similar for gensek2 and clr2seck2.

   * Checks if key is EP11 AES key token with external header and
     EP11 AES key is session bound may again lead to wrong assumptions
     in case of issues.

   * Fortunately all this is s390x specific,
     and does not affect a default installation,
     but mainly confidential computing environments (aka secure execution).

  [ Other Info ]

   * The commit/patch is upstream since Aug 21st 2023.
  __________

  The EP11 key type PKEY_TYPE_EP11 supported by zkey is incompatible with session bound keys. In particular such keys generated in a secure guest (which are implicitly bound to a supervisor session) cannot be used.
  Therefore zkey needs to be extended to support ep11 keys of the type PKEY_TYPE_EP11_AES.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2028936/+subscriptions