Accepting too many concurrent admin connections dramatically increases the
risk of a denial-of-service attack. An malicious admin connection might
flood the connection with events, which requires a huge amount of memory
to pass these events to the applications. Especially when the events
require a reply, then this can add up to a lot of memory, causing the
pkcsslotd to run into out-of-memory situations. This might cause it to
drop application connections, which can have bad effects.
32 concurrent admin connections should be more than enough at the moment.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Instead of copying each member separately, copy the entire struct at once.
This also fixes a bug where the string fields uses memcpy with strlen,
which does not copy the trailing NUL character. The target struct is
zeroed before, so there anyway is a NUL character, but that is subtle.
While at it remove the unused field shm_addr.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add definitions for the IBM-specific Ethereum 2.0 key derivation mechanism
CKM_IBM_ETH_DERIVE. It can be used to perform Ethereum 2.0 key derivation of
BLS12-381 EC keys using the mechanism described in EIP-2333. It is used with
C_DeriveKey() and has a mechanism parameter defined by structure
CK_IBM_ETH_DERIVE_PARAMS
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
External define OCK_ML_KEM_786 has a typo, it must be OCK_ML_KEM_768. Fix
this, but keep the old define for backward compatibility.
Also constant ml_kem_786 has the same typo, it must be ml_kem_768. Fix
this also (not externally visible).
Fixes: 1440e408f8
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>
CCA uses distinct key types for Pure-ML-DSA and Prehash-ML-DSA. That type
must be selected at key generation or import already.
Add a CCA token configuration option to select the ML-DSA mode to use
by default, as well as an attribute CKA_IBM_CCA_ML_DSA_KEY_MODE that
can be supplied during key generation or import to select the desired
mode. If attribute CKA_IBM_CCA_ML_DSA_KEY_MODE is not present in the
template at key generation or import, the token configuration option
determines the mode to use for the new key. For key generation,
CKA_IBM_CCA_ML_DSA_KEY_MODE must be specified in the private key template
only, and can not be specified in the public key template. When importing
a public key, it can also be specified in the public key template.
ML-DSA keys in 'PURE' mode can be used for Pure-ML-DSA sign/verify only,
that is, only mechanism CKM_ML_DSA can be used with them. ML-DSA keys in
'PREHASH' mode can be used for PreHash-ML-DSA sign/verify only, that is,
only mechanisms CKM_HASH_ML_DSA[_xxx] can be used with them.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add defines for the PKCS#11 v3.2 key types CKK_ML_KEM and CKK_ML_DSA, as
well as attributes, mechanisms, and mechanism parameter structures specific
for those key types.
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>
Add defines for the new PKCS#11 v3.2 function list, return codes, flags,
and attributes to pkcstypes.h.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add defines for the Edwards and Montgomery key types CKK_EC_EDWARDS, and
CKK_EC_MONTGOMERY, mechanisms CKM_EDDSA, CKM_EC_EDWARDS_KEY_PAIR_GEN,
and CKM_EC_MONTGOMERY_KEY_PAIR_GEN, as well as the mechanism parameter
structure CK_EDDSA_PARAMS to the pkcs11types.h header file.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add defines for mechanism CKM_IBM_ML_KEM_WITH_ECDH and its
mechanism parameter CK_IBM_ML_KEM_WITH_ECDH_PARAMS to pkcs11types.h
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
While at it, rename the length info element for dilithium to ml_dsa,
and use it for both, Dilithium as well as ML-DSA. The key components
are the same, just different sizes dependent on the variant.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
ML-DSA and ML-KEM use common definitions with IBM Dilithium and IBM Kyber,
such as the attribute types for the key components, as well as the KEM
mechanism parameter. Those definitions are changed to be named for ML-DSA
and ML-KEM respectively, but there are aliases for the old Dilithium and
Kyber names that map to the new definitions.
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>
Add 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 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>
When generating or importing an AES key, the template can contain attribute
CKA_IBM_CCA_AES_KEY_MODE to specify the mode of the CCA secure key to generate
or import. Possible choices are DATA key (CK_IBM_CCA_AES_DATA_KEY) or
CIPHER key (CK_IBM_CCA_AES_CIPHER_KEY).
If the CKA_IBM_CCA_AES_KEY_MODE attribute is not contained in the
template, then the CCA config option 'AES_KEY_MODE' or the overall default
defines the mode of the secure key that is generated or imported.
In either case, attribute CKA_IBM_CCA_AES_KEY_MODE is added to the AES key
object denoting the mode of the CCA secure key.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add defines for SHAKE mechanisms like CKM_SHAKE_128_KEY_DERIVATION and
CKM_SHAKE_256_KEY_DERIVATION.
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>
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>
The *_SP800 KDFs use the algorithm defined by FIPS SP800-56A/SP800-56C
instead of the algorithm defined by ANSI X9.63.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add defines for SHA3 mechanisms like CKM_SHA3_nnn, CKM_SHA3_nnn_HMAC,
CKM_SHA3_nnn_HMAC_GENERAL, CKM_SHA3_nnn_KEY_DERIVE, but also for
combined digest-sign mechanisms like CKM_ECDSA_SHA3_nnn,
CKM_SHA3_nnn_RSA_PKCS, and CKM_SHA3_nnn_RSA_PKCS_PSS, as well as
MGFs like CKG_MGF1_SHA3_nnn and KDFs like CKD_SHA3_nnn_KDF
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.
CKF_EC_CURVENAME is set if the token supports CKA_EC_PARAMS to use
the curveName choice (i.e. the curve name as printable string)
instead of the OID.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
`epoll` is Linux-specific. AIX has an epoll clone, but it's called `pollset`.
The API signatures are nearly identical, and is intended to be the `epoll`
equivalent for AIX. AIX-specific code blocks have been added to account for it.
Privilege management on AIX is also significantly different than on Linux. AIX
has a different set of privileges that pkcsslotd does not need, and therefore
has all of them disabled at runtime. Due to platform restrictions, the slot
daemon runs under user `slotd`, instead of the usual `pkcsslotd` on Linux.
Later versions of AIX (7.3+) do not have this restriction, but are bottlenecked
by this restriction present on 7.2. Earlier releases of AIX do not have an
equivalent implementation of pollset and are therefore not supported.
Finally, file paths that use tmpfs have been adjusted according to the platform.
On Linux, it will unconditionally use the tmpfs-directories for the appropriate
files (pid and socket files under /run), while on AIX it will use the
prefix that was mentioned during configure time. This is because AIX mounts
/var as a normal jfs2 mount point, not tmpfs as Linux does. This means AIX does
not have any advantage with using /run directly, and is therefore better to
keep the install directory self-contained. /run is not a separate mount point on
AIX either.
Signed-off-by: Akash Kulhalli <akash.kulhalli@ibm.com>
To avoid nasty preprocessor defines everywhere, encapsulate everything into a
new header `platform.h`, that handles everything automatically. Doing this also
avoids situations where the preprocessor goes into a recursive header lookup,
trying to look for a header first under usr/include and finding the same file
that triggered the search in the first place. All AIX-specific headers now
live under their own folder at usr/lib/common/aix and are automatically
included when platform.h demands it.
None of these headers are not meant to be included directly - use platform.h
instead.
Signed-off-by: Akash Kulhalli <akash.kulhalli@ibm.com>
Similar to the global session and R/W session counters in pkcsslotds shared
memory segment, add another counter field that a token can use for counting
token specific things.
The pkcsslotd also tracks this counter, and ensures that if a process dies
without decreasing its counter properly, then pkcsslotd adjusts the global
counter automatically during garbage collection to maintain a consistent
counter value across all processes.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The use of transactional memory has never really worked for openCryptoki.
Also, many code places use locks, even with '--disable-locks'.
Option '--enable-locks' has been the default so far.
To retain backward compatibility, continue to accept the '--disable-locks'
option during configuration, but ignore it if it is specified. A warning
message is issued if --disable-locks' is still used.
With this change, there is no longer a need to maintain 2 copies of the
btree.c and sess_mgr.c source (btree.c and lock_btree.c, sess_mgr.c and
lock_sess_mgr.c), which contained the same code except the differences for
supporting transactional memory versus locks. Now only the version with
locks is retained, but it is renamed to not contain the 'lock_' prefix any
more.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Allow to specify the pkcsslotd user and the pkcs11 group during
configuration.
Use '--with-pkcsslotd-user=USER' and/or '--with-pkcs-group=GROUP'
to specify the user and group name. The defaults are 'pkcsslotd'
and 'pkcs11'.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Create the unix sockets and the PID file in /run/opencryptoki, and make
sure the /run/opencryptoki directory as well as the lock and log directories
are created during 'make install' as well as during system startup via
tmpfiles.d. Since the /run directory usually is within a tmpfs file system,
it won't exist after a system restart otherwise.
Also make the /run/opencryptoki directory be owned by the 'pkcsslotd' user
and the 'pkcs11' group, and only writable by the 'pkcsslotd' user.
That way, pkcsslotd can only be started by the 'pkcsslotd' user (or root).
Nevertheless, members of the 'pkcs11' group can still connect to the sockets,
and thus can still communicate with pkcsslotd.
The 'pkcsslotd' user is created (if not already existent) during 'make install'
and RPM installation, together with the 'pkcs11' group.
When the pkcsslotd is started as 'root', change its uid to 'pkcsslotd' to drop
privileges and capabilities. Any capabilities set on the executable file
are retained, regardless if started as root or as pkcsslotd user.
If started as root, pkcsslotd can create any missing base directories, otherwise
an error is reported. It is expected that the base directories have been created
during package installation and/or tmpfiles.d prior to starting pkcsslotd.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add a define OCK_HSM_MK_CHANGE_PATH for the path to the HSM MK change data,
and adjust the code to use that define instead of hard-coding it.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Check errors for all RW-lock or mutex initialization calls, and perform
proper error handling and cleanup if it fails.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Secure key tokens store the secure key blob in attribute CKA_IBM_OPAQUE
in their key object. During an HSM master key change, the secure key blob
is being re-enciphered with the new master key. This re-enciphered secure
key blob is stored in attribute CKA_IBM_OPAQUE_REENC while the HSM master
key change operation is active.
When a HSM master key change operation is finalized, the secure key blob
enciphered with the old master key is backed up into attribute CKA_IBM_OPAQUE_OLD,
and the re-enciphered secure key blob from CKA_IBM_OPAQUE_REENC becomes
the current one in CKA_IBM_OPAQUE.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Avoid race conditions between an API function being called in a
thread, and any HSM master key state changes being done in the event
thread. Each API function that involves objects or sessions state
acquire a read lock on the per-slot HSM MK change R/W lock. Anyone
that changes the HSM MK change state acquires a write lock. That
way the API functions can run concurrently unless a HSM MK change
state changing operation is performed.
This is implemented in the API layer so that tokens do not have to
care about this themselves. Tokens that support HSM MK changes,
initialize the R/W lock and thus tell the API layer to perform locking
on each API call. Tokens that do not support HSM MK changes, are
not affected, and do not use an R/W lock.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add definitions for HSM master key change events used for communicating
between the pkcshsm_mk_change tool and the tokens.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add utility functions to serialize and de-serialize master key operation
state information, and allow to store and load them to/from files.
These functions will be used by the pkcshsm_mk_change tool, as well
as by tokens supporting concurrent master key changes.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add mechanisms CKM_AES_XTS and CKM_AES_XTS_KEY_GEN as well as
key type CKK_AES_XTS according to PKCS#11 version 3.0.
Add common code support for generating AES-XTS keys, perform
encryption/decryption as well as wrap/unwrap with AES-XTS keys.
Signed-off-by: Vishnudatha Kanjur <kanjur@ibm.com>
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add defines for mechanisms CKM_IBM_ECDSA_OTHER and CKM_IBM_BTC_DERIVE
and there mechanism parameter structures.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
C_SessionCancel terminates active session based operations.
To identify which operation(s) should be terminated, the flags parameter
should be assigned the logical bitwise OR of one or more of the bit
flags defined in the CK_MECHANISM_INFO structure.
If no flags are set, the session state will not be modified and CKR_OK
will be returned.
If a flag is set for an operation that has not been initialized in the
session, the operation flag will be ignored and C_SessionCancel will
behave as if the operation flag was not set.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Currently only CK_TOKEN_INFO.ulSessionCount is maintained with the
total number of sessions open by a token, but ulRwSessionCount is
set to CK_UNAVAILABLE_INFORMATION.
Besides the total number of sessions also maintain the number of R/W
sessions, so that ulRwSessionCount can be returned with accurate
information.
Similar as for the total number of sessions, the counter is kept in
the shared memory segment of the pkcsslotd. It exists once as global
counter, and once per process. When a process dies without unregistering
from pkcsslotd, the garbage collector of pkcsslotd decrements the global
counter by the amount of the per-process counter to keep the global
counter consistent.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
