Add check_unwrap_sensitive_extractable() to the common test code. It
unwraps the same data with each combination of CKA_SENSITIVE and
CKA_EXTRACTABLE, and with neither, and checks every new key: the
attributes match the template (any value is accepted when the template
does not set them, since the defaults are token specific);
CKA_ALWAYS_SENSITIVE and CKA_NEVER_EXTRACTABLE are FALSE; and the key
value cannot be read from a sensitive key. When the unwrapping key's
CKA_UNWRAP_TEMPLATE sets one of the attributes, a key unwrapped without
it gets that value, and a template asking for the other value must fail
with CKR_TEMPLATE_INCONSISTENT.
CKA_ALWAYS_SENSITIVE and CKA_NEVER_EXTRACTABLE are not checked on the
ICSF token, which unwraps on the ICSF server and takes these attributes
from it.
Run it from do_WrapUnwrapAES() for secret keys, from do_WrapUnwrapRSA()
for RSA private keys, and from both EC key transfer tests for EC private
keys, whose transport key's CKA_UNWRAP_TEMPLATE sets CKA_EXTRACTABLE =
FALSE. Add do_UnwrapTemplateAES(), which unwraps under a wrapping key
whose CKA_UNWRAP_TEMPLATE sets CKA_SENSITIVE = TRUE and CKA_EXTRACTABLE =
FALSE, for every AES wrap mechanism.
Signed-off-by: Alexandre Laroche <larochealexandre@hotmail.com>
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
With the change of the previous commit, we must not set the
CKF_INTERFACE_FORK_SAFE flag when retrieving interfaces.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Test RSA encapsulation and decapsulation with different key sizes and different
symmetric key types.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Enhance the test-case-common do_GetFunctionList() function, as well as
the get_interface test-case to get the PKCS#11 v3.2 function list.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
This commit contains testcase updates to include BLS12 381 curve as part of
EC tests in opencryptoki. It includes testcase changes to import public private
key pair for BLS 12 381.
Signed-off-by: Vishnudatha Kanjur <kanjur@ibm.com>
Also adjust the testcases to support larger RSA keys, i.e. for RSA 8192 bit
keys.
Running tests with larger RSA sizes increase the run time dramatically.
Thus, the RSA 8192 bit tests are disabled by default, but can be enabled
by running the test with the '-rsa8k' option.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add '--enable-sanitizer' option to easily enable a build with sanitizer.
This requires that libasan and libubsan are available.
When running with sanitizer, disable unloading of the Opencryptoki
shared libraries, to produce useful stack traces.
For the same reason 'export LSAN_OPTIONS=fast_unwind_on_malloc=false'
might be required when running the built executable.
Attention: This may make it very slow!
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The CCA token only supports to derive AES-256 keys. Skip all attempts to
derive different key sizes.
The EC testcase usually derives keys of type CKK_GENERIC_SECRET, to allow
various key sizes. It checks that the derived keys are usable and correct
by performing an HMAC operation with them (if supported by the token).
If the test runs against the CCA token, derive AES-256 keys instead, and
perform an AES encrypt operation with them to test the usability and
correctness.
Known answer tests (KAT) for ECDH are not possible with the CCA token, because
CCA only allows to perform ECDH with randomly generated EC keys, but not
with EC keys imported from clear. However, for KATs, we would need to use
imported keys.
Furthermore, ECC keys imported from clear can not have CKA_DERIVE=TRUE for
the CCA token. Make sure CKA_DERIVE is TRUE only for those cases where it
really is required.
The cca_export_import_test is changed to import an ECC private key blob
with CKA_DERIVE=TRUE. This is safe since it did generate the key blob just
before with the CCA token, so it should have everything that is needed to
support key derivation.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Explicitly give EC public keys CKA_IBM_PROTKEY_EXTRACTABLE=true. But
even if this attribute is not contained in the template, EC public keys
would get it internally when creating the object.
Signed-off-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
Field ulDeviceError in struct CK_SESSION_INFO might be set in case of a
CKR_FUNCTION_FAILED. This can be due to a policy rejection (ulDeviceError
is CKR_POLICY_VIOLATION), or due to other token internal errors.
Print the value of ulDeviceError in case its non-zero and not indicating
a policy error.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The soft token as well as the EP11 token supports wrapping of IBM Dilithium
keys. The CCA token does not offer a wrapping mechanism that can wrap IBM
Dilithium keys due to the size of the keys.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
A major part of the runtime of the RSA testcases is RSA key generation,
especially when running with the soft or ICA tokens.
While generating RSA keys with different parameters must certainly also be
tested, there is no need to generate RSA keys over and over again with the
same parameters.
Cache RSA keys so that an attempt to generate a new RSA key with the same
parameters in the same session is omitted, and a cached RSA key is used
instead (if available). Such potentially cached RSA key objects must not be
destroyed by the testcases, since this would make the cached keys unusable.
Instead, the cached keys of a session are destroyed when closing the session,
or at the very end of the testcase.
Unfortunately it is not easily possible to cache RSA keys across multiple
sessions, because a key object handle is only valid within the session it
was created, so a handle from session 1 can not be used on session 2.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
`random` returns a number within a range that includes 0; but the code does not
always handle that, leading to misleading error messages ("malloc failed" but
it was a request for a memory buffer of size 0) on test run. Those should now
be fixed.
The `ock_tests.sh.in` file has been slightly tweaked to account for some flags
that are not available on AIX. No functional differences expected across all
supported platforms.
On Linux, a null pointer is printed as "(null)", whereas on AIX nothing is
printed. Since this is only for tests, AIX now also prints the same string as
Linux when a nullptr is attempted to be printed.
Signed-off-by: Akash Kulhalli <akash.kulhalli@ibm.com>
A new parameter -combined-extract is introduced for the testcases. If this
parameter is specified, the CKA_IBM_PROTKEY_EXTRACTABLE attribute is always
set to TRUE for new key objects. Note that testcases will fail if combined
extract is not supported in the test environment! In addition to this, a
new token setup is added to ciconfig.sh to enable combined extract tests
in the CI.
Signed-off-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
Test case changes to include AES XTS mechanism for protected keys in the EP11 token.
Also, skip tests which try to create non protected AES XTS keys in EP11 token.
Also, skip p11sak AES XTS tests for EP11 token.
Signed-off-by: Vishnudatha Kanjur <kanjur@ibm.com>
Attributes CKA_IBM_DILITHIUM_KEYFORM or CKA_IBM_DILITHIUM_MODE can
be used to select the Dilithium variant to use.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The ICSF token does not support certain attributes and/or combinations
of attributes, as well as only certain EC curves and RSA keys.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
When creating an EC private key from clear key data, do not supply
CKA_EC_POINT, since PKCS#11 does not define it for an EC private key.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
When a PKCS#11 function fails with CKR_FUNCTION_FAILED and
field ulDeviceError in CK_SESSION_INFO is CKR_POLICY_VIOLATION,
then this indicates that the operation is rejected due to policy.
Skip the testcase in this case, instead if failing it.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Make use of mechanism table to translate between string and numeric format of
mechanisms. Remove duplicated code dealing with mechanism translations.
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com>
Make sure the TokData member is always freed. Special care has to be taken
for the fork situation. In that case, we have to free TokData but block all
paths to a dlclose.
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com>
Perform a HMAC sign operation with the derived key to check hat
this key is really usable (if the derived key is within the allowed
key sizes of the HMAC mechanism).
We recently encountered a problem with EP11 on a CEX5 where a derived
key blob might be invalid for certain key sizes due to a firmware bug.
This test would fail for such situations.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Since commit "Allow small RSA exponents in the default provider"
254957f768
in OpenSSL 3.0, we do no longer need to restrict the tests for the Soft
token to RSA public exponents of 3 and 65537 only.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
OpenSSL 3.0 only accepts public exponents of 3 and 65537 for RSA keys.
Skip the testcase if another public exponent is used.
Also fixed some ugly line breaks within messages.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
When the TPM token is present, the check for the ICSF token returns true,
although the TPM token is used.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
EP11 supports CKM_ECDH1_DERIVE with or without KDFs and shared data
dependent on the firmware version. Enhance the tests so that it skips
test test when it gets error CKR_MECHANISM_PARAM_INVALID when using the
EP11 token and a KDF other than CKD_NULL and/or shared data is used.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
