For CBC-PAD the output buffer size sent to ICSF was inflated to at least
cipher_text_len so the server does not send back RSN_TOO_SHORT for the
padded-then-unpadded output. Validate length against the inflated clear_len
(what we told the server) and bv_clear_data.bv_len against the caller's
real buffer. When the real buffer is too small for the unpadded result,
propagate CKR_BUFFER_TOO_SMALL so the caller can retry.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The EP11 host library does not necessarily report the required output length
when an encrypt or decrypt update call fails with CKR_BUFFER_TOO_SMALL.
In this case, report an upper bound of the output length of the update
operation: Less than one block of data can be buffered by a previous update,
thus the output is at most the input length rounded up to a multiple of the
block size. A length already reported by the EP11 library (larger than the
passed one) is kept.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
ECB, XTS encrypt and decrypt as well as CBC decrypt check that the buffer
is at least as large as the input and return CKR_BUFFER_TOO_SMALL if not,
but they do not update *out_data_len with the required buffer size.
This applies in the same way to to AES, DES, and DES3.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
In aes_key_wrap_decrypt() when the PKCS#7 unpadding fails, cleanse the
output buffer to not leak decrypted data in case of a failure.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
As per PKCS#7, the pad bytes must all equal the padding value, i.e. the number
of bytes to pad. Every byte that could be padding is examined, so the time
taken does not depend on the padding. Also make sure that the padding
value is not larger than the block size.
Suggested-by: Alexandre Laroche <larochealexandre@hotmail.com>
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Fix the AES/DES/DES3-CBC-PAD decryption handling to not produce more output
than allowed as per output buffer length.
Also check for errors during strip_pkcs_padding() to detect padding errors
and fail the operation.
With the buffer size checking, the IV must be saved before the actual
operations and must be restored in case of a CKR_BUFFER_TOO_SMALL error.
The operation might update the running IV in the context. However, the
caller must be able to retry with the original IV intact using a large
enough output buffer.
Suggested-by: Alexandre Laroche <larochealexandre@hotmail.com>
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
For Edwards and Montgomery private keys RFC 8410 defines that the private
key is an OCTET-STRING, and not a SEQUENCE as for EC keys (RFC 5915).
Fix this by encoding and decoding the correct PKCS#8 format. For decoding,
Edwards and Montgomery private keys encoded using the wrong EC-key style are
still accepted for backward compatibility.
Fixes: 3fd5120a41
Reported-by: Alexandre Laroche <larochealexandre@hotmail.com>
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
secret_key_unwrap() and priv_key_unwrap() set CKA_SENSITIVE to FALSE and
CKA_EXTRACTABLE to TRUE on every unwrapped key, after the caller's
template, and the unwrapping key's CKA_UNWRAP_TEMPLATE, had already been
validated and merged into the new object. Both were silently overwritten:
- a template asking for CKA_SENSITIVE = TRUE and CKA_EXTRACTABLE = FALSE
gave a key whose value could be read in clear with
C_GetAttributeValue(CKA_VALUE) and wrapped out again;
- an unwrapping key whose CKA_UNWRAP_TEMPLATE requires CKA_SENSITIVE =
TRUE or CKA_EXTRACTABLE = FALSE did not get that policy applied to the
keys unwrapped with it.
C_UnwrapKey returned CKR_OK in both cases.
Stop overwriting these two attributes. object_create_skel() already
starts the object from the class defaults (CKA_SENSITIVE = FALSE,
CKA_EXTRACTABLE = TRUE), lets the token's t_set_attrs_for_new_object()
supply its own defaults, and merges the template over them. CKA_LOCAL,
CKA_ALWAYS_SENSITIVE and CKA_NEVER_EXTRACTABLE are still set to FALSE, as
PKCS#11 requires for an unwrapped key.
For a template that does not specify the two attributes, under an
unwrapping key without a CKA_UNWRAP_TEMPLATE, tokens that keep the class
defaults give the same key as before. Tokens that default CKA_SENSITIVE
to TRUE (EP11 and CCA for private keys, and for secret keys when
FORCE_SENSITIVE is enabled) now apply that default to unwrapped keys
too, as they already do for generated and derived keys; until now the
unwrap path overwrote it with FALSE.
Signed-off-by: Alexandre Laroche <larochealexandre@hotmail.com>
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
If the source has an empty context, then also set the context to empty on the
target before returning early. Any left over context pointers in the target
might otherwise be freed later when the copy is freed.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
When the deep-copy if the EC-AGGREGATE mechanism parameter fails, cleanup
the operation before returning.
The EC-AGGREGATE deep-copy function must NULLify the pAggrElements field
before attempting to copy. The destination starts as a shallow memcpy of
the source, so it held the caller's pointers. If a malloc failed partway
through, it would have freed those caller-owned buffers.
While at it, move the deep-copy case into the already existing switch
above inside the mechanism parameter guard. Also check the size of the
mechanism parameter to be the expected length before deep-copying it.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
In case deep-copying the ML-DSA mechanism parameter fails, don't continue,
but go to the done label.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Saving the operation state via C_SetOperationState() only works for
mechanisms with mechanism parameters that can be serialized. Thus, mechanisms
that use a mechanism parameter that gets deep-copied into the context can
not be saved. Set the state_unsaveable flag for those mechanisms. This
will cause C_SetOperationState() to fail with with CKR_STATE_UNSAVEABLE.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Some mechanisms keep a deep copy of its mechanism parameter in the operation
context. Normal operation cleanup deep-frees them properly, but session_free()
and session_mgr_close_session() do not deep-free them, but just free the outer
structure, leaking any inner allocations. This happens when a session is
closed that has a still active operation with such a mechanism.
Fix this by directing the cleanup to the regular operation cleanup helpers
that already do it right.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Functions der_decode_ECPrivateKey() and der_decode_ECPublicKey() can be called
to decode a EC, Edwards, or Montgomery key. For EC, the OID of the curve is
the param in the AlgorithmIdentifier, and for Edwards and Montgomery the OID
in the AlgorithmIdentifier specifies the curve OID directly. Check that the
OID is one of the known curves for EC, and one of the expected Edwards or
Montgomery OIDs for Edwards and Montgomery respectively.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Function ber_decode_SPKI() extracts the OID and the parameters from the
AlgorithmIdentifier. It assumes that the BER encoded OID has a single byte
length field. While this is the case for all used OIDs, an malformed
SPKI could have an AlgorithmIdentifier that has a multi-byte length
OID. Decode the field length and do not assume a single byte length.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The decoding functions for public and private keys compare the decoded
AlgorithmIdentifier from the key material with constants to check for valid
key types. This check does not check the length of the decoded
AlgorithmIdentifier and thus might overrun the buffer producing an
out-of-bounds read for too short AlgorithmIdentifiers.
Reported-by: Stuart Thomas <stuart.thomas@triageforge.co.uk>
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The min and max key sizes for DES, DES3 and HMAC mechanisms were zero.
Update this to the correct key sizes.
Some mechanism do not have the CKF_HW flag set where it should be set,
or vice versa. Fix that.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
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>
When the login mechanism is not ICSF_CFG_MECH_SIMPLE, then there is no
wrap key, and thus variable 'new_wrap_key' is never set, but is later
on copied to 'user_wrap_key' in 'tokdata' (which also is never used).
Initialize the variable with zeros to silence the warning.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The attributes CKA_ENCAPSULATE and CKA_DECAPSULATE have been introduced
with PKCS#11 v3.2, but ICSF does not support them. This cases failures
for various test cases (i.e. RSA key gen) when these attributes are in
the templates for the keys.
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>
The check for attrs being nun-NULL is too strict. If the number of attributes
is zero, then attrs can be NULL.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
As per PKCS#11 standard, mechanism CKM_RSA_PKCS can only wrap secret keys,
but not private keys. Reject this accordingly with CKR_KEY_NOT_WRAPPABLE
for wrapping, and CKR_ARGUMENTS_BAD for unwrapping, like common code
also does.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
When the key material is too large to be wrapped by a wrapping key, ICSF
returns 8 / 11000 which is translated into CKR_DATA_LEN_RANGE. For
key wrapping this is mapped to CKR_KEY_SIZE_RANGE which fits better.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
ICSF only accepts uncompressed EC Points when creating an EC public key
object, as well as for ECDH derive as public data.
Convert compressed or raw EC points to the uncompressed form before passing
it to ICSF.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Newer KDF values might not fit into a single byte. Send them as 32 bit
big endian value instead of the single byte.
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>
Ignore the error on store_object_strength(), but when adding the mapping to
the tree fails, then free the mapping and report an error.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Make sure that C_Login, C_SetPIN, C_InitPIN, C_InitToken do not read or
update any token files or any field in the token shared memory without
holding the XProcLock.
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>
Only report CKM_EC_EDWARDS_KEY_PAIR_GEN, CKM_EC_MONTGOMERY_KEY_PAIR_GEN,
and CKM_EDDSA as available only if the EP11 version prerequisites are
fulfilled.
Mechanism CKM_EC_EDWARDS_KEY_PAIR_GEN and CKM_EC_MONTGOMERY_KEY_PAIR_GEN
are mapped to CKM_EC_KEY_PAIR_GEN. However, not only CKM_EC_KEY_PAIR_GEN
must be supported, but also the prerequisites for Edwards and Montgomery
support of EP11 must be fulfilled.
Mechanism CKM_EDDSA also requires that the prerequisites for Edwards
support of EP11 is fulfilled.
Fixes: a1156d179d
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Use a common SPKI encoding function for all public key encoding functions,
instead of having each public key encoding function manually encode the
SPKI.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Refactor the code to encode and decode the BER primitives. There was lots of
duplicated code in these functions. This is now refactored out into separate
helper functions.
Also the TLV encoding and decoding in these helpers have been refactored to
use a more streamlined implementation without many similar looking if cases.
With this, encoding and decoding data with more than 3 length octets (16 MB)
is now supported.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The use of liblber has been eliminated for most of the cases already.
The only leftover cases are in RSA, DSA, and DH public key encoding
functions for encoding BIT STRINGs.
Update these leftover places and use the already existing
ber_encode_BIT_STRING() function instead.
With this, '-lber' can be removed from the make files for most of
the tokens and tools. The ICSF token still requires liblber for its
LDAP communication.
Also adjust the configure script and example RPM spec accordingly.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The finial CKF_HW flag is automatically derived at runtime, the flag in the
ref_mech_list is ignored. For consistency, remove it. It has no effect anyway.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Don't include the CKF_HW flag. The soft token never sets the HW flag, because
its all software crypto.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The common code supports those mechanisms only for the CKK_DES3 key type,
thus the supported key sizes is 24 bytes.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
For REENCIPHER:
Verify the hardware state before activating the operation:
- current WK must match the token's expected WKVP
- new WK register must hold the WKVP claimed in the event
This mirrors the check done in INITIATE_QUERY and prevents a spurious
REENCIPHER event from activating a stranded operation state or switching
to single-APQN mode unnecessarily.
For FINALIZE:
Verify that the new WK has actually been activated on the card (current
WK == new_wkvp) before promoting re-enciphered key blobs. This mirrors
the check done in FINALIZE_QUERY and prevents a spurious FINALIZE event
from committing key objects when the new WK has not actually been activated
on the card.
For CANCEL:
No hardware check needed - cancellation only discards the re-enciphered
blobs and is safe regardless of hardware state.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
For REENCIPHER:
Verify the hardware state before activating the operation:
- current MK must match the token's expected MKVP
- new MK register must hold the MKVP claimed in the event
This mirrors the check done in INITIATE_QUERY and prevents a spurious
REENCIPHER event from activating a stranded operation state when no
matching new MK is actually loaded.
For FINALIZE:
Verify the hardware state matches the expected new MKs stored in the
active operation before promoting re-enciphered key blobs. This mirrors
the check done in FINALIZE_QUERY and prevents a spurious FINALIZE event
from committing key objects when the new MK has not actually been activated
on the card.
For CANCEL:
No hardware check needed - cancellation only discards the re-enciphered
blobs and is safe regardless of hardware state.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
CCA for Linux on x64 and Power as well as CCA for AIX checks the SHA3
Access Control Points 0x03BD-0x03C0 when performing SHA3 operations.
By default these ACPs are OFF. To enable SHA3 mechanisms for the CCA
token, all 4 of them must be turned ON.
CCA on Linux on IBM Z does not check these control points.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Some newly added mechanism are missing in the EP11 control point filter
config file. Add the missing mechanisms.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Sentence "CKA_IBM_PROTKEY_EXTRACTABLE and CKA_EXTRACTABLE cannot both be true"
is not entirely true. They can both be TRUE if control point
XCP_CPB_ALLOW_COMBINED_EXTRACT is enabled.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The ICSF token supportes creating objects in SO sessions, but rejected
finding any objects via C_FindObjectsInit in such sessions.
Fix this inconsistency. User sessions (RO or RW) see all objects that
ICSF returns. However, SO sessions may only see public objects
(CKA_PRIVATE=FALSE). Add appropriate filtering to find only the desired
objects.
Trying to use or find objects in public sessions will always fail with
CKR_USER_NOT_LOGGED_IN. Without a login no connection to the LDAP server
is available, and thus no object access is possible.
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>
