[Softhsm-develop] support for CKM_RSA_PKCS key un/wrapping

[Petr Spacek]

On 18.7.2014 10:29, Roland van Rijswijk - Deij wrote:
> Hi Petr,
>
> Petr Spacek wrote:
>> I have opened pull request #83 which adds support for CKM_RSA_PKCS key
>> un/wrapping.
>> https://github.com/opendnssec/SoftHSMv2/pull/83
>>
>> Let's discuss about this code and your requirements :-)
>>
>> Current code uses AsymmetricAlgorithm->encrypt() and decrypt() directly.
>>
>> I wonder if it is really necessary to introduce new AsymmetricAlgorithm
>> interface for wrap() and unwrap(). To me it seems that calling encrypt()
>> and decrypt() with correct AsymMech could be enough...
>>
>> Other alternative would be to add wrap() and unwrap() interface and
>> simply relay calls wrap()->encrypt() etc. It would allow us to filter
>> out some inappropriate mechanism from wrap() call but that is all. (E.g.
>> refusing to do key wrapping if mechanism is CKM_SHA1_RSA_PKCS or
>> something like that.)
>>
>> Is it worth doing so? Thank you for your opinions.
>
> I think it is worthwhile having a separate interface. Not just because
> it looks cleaner, also because you can manage permissions on keys that
> allow or disallow certain operations (such as wrapping/unwrapping). I

Could you be more specific, please? What do you mean with 'permissions'? Do 
you mean PKCS#11 tables which say e.g. that CKM_SHA1_RSA_PKCS cannot be used 
for key wrapping?

Or something else? It seems to me that crypto layer (AsymmetricAlgorithm and 
others) is deep below P11Object so those objects doesn't have any knowledge of 
allowed key usages.

I mean: In cases where PKCS#11 *standard* allows to use given mechanism for 
encryption and wrapping but P11Object says something else (e.g. allows only 
key wrapping) there is no way for AsymmetricAlgorithm to know about this 
limitation.

Please correct me if I'm wrong.


I can certainly write wrap() as a wrapper around encrypt() which will 
implement PKCS#11 'tables'. I imagine that it would be fairly simple:

bool wrap(..., padding) {
	switch (padding) {
		case RSA_PKCS:
			return encrypt(..., padding);
		
		default:
		// includes CKM_SHA1_RSA_PKCS
			return false;
	}
}


Adding knowledge about allowed key usage to AsymmetricAlgorithm would be more 
invasive change.

> also think it is worthwhile having a constructor on AsymmetricKey
> objects that allow a PKCS #8 blob as input, such that a call to unwrap
> using a SymmetricKey can invoke such a constructor. Conversely, there
> should be a function on AsymmetricKey objects that output a suitable
> PKCS #8 blob for an invocation of wrap using a SymmetricKey object.

Do I understand correctly that 'unwrap' method of SymmetricKey object should 
yield new AsymmetricKey object (constructed from PKCS8 blob)?

What method do you propose for distinguishing cases where wrapped blob 
contains symmetric or asymmetric key? (AFAIK it can happen with symmetric 
algorithms.)

Thank you for guidance!

-- 
Petr Spacek  @  Red Hat