[openssl-users] [openssl-dev] Ubsec and Chil engines

[Sander Temme]

> On Feb 19, 2016, at 3:31 AM, Matt Caswell <matt at openssl.org> wrote:

OK that made our support lines blow up so yes there is interest.

Disclaimer: I work for Thales but do not speak for Thales.

> So it seems that for chil there may possibly be some rare use (but even
> the most recent evidence is 4 years old). However the OpenSSL dev team
> do not have access to this hardware to maintain the engine and (as noted
> above) this is currently not building in 1.1.0.

I think (again, personal impression) that this is one of those sleeper integrations that a lot of people use but doesn’t get on the radar a whole lot. Using openssl is by far the easiest way to get the nShield HSM to do something with protected keys… as long as those are RSA keys.  Pair that with existing application integrations like Apache, OpenSSH, etc. I know of a number of customers and partners, none of whom I am at liberty to discuss (although they might speak up for themselves), who use OpenSSL with nShield for various applications.

So it’s not dead.  What it does, it does very well.  If anything, the lack of visible activity may indicate how easy CHIL is to use and support.

> In both cases I would like to remove these engines from 1.1.0. I'd like
> to hear from the community if there is any active use of these. One
> option if there is found to be some small scale use is to spin out the
> engine into a separately managed repo (as has happened recently with the
> GOST engine).
> 
> If I don't hear from anyone I will remove these.

Ehm.  Let’s talk about this.  As I noted above, a lot of our valued customers may depend on this even thought they might not know or may have forgotten about it.  From your October 28 commit (29e7a56d), it seems that what broke us was when the bn structure went opaque… I see only two lines in e_chil.c that depend on the internal structure of bn so that should be addressable.  We’d like to do some more things to this Engine, like more key types and, yes, those dynamic locks should go away, which requires some surgery to the stuff underneath but nothing major.  All the platforms we run on now have good locking.  And, Rich, I indeed have had those locks on my guilty conscience for all this time but not found any round tuits.

However, I’m intrigued by the notion of a PKCS#11 Engine in OpenSSL: it’s a standard (an OASIS standard now); it’s fairly fully featured; everyone in the industry supports it including Thales; and you can build a program that calls it without needing a vendor SDK, because there are standard headers and a well defined way to get to the entry points.  If we can come up with a way to pick a PKCS#11 slot and log into it that makes sense (e.g. not by poking PINs into a system wide config file etc.) then I think we’d have a winner.

What I would like to see though is for such a PKCS#11 Engine to be part of OpenSSL proper, so that our customers and everyone else’s don’t have to go hunt hither and yon for bits and bobs of software in order to make their hardware kit work with OpenSSL.  How would OpenSSL obtain a PKCS#11 Engine to include in its distribution?

Thanks,

S.

--
sander at temme.net              http://www.temme.net/sander/
PGP FP: BCD1 6D2C 8906 C48A 540E  253E 94D3 36A3 6D15 930A



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160220/9de5efaf/attachment.sig>