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>
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>
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>
If object_init_lock() or object_init_ex_data_lock() fails after the
template is assigned to 'o', then the template is not freed at the
'done' label.
Free the object's template explicitly if it is not NULL.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Some tokens may have a need to attach arbitrary data to an object in memory.
This could for example be an OpenSSL PKEY that was created from the object's
attributes, or any other processing or state data that a token needs to keep
with the object.
This data only lives in memory, and is not saved to the disk when the object
is stored (i.e. for token objects).
Each object contains a R/W lock that must be used to protect the attached
data from being accessed concurrently by several threads. Any attempt to set
or update the attached data must be protected by a WRITE lock, while any
attempt to use or read the attached data must be protected by a READ lock.
This lock is independent from the object's template R/W lock. Thus, a token
can update the attached data, although it only has a READ lock on the object
itself (as long as the objects attributes are not updated).
A token may supply a free and a reload routine when attaching such data to an
object. Whenever the object is freed, the free routine is called to allow the
token to also free the attached data. Similarly, when the object is being
reloaded from disk, e.g. because another process has changed the object, the
reload routine is called to allow the token to re-create or update the attached
data. When the reload routine is called, the WRITE lock is being held.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Like other EP11 host library functions that operate on key blobs,
m_GetAttributeValue and m_SetAttributeValue may also return
CKR_SESSION_CLOSED when the session that the key blob is bound to
is not logged in into the adapter that is currently used for the
request.
For that the session must be passed through to the functions.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The object name within a token object payload must match the file name
it was loaded from. For private token objects (CKA_PRIVATE=TRUE) the
object name is part of the encrypted payload.
A mismatch may indicate that the token object file has been tampered,
for example due to a file rename or replacement. Don't load such
objects, since this is most likely not the expected object that is being
loaded.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Implement strength and policy parsing and enforce policies in all tokens. The
main object of the policy is the struct objstrength which carries the strength
of a key along with a flag specifying if the EC is allowed, and a (maximal)
signature length if this key is used to sign or verify and the length of the
signature depends on the key.
A valid strength configuration has to be found. If no policy configuration is
found, policies are simply deactivated and keys are only classified according
to the strength definition, but can be used without restrictions. If both, a
strength and a policy configuration, are available, both have to be valid for
OpenCryptoki to start. If either of these two configurations fails to parse
or validate, OpenCryptoki will fail with a general error since the system is
not in a valid state.
The configuration files have to be owned by root:pkcs11 and have to have modes
0640. This is done for security reasons to prevent anybody except root from
altering the policy or strength definitions.
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com>
When attributes are changed via C_SetAttributeValues, give the token
a chance to react on an attribute modification. The token can, for
example, reject certain modifications, or it can perform additional
steps on an modification of certain attributes. Secure key tokens may
for example update the CKA_IBM_OPAQUE key blob to reflect the attribute
modifications.
The token specific set_attribute_values is also called when an object
is copied via C_CopyObject. While copying an object, attributes can be
modified or added, so this is basically the same as first copying the
object as-is, and then modify its attributes.
Signed-off-by: Ingo Franzki <ifranzki@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>
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>
Return CKR_TEMPLATE_INCONSISTENT when the template at C_CreateObject
does not contain a sub-class attribute, because this could also be
caused by an unknown object type.
Return CKR_ARGUMENTS_BAD if template is NULL.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
This ensures that an object can not be freed while it is still used
by another thread. The object might still be removed from a btree while another
thread is using it, but the object is not freed until its ref count is zero.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
There exist 2 almost equal functions named 'bt_node_free()' and
'bt_node_free_()'. The only difference is the signature of the callback
routine used. For one the callback just gets the node value, and for the
other it gets the node value and the STDLL_TokData_t of the token.
Simplify the code by removing the duplicate function and always use
the callback function with just the value.
Use the same callback function signature for bt_destroy().
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
