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

[Petr Spacek]

On 18.7.2014 19:23, Petr Spacek wrote:
> 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!

Proof-of-concept code is available:
https://github.com/opendnssec/SoftHSMv2/pull/85

Please let me know if it fulfills your requirements or what should be changed.

Thank you!

-- 
Petr Spacek  @  Red Hat