[Bug 2028936] Re: [SEC2340] zkey: support for key type PKEY_TYPE_EP11_AES (s390-tools)
Frank Heimes
2028936 at bugs.launchpad.net
Wed Jan 3 13:18:18 UTC 2024
Following up on the regression testing discussion and desire,
I like the hint to base the regression testing on the pkey kernel module modifications.
So using the libzpc tests (directly from upstream) is a good option:
https://github.com/opencryptoki/libzpc#Testing
libzpc's runtest runs by default 140 tests from 13 test suites
and allows to explicitly enable EC test in combination with EP11 using the env. var.
ZPC_TEST_EC_KEY_TYPE=ZPC_EC_KEY_TYPE_EP11
These are the additional steps that are needed on Ubuntu to get the test suite going:
~$ git clone https://github.com/opencryptoki/libzpc
~$ sudo apt install libjson-c-dev cmake
~$ cd libzpc/
~/libzpc$ mkdir build && cd build
~/libzpc/build$ cmake -DBUILD_TEST=ON ..
[ in case a proxy is required, like in our case: $ export https_proxy="http://your.proxy:3128/" ]
~/libzpc/build$ make
~/libzpc/build$ ./runtest
Notice that this is currently not possible with the libzpc package we have in 'noble',
since it req. commits that are not yet included in a published version.
But it's planned to release a new version of libzpc in time for 'noble' feature freeze,
that will allow me to version bump libzpc to that new and upcoming version (even if not strictly needed for the regression test here, however it's nice and clean to have it in the archive).
I'll update the SRU justification in the Bug description with these add.
steps for regression testing and update the status from Incomplete again
to New.
--
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:
[SEC2340] zkey: support for key type PKEY_TYPE_EP11_AES (s390-tools)
Status in Ubuntu on IBM z Systems:
In Progress
Status in s390-tools package in Ubuntu:
New
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:
New
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.
* Like suggested/requested in comment #10 a regression testing would make
sense and could be best done based on the pkey kernel module modifications.
And with that the libzpc tests (directly from upstream) are a good option:
https://github.com/opencryptoki/libzpc#Testing
libzpc's runtest runs by default 140 tests from 13 test suites and allows
to explicitly enable EC test in combination with EP11 using the env. var.:
ZPC_TEST_EC_KEY_TYPE=ZPC_EC_KEY_TYPE_EP11:
~$ git clone https://github.com/opencryptoki/libzpc
~$ sudo apt install libjson-c-dev cmake
~$ cd libzpc/
~/libzpc$ mkdir build && cd build
~/libzpc/build$ cmake -DBUILD_TEST=ON ..
[ in case a proxy is required:
$ export https_proxy="http://your.proxy:3128/" ]
~/libzpc/build$ make
~/libzpc/build$ ./runtest
Check from the output if the "ec"* tests are marked as "PASSED"
[ 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
More information about the foundations-bugs
mailing list