opensc-devel — discussion of developement of OpenSC and related projects

Re: [Opensc-devel] "Waiting for touch" notification

[Martin P. <ma...@ma...>]

Hi,

I made a wrapper for OSX that shows a notification when the PGP keys are 
used, can probably be extended to work on Linux etc.

Will publish the setup guide on Github after I verify that the 
instructions are repeatable.

Martin

On 16/10/2016 19:02, Thomas Habets wrote:
> When it's waiting for a touch it just waits with no user notification
> outside of the yubikey blinking. Since I have a Yubikey 4 Nano the
> blinking is not always in view, which makes me type "ssh"/"git push"
> and just stare at the screen.
>
> Has anyone explored how to surface this "please touch the smartcard"
> or something message to the user with opensc?
>
> I can imagine an ugly solution where if there's an outstanding "sign"
> operation for more than epsilon time, then maybe connect to this unix socket
> and say something, or shell out to this command. I can then use that
> to do something better than, but similar to, running:
>    xmessage 'touch the yubikey'
>
> [1] https://blog.habets.se/2016/01/Yubikey-4-for-SSH-with-physical-presence-proof
>

Re: [Opensc-devel] "Waiting for touch" notification

[Douglas E E. <dee...@gm...>]

This sounds similar to PKCS#11 CKA_ALWAYS_AUTHENTICATE and C_Login ( CKU_CONTEXT_SPECIFIC) which is designed to request the PIN for each crypto operation. NIST 800-73 says a PIV compliant card 
requires the verification of the PIN just before the use of the 9C key on the card. (The sign key)
OpenSC PKCS#11 supports this. But the  PKCS#11 application needs to recognize the CKA_ALWAYS_AUTHENTICATE attribute of the key and put up a prompt requesting the PIN.

It also sounds like an extension by Yubico of the official PIV specifications. Does the PIN need to be entered in addition or in place of touching?

You could try the Yubico PKCS#11 module and see if has the same problem.

If the only issue is you can't see it blinking,  you could use the Yubikey in a USB hub placed so you can see it :-)


On 10/16/2016 11:02 AM, Thomas Habets wrote:
> When it's waiting for a touch it just waits with no user notification
> outside of the yubikey blinking. Since I have a Yubikey 4 Nano the
> blinking is not always in view, which makes me type "ssh"/"git push"
> and just stare at the screen.
>
> Has anyone explored how to surface this "please touch the smartcard"
> or something message to the user with opensc?
>
> I can imagine an ugly solution where if there's an outstanding "sign"
> operation for more than epsilon time, then maybe connect to this unix socket
> and say something, or shell out to this command. I can then use that
> to do something better than, but similar to, running:
>    xmessage 'touch the yubikey'
>
> [1] https://blog.habets.se/2016/01/Yubikey-4-for-SSH-with-physical-presence-proof
>

-- 

  Douglas E. Engert  <DEE...@gm...>
  

[Opensc-devel] "Waiting for touch" notification

[Thomas H. <th...@ha...>]

When it's waiting for a touch it just waits with no user notification
outside of the yubikey blinking. Since I have a Yubikey 4 Nano the
blinking is not always in view, which makes me type "ssh"/"git push"
and just stare at the screen.

Has anyone explored how to surface this "please touch the smartcard"
or something message to the user with opensc?

I can imagine an ugly solution where if there's an outstanding "sign"
operation for more than epsilon time, then maybe connect to this unix socket
and say something, or shell out to this command. I can then use that
to do something better than, but similar to, running:
  xmessage 'touch the yubikey'

[1] https://blog.habets.se/2016/01/Yubikey-4-for-SSH-with-physical-presence-proof

