Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Manuel,

Historically all of our contributors working with the PKCS#11 crypto
plugin have been using Safenet HSMs, which is why the Safenet
mechanism is the default.

The "CKR_MECHANISM_PARAM_INVALID" error appears to be a bug.  You may
file a bug report in our Launchpad page. [1]

The "CryptoPluginNotFound" may mean that the PKCS#11 plugin is failing
to instantiate.  I think it may mean that we don't currently support
those algorithms.  I would have to do some debugging to get to the
root of this issue, but it sounds like we may need some more work to
support the different algorithms you're trying to use.

In theory, the PKCS#11 plugin should be able to work with any PKCS#11
device.  I suspect that fixing the "CKR_MECHANISM_PARAM_INVALID" bug
may be all we need to get the Utimaco HSM working.

You're more than welcome to contribute patches to get your HSM
working.  You can take a look at our development guide if contributing
is something you're interested in. [2]

Thanks,
- - Doug

[1] https://bugs.launchpad.net/barbican
[2] http://docs.openstack.org/developer/barbican/#barbican-for-developer
s

On 8/16/16 8:22 AM, Praktikant HSM wrote:
> Hi Douglas,
> 
> Thank you very much for your response.
> 
> When testing the usage of the generated MKEK, we ran into some
> problems. For clarification: we are testing the PKCS#11-based
> crypto plugin with a Utimaco HSM. The error messages are from
> Barbican's and Utimaco's log files.
> 
> When storing a secret, we get the following error:
> CKM_MECHANISM_INVALID (Mechanism 0x8000011c is invalid). Since this
> is a vendor specific AES-GCM mechanism by SafeNet[1], it is not
> supported by our HSMs.
> 
> In the p11_crypto.py file, the default algorithm is set to
> "VENDOR_SAFENET_CKM_AES_GCM"[2]. Thus, we specified "CKM_AES_GCM"
> in the barbican.conf file in the [p11_crypto_plugin] section to be
> used instead of the default mechanism. However, this gave us a
> "CKR_MECHANISM_PARAM_INVALID" error: mechanism length invalid
> (expected 40, provided 48).
> 
> Additionally, when trying other AES modes, e.g. CBC, there is an
> CryptoPluginNotFound error.
> 
> Is there currently a workaround which would allow us to use a
> Utimaco HSM? Also, are there any plans to natively support HSMs
> from other vendors in the near future?
> 
> Again, thank you for your support.
> 
> Best regards,
> 
> Manuel Roth
> 
> [1]:
> https://github.com/openstack/barbican/blob/306b2ac592c059c59be42c0420a
08af0a9e34f6e/barbican/plugin/crypto/pkcs11.py#L131
>
>  [2]:
> https://github.com/openstack/barbican/blob/c2a7f426455232ed04d2ccef6b3
5c87a2a223977/barbican/plugin/crypto/p11_crypto.py#L63
>
>  ------------------------------- System Engineering HSM
> 
> Utimaco IS GmbH Germanusstr. 4 52080 Aachen Germany
> 
> 
> 
> -----Original Message----- From: Douglas Mendizábal
> [mailto:douglas.mendizabal at rackspace.com] Sent: Freitag, 12. August
> 2016 18:24 To: OpenStack Development Mailing List (not for usage
> questions) <openstack-dev at lists.openstack.org> Cc: Ariano-Tim Donda
> <Ariano-Tim.Donda at utimaco.com>; Jiannis Papadakis
> <Jiannis.Papadakis at utimaco.com> Subject: Re: [openstack-dev]
> Barbican: Secure Setup & HSM-plugin
> 
> Hi Manuel,
> 
> I'm happy to hear about your interest in Barbican.  I assume your
> HSM has a PKCS#11 interface since the admin commands to generate
> the MKEK and HMAC keys worked for you.
> 
> The labels for the generated keys should be specified in the config
> file for the API process. [1]  The API process uses the MKEK and
> HMAC keys to encrypt and sign the secrets (keys) that are stored in
> Barbican by clients.
> 
> The PKCS#11 plugin was designed to use the SQL Database to store
> client keys (secrets) in the SQL database, so your API process must
> be configured to use "store_crypto" as the
> enabled_secretstore_plugins [2] in addition to specifing
> "p11_crypto" as the enabled_crypto_plguins [3].
> 
> When configured this way, Barbican uses the HSM to encrypt the
> client data (keys/secrets) before storing it in the DB.
> 
> The API itself does not currently support using keys stored by
> clients to do server-side encryption, but it's a feature that has
> been discussed in previous summits with some interest.  We've also
> had some discussions with the Designate team to add server-side
> signing that they could use to implement DNSSEC, but we don't yet
> have a blueprint for it.
> 
> Let me know if you have any more questions.
> 
> - Douglas Mendizábal
> 
> [1] 
> http://git.openstack.org/cgit/openstack/barbican/tree/etc/barbican/bar
bi
>
> 
can.conf#n278
> [2] 
> http://git.openstack.org/cgit/openstack/barbican/tree/etc/barbican/bar
bi
>
> 
can.conf#n255
> [3] 
> http://git.openstack.org/cgit/openstack/barbican/tree/etc/barbican/bar
bi
>
> 
can.conf#n260
> 
> 
> On 8/12/16 7:51 AM, Praktikant HSM wrote:
>> Hi all,
> 
>> As a member of Utimaco's pre-sales team I am currently testing
>> an integration of Barbican with one of our HSMs.
> 
> 
> 
>> We were able to generate MKEKs and HMAC keys on the HSM with the 
>> 'pkcs11-key-generation' as well as 'barbican-manage hsm'
>> commands. However, it is not fully clear to us how to use these
>> keys to encrypt or sign data.
> 
> 
> 
>> Additionally, we would appreciate further information concerning
>> the secure setup of Barbican with an HSM-plugin.
> 
> 
> 
>> Thank you in advance for your support.
> 
> 
> 
>> Best regards,
> 
> 
> 
> 
> 
>> Manuel Roth
> 
> 
> 
>> -------------------------------
> 
>> System Engineering HSM
> 
> 
> 
>> Utimaco IS GmbH
> 
>> Germanusstr. 4
> 
>> 52080 Aachen
> 
>> Germany
> 
> 
> 
>> www.utimaco.com <http://www.utimaco.com>
> 
> 
>> ---------------------------------------------------------------------
- -
>
>> 
> ______________________________________________________________________
____
>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ________________________________
> 
> Utimaco IS GmbH Germanusstr. 4, D.52080 Aachen, Germany, Tel:
> +49-241-1696-0, www.utimaco.com Seat: Aachen – Registergericht
> Aachen HRB 18922 VAT ID No.: DE 815 496 496 Managementboard: Malte
> Pollmann (Chairman) CEO, Dr. Frank J. Nellissen CFO
> 
> This communication is confidential. We only send and receive email
> on the basis of the terms set out at
> https://www.utimaco.com/en/e-mail-disclaimer/ 
> ______________________________________________________________________
____
>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXszDiAAoJEB7Z2EQgmLX7t64QAJaOMj0aizDtIxlPXzx8GbPT
kuVK1TRdrFoykLgsP6+ZQaSQCz1WsKlPTToF32iVoakeGhxJ622f4oaQ7fDWFwj2
P3g+j0s7qae3qTfg3S0YDnqbyoKVqbHmxGIi8jQL8vMaI9N4j2OFJudWXjj4ohbK
UTgn/ePeZhYoGtlOlaZE9ZAujjxCV95Suwi66QOMMri9cO3YwxOYQ1SRC354obNn
8GQmmDlsgsbO/94UliNuE+6iR2cjmYtV2I8U9PsS7b5Abs8hoO+ucZUo5k0png4n
ZWr+X74OokTK3Wjw4omlSEVX4UoQm/yRmQUJM0LvI+ulny/MULxHSs764mF8kgsV
iKYacQS8mW7u4QjfgaEtexOjKbtp89wCMBJhc+dkzJTZ1WSBQ8BVQcsubV7x/a32
qnlpkBWrCqQ1lttobhUIu21ELWKMxakc1JuY2D4cRJzWY1+5qGWADcnLqqfYXyML
oBg0D04vkUUYt6935hJEeCsUhfVCKbkzDG/9LlYs7FIEBJqQUPsUp2d8eq2GK5iJ
IJsQ7TlcLAM4TcvNqkkgh4CK7mw1p0RRfRkRfHtiqDxYE7lXaN+V1rPIge6T6J9o
M6UBhC1CVa02R/Ou5VoIYiM//ceNKE09jEMeN67ljhMK6J0kiJDEEtUIwcowmqFi
rpI1KiR31QSlZBjgJbAF
=LaU/
-----END PGP SIGNATURE-----