SoftHSM implements functions in accordance with the PKCS#11 v2.20 specified by RSA Security Inc. Read the API for a more detailed view of this interface.
The tokens are created by the user with the tool softhsm. Each token is initialized with a security officer PIN and an user PIN. The tokens are then added to the slots by the user in the config file.
Each advanced interaction with SoftHSM requires a session. The maximum number of concurrent sessions is limited to 2048 by default. This limit can be changed by editing the config file (config.h) in the source code tree before compiling the library.
A session can either be in Read/Write mode or Read-only mode, which is decided by the user upon the creation of the session.
Each session caches a copy of a cryptographic key, whenever it is used. This is to save time by not loading key material from the attributes every single time it is used by the session. To limit the size of the key cache, it is recommended to use a session for a limited time to avoid loading every single key into the memory.
Access to the objects is treated in accordance with the PKCS#11 standard.
SoftHSM currently only supports private keys, public keys, and certificates (CKO_PUBLIC_KEY, CKO_PRIVATE_KEY, and CKO_CERTIFICATE).
Only one login is required for multiple sessions on a single slot.
SoftHSM is supporting all the attributes connected to general objects, private keys, public keys, certificates, and the RSA algorithm with some minor exceptions. CKA_ALLOWED_MECHANISMS and CKA_WRAP_TEMPLATE is not supported due to their complexity.
The database for a token, which contains all the information about the objects, is loaded from the location indicated in the config file. All the information is stored unencrypted.
Only a hashed version of the SO's and user’s password is stored.
The library can be initialized with or without mutex locking. It is safe to use multiple threads with one session per thread. It will never be safe to use multiple threads in one session, because simultaneously use of e.g. the signing functions can give unexpected results.
Events like key generation, deletion of objects, errors, and function calls are logged to the syslog. The level of logging is defined by the user and the configuration script.
A backup of a token is simply done by copying the database file to a secure location.