Ubsec and Chil engines

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Ubsec and Chil engines

Matt Caswell-2
Hi all

The ubsec and chil engines are currently disabled in 1.1.0 and do not build.

As far as ubsec is concerned I understand that this is an engine for
broadcom cards. There has been very little activity with this engine
since it was first introduced. Google brings up some very old historic
references to its use.

There are a couple of more recent references.

This post from 2014 suggests that OpenSSL's support for this is broken
anyway and has been for some while:
https://forum.pfsense.org/index.php?topic=71857.0

There is also this post from 2013 from someone trying to get it to work
but with no (apparent) success:
https://stackoverflow.com/questions/17715546/openssl-speed-test-for-broadcom-engine

So for ubsec I can't find any evidence that it is being used successfully.


For chil I found this dicussion from 2012 on openssl-users where
apparently someone was using it (successfully):
http://openssl.6102.n7.nabble.com/Tutorials-on-OpenSSL-integration-with-nCipher-HSM-nShield-td2311.html

This RT ticket from 2008 is suggesting various fixes - the last of which
was applied. There was a brief flurry of commits tweaking stuff in chil
around this time:
https://rt.openssl.org/Ticket/Display.html?id=1736


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.

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.

Matt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Tomas Mraz-2
On Pá, 2016-02-19 at 11:31 +0000, Matt Caswell wrote:


> 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.
>
> 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.

As far as I know there are some customers using the Chil engine with
RHEL (openssl-1.0.1). 

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)



--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Jaroslav Imrich
In reply to this post by Matt Caswell-2
Hello Matt,

If I don't hear from anyone I will remove these.

I can confirm that CHIL engine is actively used with OpenSSL 1.0.* by the owners of nCipher/THALES nShield HSMs.

I have notified vendor support about this thread.

Regards, Jaroslav

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Matt Caswell-2
In reply to this post by Tomas Mraz-2


On 19/02/16 13:03, Tomas Mraz wrote:

> On Pá, 2016-02-19 at 11:31 +0000, Matt Caswell wrote:
>
>
>> 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.
>>
>> 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.
>
> As far as I know there are some customers using the Chil engine with
> RHEL (openssl-1.0.1).

How do you feel about the engine being spun out into a separate repo?
That of course assumes that a volunteer can be found to maintain it (I
don't believe anyone on the dev team wishes to do so).

If no such volunteer can be found how big a deal is it to remove it from
1.1.0 without a replacement? Obviously it won't be taken out of
1.0.1/1.0.2. Of course there's no reason, even if we take it out now,
that if someone needs it badly enough in the future that they couldn't
forward port the 1.0.2 version to 1.1.0 and maintain it themselves at
that point.

Matt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Matt Caswell-2
In reply to this post by Jaroslav Imrich


On 19/02/16 13:11, Jaroslav Imrich wrote:

> Hello Matt,
>
>     If I don't hear from anyone I will remove these.
>
>
> I can confirm that CHIL engine is actively used with OpenSSL 1.0.* by
> the owners of nCipher/THALES nShield HSMs.
>
> I have notified vendor support about this thread.
>
Great. Thanks Jaroslav. It would be good if the vendor could take on
support of the engine themselves.

Matt
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Richard Levitte - VMS Whacker-2
In reply to this post by Matt Caswell-2


Matt Caswell <[hidden email]> skrev: (19 februari 2016 14:12:28 CET)

>
>
>On 19/02/16 13:03, Tomas Mraz wrote:
>> On Pá, 2016-02-19 at 11:31 +0000, Matt Caswell wrote:
>>
>>
>>> 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.
>>>
>>> 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.
>>
>> As far as I know there are some customers using the Chil engine with
>> RHEL (openssl-1.0.1).
>
>How do you feel about the engine being spun out into a separate repo?
>That of course assumes that a volunteer can be found to maintain it (I
>don't believe anyone on the dev team wishes to do so).

Not so fast. I've my engine-corner on github that's intended for exactly this sort of thing. I'll happily help porting engines to become independent products. In my opinion, that will serve us all.

Engine-corner is a personal project that has nothing to do with the team per se. Participation by anyone interested is welcome (frankly, engines that no one participates in *will* die, simple as that)

>
>If no such volunteer can be found how big a deal is it to remove it
>from
>1.1.0 without a replacement? Obviously it won't be taken out of
>1.0.1/1.0.2. Of course there's no reason, even if we take it out now,
>that if someone needs it badly enough in the future that they couldn't
>forward port the 1.0.2 version to 1.1.0 and maintain it themselves at
>that point.
>
>Matt
>
>--
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Salz, Rich
In reply to this post by Matt Caswell-2

> 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).

Please do.  I know Sander was interested in updating CHIL but never found time.

That also removes the last remaining need for "dynamic locks"  huzzah
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Richard Levitte - VMS Whacker-2


"Salz, Rich" <[hidden email]> skrev: (19 februari 2016 15:07:42 CET)

>
>> 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).
>
>Please do.  I know Sander was interested in updating CHIL but never
>found time.
>
>That also removes the last remaining need for "dynamic locks"  huzzah