-- 
typedef struct me_s {
 char name[]      = { "Thomas Habets" };
 char email[]     = { "th...@ha..." };
 char kernel[]    = { "Linux" };
 char *pgpKey[]   = { "http://www.habets.pp.se/pubkey.txt" };
 char pgp[] = { "9907 8698 8A24 F52F 1C2E  87F6 39A4 9EEA 460A 0169" };
 char coolcmd[]   = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;

Re: [Opensc-devel] One bad PIN entry locks card

[Ernie K. <ern...@gm...>]

PROBLEM SOLVED

Thanks, everyone! The problem turned out to be in our use of JSS.

The JSS PK11Token login method takes a password callback handler. The
handler has a getPasswordAgain method that's used for retries, and
returning anything but null will result in a locked card.

The handler should look something like this:

    PasswordCallback pwcb = new PasswordCallback() {
        @Override
        public Password getPasswordFirstAttempt(PasswordCallbackInfo info)
throws GiveUpException {
            return new Password(pin.toCharArray());
        }
        @Override
        public Password getPasswordAgain(PasswordCallbackInfo info) throws
GiveUpException {
            return null;
        }
    };

This results in the expected IncorrectPasswordException when the PIN is bad.

Thanks again -
Ernie


On Mon, Oct 10, 2016 at 10:53 PM, Frank Morgner <fra...@go...
> wrote:

> Have you looked at the patches which add support for cac
> https://github.com/OpenSC/OpenSC/pull/841?
>
> Am 9. Oktober 2016 19:24:13 MESZ, schrieb Ernie Kovak <
> ern...@gm...>:
>
>> Hello -
>>
>> We're using NSS (JSS4 and NSS 3.20) with an OpenSC 0.16.0 module to
>> interact with a DoD CAC. CACs will lock after 3 consecutive bad PIN
>> entries, of course, and we're finding that if the user enters a bad PIN
>> even once, that hard limit is exceeded and the card is locked.
>>
>> I've substituted an ActivClient module and found that it does not lock
>> the card, so it seems like OpenSC is retrying with a bad PIN??
>>
>> If that's true, is there a configuration item that I can set to suppress
>> retries in this case?
>>
>> Thanks!
>> Ernie
>>
>> ------------------------------
>>
>> 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
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>>
> --
> Frank Morgner
>

[Opensc-devel] OpenSC now supports the use of OpenSSL-1.1.0 - Major API changes

[Douglas E E. <dee...@gm...>]

The OpenSSL-1.1.0 API now used within OpenSC. OpenSC developers are in encouraged to read

  https://github.com/OpenSC/OpenSC/pull/861

src/libopensc/sc-ossl-compat.h uses defines, macros and inline code for backward compatibility with older versions of OpenSSL. It only implements backward compatibility for functions currently used by 
OpenSC and may need additional changes.

PR 861 changed a lot of code and only partially tested. Please test the https://github.com/OpenSC/OpenSC master branch with any of your devices or proposed changes. You can test with whatever OpenSSL 
version you need. But you may need to change your code to use the OPenSSL-1.1.0 API.

https://github.com/OpenSC/OpenSC/pull/884 is the first bug found with the code. It showed up on MacOS.

-- 

  Douglas E. Engert  <DEE...@gm...>
  

Re: [Opensc-devel] One bad PIN entry locks card

[Douglas E E. <dee...@gm...>]

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    As Martin said, a debug log would help. <br>
    In addition to setting the debug level  in opensc.conf, you may want
    to turn off any pin caching to see if your problem is related to
    that.<br>
    Or if you have a PIN pad reader, try it. That forces a pin pad
    request for every time a PIN is needed. <br>
    <br>
    If possible can you try with OpenSC github master. <br>
    <br>
    <div class="moz-cite-prefix">On 10/9/2016 12:24 PM, Ernie Kovak
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAKC-s8h2S0o3FKCaQAZsmEa=L5b...@ma..."
      type="cite">
      <div dir="ltr">Hello -
        <div><br>
        </div>
        <div><span
            style="font-family:arial,helvetica,sans-serif;font-size:13px">We're
            using NSS (JSS4 and NSS 3.20) with an OpenSC 0.16.0 module
            to interact with a DoD CAC. CACs will lock after 3
            consecutive bad PIN entries, of course, and we're finding
            that if the user enters a bad PIN even once, that hard limit
            is exceeded and the card is locked. </span><br>
        </div>
        <div><span
            style="font-family:arial,helvetica,sans-serif;font-size:13px"><br>
          </span></div>
        <div><span
            style="font-family:arial,helvetica,sans-serif;font-size:13px">I've
            substituted an ActivClient module and found that it does not
            lock the card, so it seems like OpenSC is retrying with a
            bad PIN??</span></div>
        <div><span
            style="font-family:arial,helvetica,sans-serif;font-size:13px"><br>
          </span></div>
        <div><font face="arial, helvetica, sans-serif">If that's true,
            is there a configuration item that I can set to suppress
            retries in this case?</font></div>
        <div><font face="arial, helvetica, sans-serif"><br>
          </font></div>
        <div><font face="arial, helvetica, sans-serif">Thanks!</font></div>
        <div><font face="arial, helvetica, sans-serif">Ernie</font></div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! <a class="moz-txt-link-freetext" href="http://sdm.link/slashdot">http://sdm.link/slashdot</a></pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Opensc-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ope...@li...">Ope...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/opensc-devel">https://lists.sourceforge.net/lists/listinfo/opensc-devel</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="200">-- 

 Douglas E. Engert  <a class="moz-txt-link-rfc2396E" href="mailto:DEE...@gm...">&lt;DEE...@gm...&gt;</a>
 
</pre>
  </body>
</html>

Re: [Opensc-devel] One bad PIN entry locks card

[Martin P. <ma...@ma...>]

This seems like a malfunction, by no design should a software component
re-try a PIN entry, especially if it fails at some stage. A debug log would
be helpful.

On Sun, 9 Oct 2016 at 20:25 Ernie Kovak <ern...@gm...> wrote:

> Hello -
>
> We're using NSS (JSS4 and NSS 3.20) with an OpenSC 0.16.0 module to
> interact with a DoD CAC. CACs will lock after 3 consecutive bad PIN
> entries, of course, and we're finding that if the user enters a bad PIN
> even once, that hard limit is exceeded and the card is locked.
>
> I've substituted an ActivClient module and found that it does not lock the
> card, so it seems like OpenSC is retrying with a bad PIN??
>
> If that's true, is there a configuration item that I can set to suppress
> retries in this case?
>
> Thanks!
> Ernie
>
> ------------------------------------------------------------------------------
> 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
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

[Opensc-devel] One bad PIN entry locks card

[Ernie K. <ern...@gm...>]

Hello -

We're using NSS (JSS4 and NSS 3.20) with an OpenSC 0.16.0 module to
interact with a DoD CAC. CACs will lock after 3 consecutive bad PIN
entries, of course, and we're finding that if the user enters a bad PIN
even once, that hard limit is exceeded and the card is locked.

I've substituted an ActivClient module and found that it does not lock the
card, so it seems like OpenSC is retrying with a bad PIN??

If that's true, is there a configuration item that I can set to suppress
retries in this case?

Thanks!
Ernie

Re: [Opensc-devel] Failed to connect to card: Card is invalid or cannot be handled

[morphin <ozk...@us...>]

I found a solution. U can delete or close the issue.
Thank you.



--
View this message in context: http://opensc.1086184.n5.nabble.com/Re-Failed-to-connect-to-card-Card-is-invalid-or-cannot-be-handled-tp15848p15856.html
Sent from the Developer mailing list archive at Nabble.com.

Re: [Opensc-devel] OpenSC onepin

[David W. <dw...@in...>]

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

Re: [Opensc-devel] OpenSC onepin

[Jakub J. <jj...@re...>]

On 10/04/2016 03:56 PM, fra...@gm... 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

Re: [Opensc-devel] OpenSC onepin

[<fra...@gm...>]

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
> Ope...@li...
> 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

Re: [Opensc-devel] OpenSC onepin

[Jakub J. <jj...@re...>]

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

Re: [Opensc-devel] OpenSC onepin

[David W. <dw...@in...>]

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

[Opensc-devel] OpenSC onepin

[Jakub J. <jj...@re...>]

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

Re: [Opensc-devel] Failed to connect to card: Card is invalid or cannot be handled

[morphin <ozk...@us...>]

It's smartcard, i'm calling "Sim" sorry for if misunderstood... 
This is Already using with all Turkish government State Institutions.
And this is link of the smart card. http://www.akiskart.com.tr/

I can read the card with Akis program. They'r using PKCS11 under Java. But i
couldn't read with PKCS11.
<http://opensc.1086184.n5.nabble.com/file/n15849/e-imza.png> 

I found this article at Akis Guide but i'm a shell scripter i dont know
java. Do i have to use java for pkcs11? 
http://docs.oracle.com/javase/6/docs/technotes/guides/security/p11guide.html





--
View this message in context: http://opensc.1086184.n5.nabble.com/Re-Failed-to-connect-to-card-Card-is-invalid-or-cannot-be-handled-tp15848p15849.html
Sent from the Developer mailing list archive at Nabble.com.

[Opensc-devel] Failed to connect to card: Card is invalid or cannot be handled

[morphin <ozk...@us...>]

Hello. 

I have Omnikey 6121 SC with "Akis" sim card in it. Sim= "akiskart.com.tr" 
Akis has a java program "Akia" and with the program i can read the card. But
Akia hasn't API or DOC. 

I wanna read the sim card using linux from terminal without Akia. I just
need to catch "username" information.
I installed pkcs11-tool and pkcs15-tool. I think 15 is the correct one for
my SC but both can't see sim card.
I used latest Driver for 6121: ifdokccid_linux_i686-v4.2.8

And I'm using Ubuntu 16.04

What am I missing? 
You can find more informations below. Thank you for your help. 

root@xx:/home/xx# opensc-tool --atr 
Using reader with a card: OMNIKEY AG 6121 USB mobile 00 00 
3b:9f:96:81:31:fe:45:80:67:55:45:4b:41:45:12:92:31:80:73:b3:a1:80:6a 
__________________________________________ 

root@xx:/home/xx# opensc-tool -f 
Using reader with a card: OMNIKEY AG 6121 USB mobile 00 00 
3f00 [MasterFile      ] type: DF, size: 0 
select[N/A] lock[N/A] delete[N/A] create[N/A] rehab[N/A] inval[N/A]
list[N/A] 

sc_list_files() failed: Not supported 
__________________________________________ 

root@xx:/home/xx# pkcs15-tool -L 
Using reader with a card: OMNIKEY AG 6121 USB mobile 00 00 
Failed to connect to card: Card is invalid or cannot be handled 

root@xx:/home/xx# ppkcs15-tool -k 
Using reader with a card: OMNIKEY AG 6121 USB mobile 00 00 
Failed to connect to card: Card is invalid or cannot be handled 
__________________________________________ 

root@xx:/home/xx# pkcs11-tool -L 
Available slots: 
Slot 0 (0xffffffffffffffff): Virtual hotplug slot 
  (empty) 
Slot 1 (0x1): OMNIKEY AG 6121 USB mobile 00 00 
  (empty) 

root@xx:/home/xx# pkcs11-tool -I 
Cryptoki version 2.20 
Manufacturer     OpenSC (www.opensc-project.org) 
Library          Smart card PKCS#11 API (ver 0.0) 
No slot with a token was found. 




--
View this message in context: http://opensc.1086184.n5.nabble.com/Failed-to-connect-to-card-Card-is-invalid-or-cannot-be-handled-tp15847.html
Sent from the Developer mailing list archive at Nabble.com.

Re: [Opensc-devel] New port in MacPorts and question about TokenD

[David W. <dw...@in...>]

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

Re: [Opensc-devel] New port in MacPorts and question about TokenD

[Leonardo B. S. <leo...@gm...>]

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.

Re: [Opensc-devel] New port in MacPorts and question about TokenD

[David W. <dw...@in...>]

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

Re: [Opensc-devel] New port in MacPorts and question about TokenD

[David W. <dw...@in...>]

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.

Re: [Opensc-devel] New port in MacPorts and question about TokenD

[Martin P. <ma...@ma...>]

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

Re: [Opensc-devel] New port in MacPorts and question about TokenD

[David W. <dw...@in...>]

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

Re: [Opensc-devel] New port in MacPorts and question about TokenD

[Martin P. <ma...@ma...>]

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 <
leo...@gm...> 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
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

[Opensc-devel] New port in MacPorts and question about TokenD

[Leonardo B. S. <leo...@gm...>]

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.