PKCS#11 states for flag CKF_INTERFACE_FORK_SAFE:
"The returned interface will have fork tolerant semantics. When the
application forks, each process will get its own copy of all session
objects, session states, login states, and encryption states. Each
process will also maintain access to token objects with their previously
supplied handles."
This is not how Opencryptoki behaves. The forked child starts as if
cryptoki has never been initialized, it needs to initialize the cryptoki
library freshly with C_Initialize if needed.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Don't exit early when getting CKA_PRIME fails. This leaves attributes
retrieved before that failure leaking.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
When statistic counters would overflow, keep them at the maximum possible
value. Wrapping to zero is the worst possible outcome for an auditing tool,
it silently under-reports activity.
If a counter saturated, then the pkcsstatd display indicates this with
"[saturated]" instead of the counter value.
While at it also make the reset operation to operate in an per counter
atomic way. Otherwise counter increments might get lost while a reset is
performed.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Uids are typically unsigned ints (uid_t), but the code handles them as
signed int, possibly dropping the upper half values.
Also correct the statistics SHM file iterating matching logic.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Limit the number of slot to NUMBER_SLOTS_MANAGED when calculating the
size of the statistics shared memory segment.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Assign apiSessp->slotID and apiSessp->rw_session before adding the new
session to the global session list. Doing so afterwards leaves a small
window where the new session is already added to the global session list,
but these fields are not yet assigned. This could affect closing all
sessions of slot 0, incorrectly closing the newly added session
because the slot ID is not yet set and thus 0.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Limit the possible PRF values to 63 or 31 (dependent on the architecture),
to avoid undefined behavior with too large shift amounts.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Very large config files can theoretically be larger than 65535 lines long.
This would cause the line number to wrap to low values. There is no good
reason to use a short int for the line number.
Also update several printf format string to match the new type.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
In case an empty config file is parsed for policy.conf or strength.conf
the version check might cause a NULL pointer dereference.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Create the lock files using O_NOFOLLOW to prevent symlink-following.
Lock files are just opened but no data is written to it or read from it.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Function check_user_and_group() in pkcsconf checks getgid() and getegid().
Similarly, attach_shared_memory() also checks getgid() and getegid().
The apiutil only checks getegid().
Make this consistent by removing the getgid() check in pkcsconf and
attach_shared_memory(). Only the effective user id is relevant.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Use strcmp(), not strncmp() for checking if a user is a member of a group.
Using strncmp() with the length of the user name might match to a longer
group member that has the same prefix as the user.
Note that this user-space checking is just to report inconsistencies with
a user friendly error message. The real security relies on the file
permissions based on user and group checked by the kernel. So incorrectly
matching a user does not cause a security hole.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add the define for CKM_PUB_KEY_FROM_PRIV_KEY to pkcs11types.h. Also add this
mechanism to the mechanism table and the policy code.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add defines for CKM_ECDH_X_AES_KEY_WRAP and CKM_ECDH_COF_AES_KEY_WRAP to
pkcs11types.h. Also add these mechanisms to policy and statistics code.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add support for the new for ML-DSA and ML-KEM defines in PKCS#11 v3.2.
Mechanism CKM_HASH_ML_DSA does not increment the counters for the implicit
hash mechanisms referenced in its mechanism parameter. This is because this
mechanism expects the message to be supplied already pre-hashed by the
caller. The hash mechanism referenced in the mechanism parameter is only
used for including its OID into the message encoding as of FIPS 204
HashML-DSA, but not to perform hashing.
However, the policy checks the hash mechanism of CKM_HASH_ML_DSA, and only
allows it to be used if no policy rule rejects it. Although CKM_HASH_ML_DSA
does not perform hashing itself, the policy still might forbid to use a
certain hash mechanism, and thus the whole CKM_HASH_ML_DSA mechanism usage
must be rejected if the referenced hash mechanism is rejected.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
PKCS#11 v3.2: For C_EncapsulateKey, an ephemeral key pair is generated.
The value of the generated public key is returned as the ciphertext.
The generated private key is used with public key provided in the API to
generate a symmetric key using DH Derive. For C_DecapsulateKey, the
ciphertext is used with the private key provided in the API to generate
a symmetric key using DH Derive.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
PKCS#11 v3.2: For C_EncapsulateKey, an ephemeral key pair is generated.
The value of the generated public key is returned as the ciphertext.
The generated private key is used with public key provided in the API to
generate a symmetric key using EC Derive. For C_DecapsulateKey, the
ciphertext is used with the private key provided in the API to generate
a symmetric key using EC Derive.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
PKCS#11 v3.2: When the mechanism is used in key encapsulation, the secret
key is generated in the C_EncapsulateKey function and then wrapped with
RSA PKCS or OAEP. C_DecapsulateKey is exactly equivalent to C_UnwrapKey
for RSA PKCS or OAEP.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Implement C_En/DecapsulateKey functions by routing them through to the
tokens. Also add base support for en-/decapsulation in the key manager.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
PKCS#11 v3.2 states: "Any mechanism that supports C_VerifyInit must also
support C_VerifySignatureInit."
Use common code for both variants, C_VerifyInit, C_Verify, C_VerifyUpdate,
C_VerifyFinal, as well as C_VerifySignatureInit, C_VerifySignature,
C_VerifySignatureUpdate, C_VerifySignatureFinal.
The only difference is that for C_VerifySignatureInit the signature to be
verified is passed at the init call, while for C_VerifyInit, it is passed
only at the final call.
C_VerifySignatureInit saves the signature in the context, so that it is
available later when the final verification is performed. That way the
tokens do not need to implement both variants, but can support both
transparently.
It is ensured that the sequence of calls can not be mixed. Otherwise
CKR_OPERATION_NOT_INITIALIZED is returned.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add support for the new PKCS#11 v3.2 function list and the new functions
(all of them return CKR_FUNCTION_NOT_SUPPORTED as of now), as well as
for the new encapsulate/decvapsulate attributes.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Make the Edwards and Montgomery mechanisms and their mechanism parameter known
to common code, policy, statistics, etc. Also support for BER-en-/decoding of
public and private Edwards and Montgomery keys.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Make the mechanism CKM_IBM_ML_KEM_WITH_ECDH and its mechanism
parameter CK_IBM_ML_KEM_WITH_ECDH_PARAMS known to common code,
policy, statics, etc.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Change all Dilithium and Kyber related functions to be named as ML-DSA
and ML-KEM respectively, but ensure that they can be used for Dilithium
and ML-DSA, as well as Kyber and ML-KEM respectively.
While at it, refactor some code places to unify Dilithium/ML-DSA and
Kyber/ML-KEM functions.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The commit adds support for BLS 12 381 curve as part of CKM_IBM_ECDSA_OTHER
with CKM_IBM_BLS submechanism for EP11 token.
Signed-off-by: Vishnudatha Kanjur <kanjur@ibm.com>
When checking for curves allowed by the policy, check for memcmp()
returning zero to indicate that the curve inn question was found
on the allowed curve list.
Fixes: 8df74e7c8d
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
PKCS#11 v3.0 and later states the following for C_XxxInit() calls:
C_XxxInit can be called with pMechanism set to NULL_PTR to terminate an
active operation. If an operation has been initialized and it cannot be
cancelled, CKR_OPERATION_CANCEL_FAILED must be returned.
Implement this by calling session_mgr_cancel() with the appropriate operation
flag in case pMechanism is NULL. This is the same effect as if
C_SessionCancel() is called with the same operation flag.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Mask out all non-operation mechanism flags to check if the mechanism
still supports at least one operation after the flags have been adjusted
due to policy.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
CKF_EC_OID is the same as CKF_EC_NAMEDCURVE, and CKF_EC_NAMEDCURVE is
deprecated since PKCS#11 v3.0.
Commit 304941d826 introduced CKF_EC_OID
as an alias for CKF_EC_NAMEDCURVE, but did not adjust the places where
CKF_EC_NAMEDCURVE is used. Lets now unify this and adjust all places
where CKF_EC_NAMEDCURVE is used to use CKF_EC_OID instead.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add support for key types like CKK_SHAxxx_HMAC and the corresponding key
generation mechanisms CKM_SHAxxx_KEY_GEN. These key types are similar to
the generic secret key type (CKK_GENERIC_SECRET). Keys of these types can
be used for the corresponding HMAC-SHA mechanisms (CKM_SHAxxx_HMAC and
CKM_SHAxxx_HMAC_GENERAL), along with generic secret keys.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add support for the mechanism CKM_SHA512_224_KEY_DERIVATION and
CKM_SHA512_256_KEY_DERIVATION to common code, as well as to the Soft, ICA,
and EP11 token.
Not that the EP11 firmware does currently not support these mechanisms, so
the EP11 token won't support them either. However, if the EP11 firmware ever
supports them, then the EP11 token is ready for it.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Newer GCC versions report errors for string initialization where the
terminating NULL character does not fit into the target variable.
All the fixed places use non-zero-terminated strings, but add an additional
character to make the compiler happy.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Handling for mechanism CKM_IBM_DILITHIUM is missing in function
policy_check_signature_size(). This causes policy_update_mech_info() to
remove the CKF_SIGN and CKF_VERIFY flags when a minimum strength of
larger than 0 is configured in the policy config file, because function
policy_check_signature_size() erroneously returns a signature size of zero,
which is below the allowed signature size. Return a signature size of
256 bits instead.
This only affects the mechanism info returned by C_GetMechanismInfo(),
when the policy defines minimum strength of larger than 0. It does not
affect the mechanism execution, nor signature creation or verification.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add defines for mechanism CKM_ECDH_AES_KEY_WRAP to the header file, the
mechanism table, as well as the policy and statistics code.
Field ulAESKeyBits of the CK_ECDH_AES_KEY_WRAP_PARAMS mechanism parameter
may not be set when performing unwrap. For unwrap, the size of the
temporary AES key is a result of unwrapping, and may not be known
by the caller. Field ulAESKeyBits should be set to zero if unknown.
In such cases the policy check can not check if the size of the
temporary AES key is according to the used policy.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add defines for mechanism CKM_RSA_AES_KEY_WRAP to the header file, the
mechanism table, as well as the policy and statistics code.
Field ulAESKeyBits of the CK_RSA_AES_KEY_WRAP_PARAMS mechanism parameter
may not be set when performing unwrap. For unwrap, the size of the
temporary AES key is a result of unwrapping, and may not be known
by the caller. Field ulAESKeyBits should be set to zero if unknown.
In such cases the policy check can not check if the size of the
temporary AES key is according to the used policy.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add defines for CKM_AES_KEY_WRAP, CKM_AES_KEY_WRAP_PAD, CKM_AES_KEY_WRAP_KWP,
and CKM_AES_KEY_WRAP_PKCS7 (PKCS#11 v3.1) to the header file, the mechanism
table, and the policy code.
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>
Ensure that the new SHAKE mechanisms are supported by common code
utility functions, as well as policy code.
Add a new token specific SHAKE key derivation function to allow a
token to provide such an implementation. Other than the SHA-based key
derivation functions, SHAKE key derivation can not be implemented by
common code, because there is no SHAKE digest mechanism that could be
used to hash the base key value. Therefore, this must be passed to
the tokens for them to perform the key derivation.
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>
