Add support for some IBM specific mechanisms supported by OpenCryptoki for the RPC protocol #415
Conversation
ifranzki
force-pushed
the
ibm-specific-mechs
branch
from
2f072a6
to
949daa1
Compare
There was a problem hiding this comment.
Sorry for the delay. The changes look good to me, though I have a few concerns: whether those new mechanisms work without recursive attributes (#366) and need to wait for PKCS#11 3.0 support. Perhaps you could point me to the actual usage in openCryptoki?
All in all, the RPC changes seem reasonable and we could merge them first.
Yes this works with just regular C_Encrypt/C_Decrypt functions as of PKCS v2.40. |
None if these changes are dependent to recursive attributes. Commit a8f205c is the only one that is related to attribute-array attributes, but is not really required for this PR. Opencryptoki does support attribute-array attributes in general, and some of the opencryptoki testcases use them, so I thought I could get those tests to work without your PR, but it seems not. But this does not matter for these changes. |
Signed-off-by: Ingo Franzki <[email protected]>
Used by CKM_ECDH1_DERIVE, CKM_IBM_EC_X25519 and CKM_IBM_EC_X448. Signed-off-by: Ingo Franzki <[email protected]>
Signed-off-by: Ingo Franzki <[email protected]>
Signed-off-by: Ingo Franzki <[email protected]>
Signed-off-by: Ingo Franzki <[email protected]>
They take a 16 byte (AES) or 8 byte (DES/DES3) IV as mechanism parameter. Signed-off-by: Ingo Franzki <[email protected]>
The take a mechanism parameter of type CK_MAC_GENERAL_PARAMS which is a CK_ULONG. Signed-off-by: Ingo Franzki <[email protected]>
It takes the the public value of the other party as mechanism parameter. Signed-off-by: Ingo Franzki <[email protected]>
When the buffer is not NULL, but the length is zero then treat this as an empty message. Serialize this in a special way so that the server can restore the same situation. Example: Terminate an operation via C_XxxFinal, but there is no more data for the final part. A call to C_XxxFinal with buffer=NULL and length=0 would be treated as a size query, and would not terminate the operation. So the way to terminate the operation without more data is to specify buffer!=NULL but length=0. When sending a byte array, and the buffer is NULL, and the length is zero, don't treat this is invalid, but as empty message. Example: C_XxxUpdate with an empty message. Signed-off-by: Ingo Franzki <[email protected]>
It takes a CK_AES_CTR_PARAMS structure as mechanism parameter. Signed-off-by: Ingo Franzki <[email protected]>
It takes a CK_GCM_PARAMS structure as mechanism parameter. Signed-off-by: Ingo Franzki <[email protected]>
ifranzki
force-pushed
the
ibm-specific-mechs
branch
from
949daa1
to
6c07b98
Compare
|
Thank you! |
This patch series adds support for a couple of IBM specific mechanisms (and attributes), as well as some standard mechanisms that use mechanism parameters that were not supported so far for the RPC protocol.
All these mechanisms are supported by OpenCryptoki (https:/opencryptoki/opencryptoki) and we would like to make sure that those mechanisms can be used with p11-kit's remote-PKCS#11 feature.
I have tested this by running OpenCryptoki's testcases (https:/opencryptoki/opencryptoki/tree/master/testcases - slightly modified) over p11-kit's remote PKCS#11 interface. Some modifications in OpenCryptoki's testcases were required to let it use the p11-kit's p11-kit-client.so instead of OpenCryptkis's shared library, as well as to avoid the use of things not supported by p11-kit: Attribute-array attributes (CKA_WRAP_TEMPLATE etc), and PKCS#11 version 3.0 interfaces.