[openstack-dev] [barbican] Can we support key wrapping mechanisms other than CKM_AES_CBC_PAD?

Lingxian Kong anlin.kong at gmail.com
Wed Jul 11 10:48:48 UTC 2018


Hi Ade,

Thanks for your reply.

I just replaced `CKM_AES_CBC_PAD` with `CKM_RSA_PKCS` here[1], of course I
defined `CKM_RSA_PKCS = 0x00000001` in the code, but still got the
following error:

*Jul 11 10:42:05 barbican-devstack devstack at barbican-svc.service[19897]:
2018-07-11 10:42:05.309 19900 WARNING barbican.plugin.crypto.p11_crypto
[req-f2d27105-4811-4c77-a321-2ac1399cc9d2 b268f84aef814ae*
*da17ad3fa38e0049d 7abe0e02baec4df2b6046d7ef7f44998 - default default]
Reinitializing PKCS#11 library: HSM returned response code: 0x7L
CKR_ARGUMENTS_BAD: P11CryptoPluginException: HSM returned response code:
0x7L CKR_ARGUMENTS_BAD*

​[1]:
https://github.com/openstack/barbican/blob/5dea5cec130b59ecfb8d46435cd7eb3212894b4c/barbican/plugin/crypto/pkcs11.py#L496
​


Cheers,
Lingxian Kong

On Wed, Jul 11, 2018 at 9:18 PM, Ade Lee <alee at redhat.com> wrote:

> Lingxian,
>
> I don't see any reason not to provide support for other wrapping
> mechanisms.
>
> Have you tried hacking the code to use one of the other wrapping
> mechanisms to see if it works?  Ultimately, what is passed are
> parameters to CFFI.  As long as you pass in the right input and your
> PKCS#11 library can support it, then there should be no problem.
>
> If it works, it makes sense to make the wrapping algorithm configurable
> for the plugin.
>
> It may or may not make sense to store the wrapping algorithm used in
> the secret plugin-metadata if we want to support migration to other
> HSMs.
>
> Ade
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180711/611c7765/attachment.html>


More information about the OpenStack-dev mailing list