That should be removed either way. Engines should handle their own locks whatever way the programmer wants.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Nikos Mavrogiannopoulos-2
In reply to this post by Matt Caswell-2
On Fri, 2016-02-19 at 13:12 +0000, Matt Caswell wrote:

> As far as I know there are some customers using the Chil engine
> > with
> > RHEL (openssl-1.0.1). 
>
> How do you feel about the engine being spun out into a separate repo?
> That of course assumes that a volunteer can be found to maintain it
> (I
> don't believe anyone on the dev team wishes to do so).
>
> If no such volunteer can be found how big a deal is it to remove it
> from
> 1.1.0 without a replacement? Obviously it won't be taken out of
> 1.0.1/1.0.2. Of course there's no reason, even if we take it out now,
> that if someone needs it badly enough in the future that they
> couldn't forward port the 1.0.2 version to 1.1.0 and maintain it
> themselves at that point.

It may even be better, instead of pushing for different engines for
different hardware, to make PKCS#11 the only API used to talk to
hardware. There is a quite functional (and active as project) pkcs11
engine for openssl [0].

regards,
Nikos

[0]. https://github.com/OpenSC/engine_pkcs11

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Blumenthal, Uri - 0553 - MITLL
In reply to this post by Matt Caswell-2
+1. 

With one exception: engine_pkcs11 has been subsumed (and merged into) libp11.

I've tested it with a few different PIV tokens (RSA and ECC), and it was great.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Nikos Mavrogiannopoulos
Sent: Friday, February 19, 2016 09:53
To: [hidden email]
Reply To: [hidden email]
Subject: Re: [openssl-dev] Ubsec and Chil engines

On Fri, 2016-02-19 at 13:12 +0000, Matt Caswell wrote:

> As far as I know there are some customers using the Chil engine
> > with
> > RHEL (openssl-1.0.1). 
>
> How do you feel about the engine being spun out into a separate repo?
> That of course assumes that a volunteer can be found to maintain it
> (I
> don't believe anyone on the dev team wishes to do so).
>
> If no such volunteer can be found how big a deal is it to remove it
> from
> 1.1.0 without a replacement? Obviously it won't be taken out of
> 1.0.1/1.0.2. Of course there's no reason, even if we take it out now,
> that if someone needs it badly enough in the future that they
> couldn't forward port the 1.0.2 version to 1.1.0 and maintain it
> themselves at that point.
It may even be better, instead of pushing for different engines for
different hardware, to make PKCS#11 the only API used to talk to
hardware. There is a quite functional (and active as project) pkcs11
engine for openssl [0].

regards,
Nikos

[0]. https://github.com/OpenSC/engine_pkcs11

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Sander Temme
In reply to this post by Matt Caswell-2

> On Feb 19, 2016, at 3:31 AM, Matt Caswell <[hidden email]> 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.

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




--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (242 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Sat, 20 Feb 2016 12:40:38 -0800, Sander Temme <[hidden email]> said:

sander>
sander> > On Feb 19, 2016, at 3:31 AM, Matt Caswell <[hidden email]> wrote:
sander>
sander> OK that made our support lines blow up so yes there is interest.
sander>
sander> Disclaimer: I work for Thales but do not speak for Thales.
sander>
sander> > So it seems that for chil there may possibly be some rare use (but even
sander> > the most recent evidence is 4 years old). However the OpenSSL dev team
sander> > do not have access to this hardware to maintain the engine and (as noted
sander> > above) this is currently not building in 1.1.0.
sander>
sander> I think (again, personal impression) that this is one of those
sander> sleeper integrations that a lot of people use but doesn’t get
sander> on the radar a whole lot. Using openssl is by far the easiest
sander> way to get the nShield HSM to do something with protected
sander> keys… as long as those are RSA keys.  Pair that with existing
sander> application integrations like Apache, OpenSSH, etc. I know of
sander> a number of customers and partners, none of whom I am at
sander> liberty to discuss (although they might speak up for
sander> themselves), who use OpenSSL with nShield for various
sander> applications.

Oh, nShield?  Back when I was playing with e_chil.c, it was nCipher.
But, no matter really...

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

The trouble is that we can't verify that.  We don't have the hardware
or the expertise.  Even the few of us that got to play with a nCipher
box 15+ years ago don't have that around any more.  So there's that
pile of code that no one dares to touch because we have no idea what
the effects might be and have no way of testing that.

With all that in mind, I've a question back to you...  wouldn't it be
more productive if Thales let an OpenSSL engine, built as a DSO,
accompany the hardware?  Considering you are much closer to the
hardware and the expertise, it seems a bit more appropriate, doesn't
it?

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

I'm not sure if this is a problem specifically for OpenSSL to solve,
or if it is a packager problem.  Sometimes, the border between the two
might be blurry, but...  If OpenSSL is to "obtain" a PKCS#11 engine,
it would probably be by writing one.  It would be far easier, though,
if someone would package the already existing engine_pkcs11 with
OpenSSL (that packaging doesn't have to be done by the OpenSSL team),
*or* with hardware distributions.

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Jaroslav Imrich
In reply to this post by Sander Temme
On 20 February 2016 at 21:40, Sander Temme <[hidden email]> wrote:
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.

Let's not forget that CHIL provides one very unique feature - forked process keeps the authentication state of its parent and can access HSM keys if its parent was authenticated. PKCS#11 specification prohibits such behavior (PKCS#11 v2.20 chapter 6.6.1) and because of that PKCS#11 based engine couldn't fully replace CHIL engine.

Regards, Jaroslav

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Nikos Mavrogiannopoulos-2
On Sat, 2016-02-20 at 23:34 +0100, Jaroslav Imrich wrote:

> On 20 February 2016 at 21:40, Sander Temme <[hidden email]> wrote:
> >  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.
> Let's not forget that CHIL provides one very unique feature - forked
> process keeps the authentication state of its parent and can access
> HSM keys if its parent was authenticated. PKCS#11 specification
> prohibits such behavior (PKCS#11 v2.20 chapter 6.6.1) and because of
> that PKCS#11 based engine couldn't fully replace CHIL engine.

That's an implementation detail. As far as I know engine_pkcs11 does
not require re-authentication after fork. It handles the pkcs11
peculiarities internally.

regards,
Nikos

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

David Woodhouse-7
In reply to this post by Nikos Mavrogiannopoulos-2
On Fri, 2016-02-19 at 15:53 +0100, Nikos Mavrogiannopoulos wrote:

> On Fri, 2016-02-19 at 13:12 +0000, Matt Caswell wrote:
>
> > As far as I know there are some customers using the Chil engine
> > > with
> > > RHEL (openssl-1.0.1). 
> >
> > How do you feel about the engine being spun out into a separate
> > repo?
> > That of course assumes that a volunteer can be found to maintain it
> > (I
> > don't believe anyone on the dev team wishes to do so).
> >
> > If no such volunteer can be found how big a deal is it to remove it
> > from
> > 1.1.0 without a replacement? Obviously it won't be taken out of
> > 1.0.1/1.0.2. Of course there's no reason, even if we take it out
> > now,
> > that if someone needs it badly enough in the future that they
> > couldn't forward port the 1.0.2 version to 1.1.0 and maintain it
> > themselves at that point.
>
> It may even be better, instead of pushing for different engines for
> different hardware, to make PKCS#11 the only API used to talk to
> hardware. There is a quite functional (and active as project) pkcs11
> engine for openssl [0].
Agreed. With the caveat that I *really* want libp11 and engine_pkcs11
to die, and be replaced by native code in openssl/crypto/pkcs11/

That way we can integrate it *properly*, with various SSL certificate
handling functions just naturally taking PKCS#11 URIs alongside
filenames.

Integrating libp11 itself would require relicensing it, which might be
non-trivial but perhaps still achievable. Or maybe we should
reimplement it, basing the new version around p11-kit.

It would be an *optional* thing, of course. Windows builds might
default to no-pkcs11. But p11-kit ought to exist fairly much everywhere
*else*.

Apart from UEFI :)

--
David Woodhouse                            Open Source Technology Centre
[hidden email]                              Intel Corporation



--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

David Woodhouse-7
In reply to this post by Richard Levitte - VMS Whacker-2
On Sat, 2016-02-20 at 22:55 +0100, Richard Levitte wrote:

>
> sander> What I would like to see though is for such a PKCS#11 Engine
> sander> to be part of OpenSSL proper, so that our customers and
> sander> everyone else’s don’t have to go hunt hither and yon for bits
> sander> and bobs of software in order to make their hardware kit work
> sander> with OpenSSL.  How would OpenSSL obtain a PKCS#11 Engine to
> sander> include in its distribution?
>
> I'm not sure if this is a problem specifically for OpenSSL to solve,
> or if it is a packager problem. 
I touched on this in a message a few minutes ago, but I *definitely*
think it's the former.

If we integrate the support natively into OpenSSL, then PKCS#11 URIs
(see RFC7512) can be first-class citizens throughout the crypto and SSL
APIs. Any function which takes a filename for a cert or key should also
accept¹ a PKCS#11 URI.

Then we can also use PKCS#11 for the trust database, which allows us to
properly handle the trusted *purposes* in ways that a flat file
doesn't. And that flat file is now *exported* from the p11-kit-trust
token purely for the benefit of OpenSSL, which it would be nice to stop
doing.

I am happy to work on this.

--
David Woodhouse                            Open Source Technology Centre
[hidden email]                              Intel Corporation


¹ Or "have a parallel function which takes"... but seriously, how often is
  a string which starts "pkcs11:" going to have been intended as a an
  actual *filename*? :)

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Mon, 22 Feb 2016 11:32:21 +0000, David Woodhouse <[hidden email]> said:

dwmw2> On Sat, 2016-02-20 at 22:55 +0100, Richard Levitte wrote:
dwmw2> >
dwmw2> > sander> What I would like to see though is for such a PKCS#11 Engine
dwmw2> > sander> to be part of OpenSSL proper, so that our customers and
dwmw2> > sander> everyone else’s don’t have to go hunt hither and yon for bits
dwmw2> > sander> and bobs of software in order to make their hardware kit work
dwmw2> > sander> with OpenSSL.  How would OpenSSL obtain a PKCS#11 Engine to
dwmw2> > sander> include in its distribution?
dwmw2> >
dwmw2> > I'm not sure if this is a problem specifically for OpenSSL to solve,
dwmw2> > or if it is a packager problem. 
dwmw2>
dwmw2> I touched on this in a message a few minutes ago, but I *definitely*
dwmw2> think it's the former.
dwmw2>
dwmw2> If we integrate the support natively into OpenSSL, then PKCS#11 URIs
dwmw2> (see RFC7512) can be first-class citizens throughout the crypto and SSL
dwmw2> APIs. Any function which takes a filename for a cert or key should also
dwmw2> accept¹ a PKCS#11 URI.
dwmw2>
dwmw2> Then we can also use PKCS#11 for the trust database, which allows us to
dwmw2> properly handle the trusted *purposes* in ways that a flat file
dwmw2> doesn't. And that flat file is now *exported* from the p11-kit-trust
dwmw2> token purely for the benefit of OpenSSL, which it would be nice to stop
dwmw2> doing.
dwmw2>
dwmw2> I am happy to work on this.

That takes me back to crypto/store, which is currently removed in
master but which I have a rework of in a branch, which is meant to
solve this exact problem, but without being exclusively tied to
PKCS#11.  The design is to have it work with engine backends, and a
PKCS#11 engine that's part of OpenSSL would fit that bill, so to say.

Shall we talk?

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

David Woodhouse-7
On Mon, 2016-02-22 at 12:52 +0100, Richard Levitte wrote:
>
> That takes me back to crypto/store, which is currently removed in
> master but which I have a rework of in a branch, which is meant to
> solve this exact problem, but without being exclusively tied to
> PKCS#11.  The design is to have it work with engine backends, and a
> PKCS#11 engine that's part of OpenSSL would fit that bill, so to say.

That seems ideal. The TPM ENGINE could benefit from it too.

I'd really like to look at this from the *application* developer's
point of view.

Please clear your mind of any internal OpenSSL knowledge and context,
and take a look at the OpenConnect VPN client, and the various hoops it
has to jump through to load a certificate:
http://git.infradead.org/users/dwmw2/openconnect.git/blob/v7.06:/openssl.c#l261
through to the main load_certificate() function which ends at line
916. 

(You can ignore the entire contents of openssl-pkcs11.c for now.)

Even if you discount the TPM and PKCS#11 parts, it's bad enough for
just loading certificates from a file. We force the *application* to
inspect the file that the user asked it to use, and work out what kind
of file it is. And then even the handling of the *passphrase* is
different according to what kind of file it is — PKCS#12 functions need
the password handed in, while PEM functions are given a callback
function instead.

And don't even *talk* to me about the horridness with the TPM's UI
having no way to pass through any opaque data to the callback, and the
need for that 'static struct openconnect_info *ui_vpninfo' at line 276.
Actually, do talk to me about that. Let's fix it before 1.1?

We desperately need to provide applications with a function that
silently Does The Right Thing, when given a filename or a PKCS#11 URI
or whatever other string a user might put reasonably put into a config
file to specify a certificate/key.

> Shall we talk?

Absolutely :)

--
David Woodhouse                            Open Source Technology Centre
[hidden email]                              Intel Corporation


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Jaroslav Imrich
In reply to this post by Nikos Mavrogiannopoulos-2
On 22 February 2016 at 11:16, Nikos Mavrogiannopoulos <[hidden email]> wrote:
That's an implementation detail. As far as I know engine_pkcs11 does
not require re-authentication after fork. It handles the pkcs11
peculiarities internally.

AFAIK this works by caching the PIN in engine_pkcs11 internally and is OK for most of the use cases with smartcards. However HSMs usually use more complex authentication schemes where this approach does not work i.e. in order to login there must be N of M physical tokens/cards with passwords presented in a sequence (requires vendor specific extensions when used via PKCS#11). CHIL engine already handles such schemes very well and does not need to reauthenticate after fork.

Regards, Jaroslav

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Salz, Rich
In reply to this post by David Woodhouse-7
> If we integrate the support natively into OpenSSL, then PKCS#11 URIs (see
> RFC7512) can be first-class citizens throughout the crypto and SSL APIs. Any
> function which takes a filename for a cert or key should also accept¹ a
> PKCS#11 URI.

It'd be great to see a crypto/pkcs11 directory with full native support (as much as possible).

But really doubtful to happen in 1.1 as the API freeze is in a month.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
12