For better scripting capabilities, the SO PIN and the RACF password can
optionally be supplied via options -R and -S. If not specified you are
prompted for them.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
If -slot is specified then create the new ICSF token at the given slot number.
Otherwise the next free slot is used.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
If relative file names are specified for the SASL key and certificates,
store the absolute path of them into the ICSF token config file.
This makes it location independent.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Since SASL authentication does not require unlocking the token master key
to obtain an RACF password, public sessions (sessions opened without a
prior User or SO login) are supported for accessing and operating on public
objects when using SASL. In contrast, Simple authentication requires a User
or SO login before token operations can be performed because the RACF
password must be decrypted from disk using the token master key.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Use 'pkcsicsf -p <token-name>' to change the RACF password of an existing
ICSF token.
The pkcsicsf tool updates the RACF file under the XProcLock, so the ICSF
token must read the RACF file under the XProcLock. This prevents concurrent
reads on a RACF file that is currently modified.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Similar to the FIPS-compliant token data store format of the other tokens,
define a new token data store format for the ICSF token.
The new data format is used when the ICSF token has 'tokversion = 3.28'
in the slot definition in opencryptoki.conf. Existing ICSF tokens continue
to work unchanged. New ICSF tokens added via the pkcsicsf tool will always
have 'tokversion = 3.28' and thus use the new data format.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Not all variables ('@...@' placeholders) in man pages were correctly
substituted by AC_CONFIG_FILES or the existing SED rules.
Introduce a common substitution rule for man pages and process all
man pages with it.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Using pkcsicsf with '-a all' adds all available ICSF tokens. Mention this in
the man page.
For each added token, pkcsicsf prompts for the SO pin to set. Mention the
token name for which the SO pin is prompted.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Using the global slot_data variable might cause issues when multiple ICSF
token instances are used. This variable is an array indexed by slot number,
holding the pointer to the slot data in the shared memory segment of the
token.
There is no need for this global variable, just remember the pointer to
the slot data in the shared memory segment of the token in the token
private data.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Currently the ICSF token is added using 'pkcsicsf -a' and the default
SO pin (87654321) must be used with it. Only then a subsequent setting
of the SO pin via 'pkcsconf -P' works (where the old pin is also the
default SO pin).
The reason for this is that 'pkcsicsf -a' does not create a NVTOK.dat,
and thus, when the token comes up the very first time, the NVTOK.dat
is created, but with the SO default pin. This happens for example
during 'pkcsconf -P', before the new PIN is set.
Update pkcsicsf tool to also create an initial NVTOK.dat file which
contains the hash of the user supplied SO pin. Thus, any SO pin can
be used with 'pkcsicsf -a', and this already sets the SO pin.
The initial NVTOK.dat is a too short version, and will be written in
its full length on the very first use of the token.
With this change no subsequent 'pkcsconf -P' is required (but possible),
the desired SO pin is already set and the token is already initialized.
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>
Restrict the token name (tokname) and config name (confname) that is
specified in opencryptoki.conf to only contain certain characters.
They must not be '.' or '..', and must not contain '/'.
If the confname specified an absolute path, no restriction is applied.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
README.md:
- Fix "Fox example" typo (should be "For example")
- Swap CPPFLAGS/LDFLAGS values in configure example (-I for CPPFLAGS,
-L for LDFLAGS)
- Fix word order "which features is it" to "which features it is"
- Add missing verb "set" in DISTCHECK_CONFIGURE_FLAGS note and add
closing period
- Restore indentation of "For more installation information" line
man/man1/p11sak.1.in:
- Fix "a AES" and "a AES-XTS" to "an AES" and "an AES-XTS"
- Capitalize proper nouns "edwards" and "montgomery" in curve descriptions
- Fix "Coyping" typo to "Copying" in two section headings
- Remove stray "command, and the" and fix "supress" to "suppress" in
--force|-f option description
- Fix missing space in "samealgorithm" (two occurrences)
Signed-off-by: Karel Srot <ksrot@redhat.com>
Add support for the new ECDH_*_AES_KEY_WRAP mechanisms to the p11sak
wrap-key and unwrap-key commands.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add support for PKCS#11 v3.2 ML-DSA and ML-KEM key types to p11sak.
P11sak can now generate, list, export, import, extract, etc such keys.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add key types 'ec-edwards' and 'ec-montgomery' to the p11sak tool,
and allow to generate, import, and export keys of these types.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
With the '-e'/'--ep11-session-id' option the list-key command shows the
EP11 session IDs of the listed keys. If a key is not bound to an EP11
session, then '-' or '[none]' is displayed.
This only works for EP11 tokens.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Enhance the p11sak tool to support IBM ML-DSA and IBM ML-KEM keys.
It can generate IBM ML-DSA and IBM ML-KEM keys, can list them and their
attributes, can remove, alter, etc them, just like with the other key types
as well.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Make BLS12-381 known to p11sak, so that it can generate EC keys of this curve.
Public EC key objects of the BLS12-381 curve needs to have CKA_DERIVE=TRUE to
be used with the aggregate mechanism. Thus, allow to specify the CKA_DERIVE
attribute also for the public part of an EC key.
Note: As per PKCS#11 standard, public keys don't have the CKA_DERIVE attribute,
but we allow it anyway to be able to support BLS12-384 aggregation operations.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
When exporting private keys, option '--encrypted-pem' can now be specified.
This causes the PEM file to be encrypted using AES-CBC and an AES 256 bit key
that is derived from the password.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Describe how to generate password protected or HSM protected client keys
and certificates, and how to use them with p11kmip.
While at it, fix a few typos.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Allow RSA key sizes of up to 16384 for the p11sak tool.
A token might not support all these RSA key sizes, but will return an
error if an RSA key size is used that is not supported by the token.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
This tool may be used to export AES secret keys from a PKCS#11 token repository to a KMIP
server by wrapping them under a shared RSA key pair. This tool may also import AES secret
keys from a KMIP server to a PKCS#11 token repository using the same method.
Signed-off-by: John Craig <john.craig@ibm.com>
