OpenSC onepin

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

OpenSC onepin

Jakub Jelen
Hello all,

recently we discussed the usefulness of the onepin library and basically
came to conclusion that the onepin should be used by default. Most of
the cards have only one pin (if there is the second, it is most probably
not needed to be visible in the PKCS#11, since should be "signature
pin") and also the PKCS#11 specification is moving away from the mapping
of multiple pins to multiple PKCS#11 tokens (citation needed?).

The intention of this email is to start a discussion, if we still want
to have virtual slots by default. Mozilla is not going to expose the
"friendly bit" in UI [1], which would be possible workaround. But AFAIK,
we could make that default and for the other use cases create some
virtual-slots-opensc-pkcs11.so which would behave like the current default.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=322145

Regards,

--
Jakub Jelen
Security Technologies
Red Hat


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC onepin

David Woodhouse
On Tue, 2016-10-04 at 11:55 +0200, Jakub Jelen wrote:
> Hello all,
>
> recently we discussed the usefulness of the onepin library and basically
> came to conclusion that the onepin should be used by default. Most of
> the cards have only one pin (if there is the second, it is most probably
> not needed to be visible in the PKCS#11, since should be "signature
> pin") and also the PKCS#11 specification is moving away from the mapping
> of multiple pins to multiple PKCS#11 tokens (citation needed?).

The citation for that would be
http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/cn02/pkcs11-ug-v2.40-cn02.html#_Toc406760011

> The intention of this email is to start a discussion, if we still want
> to have virtual slots by default. Mozilla is not going to expose the
> "friendly bit" in UI [1], which would be possible workaround. But AFAIK,
> we could make that default and for the other use cases create some
> virtual-slots-opensc-pkcs11.so which would behave like the current default.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=322145

Hm, that manages to be all about the CKA_PRIVATE attribute on objects,
without ever once mentioning CKA_PRIVATE. Impressive :)

It seems that the NSS softokn doesn't *permit* you to specify
CKA_PRIVATE==CK_TRUE when importing a cert...

$ p11tool --load-certificate ec-cert.pem --mark-private --label OC-EC --id 123403 --write 'pkcs11:token=NSS%20Certificate%20DB'
...
C_CreateObject
  IN: hSession = S16777217
  IN: pTemplate = (10) [ CKA_CLASS, CKA_ID, CKA_VALUE, CKA_TOKEN, CKA_CERTIFICATE_TYPE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, CKA_LABEL, CKA_PRIVATE ]
C_CreateObject = CKR_ATTRIBUTE_VALUE_INVALID


NSS therefore knows that its own token will always show *all*
certificates in a C_FindObjects() call even before login. It calls this
special-case behaviour "friendly".

We can't know that other tokens are "friendly", because objects can be
explicitly created with CKA_PRIVATE==CK_TRUE and if they are created
*without* an explicit value for CKA_PRIVATE then the token itself gets
to choose, and some tokens *do* set CKA_PRIVATE==CK_TRUE even for
CKO_CERTIFICATE objects, if given the choice.

So what's the problem here? That NSS is trying to log in to *all* the
different PKCS#11 slots of a given card, which are exposed separately
in PKCS#11 because they *might* theoretically have different PINs? 

And the proposed solution is to stop exposing multiple PKCS#11 slots
per card, because in practice people *don't* actually set multiple PINs
on the same card? So at least they only get one PIN prompt?

I'd still prefer to see the NSS behaviour improved, and perhaps achieve
some kind of consensus on how we search for objects in various
"friendly" and non-friendly tokens. 

For a start, why can't we iterate over all the tokens and see if we
find what we're after, and only *then* go back and log in to the ones
that need it, if we don't?  Although that doesn't necessarily fix
Firefox when we *don't* have a client cert and the request was just
opportunistic, it would fix many cases where the object *is* found.

It might also be interesting to approach the PKCS#11 TC and suggest a
new flag which tokens can report, to indicate that they *are*
"friendly", which is defined as "has no CKA_PRIVATE certificates". Or
perhaps the C_FindObjects() API can be extended in a compatible way, to
allow a token to indicate that "No CKA_PRIVATE objects were excluded
from these results" for *that* specific C_FindObjects() call. Then NSS
*would* be able to extend its "PK11_IsFriendly()" hack to cover tokens
other than its own internal softokn.


-- 
dwmw2
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
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: OpenSC onepin

Jakub Jelen
On 10/04/2016 01:17 PM, David Woodhouse wrote:

> On Tue, 2016-10-04 at 11:55 +0200, Jakub Jelen wrote:
>> Hello all,
>>
>> recently we discussed the usefulness of the onepin library and basically
>> came to conclusion that the onepin should be used by default. Most of
>> the cards have only one pin (if there is the second, it is most probably
>> not needed to be visible in the PKCS#11, since should be "signature
>> pin") and also the PKCS#11 specification is moving away from the mapping
>> of multiple pins to multiple PKCS#11 tokens (citation needed?).
> The citation for that would be
> http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/cn02/pkcs11-ug-v2.40-cn02.html#_Toc406760011

Thank you for the reference. It is exactly what I had in my mind, but I
didn't find proper words to pinpoint that.

>> The intention of this email is to start a discussion, if we still want
>> to have virtual slots by default. Mozilla is not going to expose the
>> "friendly bit" in UI [1], which would be possible workaround. But AFAIK,
>> we could make that default and for the other use cases create some
>> virtual-slots-opensc-pkcs11.so which would behave like the current default.
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=322145
> [...]
>
> So what's the problem here? That NSS is trying to log in to *all* the
> different PKCS#11 slots of a given card, which are exposed separately
> in PKCS#11 because they *might* theoretically have different PINs?

That is basically the original problem in the bug and one of the
variants brought up many times on this mailing list and among Mozilla
users. But so far, the proposed solution was to use "onepin". There was
an pressure on Mozilla to change their behavior (above bug), but it was
never accepted. Instead the specification shifted the onepin way.

I think upstream projects should follow specification recommendations
and make the tools working for most of the current users and use cases,
unless there is a good reason not to do that.

> And the proposed solution is to stop exposing multiple PKCS#11 slots
> per card, because in practice people *don't* actually set multiple PINs
> on the same card? So at least they only get one PIN prompt?
>
> I'd still prefer to see the NSS behaviour improved, and perhaps achieve
> some kind of consensus on how we search for objects in various
> "friendly" and non-friendly tokens.
>
> For a start, why can't we iterate over all the tokens and see if we
> find what we're after, and only *then* go back and log in to the ones
> that need it, if we don't?  Although that doesn't necessarily fix
> Firefox when we *don't* have a client cert and the request was just
> opportunistic, it would fix many cases where the object *is* found.

The problem is how you define what "you're after". Unless you log in,
you can never know if it is everything what you can see. You can have a
card showing only single certificate before login and hiding the other,
which would lead into very unexpected behavior for users. You can also
have empty cards, which would also fail with this heuristic.

> It might also be interesting to approach the PKCS#11 TC and suggest a
> new flag which tokens can report, to indicate that they *are*
> "friendly", which is defined as "has no CKA_PRIVATE certificates". Or
> perhaps the C_FindObjects() API can be extended in a compatible way, to
> allow a token to indicate that "No CKA_PRIVATE objects were excluded
> from these results" for *that* specific C_FindObjects() call. Then NSS
> *would* be able to extend its "PK11_IsFriendly()" hack to cover tokens
> other than its own internal softokn.

This would be the optimal approach, but it sounds like a run on a very
long distance, updating all the software to reflect these flags and the
new cards to publish these attributes. But thank you for mentioning
that. I will try to pursuit that.

Regards,

--
Jakub Jelen
Security Technologies
Red Hat


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC onepin

frankmorgner
In reply to this post by Jakub Jelen
Hi!

If I'm not mistaken, we are not exposing a virtual hotplug slot to the
application anymore.  Slots are only created for actual readers, see
https://github.com/OpenSC/OpenSC/blob/master/src/pkcs11/slot.c#L142. I
reintroduced the virtual hotplug slot in
https://github.com/OpenSC/OpenSC/pull/872, because NSS currently expects
that, once created, a slot never disappears.

Do you have a link to the one-pin-discussion?

Regards,
Frank.

On Tuesday, October 04 at 11:55AM, Jakub Jelen wrote:

> Hello all,
>
> recently we discussed the usefulness of the onepin library and basically
> came to conclusion that the onepin should be used by default. Most of
> the cards have only one pin (if there is the second, it is most probably
> not needed to be visible in the PKCS#11, since should be "signature
> pin") and also the PKCS#11 specification is moving away from the mapping
> of multiple pins to multiple PKCS#11 tokens (citation needed?).
>
> The intention of this email is to start a discussion, if we still want
> to have virtual slots by default. Mozilla is not going to expose the
> "friendly bit" in UI [1], which would be possible workaround. But AFAIK,
> we could make that default and for the other use cases create some
> virtual-slots-opensc-pkcs11.so which would behave like the current default.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=322145
>
> Regards,
>
> --
> Jakub Jelen
> Security Technologies
> Red Hat
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC onepin

Jakub Jelen
On 10/04/2016 03:56 PM, [hidden email] wrote:
> Hi!
>
> If I'm not mistaken, we are not exposing a virtual hotplug slot to the
> application anymore.

Yes, you are right. The master does not show this one. But as far as I
understand to this problem is not in the virtual hotplug, but in the
PINs of the card creating the virtual slots, isn't it?

> Slots are only created for actual readers, see
> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs11/slot.c#L142. I
> reintroduced the virtual hotplug slot in
> https://github.com/OpenSC/OpenSC/pull/872, because NSS currently expects
> that, once created, a slot never disappears.
>
> Do you have a link to the one-pin-discussion?
It was internal/offline discussion, mostly theoretical (based on the
mails, comments and issues), because I don't have any cards exposing
more PINs in this way and that would make a difference of the both
libraries to test.

 From the discussion, what we would like to avoid is to have two
(basically same) libraries in the OS for several reasons (p11-kit, ...).
The inception to make the other symlink came in the mailing list more
than two years ago [1] without any follow up. The pursuing the solution
without virtual slots (single PIN) sounds reasonable for most of the
cards. But still I might miss some part of the current behavior so
correct me if I am wrong.

[1] http://opensc.1086184.n5.nabble.com/opensc-onepin-td14433.html

Regards,

--
Jakub Jelen
Security Technologies
Red Hat


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC onepin

David Woodhouse
In reply to this post by Jakub Jelen
On Tue, 2016-10-04 at 14:41 +0200, Jakub Jelen wrote:

> On 10/04/2016 01:17 PM, David Woodhouse wrote:
> > So what's the problem here? That NSS is trying to log in to *all* the
> > different PKCS#11 slots of a given card, which are exposed separately
> > in PKCS#11 because they *might* theoretically have different PINs?
>
> That is basically the original problem in the bug and one of the
> variants brought up many times on this mailing list and among Mozilla
> users. But so far, the proposed solution was to use "onepin". There was
> an pressure on Mozilla to change their behavior (above bug), but it was
> never accepted. Instead the specification shifted the onepin way.
>
> I think upstream projects should follow specification recommendations
> and make the tools working for most of the current users and use cases,
> unless there is a good reason not to do that.
Well, the problem is that the specification doesn't actually *give* any
recommendations here. The overall behaviour of applications trying to
find an object across a number of PKCS#11 tokens is *entirely*
unspecified, without even any hints about common practice in the Usage
Guide.

I'm trying to remedy that (amongst other things) in 
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html

> > For a start, why can't we iterate over all the tokens and see if we
> > find what we're after, and only *then* go back and log in to the ones
> > that need it, if we don't?  Although that doesn't necessarily fix
> > Firefox when we *don't* have a client cert and the request was just
> > opportunistic, it would fix many cases where the object *is* found.
>
> The problem is how you define what "you're after". Unless you log in,
> you can never know if it is everything what you can see. You can have a
> card showing only single certificate before login and hiding the other,
> which would lead into very unexpected behavior for users. You can also
> have empty cards, which would also fail with this heuristic.
Right. So far I've been focusing on tools which take a certificate
specifier (previously just a filename, but now a PKCS#11 URI) on the
command line or in a config file. In that case it's simple — if the
certificate has CKA_PRIVATE==CK_TRUE, then the PKCS11 URI needs to
uniquely specify the token. Then we'll log into that token, and find
the certificate we need.

For NSS, some of the FindCertificate* APIs do operate only on the
internal softokn, and not on external tokens at all. Others will
attempt to iterate over all tokens, requiring PINs for them all.

> >
> > It might also be interesting to approach the PKCS#11 TC and suggest a
> > new flag which tokens can report, to indicate that they *are*
> > "friendly", which is defined as "has no CKA_PRIVATE certificates". Or
> > perhaps the C_FindObjects() API can be extended in a compatible way, to
> > allow a token to indicate that "No CKA_PRIVATE objects were excluded
> > from these results" for *that* specific C_FindObjects() call. Then NSS
> > *would* be able to extend its "PK11_IsFriendly()" hack to cover tokens
> > other than its own internal softokn.
>
> This would be the optimal approach, but it sounds like a run on a very
> long distance, updating all the software to reflect these flags and the
> new cards to publish these attributes. But thank you for mentioning
> that. I will try to pursuit that.
Actually, there isn't *much* software to update. Applications generally
don't do this for themselves. We fix NSS, GnuTLS and the OpenSSL
PKCS#11 ENGINE, and that actually covers *much* of the ecosystem.

But first we do need a consensus on the behaviour we want them to
implement. Even in the Mozilla bug you referenced, I don't see a
specific algorithm that would work.

--
dwmw2
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment