New port in MacPorts and question about TokenD

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

New port in MacPorts and question about TokenD

Leonardo Brondani Schenkel-2
Hello all,

I have recently submitted a port for OpenSC in MacPorts:
https://trac.macports.org/ticket/52372

The port has been accepted and I volunteered to be the maintainer. I'm
a long time user of both OpenSC and MacPorts, so I hope that this port
will be useful for other Mac smartcard users — maybe some of them
members of this very list.

The port as it is now does not build the TokenD, though. This is what
I want to introduce next and that's the reason why I'm posting. Since
TokenD needs the OpenSC sources when building, I would like to know
how exact must be the match between the OpenSC sources that were used
by TokenD and the sources used to build the version of libopensc that
is available at runtime. This will determine if TokenD can be a
separate opensc-tokend port which is installable on its own (but
dependent on opensc) or it will be a new "+tokend" variant of the
opensc port (variants in MacPorts are like USE flags in Gentoo that
can be used to turn on/off features when building packages).

I strongly suspect that they must be built together or you risk
running into a world of pain when a libopensc gets upgraded and you
have a TokenD built against and older version (or vice-versa), but it
does not harm to ask the list.

I already have a successful build of TokenD built via MacPorts on my
machine, so the outcome of this discussion will determine how I'm
going to submit this work to MacPorts. Any suggestions on the matter
are greatly appreciated.

Thank you,
Leonardo.

------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: New port in MacPorts and question about TokenD

Martin Paljak-4
Hello,

It better be +tokend in this wording. Think of OpenSC.tokend like out-of-tree PKCS#11 or Minidriver interface of OpenSC. It could also be bundled inside OpenSC code tree as well (but is not, for historical reasons).

For some reason (IMHO) it feels like MacPorts is more about things that don't integrate with OSX that deeply (unlike the standard .pkg/.dmg interface) and thus only to provide PKCS#11 and command line tools by default.

But it could also be a separate package.

The reason for calling libopensc a "deprecated library" is only to encourage developers to build against "proper interfaces" like PKCS#11 or some platform-specific interface, not to make it impossible to build a component-based OpenSC.

Best,

Martin

On Tue, 27 Sep 2016 at 21:57 Leonardo Brondani Schenkel <[hidden email]> wrote:
Hello all,

I have recently submitted a port for OpenSC in MacPorts:
https://trac.macports.org/ticket/52372

The port has been accepted and I volunteered to be the maintainer. I'm
a long time user of both OpenSC and MacPorts, so I hope that this port
will be useful for other Mac smartcard users — maybe some of them
members of this very list.

The port as it is now does not build the TokenD, though. This is what
I want to introduce next and that's the reason why I'm posting. Since
TokenD needs the OpenSC sources when building, I would like to know
how exact must be the match between the OpenSC sources that were used
by TokenD and the sources used to build the version of libopensc that
is available at runtime. This will determine if TokenD can be a
separate opensc-tokend port which is installable on its own (but
dependent on opensc) or it will be a new "+tokend" variant of the
opensc port (variants in MacPorts are like USE flags in Gentoo that
can be used to turn on/off features when building packages).

I strongly suspect that they must be built together or you risk
running into a world of pain when a libopensc gets upgraded and you
have a TokenD built against and older version (or vice-versa), but it
does not harm to ask the list.

I already have a successful build of TokenD built via MacPorts on my
machine, so the outcome of this discussion will determine how I'm
going to submit this work to MacPorts. Any suggestions on the matter
are greatly appreciated.

Thank you,
Leonardo.

------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: New port in MacPorts and question about TokenD

David Woodhouse
In reply to this post by Leonardo Brondani Schenkel-2
On Tue, 2016-09-27 at 20:55 +0200, Leonardo Brondani Schenkel wrote:

> The port as it is now does not build the TokenD, though. This is what
> I want to introduce next and that's the reason why I'm posting. Since
> TokenD needs the OpenSC sources when building, I would like to know
> how exact must be the match between the OpenSC sources that were used
> by TokenD and the sources used to build the version of libopensc that
> is available at runtime. This will determine if TokenD can be a
> separate opensc-tokend port which is installable on its own (but
> dependent on opensc) or it will be a new "+tokend" variant of the
> opensc port (variants in MacPorts are like USE flags in Gentoo that
> can be used to turn on/off features when building packages).
>
> I strongly suspect that they must be built together or you risk
> running into a world of pain when a libopensc gets upgraded and you
> have a TokenD built against and older version (or vice-versa), but it
> does not harm to ask the list.
Well... the OpenSC project installs a shared library for libopensc, and
a libopensc.pc pkg-config file to let external things build against it.
If the ABI of that library changes in an incompatible way without the
soname being bumped, then we are Doing It Wrong™.

That said, lots of projects Do It Wrong, and I don't blame you for
asking :)


On Wed, 2016-09-28 at 06:34 +0000, Martin Paljak wrote:
> The reason for calling libopensc a "deprecated library" is only to 
> encourage developers to build against "proper interfaces" like 
> PKCS#11 or some platform-specific interface, not to make it 
> impossible to build a component-based OpenSC.

Do we call it a 'deprecated library'? That still doesn't mean we get to
break shared library ABI rules, does it?

And in this case, I believe Tokend *is* the "proper" platform-specific
interface for OSX, just as the minidriver is the proper platform-
specific interface for Windows.

So if we *aren't* painstakingly following shared library ABI rules for
libopensc, and Leonardo's concerns are valid... then maybe
Tokend.OpenSC should be part of the OpenSC repository, like the Windows
minidriver is.

Or a third possibility: what's wrong with just using a Tokend.PKCS#11
such as the one mentioned at
http://ludovicrousseau.blogspot.co.uk/2010/04/free-software-tokend-above-pkcs11-for.html

Then you can use it with *any* PKCS#11 module, including OpenSC's. Why
have a hardware-specific Tokend implementation at all?

--
dwmw2
------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

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

Re: New port in MacPorts and question about TokenD

Martin Paljak-4
On 28/09/16 11:34, David Woodhouse wrote:
> Then you can use it with *any* PKCS#11 module, including OpenSC's. Why
> have a hardware-specific Tokend implementation at all?


In theory - yes. In practice - there is a shitload of weirdly buggy
PKCS#11 modules out there and when you need to provide reliability, such
wishful layering often fails to deliver. And you need to configure them
and resolve conflicts and ...

The other sad part about tokend is - it will be phased out.

https://developer.apple.com/reference/cryptotokenkit

Anyway, it seems that such "long layering" is something that is actively
being worked against, with things like WebUSB being preferred by some
implementers instead of going through whatever would provide access to
hardware tokens (think: pkcs11-pcsc-ccid)

Regards,

Martin

--
@martinpaljak
+3725156495

------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: New port in MacPorts and question about TokenD

David Woodhouse
In reply to this post by Martin Paljak-4
Replying to this separately as it's a bit of a digression, but still
related...

On Wed, 2016-09-28 at 06:34 +0000, Martin Paljak wrote:
> For some reason (IMHO) it feels like MacPorts is more about things
> that don't integrate with OSX that deeply (unlike the standard
> .pkg/.dmg interface) and thus only to provide PKCS#11 and command
> line tools by default.

OK, so how *should* this work. Let's take the specific example of
OpenConnect, my VPN client. I try to make sure it works for everyone —
on Linux platforms it Just Works™ if you provide a RFC7512 PKCS#11 URI
in place of a filename for a certificate/key, and on Windows there's a
similar string format to identify certificates in the Windows
certificate store (and the GUIs make that work nicely).

OSX is... problematic. I'd love to be able to use certificates from the
Keychain, but I don't know how. I was trying to help a user only last
week who had a key in the Keychain and was trying to make OpenConnect
work.

So you're right. It doesn't integrate with OSX that deeply, and it only
provides PKCS#11. That much I already knew.

But how do I *fix* it? 

I'm aware of https://github.com/slushpupie/KeychainToken which exposes
the Keychain via PKCS#11, and I could attempt to work with that, but
it's basically a dead project and I understand it's not likely to work
with recent versions of OSX. Although Jay has kindly said he's¹ willing
to relicense if we need to import parts of that code into some other
project in some form, which might be useful.

Should there be an OpenSSL ENGINE and/or GnuTLS support for talking
directly to the OSX Keychain? GnuTLS has that support for Windows
system keys and I believe there's an OpenSSL CAPI engine somewhere.

I *want* to make your statement above untrue, at least for OpenConnect.
But I have *no* idea how.


If KeychainToken can be made to work, perhaps that's the way forward.
MacPorts can basically work like other *nix platforms and do it based
on PKCS#11. On Linux we load p11-kit-proxy.so as the default PKCS#11
provider (or directly use libp11-kit to load all the right tokens).

So if we configure p11-kit to indicate that KeychainToken should be
loaded, then well-behaved applications would mostly Just Work.

--
dwmw2

¹ I made an assumption there because the language forced me to choose
  a pronoun, and I went with the most likely one. Sincere apologies if
  I got it wrong.
------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

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

Re: New port in MacPorts and question about TokenD

David Woodhouse
In reply to this post by Martin Paljak-4
On Wed, 2016-09-28 at 11:41 +0300, Martin Paljak wrote:
> On 28/09/16 11:34, David Woodhouse wrote:
> > Then you can use it with *any* PKCS#11 module, including OpenSC's. Why
> > have a hardware-specific Tokend implementation at all?
>
>
> In theory - yes. In practice - there is a shitload of weirdly buggy
> PKCS#11 modules out there and when you need to provide reliability, such
> wishful layering often fails to deliver. And you need to configure them
> and resolve conflicts and ...

True. But for the OpenSC case we don't have to care about those other
buggy PKCS#11 providers.

For us to deprecate Tokend.OpenSC in favour of Tokend.PKCS#11 we *only*
need the OpenSC PKCS#11 module to be working right.

All those other crappy third-party modules can still be weirdly buggy,
and we aren't any worse off. Those vendors are going to need to fix
*their* PKCS#11 provider before *they* stop shipping their Tokend.XXXX
and say "hey, do it through Tokend.PKCS#11". But that's their business.

> The other sad part about tokend is - it will be phased out.
>
> https://developer.apple.com/reference/cryptotokenkit
>
> Anyway, it seems that such "long layering" is something that is actively
> being worked against, with things like WebUSB being preferred by some
> implementers instead of going through whatever would provide access to
> hardware tokens (think: pkcs11-pcsc-ccid)

Yeah, that definitely makes it more fun :)

So is PCSC going to go away completely? For the Yubikey OATH support,
talking directly to the YubiOATH applet on the card, I currently do it
through PCSC identically (modulo Windows Unicode stupidity) on *all*
platforms:
http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/yubikey.c

This is separate from the *crypto* key support which I only do via
PKCS#11 right now (qv). Is even this going to break?

--
dwmw2
------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

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

Re: New port in MacPorts and question about TokenD

Leonardo Brondani Schenkel-2
In reply to this post by David Woodhouse
On 2016-09-28 10:34, David Woodhouse wrote:
> Well... the OpenSC project installs a shared library for libopensc, and
> a libopensc.pc pkg-config file to let external things build against it.
> If the ABI of that library changes in an incompatible way without the
> soname being bumped, then we are Doing It Wrong™.
>
> That said, lots of projects Do It Wrong, and I don't blame you for
> asking :)

Yes, I understand how shared libraries are supposed to maintain ABI/API
compatibility however my question was more or less the current state of
affairs and not the desirable one. :-)

I suspect that even if OpenSC intends to maintain a stable ABI/API for
libopensc (as expected of a shared library), inadvertent breakages won't
be detected in practice due to the fact that OpenSC builds everything
together and nobody tests different libopensc/TokenD version combinations.

I'm also not aware of any other project that uses libopensc. The fact
that the libopensc headers are declared as non-installable in the
Makefile also gives a strong indication that nobody is really expecting
libopensc to be used by third-parties.

I just don't want to gamble and have ports that build combinations  that
were never really build or tested by anyone. As the maintainer in
MacPorts, I'm not comfortable with making MacPorts users the guinea pigs
of such combinations.

> And in this case, I believe Tokend *is* the "proper" platform-specific
> interface for OSX, just as the minidriver is the proper platform-
> specific interface for Windows.
>
> So if we *aren't* painstakingly following shared library ABI rules for
> libopensc, and Leonardo's concerns are valid... then maybe
> Tokend.OpenSC should be part of the OpenSC repository, like the Windows
> minidriver is.

Just to clarify that I'm not claiming that the API/ABI are being broken,
just that I'm skeptical that any breakage would be detected since
(almost) nobody uses libopensc besides TokenD and they are always built
together.

Honestly, maintaining a stable API/ABI can be a pain and it could be
much better for everybody if TokenD was integrated into the OpenSC
sources and then you don't need to care about libopensc and you're free
to refactor it at will. I don't see the point of paying the price of
maintaining compatibility of a library if that library has no other users.

However, my intent was not to start a big discussion or make any
requests or suggest changes in OpenSC — all I want to do is to have a
well-behaving and stable MacPorts port. :-)

> Or a third possibility: what's wrong with just using a Tokend.PKCS#11
> such as the one mentioned at
> http://ludovicrousseau.blogspot.co.uk/2010/04/free-software-tokend-above-pkcs11-for.html
>
> Then you can use it with *any* PKCS#11 module, including OpenSC's. Why
> have a hardware-specific Tokend implementation at all?

I agree that the TokenD you mentioned would be a much better option than
the custom OpenSC one. It could work in the same way and have the same
purpose as p11-kit does in Linux.

But according to Apple TokenD modules are a deprecated technology and
who knows until when they are going to work. It becomes hard to justify
the time investment on building something that could simply stop working
on the very next OS release.

// Leonardo.

------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: New port in MacPorts and question about TokenD

David Woodhouse
In reply to this post by David Woodhouse
On Wed, 2016-09-28 at 08:28 -0600, Nathan Toone wrote:
> This is completely beyond my experience and knowledge - but does
> CommonCrypto (the apple-sanctioned crypto API to use instead of
> OpenSSL, for example) provide what is needed?

Maybe that's one option. But in addition to the "normal" TLS connection
with client certificates that CommonCrypto could provide, we *also*
need to support DTLS (TLS over UDP) with a pre-1.0 version of the DTLS
protocol Cisco are still using. The only libraries which support *that*
are OpenSSL and GnuTLS. And then only because I fixed them both to do
so :)

So we'd end up having to have a horrible hybrid of one crypto library
for the TLS connection, and another one for DTLS. Which actually we
*have* had for years but I'd *just* abolished it :)

And it's also been a horribly painful experience trying to get OpenSSL
and GnuTLS to Just Work™ with all the random certificates you're going
to encounter in the wild. Doing it all again for CommonCrypto doesn't
strike me as being a recipe for happiness, especially as I don't even
have an OSX test box to hand.

If somebody *really* wanted to step forward and promise to maintain a
CommonCrypto back end with feature parity, I might be inclined to allow
them. But I doubt it's something I'm going to embark upon myself.

I think we'd be much better off adding Keychain support to GnuTLS under
its "system keys" support, much as it has CAPI/CNG support on Windows.

Hell, you could basically cobble this together by hacking up my
existing TPM support in OpenConnect¹ and making it use the Keychain
functions like SecKeyRawSign()² instead of the Trousers TSS functions.

Forget the whole #ifndef HAVE_GNUTLS_CERTIFICATE_SET_KEY code block
from line 40-96. Nobody cares about versions that old any more.

So the tpm_sign_fn() function ends up basically just being a call to
SecKeyRawSign(), and the load_tpm_key() function just needs to find the
appropriate SecKey object in the (appropriate) Keychain, so it can be
used later in tpm_sign_fn(). How hard can *that* be? :)

cf. http://stackoverflow.com/questions/5767957/get-certificates-in-keychain

But now I look into it, it looks like these Keychain APIs are the
*same* as Jay's KeychainToken is using; I'm not sure it's so obsolete
after all. Perhaps homebrew/MacPorts/etc. should just be shipping
KeychainToken by default, enabled via a p11-kit module file, and then
keys in the token would just automatically be visible to well-behaved
*nix applications.



-- 
dwmw2

¹ http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/gnutls_tpm.c
² https://developer.apple.com/reference/security/1618025-seckeyrawsign
------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment