Check that an encrypt or decrypt call with a too small buffer correctly
returns CKR_BUFFER_TOO_SMALL, update the output buffer length to the
required size, and does not write to the output buffer beyond the
provided output buffer length. Furthermore, the operation must stay
active and a retry must be possible.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Run check_unwrap_sensitive_extractable() after the private key unwrap in
the ML-DSA and ML-KEM key transfer tests, for every test vector, and add
do_WrapUnwrapDHKey(), which wraps a generated DH private key under an AES
key with CKM_AES_CBC_PAD and runs the same check.
DSA is not covered: the soft token is built with -DNODSA, so no DSA test
runs there.
Signed-off-by: Alexandre Laroche <larochealexandre@hotmail.com>
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
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>
ICSF enforces NIST SP 800-56A compliance for private key validation during
key agreement. The key DH_PRIVATE_B does not pass this validation.
Update the testcase to use a valid private DH key that is complaint per
NIST SP 800-56A R3 5.6.2.1.2.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
CKR_FUNCTION_CANCELED usually indicates that a control point prohibits
an operation, or that the operation is not allowed due to some other
policy. Skip the test in that case.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
C_DeriveKey may return CKR_KEY_SIZE_RANGE when CCA enforces the NIST
security strength requirements regarding ECC curve type (input) and
derived key-length.
Skip the test in such cases.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Older EP11 firmware does not support ECDH with KDFs other than CKD_NULL, or
with non-empty shared data. This fails with CKR_MECHANISM_PARAM_INVALID
and must be skipped as unsupported properly. This error might only be
reported for the non-size-query call to C_EncapsulateKey.
Add a test vector with CKD_NULL and empty shared data to have at least one
supported test for such older EP11 cards.
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 digest test to use both, C_VerifyInit as well as
C_VerifySignatureInit for the HMAC tests.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
In case the testcase is skipped due to CKR_CURVE_NOT_SUPPORTED, use the right
array (i.e. der_ec_edwards_supported instead of montgomery_ecdh_tv) to get
the testcases name from.
Fixes: 9298f52ba4
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Use the unwrapped private key for further processing to check if the
unwrapped key can be used, not the original private key.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Otherwise the loop at the testcase_cleanup label to destroy the keys
might use uninitialized memory and try to destroy garbage handles.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Enhance the ibm_ml_kem as well as the tok2tok_transport test to also
perform the CKM_IBM_ML_KEM_WITH_ECDH mechanism.
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>
Setup the AES-CTR mechanism parameter using the current counter width in
bits (not bytes). Also make sure that it uses the counter value and width
from the known answer test vectors, not the hard-coded one (although they
are the same currently)
Signed-off-by: Ingo Franzki <ifranzki@linux.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>
In case RSA key generation fails with CKR_KEY_SIZE_RANGE, skip the test.
CKR_KEY_SIZE_RANGE indicates that the size of a key part (modulus or
public exponent) is not supported by the token.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Only a certain amount of data can be encrypted with RSA-OAEP for a given
RSA key size and OAEP digest. Skip the test if the temporary AES key of
a CKM_RSA_AES_KEY_WRAP key wrap operation can not be wrapped due to these
size restrictions.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Coverity findings: hashAlg or mgf cannot be equal to two different values
at the same time.
Fixes: fdff7ca5e2
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Check for CKR_FUNCTION_CANCELED and skip the test. CKR_FUNCTION_CANCELED
means that the operation is not allowed due to a control point setting.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Do the memcmp with the right length. Using a wrong length may cause
it to overrun the buffers, or compare in a wrong length. Both most
likely result in the false assumption that the testcase would have
failed, because the two buffers would not be the same.
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>
The bPrepend flag in CK_IBM_KYBER_PARAMS can not be used as an indication
if the hSecret key handle is valid or not. The bPrepend flag only determines
if the hybrid secret is prepended to the Kyber secret, or appended.
To check if a hybrid secret is specified check if the hSecret handle
is CK_INVALID_HANDLE or a valid object handle value.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
When the CCA token is configured to use CCA AES CIPHER keys, then wrapping
such keys is not possible, and an attempt to do so fails with
CKR_KEY_NOT_WRAPPABLE. Don't treat this as an error but skip the test.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Enhance the list of hash based key derivation mechanisms to also
include the two SHAKE key derivation mechanisms.
According to the PKCS#11 standard, SHAKE key derivation needs to
have a key type and/or a length provided in the template. Skip the
tests where either no key type and length is specified at all, or
no length is specified together with a key type of CKK_GENERIC_SECRET.
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>
To allow running the testcase concurrently against the same token, generate a
unique name, so that one process does not find another process's token object,
because this would cause the testcase to fail, although its not a real failure,
just an effect of running concurrently.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
... thus no known answer tests (KATs) are possible. Just skip the
signature comparison, but keep the signature size check, and verify
the known answer signature via C_Verify using the key. The known
answer signature as well as the (randomized) actual signature must
both verify OK with the current key.
Currently only the soft token (i.e. the oqsprovider, or more precisely
liboqs) uses randomized signatures, EP11 and CCA use deterministic
signatures.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
PKCS#11 v3.0 adds mechanisms like CKM_SHA3_nnn_KEY_DERIVE for SHA3 based key
derivation. For whatever reason, the SHA3 variants of those mechanisms are
called like ..._KEY_DERIVE while the SHA1 and SHA2 variants are called like
..._KEY_DERIVATION.
In PKCS#11 v3.1 this has been aligned and these mechanisms are now called
CKM_SHA3_nnn_KEY_DERIVATION, but there are aliases for the old mechanism
names like CKM_SHA3_nnn_KEY_DERIVE to map to the new names.
Update the code to use the new names, but also add the aliases so that
existing applications that use the old names continue to work. Also add
the aliases to the policy parser, to allow parsing existing policy files
that use the old names.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
