For unflattening array attributes there was no length check for the attribute
elements within the array attribute to check if the length information within
the array elements is within the array attribute buffer.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
For unflattening ULONG attributes that are stored as 32 bit ULONG a length
check was missing to check if the 32 bit value still is within the buffer
boundaries.
Also check the length before allocating an attribute buffer. Otherwise
a garbage length may cause a very large memory allocation that can cause
memory pressure for other processes.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add support for CKM_PUB_KEY_FROM_PRIV_KEY in common code. This can be
supported transparently for the tokens, by using the SPKI contained in
attribute CKA_PUBLIC_KEY_INFO to extract the public key from.
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>
Always call object_mgr_restore_obj_withSize() directly and with a proper size.
This ensures that tampered object data does not cause out-of-bounds access.
With that, any check for the special size of -1 can be removed, because now
the size must always be the correct size. This also applies to function
template_unflatten_withSize().
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>
For keys of class CKO_SECRET_KEY and CKO_PRIVATE_KEY set the CKA_PRIVATE
attribute to TRUE by default. For other objects the default remains
CKA_PRIVATE=FALSE.
In case USER is not logged in, the default for CKA_PRIVATE also remains at
FALSE, because a public or SO session does not have access to private
objects, and thus private keys can not be created in a public or SO session.
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>
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>
Implement the CKM_RSA_AES_KEY_WRAP mechanism by internally performing mechanism
CKM_AES_KEY_GEN for generation of the temporary wrapping key, mechanism
CKM_AES_KEY_WRAP_KWP for wrapping the to-be wrapped key, and mechanism
CKM_RSA_PKCS_OAEP for wrapping the temporary AES wrapping key.
Afterwards, destroy the temporary AES key.
The temporary AES wrapping key object is generated as a session object with
CKA_HIDDEN=TRUE, so that it can not be found by means of C_FindObject.
It exists only for a very short time, but it should never be able to be found
by a PKCS#11 application whatsoever.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The PKCS#11 standard defines the CKA_ALWAYS_AUTHENTICATE attribute for private
keys (i.e. objects with class=CKO_PRIVATE_KEY) only. It may only be set to
CK_TRUE when CKA_PRIVATE is also CK_TRUE.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Add support for generating IBM Dilithium keys with mechanism
CKM_IBM_DILITHIUM for the soft token using the 'oqsprovider'.
The soft token can only support those Dilithium variants that the
'oqsprovider' supports. Currently, these are the 3 round 3 variants
with object IDs '1.3.6.1.4.1.2.267.7.4.4', '1.3.6.1.4.1.2.267.7.6.5',
and '1.3.6.1.4.1.2.267.7.8.7'. Those are called 'dilithium2',
'dilithium3' and 'dilithium5' by the 'oqsprovider'.
This is an experimental feature, it may change in an incompatible way in
the future! It is not known how the 'oqsprovider' changes in the future,
and if it then still supports the Dilithium variants known by Opencryptoki.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The private key components of Dilithium and Kyber keys should be sensitive,
and thus should not be retrievable if CKA_SENSITIVE is true or CKA_EXTRACTABLE
is false.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
For OpenSSL BIGNUMs containing sensitive private key material, use
BN_secure_new() to allocate the BIGNUM on OpenSSLs secure heap.
Also clean any buffers that might contain sensitive data before freeing it.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Similar to keys and certificates, a HW feature object also has a 'subclass'
attribute, i.e. CKA_HW_FEATURE_TYPE. This subclass is used when validating
attributes during C_SetAttributeValue() and C_CopyObject().
Without this fix, setting attributes of a HW feature object, or copying a
HW feature object will most likely fail with CKR_ATTRIBUTE_VALUE_INVALID,
because the subclass is not known and thus the attribute validation fails.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Allow to remove an attribute from a template.
Also refactor template_update_attribute() to use the new
template_remove_attribute() function to remove the attribute
if it is already existing.
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>
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>
No token is supporting JUNIPER key type anyway, so remove all
common code related to JUNIPER key type as well.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
No token is supporting BATON key type anyway, so remove all
common code related to BATON key type as well.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
No token is supporting SKIPJACK key type anyway, so remove all
common code related to SKIPJACK key type as well.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
No token is supporting IDEA key type anyway, so remove all
common code related to IDEA key type as well.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
No token is supporting CAST key types anyway, so remove all
common code related to CAST key types as well.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
No token is supporting RC2, RC4, and RC5 key types anyway, so remove all
common code related to RC2, RC4, and RC5 key types as well.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
No token is supporting KEA key type anyway, so remove all
common code related to KEA key type as well.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
No token is supporting CDMF mechanisms anyway, so remove all
common code related to CDMF mechanisms as well.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Return CKR_ATTRIBUTE_READ_ONLY if this attribute is attempted to
be modified via C_SetAttributeValues or C_CopyObject. When keys are
created by means of C_GenerateKey, C_GenerateKeyPair, C_DeriveKey,
C_UnwrapKey, or C_CreateObject the attribute value must be FALSE,
otherwise CKR_ATTRIBUTE_VALUE_INVALID is returned.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
PKCS#11: "The Cryptoki attributes which can be modified during
the course of a C_CopyObject operation are the same as the Cryptoki
attributes which are described as being modifiable, plus the three
special attributes CKA_TOKEN, CKA_PRIVATE, CKA_MODIFIABLE and
CKA_DESTROYABLE."
CKA_COPYABLE can not be set to TRUE once it was set to FALSE, so it
also can not be set to TRUE during C_CopyObject.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Some ULONG attributes are always stored as 32 bit ULONG, while others are stored
in the length that CK_ULONG is on the systems architecture. I.e. on a 64 bit
system a CK_ULONG is 64 bit in size, while on a 32 bit system it is 32 bit in size.
The same logic must also be used when unflattening attribute-array elements,
when an element is such an attribute that is always stored as 32 bit ULONG.
Also fix an error when flattening an attribute-array element.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The following attributes can not be modified after object creation:
CKA_ALLOWED_MECHANISMS, CKA_WRAP_TEMPLATE, CKA_UNWRAP_TEMPLATE, and
CKA_ALWAYS_AUTHENTICATE. Return CKR_ATTRIBUTE_READ_ONLY if those
attributes are being modified.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The secure key blob for all the keys used with the CCA token is
stored in an attribute CKA_IBM_OPAQUE. The content is a so called
secure CCA key token and a description can be found in the
"Secure Key Solution with the Common Cryptographic
Architecture Application Programmer's Guide".
There is a requirement to export and import these raw secure key token
objects. Export is simple: Just fetch the value the CKA_IBM_OPAQUE
attribute for a key object and dump it for example into a file.
Importing such a value was until now not supported. This patch
enables the possibility to import such a raw CCA key token object with
the C_CreateObject() pkcs#11 function.
To import an CCA DES key token, use a template with these mandatory
attributes:
CKA_CLASS = CKO_SECRET_KEY
CK_KEY_TYPE = CKK_DES
CKA_IBM_OPAQUE - with the CCA DES key token
to import an CCA DES3 key token, use a template with these mandatory
attributes:
CKA_CLASS = CKO_SECRET_KEY
CK_KEY_TYPE = CKK_DES3
CKA_IBM_OPAQUE - with the CCA DES3 key token
to import an CCA AES data key token, use a template with these mandatory
attributes:
CKA_CLASS = CKO_SECRET_KEY
CK_KEY_TYPE = CKK_AES
CKA_IBM_OPAQUE - with the CCA AES data key token
CCA AES cipher key token import is not supported yet.
to import an CCA internal RSA private key token, use a template with
these mandatory attributes:
CKA_CLASS = CKO_PRIVATE_KEY
CKA_KEY_TYPE = CKK_RSA
CKA_IBM_OPAQUE - with the CCA RSA private key token
to import an CCA RSA public key token, use a template with these
mandatory attributes:
CKA_CLASS = CKO_PUBLIC_KEY
CKA_KEY_TYPE = CKK_RSA
CKA_IBM_OPAQUE - with the CCA RSA public key token
to import an CCA HMAC key token, use a template with these mandatory
attributes:
CKA_CLASS = CKO_SECRET_KEY
CKA_KEY_TYPE = CKK_GENERIC_SECRET
CKA_VALUE - with a dummy value the size in bytes of the clear key
byte size.
CKA_IBM_OPAQUE with the CCA RSA private key token.
to import an CCA internal EC private key token, use a template with
these mandatory attributes:
CKA_CLASS = CKO_PRIVATE_KEY
CKA_KEY_TYPE = CKK_EC
CKA_IBM_OPAQUE - with the CCA EC private key token
to import an CCA EC public key token, use a template with these
mandatory attributes:
CKA_CLASS = CKO_PUBLIC_KEY
CKA_KEY_TYPE = CKK_EC
CKA_IBM_OPAQUE - with the CCA EC public key token
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
new debug function to hexdump mem region TRACE_DEBUG_DUMP
new debug function to trace one attriubte TRACE_DEBUG_DUMPATTR
new debug function to trace a template TRACE_DEBUG_DUMPTEMPL
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Certain attributes, such as CKA_WRAP_TEMPLATE and CKA_UNWRAP_TEMPLATE
contain an array of attributes. These kind of attributes need special
handling at various places, e.g. when storing and reading token objects
from the token object directory, but also when templates are copied or
populated.
Note: Although parts of the token object load and store code has been
previously duplicated to source file usr/sbin/pkcscca/pkcscca.c, the
current changes do not need to be synchronized over to pkcscca.c.
pkcscca.c does not care about any array-attributes, it only looks at some
standard attributes, such as CKA_CLASS, CKA_KEY_TYPE, CKA_VALUE, and
CKA_IBM_OPAQUE. The way array-attributes are stored on disk allows that
such attributes are treated as regular attributes with an arbitrary payload.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Currently re-authentication for each use of a key is not supported
by Opencryptoki, so do not allow to set CKA_ALWAYS_AUTHENTICATE to
TRUE.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Function template_update_attribute now rturnd CKR_HOST_MEMORY if no
more memory is available. Fix all callers to check for the return code
of template_update_attribute and cleanup appropriately.
Closes: https://github.com/opencryptoki/opencryptoki/issues/339
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
When accessing attributes, check that the length is matching to the
attribute type, e.g. before reading a CK_ULONG or CK_BBOOL attribute
value, make sure that the attribute value size matches the type.
Also add checks for accessing empty attributes. An empty attribute
has a length of 0, and a pointer of NULL. Ensure to not use an NULL
pointer when dealing with an empty attribute.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
If CKA_DESTROYABLE is FALSE, then the object can not be destroyed.
If CKA_COPYABLE is FALSE, then the object can not be copied.
The default for both is TRUE.
CKA_DESTROYABLE can be updated via C_SetAttributeValue at any time,
unless CKA_MODIFIABLE is FALSE. CKA_COPYABLE can only be update to
FALSE (if CKA_MODIFIABLE=TRUE). Once it is FALSE, it can not be
updated to TRUE anymore. The default for both attributes is TRUE.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The CKA_TRUSTED attribute can be set for certificates, public and secret key
objects. This attribute can be set to TRUE only be SO after object creation.
Once attribute CKA_WRAP_WITH_TRUSTED is set to TRUE, it becomes read only.
If a key has CKA_WRAP_WITH_TRUSTED = TRUE, then it can only be wrapped
with a key that has CKA_TRUSTED = TRUE.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
When copying attribute CKA_UNIQUE_ID a buffer overrun by 1 byte
occurs when generating a new unique id for the copied object.
Fixes: 07ee26eeef
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
