Routine check_required_versions not only checks required firmware
versions, but also crypto card levels. If this check fails, the
reason may also be that available cards are too old.
Signed-off-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
Print the initial trace message as ERROR instead of as INFO, although this
is really not an error. However, when a trace level lower than INFO is
selected, then the initial trace message would not be written.
The initial trace message contains information about the Opencryptoki
version as well as the trace level selected. This information is always
important, even for lower trace levels.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Don't change protected key related attributes for public keys.
Otherwise CKA_IBM_PROTKEY_EXTRACTABLE might be turned off, which
would prevent public key operations to be performed via CPACF.
Signed-off-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
Add similar memcpy length checks for EC/Ed. Also clarify some length
calculations by introducing constants for p521 and ed448 CPACF
buffer sizes.
Signed-off-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
In case of XTS, the PCC instruction is used to create the XTS iv from given
tweak and XTS key 1. The KM instruction is used for encryption/decryption
using key 2. Both instructions may be interrupted by an LGR. But PCC either
succeeds or fails as a whole, while KM may process less blocks than expected.
Signed-off-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
In case of EC/ED sign the whole signing operation with a given input message or
hash either succeeds or goes wrong. So in case of an LGR, we can simply retry
the whole operation. Verification is not a problem at all, because public keys
are not protected keys.
Signed-off-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
During live guest relocation (LGR) protected keys will become invalid and
their usage will result in a verification pattern mismatch error. Any code
that uses a protected key must therefore be able to handle this error by
re-establishing the protected key from the key material it was derived
from.
Live guest relocation may happen at any time with the exception that
processing of a single data block by a CPACF instruction can be viewed as
an atomic operation. This means that the AES algorithm always either
processes a given full block or fails entirely to process this block.
The application might perform an "in place" encryption/decryption, so that
input and output buffers are identical and data up to the point where
partial completion occurred, is already processed. As there are always
complete blocks processed, opencryptoki must be able to retry such an
operation on a block boundary with the actual CPACF parm block and running
iv or counter.
Signed-off-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
As the low-level functions return either zero or numbers of
processed bytes, the return value cannot be negative.
Signed-off-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
Make sure that the new pkey's verification pattern matches the one in
ep11_data. This should always be the case, except there was a live
guest relocation (LGR) in the middle of the process. In case of XTS
there could even be an LGR between creating the protected keys from
the two XTS keys. Also add the pkey lock usage at some places where
it was missing in old code.
Signed-off-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
The new convert_key callback function for EP11 works very similar to the
one for CCA. Just some ep11-related details are different.
Signed-off-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
Introduce a read/write lock to protect the pkey_mk_vp field in cca_data
against concurrent access from multiple threads. This is already
implemented for EP11, but was still missing for CCA.
Since the most frequent use case is to just compare (i.e. read) the VP,
a read lock allows concurrent reading without blocking other threads.
With a mutex all other threads are potentially blocked as long as one
thread has the mutex, even as it just reads the VP.
Also add some retry logic to ccatok_pkey_update, because an LGR could
happen while updating a key.
Signed-off-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
The new convert_key callback function handles re-creating protected keys from
their related secure keys. It is called after an LGR when continuing to run
on the new system. This includes locking/unlocking of related key objects and
retrying the operation if another LGR happens in the middle of the process.
It also handles the case where creating the protected key from an XTS key1
happened on the old system, but creating the protected key from XTS key2
happens on the new system after an LGR. Lastly, the verification pattern of
the firmware wrapping key on the new system is saved in cca_data.
Signed-off-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
Routine aes_xts_cipher used *out_data_len als running offset to hold
the number of processed bytes. When retrying XTS ops, e.g. in case of
a wkvp mismatch, this corrupted the output buffer length as specified
by the calling function.
Signed-off-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
Unify the shared memory segment naming of the ICSF tokens to match the
naming of the other tokens.
Also support to have multiple ICSF tokens, by automatically adding a 'tokname'
keyword pair to the slot configuration when adding a ICSF token via the
pkcsicsf tool. For multiple ICSF tokens it is important that each token
uses its own token directory, and thus a unique token name is required.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
When using the pkcshsm_mk_change tool to initiate a concurrent master
key change, it is important that all affected tokens are available and
that the user using the pkcshsm_mk_change tool has permissions to use all
tokens, i.e. the user should be part of all token groups.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
A new optional key value pair named 'usergroup' can be specified within a
slot structure to specify the user group name that is set as the owner of
the token directory. Only users that are members of this group have access
to the token and its objects. Users that are not a member of this group
will not see the token as being available (e.g. via 'pkcsconf -t' or via
'C_GetTokenInfo').
If no token group is specified, then the token is owned by the 'pkcs11' group
like before this change.
If a token user group is specified, then the pkcsslotd checks if that group
exists, and if all members of that group are also members of the 'pkcs11'
group. This is required to be able to access the pkcsslotd socket at all.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add support for C_Login with user type CKU_CONTEXT_SPECIFIC for authenticating
due to key usage with CKA_ALWAYS_AUTHENTICATE=TRUE.
If no operation context has the flag set to indicate that authentication is
required, C_Login fails with CKR_OPERATION_NOT_INITIALIZED.
On successful login, reset the flag to indicate that authentication is required
in the operation context to indicate that authentication has been performed.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
In operation execution of sign and decrypt (i.e. C_Sign, C_SignUpdate,
C_SignFinal, C_Decrypt, C_DecryptUpdate, C_DecryptFinal, etc.) check if the
flag indicating that authentication is required is still set in the operation
context.
If set, then no C_Login has been performed since the operation was
initialized, and the call fails with CKR_USER_NOT_LOGGED_IN. If the
flag is not set, then either no authentication has been requested, or it has
been requested, and a proper C_Login has been performed since the operation
was initialized, and thus we can continue with operation execution.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Check attribute CKA_ALWAYS_AUTHENTICATE on operation init calls with private
keys (i.e. C_SignInit, C_DecryptInit) and set a flag in the operation context
that authentication is required before the operation can be continued.
Note that the ICSF token does not support the CKA_ALWAYS_AUTHENTICATE
attribute, because the underlying ICSF services do not support that
attribute. Specifying CKA_ALWAYS_AUTHENTICATE in a template will most
likely fail because ICSF does not know this attribute. The behavior is
as if CKA_ALWAYS_AUTHENTICATE would be FALSE.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The PKCS#11 standard defines the CKA_ALWAYS_AUTHENTICATE attribute for private
keys (i.e. objects with class=CKO_PRIVATE_KEY) only. It may only be set to
CK_TRUE when CKA_PRIVATE is also CK_TRUE.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
It turns out that ICSF supports the SHA3-HMAC mechanisms since z/OS 2.5.0,
but the RPLUGIN of the z/OS LDAP server does not support them.
Disable the mechanisms for now. Once the z/OS RPLUGIN has been enhanced, they
can be enabled quickly.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
A couple of places are missing SHA3-HMAC support, fix this.
Note that HMAC-SHA3 is only supported by z/OS 2.5.0 or later.
It will fail with CKR_FUNCTION_FAILED if used with a z/OS version
that does not support it.
Fixes: 259e9472e0
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Fix a coverity finding on a missing length check. The key value structure
contains not only the modulus, but also the public exponent. Make sure that
they fit into the size of the key value structure.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
When object_put() is called with unlock = FALSE, then it is assumed that
the object is currently not locked. Thus object_put() obtains the read lock
to check if the object is a session or private object. After that the object
must always be unlocked, regardless of the 'unlock' parameter. Either
'unlock' was TRUE then we must unlock the object, or if 'unlock' was FALSE,
then we locked the object our-self, and thus must unlock it again.
Currently, object_put() may only be called with unlock = FALSE by
h_opaque_2_blob() from the EP11 token, when h_opaque_2_blob() was called
with lock_type=NO_LOCK. Currently there is no such case that does that.
Another case where object_put() may be called with unlock = FALSE is
object_mgr_find_in_map_nocache(), when it gets called with lock_type=NO_LOCK.
There, in error cases object_put() may be called with unlock = FALSE.
Currently there is no such case that calls object_mgr_find_in_map_nocache()
with lock_type=NO_LOCK.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Don't go to out label again if an error occurs during unlock.
Instead return the lock error, if no other error is set.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Policy and statistics code has a need to check certain fields of the mechanism
parameter structures. Check for correct mechanism parameter length and pointer
before attempting to access the mechanism parameter fields. This avoids
seg-faults in case an application passes an invalid mechanism parameter.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
For the IBM Kyber key type, the CKA_IBM_KYBER_SK attribute contains the
private key and thus, this attribute is sensitive. Attribute CKA_IBM_KYBER_PK
contains the public key and is not sensitive.
Fixes: f8ad4f0395
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
CCA error 8/2053 means "No message found in the OAEP-decoded data" and is
an additional error (in addition to the already handled 8/2054 error: "There
is a non-valid RSA Enciphered Key cryptogram: OAEP optional encoding
parameters failed validation") that could be returned by CCA verb CSNDPKD in
case of RSA-OAEP on invalid encoded messages.
Translate this error also to CKR_ENCRYPTED_DATA_INVALID to not allow any
distinction between these two error situations. Until now 8/2053 was
translated to CKR_FUNCTION_FAILED, like any other CCA error codes.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add support for the soft token to sign and verify with IBM Dilithium keys.
This is an experimental feature, it may change in an incompatible way in
the future! It is not known how the 'oqsprovider' changes in the future,
and if it then still supports the Dilithium variants known by Opencryptoki.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add support for the soft token to import IBM Dilithium keys from clear
key values. The clear key values can either be supplied via CKA_VALUE,
or via the individual key component attributes.
For a public Dilithium key, the CKA_VALUE attribute may contain the BER
encoded SPKI of the public key. For a private Dilithium key, it may
contain the PKCS#8 encoded private key value.
This is an experimental feature, it may change in an incompatible way in
the future! It is not known how the 'oqsprovider' changes in the future,
and if it then still supports the Dilithium variants known by Opencryptoki.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add support for generating IBM Dilithium keys with mechanism
CKM_IBM_DILITHIUM for the soft token using the 'oqsprovider'.
The soft token can only support those Dilithium variants that the
'oqsprovider' supports. Currently, these are the 3 round 3 variants
with object IDs '1.3.6.1.4.1.2.267.7.4.4', '1.3.6.1.4.1.2.267.7.6.5',
and '1.3.6.1.4.1.2.267.7.8.7'. Those are called 'dilithium2',
'dilithium3' and 'dilithium5' by the 'oqsprovider'.
This is an experimental feature, it may change in an incompatible way in
the future! It is not known how the 'oqsprovider' changes in the future,
and if it then still supports the Dilithium variants known by Opencryptoki.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
In preparation to support the IBM specific CKM_IBM_DILITHIUM mechanism,
try to load the oqsprovider. The oqsprovider is an optional provider for
OpenSSL 3.x and must be separately installed and configured.
It is available at https://github.com/open-quantum-safe/oqs-provider/ .
If loading of the oqsprovider fails, then mechanism CKM_IBM_DILITHIUM is
not supported by the soft token.
This is an experimental feature, it may change in an incompatible way in
the future! It is not known how the 'oqsprovider' changes in the future,
and if it then still supports the Dilithium variants known by Opencryptoki.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
A token can either implement its own token_specific_key_unwrap() function
to perform the unwrap operations itself, or it can use common code to
perform the unwrap operation. In case the token performs the unwrap itself,
it can check if it supports the to be unwrapped key type and strength (e.g.
bit size, EC curve, etc), and act accordingly. However, if the token uses
common code for unwrapping, it has no chance to check the unwrapped key.
Thus it can happen that the common code unwraps a key with a key type or
strength that the token does not support.
Call the token_specific_set_attrs_for_new_object() function with mode
MODE_UNWRAPPED to give the token a chance to inspect the just unwrapped key
and take appropriate actions. This is only done when the common code is
used to perform the unwrap. If the token provides its own
token_specific_key_unwrap() function, then no additional call to the
token_specific_set_attrs_for_new_object() function is done, because the
token can check the unwrapped key in its token_specific_key_unwrap() function
already.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Let s390_pcc return the condition code of the PCC instruction.
Also fix the error handling in the calling functions.
Signed-off-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
Fix covscan warnings on cases like 'if (a - b > 0)' where both 'a' and 'b'
are unsigned types. In case 'b' is larger than 'a', then the subtraction
result may overflow because the result is also treated as unsigned type.
Fix this by using 'if (a > b)' instead.
Note that in the changed places 'a' is always larger than or equal to 'b',
so the overflow does not happen. Still, changing the code to be less
error-prone is a good thing.
Closes: https://github.com/opencryptoki/opencryptoki/issues/782
Suggested-by: Than Ngo <than@redhat.com>
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
When adding common code support for the SHA based key derivation mechanisms
it was forgotten to also increase the statistics counters for those
mechanisms on successful completion.
Fixes: a34694e384
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
