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

Re: [Opensc-devel] IDPrime MD

[Pawel J. <paw...@gm...>]

On Thu, Dec 19, 2019 at 2:11 PM Jakub Jelen <jj...@re...> wrote:
>
> On Thu, 2019-12-19 at 00:00 +0100, Pawel Jasinski wrote:
> > Hi,
> >
> > I am trying to get IDPrime MD card to work. After compiling the PR
> > from: https://github.com/OpenSC/OpenSC/pull/1772 the following errors
> > are reported:
> >
> > rejap@zed:~/github/OpenSC-IdPrime$ opensc-tool --verbose --serial --
> > info --atr
> > OpenSC 0.20.0 [gcc  7.4.0]
> > Enabled features: locking zlib openssl pcsc(libpcsclite.so.1)
> > Using reader with a card: Alcor Micro AU9560 00 00
> > Card ATR:
> > 3B 7F 96 00 00 80 31 80 65 B0 84 56 51 10 12 0F ;.....1.e..VQ...
> > FE 82 90 00                                     ....
> > Connecting to card in reader Alcor Micro AU9560 00 00...
> > Failed to connect to card: Wrong length
> >
> > Enabling debug reveals the following:
> > ...
> > P:9939; T:0x139703700438912 23:48:50.051 [opensc-tool]
> > iso7816.c:576:iso7816_select_file: returning with: -1205 (Incorrect
> > parameters in APDU)
> > P:9939; T:0x139703700438912 23:48:50.052 [opensc-tool]
> > card.c:842:sc_select_file: 'SELECT' error: -1205 (Incorrect
> > parameters
> > in APDU)
> > P:9939; T:0x139703700438912 23:48:50.052 [opensc-tool]
> > dir.c:172:sc_enum_apps: Cannot select EF.DIR file: -1205 (Incorrect
> > parameters in APDU)
> > ...
> > P:9939; T:0x139703700438912 23:48:50.243 [opensc-tool]
> > iso7816.c:162:iso7816_read_binary: Check SW error: -1211 (Security
> > status not satisfied)
> > P:9939; T:0x139703700438912 23:48:50.243 [opensc-tool]
> > card-idprime.c:216:idprime_process_index: returning with: -1206
> > (Wrong
> > length)
> > P:9939; T:0x139703700438912 23:48:50.243 [opensc-tool]
> > card-idprime.c:274:idprime_init: returning with: -1206 (Wrong length)
> > P:9939; T:0x139703700438912 23:48:50.243 [opensc-tool]
> > card.c:362:sc_connect_card: driver 'Gemalto IDPrime' init() failed:
> > Wrong length
> > P:9939; T:0x139703700438912 23:48:50.244 [opensc-tool]
> > reader-pcsc.c:637:pcsc_disconnect: Alcor Micro AU9560 00
> > 00:SCardDisconnect returned: 0x00000000
> > P:9939; T:0x139703700438912 23:48:50.244 [opensc-tool]
> > card.c:406:sc_connect_card: returning with: -1206 (Wrong length)
> > Failed to connect to card: Wrong length
> >
> > Those are only error parts. Full log can be posted if needed.
> >
> > Is there a hope to support this card?  I wouldn't mind spending some
> > time tinkering with it, but I definitely need help.
> > Not sure if it makes a difference, but I am able to capture USB
> > communication when card is used from Windows.
>
> Hello Pawel,
>
> thank you for your interest. I still hope that we could support this
> card, but with the lack of specification, it is hard to get all the
> corner cases correctly. Especially when there are different versions of
> the IDPrime and different versions of the applets. I have only one card
> with only one applet version, which I based the changes on.
>
> The full debug log would certainly help. The context of your messages
> is not completely clear. You can share it here, to the PR or directly
> to my email, but that should really not contain any private information
> before you start writing PINs :)
>
> Best regards,
> --
> Jakub Jelen
> Senior Software Engineer
> Security Technologies
> Red Hat, Inc.
>

I did some extra poking and I am afraid communication between card and
driver is partially encrypted.
My experiment involves capturing USB traffic between card reader and
Windows guest.
First test involves inserting a card into windows twice and comparing
2 captures. The captured communication looks almost identical in both
cases until the point where payload with random content appears.
After this packet, the flow of communication is still identical
(commands, sizes, sequences) but payloads are different.
Second test involves capturing packets during "certutil.exe -scinfo"
which retrieves content of certificates from smart card.
I am not able to find any strings from certificates in the captured stream.
--pawel

Re: [Opensc-devel] IDPrime MD

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

On Thu, 2019-12-19 at 00:00 +0100, Pawel Jasinski wrote:
> Hi,
> 
> I am trying to get IDPrime MD card to work. After compiling the PR
> from: https://github.com/OpenSC/OpenSC/pull/1772 the following errors
> are reported:
> 
> rejap@zed:~/github/OpenSC-IdPrime$ opensc-tool --verbose --serial --
> info --atr
> OpenSC 0.20.0 [gcc  7.4.0]
> Enabled features: locking zlib openssl pcsc(libpcsclite.so.1)
> Using reader with a card: Alcor Micro AU9560 00 00
> Card ATR:
> 3B 7F 96 00 00 80 31 80 65 B0 84 56 51 10 12 0F ;.....1.e..VQ...
> FE 82 90 00                                     ....
> Connecting to card in reader Alcor Micro AU9560 00 00...
> Failed to connect to card: Wrong length
> 
> Enabling debug reveals the following:
> ...
> P:9939; T:0x139703700438912 23:48:50.051 [opensc-tool]
> iso7816.c:576:iso7816_select_file: returning with: -1205 (Incorrect
> parameters in APDU)
> P:9939; T:0x139703700438912 23:48:50.052 [opensc-tool]
> card.c:842:sc_select_file: 'SELECT' error: -1205 (Incorrect
> parameters
> in APDU)
> P:9939; T:0x139703700438912 23:48:50.052 [opensc-tool]
> dir.c:172:sc_enum_apps: Cannot select EF.DIR file: -1205 (Incorrect
> parameters in APDU)
> ...
> P:9939; T:0x139703700438912 23:48:50.243 [opensc-tool]
> iso7816.c:162:iso7816_read_binary: Check SW error: -1211 (Security
> status not satisfied)
> P:9939; T:0x139703700438912 23:48:50.243 [opensc-tool]
> card-idprime.c:216:idprime_process_index: returning with: -1206
> (Wrong
> length)
> P:9939; T:0x139703700438912 23:48:50.243 [opensc-tool]
> card-idprime.c:274:idprime_init: returning with: -1206 (Wrong length)
> P:9939; T:0x139703700438912 23:48:50.243 [opensc-tool]
> card.c:362:sc_connect_card: driver 'Gemalto IDPrime' init() failed:
> Wrong length
> P:9939; T:0x139703700438912 23:48:50.244 [opensc-tool]
> reader-pcsc.c:637:pcsc_disconnect: Alcor Micro AU9560 00
> 00:SCardDisconnect returned: 0x00000000
> P:9939; T:0x139703700438912 23:48:50.244 [opensc-tool]
> card.c:406:sc_connect_card: returning with: -1206 (Wrong length)
> Failed to connect to card: Wrong length
> 
> Those are only error parts. Full log can be posted if needed.
> 
> Is there a hope to support this card?  I wouldn't mind spending some
> time tinkering with it, but I definitely need help.
> Not sure if it makes a difference, but I am able to capture USB
> communication when card is used from Windows.

Hello Pawel,

thank you for your interest. I still hope that we could support this
card, but with the lack of specification, it is hard to get all the
corner cases correctly. Especially when there are different versions of
the IDPrime and different versions of the applets. I have only one card
with only one applet version, which I based the changes on.

The full debug log would certainly help. The context of your messages
is not completely clear. You can share it here, to the PR or directly
to my email, but that should really not contain any private information
before you start writing PINs :)

Best regards,
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.

[Opensc-devel] IDPrime MD

[Pawel J. <paw...@gm...>]

Hi,

I am trying to get IDPrime MD card to work. After compiling the PR
from: https://github.com/OpenSC/OpenSC/pull/1772 the following errors
are reported:

rejap@zed:~/github/OpenSC-IdPrime$ opensc-tool --verbose --serial --info --atr
OpenSC 0.20.0 [gcc  7.4.0]
Enabled features: locking zlib openssl pcsc(libpcsclite.so.1)
Using reader with a card: Alcor Micro AU9560 00 00
Card ATR:
3B 7F 96 00 00 80 31 80 65 B0 84 56 51 10 12 0F ;.....1.e..VQ...
FE 82 90 00                                     ....
Connecting to card in reader Alcor Micro AU9560 00 00...
Failed to connect to card: Wrong length

Enabling debug reveals the following:
...
P:9939; T:0x139703700438912 23:48:50.051 [opensc-tool]
iso7816.c:576:iso7816_select_file: returning with: -1205 (Incorrect
parameters in APDU)
P:9939; T:0x139703700438912 23:48:50.052 [opensc-tool]
card.c:842:sc_select_file: 'SELECT' error: -1205 (Incorrect parameters
in APDU)
P:9939; T:0x139703700438912 23:48:50.052 [opensc-tool]
dir.c:172:sc_enum_apps: Cannot select EF.DIR file: -1205 (Incorrect
parameters in APDU)
...
P:9939; T:0x139703700438912 23:48:50.243 [opensc-tool]
iso7816.c:162:iso7816_read_binary: Check SW error: -1211 (Security
status not satisfied)
P:9939; T:0x139703700438912 23:48:50.243 [opensc-tool]
card-idprime.c:216:idprime_process_index: returning with: -1206 (Wrong
length)
P:9939; T:0x139703700438912 23:48:50.243 [opensc-tool]
card-idprime.c:274:idprime_init: returning with: -1206 (Wrong length)
P:9939; T:0x139703700438912 23:48:50.243 [opensc-tool]
card.c:362:sc_connect_card: driver 'Gemalto IDPrime' init() failed:
Wrong length
P:9939; T:0x139703700438912 23:48:50.244 [opensc-tool]
reader-pcsc.c:637:pcsc_disconnect: Alcor Micro AU9560 00
00:SCardDisconnect returned: 0x00000000
P:9939; T:0x139703700438912 23:48:50.244 [opensc-tool]
card.c:406:sc_connect_card: returning with: -1206 (Wrong length)
Failed to connect to card: Wrong length

Those are only error parts. Full log can be posted if needed.

Is there a hope to support this card?  I wouldn't mind spending some
time tinkering with it, but I definitely need help.
Not sure if it makes a difference, but I am able to capture USB
communication when card is used from Windows.

Cheers
Pawel

Re: [Opensc-devel] SafenetID Prime 940

[Alex B. <al...@al...>]

You can buy these cards on the open market in quantities as small as 1, then load your own certs for testing.

> El 10 oct 2019, a les 11:50, J.W...@mi... va escriure:
> 
> Hi Jakub,
> 
> Right now, I don't have any of them yet.
> I could order one, but that will cost me at least 500 euro (card including official governmental certificates)
> If I can get permission, and put the bill on someone else's desk, I will do so.
> When so, I'll report the ATR
> 
> 
> Met vriendelijke groet,
> Hans Witvliet, J, Ing., DMO/OPS/I&S/APH, Kennis Team Opensource
> Coldenhovelaan 1 Maasland 3531RC Coldehovelaan 1, kamer B213
> 
> 
> -----Original Message-----
> From: Jakub Jelen [mailto:jj...@re...]
> Sent: donderdag 10 oktober 2019 10:30
> To: Witvliet, J, Ing., DMO/JIVC/GIT&INFRA/ITT; ope...@li...
> Subject: Re: [Opensc-devel] SafenetID Prime 940
> 
>> On Wed, 2019-10-09 at 15:20 +0000, J.W...@mi... wrote:
>> Anyone around having experience with this card under Linux?
>> Does it work with opensc / pkcs11_tool / openvpn as shipped with most
>> distro's ??
> 
> Hello,
> At this moment, I think it is not supported in any released version of
> OpenSC. But I was recently working on adding the support for IDPrime
> 3810 and and IDPrime MD 840 (I think -- the numbers are not written on
> the cards and there is no specification) so feel free to try with the
> following changes:
> 
> https://github.com/OpenSC/OpenSC/pull/1772
> 
> What ATR does your card report?
> 
>  opensc-tool --atr
> 
> Regards,
> Jakub
> 
>> Met vriendelijke groet,
>> Hans Witvliet, J, Ing., DMO/OPS/I&S/APH, Kennis Team Opensource
>> Coldenhovelaan 1 Maasland 3531RC Coldehovelaan 1, kamer B213
>> 
>> 
>> Dit bericht kan informatie bevatten die niet voor u is bestemd.
>> Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u
>> is toegezonden, wordt u verzocht dat aan de afzender te melden en het
>> bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid
>> voor schade, van welke aard ook, die verband houdt met risico's
>> verbonden aan het elektronisch verzenden van berichten.
>> 
>> This message may contain information that is not intended for you. If
>> you are not the addressee or if this message was sent to you by
>> mistake, you are requested to inform the sender and delete the
>> message. The State accepts no liability for damage of any kind
>> resulting from the risks inherent in the electronic transmission of
>> messages.
>> _______________________________________________
>> Opensc-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> --
> Jakub Jelen
> Senior Software Engineer
> Security Technologies
> Red Hat, Inc.
> 
> 
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
> 
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
> 
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel

Re: [Opensc-devel] SafenetID Prime 940

[<J.W...@mi...>]

Hi Jakub,

Right now, I don't have any of them yet.
I could order one, but that will cost me at least 500 euro (card including official governmental certificates)
If I can get permission, and put the bill on someone else's desk, I will do so.
When so, I'll report the ATR


Met vriendelijke groet,
Hans Witvliet, J, Ing., DMO/OPS/I&S/APH, Kennis Team Opensource
Coldenhovelaan 1 Maasland 3531RC Coldehovelaan 1, kamer B213


-----Original Message-----
From: Jakub Jelen [mailto:jj...@re...]
Sent: donderdag 10 oktober 2019 10:30
To: Witvliet, J, Ing., DMO/JIVC/GIT&INFRA/ITT; ope...@li...
Subject: Re: [Opensc-devel] SafenetID Prime 940

On Wed, 2019-10-09 at 15:20 +0000, J.W...@mi... wrote:
> Anyone around having experience with this card under Linux?
> Does it work with opensc / pkcs11_tool / openvpn as shipped with most
> distro's ??

Hello,
At this moment, I think it is not supported in any released version of
OpenSC. But I was recently working on adding the support for IDPrime
3810 and and IDPrime MD 840 (I think -- the numbers are not written on
the cards and there is no specification) so feel free to try with the
following changes:

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

What ATR does your card report?

  opensc-tool --atr

Regards,
Jakub

> Met vriendelijke groet,
> Hans Witvliet, J, Ing., DMO/OPS/I&S/APH, Kennis Team Opensource
> Coldenhovelaan 1 Maasland 3531RC Coldehovelaan 1, kamer B213
>
>
> Dit bericht kan informatie bevatten die niet voor u is bestemd.
> Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u
> is toegezonden, wordt u verzocht dat aan de afzender te melden en het
> bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid
> voor schade, van welke aard ook, die verband houdt met risico's
> verbonden aan het elektronisch verzenden van berichten.
>
> This message may contain information that is not intended for you. If
> you are not the addressee or if this message was sent to you by
> mistake, you are requested to inform the sender and delete the
> message. The State accepts no liability for damage of any kind
> resulting from the risks inherent in the electronic transmission of
> messages.
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
--
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.


Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

Re: [Opensc-devel] SafenetID Prime 940

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

On Wed, 2019-10-09 at 15:20 +0000, J.W...@mi... wrote:
> Anyone around having experience with this card under Linux?
> Does it work with opensc / pkcs11_tool / openvpn as shipped with most
> distro's ??

Hello,
At this moment, I think it is not supported in any released version of
OpenSC. But I was recently working on adding the support for IDPrime
3810 and and IDPrime MD 840 (I think -- the numbers are not written on
the cards and there is no specification) so feel free to try with the
following changes:

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

What ATR does your card report?

  opensc-tool --atr

Regards,
Jakub

> Met vriendelijke groet,
> Hans Witvliet, J, Ing., DMO/OPS/I&S/APH, Kennis Team Opensource
> Coldenhovelaan 1 Maasland 3531RC Coldehovelaan 1, kamer B213
> 
> 
> Dit bericht kan informatie bevatten die niet voor u is bestemd.
> Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u
> is toegezonden, wordt u verzocht dat aan de afzender te melden en het
> bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid
> voor schade, van welke aard ook, die verband houdt met risico's
> verbonden aan het elektronisch verzenden van berichten.
> 
> This message may contain information that is not intended for you. If
> you are not the addressee or if this message was sent to you by
> mistake, you are requested to inform the sender and delete the
> message. The State accepts no liability for damage of any kind
> resulting from the risks inherent in the electronic transmission of
> messages.
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.

[Opensc-devel] SafenetID Prime 940

[<J.W...@mi...>]

Anyone around having experience with this card under Linux?
Does it work with opensc / pkcs11_tool / openvpn as shipped with most distro's ??


Met vriendelijke groet,
Hans Witvliet, J, Ing., DMO/OPS/I&S/APH, Kennis Team Opensource
Coldenhovelaan 1 Maasland 3531RC Coldehovelaan 1, kamer B213


Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

[Opensc-devel] Security devroom on FOSDEM 2020

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

Hello OpenSC enthusiasts,

we are organizing, again, security devroom on next FOSDEM so I would
like to invite you, if you have interesting topic to share, you would
like to come and see other talks or just come to say hello or have a
chat.

For more information, see the official announcement:

https://lists.fosdem.org/pipermail/security-devroom/2019/000187.html

Looking forwards to see you there.
Regards,
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.

[Opensc-devel] pam_p11 0.3.1 released

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

Hi all!

I'm happy to announce the new pam_p11 release 0.3.1, which can be found
here https://github.com/OpenSC/pam_p11/releases/tag/pam_p11-0.3.1.
<https://github.com/OpenSC/pam_p11/releases/tag/pam_p11-0.3.1> This release
fixes a buffer overflow when creating signatures longer than 256 bytes
(CVE-2019-16058). This bug is present in pam_p11 version 0.2.0 and 0.3.0.

Regards, Frank.

[Opensc-devel] Upcoming release 0.19.0 needs testing

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

Hi all!

You'll find a pre-release of OpenSC 0.20.0 on Github
<https://github.com/OpenSC/OpenSC/releases/tag/0.20.0-rc1>. A draft version
of the user visible changes is available in this ticket
<https://github.com/OpenSC/OpenSC/issues/1782>.

Refer to the wiki page
<https://github.com/OpenSC/OpenSC/wiki/Smart-Card-Release-Testing> on how
to  systematically test your card. Please extend the page with test results
from your smart cards.

This release contains fixes for some security issues. We try to publish the
final release in the middle of September.

Regards,
Frank.

Re: [Opensc-devel] event managers

[Ludovic R. <lud...@gm...>]

Le dim. 17 mars 2019 à 15:42, <J.W...@mi...> a écrit :
> Hi all,

Hello,

> I noticed that (atleast with Ubuntu-distr), there are multiple event mnagers present:
>
> 1)      Card_eventmgr
> 2)      Pkcs11_eventmgr
> Both of them have their config residing in /etc/pam_pkcs11/
> And those file look for 90% suspiciously similar.
>
> So anyone around here  that can:
> 1)      explain what the benefit of one is over the other?

card_eventmgr detects events at the PC/SC layer.
pkcs11_eventmgr detects events at the PKCS#11 layer

If you do not use a PKCS#11 library maybe card_eventmgr is better :-)

> 2)      In case of multiple readers & multiple cards, how to see which one got inserted or removed?

I don't know. I have not used these programs since years.

> 3)      How to properly de-bounce them (on ONE event taking place, the cardin / cardout routines are multiple times executed

You should not have duplicated events.
I think it is a bug.

Bye

PS: I was the maintainer of pam_pkcs11.

-- 
 Dr. Ludovic Rousseau

[Opensc-devel] event managers

[<J.W...@mi...>]

Hi all,

I noticed that (atleast with Ubuntu-distr), there are multiple event mnagers present:


1)      Card_eventmgr

2)      Pkcs11_eventmgr
Both of them have their config residing in /etc/pam_pkcs11/
And those file look for 90% suspiciously similar.

So anyone around here  that can:

1)      explain what the benefit of one is over the other?

2)      In case of multiple readers & multiple cards, how to see which one got inserted or removed?

3)      How to properly de-bounce them (on ONE event taking place, the cardin / cardout routines are multiple times executed

Kind regards, Hans

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

Re: [Opensc-devel] Engine support for ed25519 keys

[Cameron D. <cam...@gm...>]

Following up on this.

Openssl is actively working on their Ed25519/EdDSA implementation.  Do we
know that they are moving toward an engine-friendly implementation?

I say this because I followed EC support in libp11 and know it had to do
some tricks to get it to work with openssl.  The openssl developers
eventually reworked the EC_KEY interface to make it "engine friendly".
This is good.

My concern is we'll go through that same drawn out implementation approach
with Ed25519.

I've looked at the latest openssl-3.0.0-dev and I'm not sure it has the
hooks to integrate cleanly with an engine. Since openssl is working this
now, how do we encourage them to provide the right hooks for libp11 and
engine support?

Thanks,

Cam

Re: [Opensc-devel] Question about multiple applications

[Bob B. <fig...@gm...>]

Hi Douglas and Frank,

Thank you for your answer.

To answer your questions:
1. Yes, I have my own driver I implemented it based on the existing driver
implementation (EnterSafe, ePass2003 and others), it also supports PKCS# 15.
2. I am using PCSC, I used the implementation in version 0.18.0, I did not
change anything.
3. Application A is the one that called the C_OpenSession, B just keeps on
looping. I see the error on C_OpenSession, CKR_TOKEN_NOT_PRESENT is the
error.
4. The PRESENT and ABSENT (sorry for not being clear) is based on the
refresh_attributes (reader-pcsc.c), when the SC_READER_CARD_PRESENT is
checked.
5. I haven't tried on Linux, I do my test mainly in Windows 8.1.
5. Sorry I cannot share my codes or logs, as of the moment it is pretty
messed-up. Most of my changes are only on the driver implementation,
(card-*.c, pkcs15-*.c) but I added a lot of logs and commented-out code
everywhere.

Here's what I tried, because I wanted to isolate the problem.
 - Application B starts
 - Application B calls C_Initialize
 - Application B starts loop with sleep (without calling C_WaitForSlotEvent)
 - Application A starts
 - Application A calls C_Initialize
 - Application A calls C_InitToken
 - Application A calls C_OpenSession (FAILS, CKR_TOKEN_NOT_PRESENT)
 - Application A calls C_Finalize
 - Application A stops
 - Application B stops loop
 - Application B calls C_Finalize
 - Application B stops

As you can see it is still the same issue, I tried to debug why the
C_OpenSession is returning the  CKR_TOKEN_NOT_PRESENT.

>From C_OpenSession, the error was returned by slot_get_token (slot.c),
from slot_get_token, error was returned by card_detect (slot.c),
card_detect is the one the returned the CKR_TOKEN_NOT_PRESENT error, after
it get 0 from sc_detect_card_presence (sc.c).

The sc_detect_card_presence called pcsc_detect_card_presence
(reader-pcsc.c),
pcsc_detect_card_presence called the refresh_attributes (reader-pcsc.c)
which returned the 0,
0 is actually SC_SUCCESS. It was returned after calling
SCardGetStatusChange and it returned SCARD_E_TIMEOUT.
When SCARD_E_TIMEOUT is returned, it will remove the SC_READER_CARD_CHANGE
from the reader flag and will return SC_SUCCESS.

Not also sure, what happened but when I trace the reader state in
refresh_attributes, I notice that on Application A the SCARD_STATE_INUSE is
always present my guess is it is because of the Application B running in
parallel.

If I run Application A alone without Application B, the SCARD_STATE_INUSE
is sometimes present, and SCARD_STATE_CHANGED is also present.

If it doesn't go in line 336 of the refresh_attributes it will be okay. So
to fix, modified line 335 to be;

if ((rv != SCARD_S_SUCCESS) && (rv != (LONG) SCARD_E_TIMEOUT)) {

So that it will always be forced to run the code after the condition in
line 335 and check for the SCARD_STATE_PRESENT reader state (line 361).

So far the hack is working for my scenario, but I am not sure if it is the
correct way to handle it or why it was built that way.

I base the line number on the original code here.
https://github.com/OpenSC/OpenSC/blob/0.18.0/src/libopensc/reader-pcsc.c


I have some additional question still related to multiple application
support of OpenSC.
Frank mentioned that;
* Consequently, when initializing the card in process A with a PIN, that
PIN doesn't show up in the sc_pkcs15_card_t object of process B if the card
was already visible for B. You should never be able to use the newly
initialized card in B (without calling C_Finalize()/C_Initialize()). *

Does this mean that on the current implementation of OpenSC, each process
that uses the PKCS# 11 module has it's own memory space and does not "share
resources"? The reason I ask is because PKCS# 11 standard section 13.2
mentioned that;
*Whenever  possible,  changing  the  value  of  an  object  attribute
should  impact  the  behavior  of  active   operations in other
applications or threads.*

It was also mentioned in section 2 that one of it's goal is the
*resource   sharing   (multiple   applications   accessing   multiple
devices),   presenting   to applications a common, logical view of the
device called a “cryptographic token”.*

If I wanted to support this, what will be the best way to approach it,
create a shared memory or create a dedicated service to sync the
sc_pkcs15_card_t object across all applications/processes?

Source:
https://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-11r1.pdf

I greatly appreciate your time and patience and I want you to know that I
am learning a lot from you.


Thanks,

Jared

On Sun, Dec 30, 2018 at 9:04 PM Douglas E Engert <dee...@gm...> wrote:

> My interpretation was A initialized the card, but B did not realize that
> happened.
> so A needs to force a reset when the initializing is complete.
>
> As you point out B could have interfered with the initialization if A did
> not hold
> the lock while doing all the initialization steps to keep B from
> interfering.
>
> With out some logs (and it sounds like he is writing a new diver) it is
> hard to say.
>
>
> On 12/29/2018 6:35 PM, Frank Morgner wrote:
> > We don't need to share a mutex across processes, because we don't share
> > contexts across the process boundaries. Consequently, when initializing
> > the card in process A with a PIN, that PIN doesn't show up in the
> > sc_pkcs15_card_t object of process B if the card was already visible for
> > B. You should never be able to use the newly initialized card in B
> > (without calling C_Finalize()/C_Initialize()).
> >
> > However, calling C_WaitForSlotEvent() and C_GetTokenInfo() from B should
> > not interfere with A initializing the card. This may be a bug within
> > OpenSC.  You should check in the logs which APDUs B actually sends while
> > A is initializing.
> >
> > In general, locking in PC/SC should be done based on the command that's
> > issued to avoid interference (sc_lock()/sc_unlock()), which is why A
> > should not be interrupted during pkcs15_initialize() or
> > pkcs15_init_pin().  Whether or not unpowering the card is useful or
> > harming, depends on the card.
> >
> > If you want to get more details, send the logs and show your code.
> >
>
> --
>
>   Douglas E. Engert  <DEE...@gm...>
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

Re: [Opensc-devel] Question about multiple applications

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

My interpretation was A initialized the card, but B did not realize that happened.
so A needs to force a reset when the initializing is complete.

As you point out B could have interfered with the initialization if A did not hold
the lock while doing all the initialization steps to keep B from interfering.

With out some logs (and it sounds like he is writing a new diver) it is hard to say.


On 12/29/2018 6:35 PM, Frank Morgner wrote:
> We don't need to share a mutex across processes, because we don't share
> contexts across the process boundaries. Consequently, when initializing
> the card in process A with a PIN, that PIN doesn't show up in the
> sc_pkcs15_card_t object of process B if the card was already visible for
> B. You should never be able to use the newly initialized card in B
> (without calling C_Finalize()/C_Initialize()).
> 
> However, calling C_WaitForSlotEvent() and C_GetTokenInfo() from B should
> not interfere with A initializing the card. This may be a bug within
> OpenSC.  You should check in the logs which APDUs B actually sends while
> A is initializing.
> 
> In general, locking in PC/SC should be done based on the command that's
> issued to avoid interference (sc_lock()/sc_unlock()), which is why A
> should not be interrupted during pkcs15_initialize() or
> pkcs15_init_pin().  Whether or not unpowering the card is useful or
> harming, depends on the card.
> 
> If you want to get more details, send the logs and show your code.
> 

-- 

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

Re: [Opensc-devel] Question about multiple applications

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

We don't need to share a mutex across processes, because we don't share
contexts across the process boundaries. Consequently, when initializing
the card in process A with a PIN, that PIN doesn't show up in the
sc_pkcs15_card_t object of process B if the card was already visible for
B. You should never be able to use the newly initialized card in B
(without calling C_Finalize()/C_Initialize()).

However, calling C_WaitForSlotEvent() and C_GetTokenInfo() from B should
not interfere with A initializing the card. This may be a bug within
OpenSC.  You should check in the logs which APDUs B actually sends while
A is initializing.

In general, locking in PC/SC should be done based on the command that's
issued to avoid interference (sc_lock()/sc_unlock()), which is why A
should not be interrupted during pkcs15_initialize() or
pkcs15_init_pin().  Whether or not unpowering the card is useful or
harming, depends on the card.

If you want to get more details, send the logs and show your code.

-- 
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] Question about multiple applications

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

I went back and read your other emails, and have some questions below.


On 12/18/2018 9:06 PM, Bob Backlund wrote:
> Hi,
> 
> Just some question about how the OpenSC PKCS# 11 (DLL) handles the multiple applications using it.
> 
> The scenario is I have two applications, application A and application B loading the same DLL.
> 
> Application B loops continuously, calling C_WaitForSlotEvent and C_GetTokenInfo, basically it just checks for the insert and remove events from the smart card.
> 
> Application A can call C_InitPIN and C_InitToken.

You say you have logs, so I assume you have a driver. You also said you where trying to write your own driver
and you were simulation a token. Are you trying tying to simulate the token within OpenSC, without using PCSC?

If you are NOT using PCSC to coordinate access from 2 applications you are one your own. OpenSC is expecting
PCSC or one of the older reader drivers to do the coordination between applications.

> 
> The conflict happens when, while the application B is checking for smart card events, application A then calls C_InitToken, which deletes the smart card contents, and formats it to be a new card, (and 
> possibly deleting the PKCS# 15 objects) and the next call to C_OpenSession fails returning CKR_TOKEN_NOT_PRESENT error.

Is the failing "next call to C_OpenSession" done by A or B? Or by both?

OpenSC will assume the card has not changed much from one session to another and may have cached some
info about objects and files on the token in memory. But if it receives a PCSC event that says the card was reset or other error
from SCardBeginTransaction (which is done when the sc_lock goes from 0 to > 0) OpenSC will discard any cached data and
try to reconnect to the card and reread what is needed from the card, and set not logged_in.

These are possible return codes for SCard* routines:
https://docs.microsoft.com/en-us/windows/desktop/SecAuthN/authentication-return-values
> 
> When I try to check the logs, the state of the smart card become ABSENT , I can see this during the C_InitToken, when sc_detect_card_presence is called.

Lower level logs would show where sc_detect_card_presence got the error.

> 
> When I try to run application A, and call C_InitToken without the application B running, I do not encounter this issue, and the smart card does not become ABSENT but instead I can see from the logs 
> that its state become CHANGED.

What are "ABSENT" and "CHANGED" Are they at the PKCS\#11 level or something internal to to your driver, PCSC or OpenSC?
> 
> I am not sure if this is the expected behavior or where or how I should handle it. I am not sure if this is also an issue on the OpenSC PKCS# 11 DLL or the smart card. I tried to look at the available 
> documentation but couldn't find an answer to this,

Very little OpenSC internal documentation, mostly the code.

Have you get your driver to run on Linux? It would eliminate possible issues with DLL "Critical Section"

If you think you have found bugs in OpenSC, (and not just your driver) you can open a issue on
https://github.com/OpenSC/OpenSC/issues

Are you willing to share any logs? Doing this via an open issue would be preferred.
If you think the DLL "Critical Section" is incorrect, open an issue.

> 
> Your expert opinion is greatly appreciated.
> 
> 
> Thanks,
> 
> fightingsibuyas
> 
> 
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> 

-- 

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

Re: [Opensc-devel] Question about multiple applications

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

One more comment.

It should also be possible to use ScardEndTransaction() with SCARD_RESET_CARD or SCARD_UNPOWER_CARD
at the end of the C_InitToken transaction.


On 12/28/2018 7:20 AM, Douglas E Engert wrote:
> I will deffer to others on the use critical section. But it my understanding that opensc locking is meant
> for a single process. There is no intent to do a global lock across other processes in the system. PCSC is
> used to do that.
> 
> I still contend that what you may be seeing is Application A that just did a C_InitToken should
> do a SCardDisconnect() with SCARD_RESET_CARD or SCARD_UNPOWER_CARD so other applications that are waiting
> for an event will be notified by PCSC that a reset was done.
> 
> reader-pcsc.c in pcsc_disconnect() has:
> 606 if (!priv->gpriv->cardmod && !(reader->ctx->flags & SC_CTX_FLAG_TERMINATE)) {
> That may be the problem on windows.
> 
> opensc.conf also has "disconnect_action = leave|reset|unpower;" but what is missing is a way to do a
> SCARD_RESET_CARD or SCARD_UNPOWER_CARD only in special situations such as C_InitToken. And all the
> actions required to do C_InitToken need to be done under one transaction or the session needs to be
> exclusive rather then shared.
> 
> 
> 
> On 12/27/2018 10:00 PM, Bob Backlund wrote:
>> Hi Douglas,
>>
>> Thank you for your reply.
>>
>> I understand that the "OpenSC PKCS#11 relies on the PCSC layer to lock access" but I think the issue lies on the lock used for the Windows system, on the pkcs11-global.c, I can see that the type of 
>> lock used is Critical Section as opposed to Mutex. It was mentioned on the Microsoft documentation that ;
>> /A critical section object provides synchronization similar to that provided by a mutex object, except that a critical section can be used *only by the threads of a single process*. Critical section 
>> objects *cannot be shared across processes*.
>> /
>>
>> Correct me if I'm wrong, but I think, to be able to handle "multiple applications" we may need to use Mutex instead of the default Critical Section. If that is the case how am able to do it in the 
>> OpenSC layer, do I just change the implementation to use Mutex instead of Critical Section (by changing the flow in the function pointer)?
>>
>> I am not sure if what I am saying makes sense, my apologies if this is something I over complicate.
>>
>> I appreciate your help on this.
>>
>> *Source: https://docs.microsoft.com/en-us/windows/desktop/Sync/critical-section-objects*
>>
>>
>> Thanks,
>>
>> Jared
>>
>> On Wed, Dec 19, 2018 at 9:05 PM Douglas E Engert <dee...@gm... <mailto:dee...@gm...>> wrote:
>>
>>     The OpenSC PKCS#11 relies on the PCSC layer to lock access to the card across multiple applications.
>>
>>     https://github.com/OpenSC/OpenSC/wiki/PCSC-and-pcsc-lite
>>
>>     http://ludovic.rousseau.free.fr/softwares/pcsc-tools/
>>
>>     https://docs.microsoft.com/en-us/windows/desktop/secauthn/smart-card-and-reader-access-functions
>>
>>     In regards to one application modifying the card while another application is waiting for events,
>>     the event will contain a SCARD_W_* return.
>>
>>     The application (A) that modified the card in such a drastic way should do a card reset,
>>     that will cause the the event returned to (B) will cause (B) to start over.
>>
>>     https://docs.microsoft.com/en-us/windows/desktop/SecAuthN/authentication-return-values
>>
>>     Doing do a C_InitToken is like formatting your hard drive. Most applications can not copy with this.
>>     In other words don't do it while other applications are running.
>>
>>
>>     On 12/18/2018 9:06 PM, Bob Backlund wrote:
>>      > Hi,
>>      >
>>      > Just some question about how the OpenSC PKCS# 11 (DLL) handles the multiple applications using it.
>>      >
>>      > The scenario is I have two applications, application A and application B loading the same DLL.
>>      >
>>      > Application B loops continuously, calling C_WaitForSlotEvent and C_GetTokenInfo, basically it just checks for the insert and remove events from the smart card.
>>      >
>>      > Application A can call C_InitPIN and C_InitToken.
>>      >
>>      > The conflict happens when, while the application B is checking for smart card events, application A then calls C_InitToken, which deletes the smart card contents, and formats it to be a new
>>     card, (and
>>      > possibly deleting the PKCS# 15 objects) and the next call to C_OpenSession fails returning CKR_TOKEN_NOT_PRESENT error.
>>      >
>>      > When I try to check the logs, the state of the smart card become ABSENT , I can see this during the C_InitToken, when sc_detect_card_presence is called.
>>      >
>>      > When I try to run application A, and call C_InitToken without the application B running, I do not encounter this issue, and the smart card does not become ABSENT but instead I can see from the
>>     logs
>>      > that its state become CHANGED.
>>      >
>>      > I am not sure if this is the expected behavior or where or how I should handle it. I am not sure if this is also an issue on the OpenSC PKCS# 11 DLL or the smart card. I tried to look at the
>>     available
>>      > documentation but couldn't find an answer to this,
>>      >
>>      > Your expert opinion is greatly appreciated.
>>      >
>>      >
>>      > Thanks,
>>      >
>>      > fightingsibuyas
>>      >
>>      >
>>      > _______________________________________________
>>      > Opensc-devel mailing list
>>      > Ope...@li... <mailto:Ope...@li...>
>>      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>      >
>>
>>     --
>>        Douglas E. Engert  <DEE...@gm... <mailto:DEE...@gm...>>
>>
>>
>>
>>     _______________________________________________
>>     Opensc-devel mailing list
>>     Ope...@li... <mailto:Ope...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>>
>>
>> _______________________________________________
>> Opensc-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
> 

-- 

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

Re: [Opensc-devel] Question about multiple applications

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

I will deffer to others on the use critical section. But it my understanding that opensc locking is meant
for a single process. There is no intent to do a global lock across other processes in the system. PCSC is
used to do that.

I still contend that what you may be seeing is Application A that just did a C_InitToken should
do a SCardDisconnect() with SCARD_RESET_CARD or SCARD_UNPOWER_CARD so other applications that are waiting
for an event will be notified by PCSC that a reset was done.

reader-pcsc.c in pcsc_disconnect() has:
606 if (!priv->gpriv->cardmod && !(reader->ctx->flags & SC_CTX_FLAG_TERMINATE)) {
That may be the problem on windows.

opensc.conf also has "disconnect_action = leave|reset|unpower;" but what is missing is a way to do a
SCARD_RESET_CARD or SCARD_UNPOWER_CARD only in special situations such as C_InitToken. And all the
actions required to do C_InitToken need to be done under one transaction or the session needs to be
exclusive rather then shared.



On 12/27/2018 10:00 PM, Bob Backlund wrote:
> Hi Douglas,
> 
> Thank you for your reply.
> 
> I understand that the "OpenSC PKCS#11 relies on the PCSC layer to lock access" but I think the issue lies on the lock used for the Windows system, on the pkcs11-global.c, I can see that the type of 
> lock used is Critical Section as opposed to Mutex. It was mentioned on the Microsoft documentation that ;
> /A critical section object provides synchronization similar to that provided by a mutex object, except that a critical section can be used *only by the threads of a single process*. Critical section 
> objects *cannot be shared across processes*.
> /
> 
> Correct me if I'm wrong, but I think, to be able to handle "multiple applications" we may need to use Mutex instead of the default Critical Section. If that is the case how am able to do it in the 
> OpenSC layer, do I just change the implementation to use Mutex instead of Critical Section (by changing the flow in the function pointer)?
> 
> I am not sure if what I am saying makes sense, my apologies if this is something I over complicate.
> 
> I appreciate your help on this.
> 
> *Source: https://docs.microsoft.com/en-us/windows/desktop/Sync/critical-section-objects*
> 
> 
> Thanks,
> 
> Jared
> 
> On Wed, Dec 19, 2018 at 9:05 PM Douglas E Engert <dee...@gm... <mailto:dee...@gm...>> wrote:
> 
>     The OpenSC PKCS#11 relies on the PCSC layer to lock access to the card across multiple applications.
> 
>     https://github.com/OpenSC/OpenSC/wiki/PCSC-and-pcsc-lite
> 
>     http://ludovic.rousseau.free.fr/softwares/pcsc-tools/
> 
>     https://docs.microsoft.com/en-us/windows/desktop/secauthn/smart-card-and-reader-access-functions
> 
>     In regards to one application modifying the card while another application is waiting for events,
>     the event will contain a SCARD_W_* return.
> 
>     The application (A) that modified the card in such a drastic way should do a card reset,
>     that will cause the the event returned to (B) will cause (B) to start over.
> 
>     https://docs.microsoft.com/en-us/windows/desktop/SecAuthN/authentication-return-values
> 
>     Doing do a C_InitToken is like formatting your hard drive. Most applications can not copy with this.
>     In other words don't do it while other applications are running.
> 
> 
>     On 12/18/2018 9:06 PM, Bob Backlund wrote:
>      > Hi,
>      >
>      > Just some question about how the OpenSC PKCS# 11 (DLL) handles the multiple applications using it.
>      >
>      > The scenario is I have two applications, application A and application B loading the same DLL.
>      >
>      > Application B loops continuously, calling C_WaitForSlotEvent and C_GetTokenInfo, basically it just checks for the insert and remove events from the smart card.
>      >
>      > Application A can call C_InitPIN and C_InitToken.
>      >
>      > The conflict happens when, while the application B is checking for smart card events, application A then calls C_InitToken, which deletes the smart card contents, and formats it to be a new
>     card, (and
>      > possibly deleting the PKCS# 15 objects) and the next call to C_OpenSession fails returning CKR_TOKEN_NOT_PRESENT error.
>      >
>      > When I try to check the logs, the state of the smart card become ABSENT , I can see this during the C_InitToken, when sc_detect_card_presence is called.
>      >
>      > When I try to run application A, and call C_InitToken without the application B running, I do not encounter this issue, and the smart card does not become ABSENT but instead I can see from the
>     logs
>      > that its state become CHANGED.
>      >
>      > I am not sure if this is the expected behavior or where or how I should handle it. I am not sure if this is also an issue on the OpenSC PKCS# 11 DLL or the smart card. I tried to look at the
>     available
>      > documentation but couldn't find an answer to this,
>      >
>      > Your expert opinion is greatly appreciated.
>      >
>      >
>      > Thanks,
>      >
>      > fightingsibuyas
>      >
>      >
>      > _______________________________________________
>      > Opensc-devel mailing list
>      > Ope...@li... <mailto:Ope...@li...>
>      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >
> 
>     -- 
> 
>        Douglas E. Engert  <DEE...@gm... <mailto:DEE...@gm...>>
> 
> 
> 
>     _______________________________________________
>     Opensc-devel mailing list
>     Ope...@li... <mailto:Ope...@li...>
>     https://lists.sourceforge.net/lists/listinfo/opensc-devel
> 
> 
> 
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> 

-- 

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

Re: [Opensc-devel] Question about multiple applications

[Bob B. <fig...@gm...>]

Hi Douglas,

Thank you for your reply.

I understand that the "OpenSC PKCS#11 relies on the PCSC layer to lock
access" but I think the issue lies on the lock used for the Windows system,
on the pkcs11-global.c, I can see that the type of lock used is Critical
Section as opposed to Mutex. It was mentioned on the Microsoft
documentation that ;

*A critical section object provides synchronization similar to that
provided by a mutex object, except that a critical section can be used only
by the threads of a single process. Critical section objects cannot be
shared across processes.*

Correct me if I'm wrong, but I think, to be able to handle "multiple
applications" we may need to use Mutex instead of the default Critical
Section. If that is the case how am able to do it in the OpenSC layer, do I
just change the implementation to use Mutex instead of Critical Section (by
changing the flow in the function pointer)?

I am not sure if what I am saying makes sense, my apologies if this is
something I over complicate.

I appreciate your help on this.

*Source:
https://docs.microsoft.com/en-us/windows/desktop/Sync/critical-section-objects
<https://docs.microsoft.com/en-us/windows/desktop/Sync/critical-section-objects>*


Thanks,

Jared

On Wed, Dec 19, 2018 at 9:05 PM Douglas E Engert <dee...@gm...> wrote:

> The OpenSC PKCS#11 relies on the PCSC layer to lock access to the card
> across multiple applications.
>
> https://github.com/OpenSC/OpenSC/wiki/PCSC-and-pcsc-lite
>
> http://ludovic.rousseau.free.fr/softwares/pcsc-tools/
>
>
> https://docs.microsoft.com/en-us/windows/desktop/secauthn/smart-card-and-reader-access-functions
>
> In regards to one application modifying the card while another application
> is waiting for events,
> the event will contain a SCARD_W_* return.
>
> The application (A) that modified the card in such a drastic way should do
> a card reset,
> that will cause the the event returned to (B) will cause (B) to start over.
>
>
> https://docs.microsoft.com/en-us/windows/desktop/SecAuthN/authentication-return-values
>
> Doing do a C_InitToken is like formatting your hard drive. Most
> applications can not copy with this.
> In other words don't do it while other applications are running.
>
>
> On 12/18/2018 9:06 PM, Bob Backlund wrote:
> > Hi,
> >
> > Just some question about how the OpenSC PKCS# 11 (DLL) handles the
> multiple applications using it.
> >
> > The scenario is I have two applications, application A and application B
> loading the same DLL.
> >
> > Application B loops continuously, calling C_WaitForSlotEvent and
> C_GetTokenInfo, basically it just checks for the insert and remove events
> from the smart card.
> >
> > Application A can call C_InitPIN and C_InitToken.
> >
> > The conflict happens when, while the application B is checking for smart
> card events, application A then calls C_InitToken, which deletes the smart
> card contents, and formats it to be a new card, (and
> > possibly deleting the PKCS# 15 objects) and the next call to
> C_OpenSession fails returning CKR_TOKEN_NOT_PRESENT error.
> >
> > When I try to check the logs, the state of the smart card become ABSENT
> , I can see this during the C_InitToken, when sc_detect_card_presence is
> called.
> >
> > When I try to run application A, and call C_InitToken without the
> application B running, I do not encounter this issue, and the smart card
> does not become ABSENT but instead I can see from the logs
> > that its state become CHANGED.
> >
> > I am not sure if this is the expected behavior or where or how I should
> handle it. I am not sure if this is also an issue on the OpenSC PKCS# 11
> DLL or the smart card. I tried to look at the available
> > documentation but couldn't find an answer to this,
> >
> > Your expert opinion is greatly appreciated.
> >
> >
> > Thanks,
> >
> > fightingsibuyas
> >
> >
> > _______________________________________________
> > Opensc-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opensc-devel
> >
>
> --
>
>   Douglas E. Engert  <DEE...@gm...>
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

Re: [Opensc-devel] Question about multiple applications

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

The OpenSC PKCS#11 relies on the PCSC layer to lock access to the card across multiple applications.

https://github.com/OpenSC/OpenSC/wiki/PCSC-and-pcsc-lite

http://ludovic.rousseau.free.fr/softwares/pcsc-tools/

https://docs.microsoft.com/en-us/windows/desktop/secauthn/smart-card-and-reader-access-functions

In regards to one application modifying the card while another application is waiting for events,
the event will contain a SCARD_W_* return.

The application (A) that modified the card in such a drastic way should do a card reset,
that will cause the the event returned to (B) will cause (B) to start over.

https://docs.microsoft.com/en-us/windows/desktop/SecAuthN/authentication-return-values

Doing do a C_InitToken is like formatting your hard drive. Most applications can not copy with this.
In other words don't do it while other applications are running.


On 12/18/2018 9:06 PM, Bob Backlund wrote:
> Hi,
> 
> Just some question about how the OpenSC PKCS# 11 (DLL) handles the multiple applications using it.
> 
> The scenario is I have two applications, application A and application B loading the same DLL.
> 
> Application B loops continuously, calling C_WaitForSlotEvent and C_GetTokenInfo, basically it just checks for the insert and remove events from the smart card.
> 
> Application A can call C_InitPIN and C_InitToken.
> 
> The conflict happens when, while the application B is checking for smart card events, application A then calls C_InitToken, which deletes the smart card contents, and formats it to be a new card, (and 
> possibly deleting the PKCS# 15 objects) and the next call to C_OpenSession fails returning CKR_TOKEN_NOT_PRESENT error.
> 
> When I try to check the logs, the state of the smart card become ABSENT , I can see this during the C_InitToken, when sc_detect_card_presence is called.
> 
> When I try to run application A, and call C_InitToken without the application B running, I do not encounter this issue, and the smart card does not become ABSENT but instead I can see from the logs 
> that its state become CHANGED.
> 
> I am not sure if this is the expected behavior or where or how I should handle it. I am not sure if this is also an issue on the OpenSC PKCS# 11 DLL or the smart card. I tried to look at the available 
> documentation but couldn't find an answer to this,
> 
> Your expert opinion is greatly appreciated.
> 
> 
> Thanks,
> 
> fightingsibuyas
> 
> 
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> 

-- 

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

[Opensc-devel] Question about multiple applications

[Bob B. <fig...@gm...>]

Hi,

Just some question about how the OpenSC PKCS# 11 (DLL) handles the multiple
applications using it.

The scenario is I have two applications, application A and application B
loading the same DLL.

Application B loops continuously, calling C_WaitForSlotEvent and
C_GetTokenInfo, basically it just checks for the insert and remove events
from the smart card.

Application A can call C_InitPIN and C_InitToken.

The conflict happens when, while the application B is checking for smart
card events, application A then calls C_InitToken, which deletes the smart
card contents, and formats it to be a new card, (and possibly deleting the
PKCS# 15 objects) and the next call to C_OpenSession fails returning
CKR_TOKEN_NOT_PRESENT error.

When I try to check the logs, the state of the smart card become ABSENT , I
can see this during the C_InitToken, when sc_detect_card_presence is called.

When I try to run application A, and call C_InitToken without the
application B running, I do not encounter this issue, and the smart card
does not become ABSENT but instead I can see from the logs that its state
become CHANGED.

I am not sure if this is the expected behavior or where or how I should
handle it. I am not sure if this is also an issue on the OpenSC PKCS# 11
DLL or the smart card. I tried to look at the available documentation but
couldn't find an answer to this,

Your expert opinion is greatly appreciated.


Thanks,

fightingsibuyas

Re: [Opensc-devel] Question about C_InitToken reinitialize

[Bob B. <fig...@gm...>]

Hi Douglas,

Thank you for your explanation, I agree it does get me confused at times, I
decided to just handle it on the client application side, we can consider
my question answered. Thank you again.


Cheers,

fightingsibuyas

On Wed, Oct 31, 2018 at 1:04 AM Douglas E Engert <dee...@gm...> wrote:

>
> There are other simulated smart card software available, and a number on
> github
> Search for github smartcard emulation. Check this one out:
> https://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html
>
> When writing a simulator it is easy to mix up the security layers between
> the OpenSC driver and the simulated card. The reason for a physical card is
> to protect the keys and PINs behind the cards security layer.  All of the
> application and middleware like PKCS#11 and OpenSC are only tools to make
> it easier to access the card. Anyone can take the OpenSC code and hack it
> anyway they want.
> i.e. "gain access to the PKCS#11 API"  But they can not hack the physical
> card. It has its own protection including physical protection to destroy
> memory if one tries to tamper with the card .(Better to destroy the card
> then to expose the keys.) So you need to define first how your simulated
> card is protected. Could a hacker gain access to you system or its backups
> and copy the files and do a offline attack? Would the files be encrypted,
> and how is the encryption key protected?
>
> The C_Login for SO pin should result in the driver sending this to the
> card  usually by a VERIFY APDU. Your simulated card will then have to
> determine if it is valid, and set some login state.
> Then as other APDUs are sent to the card it can check if the login state
> is still valid. Some APDUs or resets will cause the login state to be lost.
> The card should also keep track of consecutive failures
> of the SO and User points and lock the use of the PIN.
>
>
> On Mon, Oct 29, 2018 at 9:01 PM Bob Backlund <fig...@gm...>
> wrote:
>
>> Hi Douglas,
>>
>> Thank you for your reply.
>>
>> Do you have a specific card in mind?
>>  - No specific card, I have a software that simulates the smart card
>> operations, I also implemented my own OpenSC driver for this.
>> Do you expect the user to do their own card administration? i.e. know the
>> SO pin?
>>  - No, the administrator that knows the SO pin will be different from the
>> user (that knows user pin). Maybe my concern is summarized with the concern
>> about the C_InitToken implementation. Because I got confused with the PKCS#
>> 11 definition of the C_InitToken (the one I mentioned previously).
>>
>> I am not sure if I need to change the implementation of C_InitToken and
>> add the verify/validate of the SO pin inside the C_InitToken or do I do it
>> on the client application layer, call C_Login (for SO pin) first, if
>> success proceed with C_InitToken, if fail return error.
>>
>> Another concern is about the security, with the current implementation of
>> C_InitToken, if someone got access to the PKCS# 11 API, he could just call
>> the C_InitToken and erase the contents of the card without knowing the SO
>> pin or the user pin. How do you usually handle/secure this kind of stuff?
>>
>> Are you trying to be a card issuer and do remote administration over the
>> web?
>>  - None of anything like that as of now.
>>
>> Sorry if I am having problem explaining the problem, I am new to PKCS# 11
>> and to OpenSC. Your expert view on this is greatly appreciated.
>>
>>
>> Cheers,
>>
>> fightingsibuyas
>>
>> On Tue, Oct 30, 2018 at 1:19 AM Douglas E Engert <dee...@gm...>
>> wrote:
>>
>>> You asked about OpenSC documentation. OpenSC attempts to present a
>>> PKC#11 interface for use by a user. But it really comes done to what the
>>> specific token (card) allows. Many of the tokens do not support what you
>>> are trying to do. OpenSC includes a number of card specific tools to help
>>> administer cards.
>>>
>>> In many security environments, the card is issued by some organization
>>> (company/university/gov) where the user never knows the SO pin (if there is
>>> one)  Many of these cards use  a 3DES or AES key for authentication to do
>>> card administration. The card administration is done in a secure
>>> environment so the SO pin and 3DES or AES keys are kept secure. OpenSC is
>>> not trying to support such environments.
>>>
>>> It sounds like you are in an environment where the user should know the
>>> SO pin, as your question what if the user lost/forgot the SO pin. My answer
>>> would to buy a new card.
>>>
>>> So some questions about what are you really trying to do:
>>> Do you have a specific card in mind?
>>> Do you expect the user to do their own card administration? i.e. know
>>> the SO pin?
>>> Are you trying to be a card issuer and do remote administration over the
>>> web?
>>> (As hinted at above there are many security issues with doing this.)
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Oct 29, 2018 at 9:03 AM Bob Backlund <fig...@gm...>
>>> wrote:
>>>
>>>> Hi Paul,
>>>>
>>>> Thank you for your reply. I appreciate your help, I have some comments
>>>> below.
>>>>
>>>> Hi! It seems that the SO PIN you passed should be checked by the token
>>>> itself. In other words it can be stated as: in order to re-initialize the
>>>> token you have to *log on* to that token.
>>>>  - Do you mean that before I call the C_InitToken that the verification
>>>> of the SO PIN should be done outside the C_InitToken, like calling the
>>>> C_Login before the C_InitToken? The PKCS# 11 statement I mentioned is under
>>>> the C_InitToken definition from my understanding the verification of the SO
>>>> PIN should be done inside the C_InitToken. I am testing the C_InitToken
>>>> with two test case, first test case is that I give the correct SO PIN,
>>>> second case is I give the wrong SO PIN. On the first case my expectation is
>>>> that C_InitToken will reset the card (deleting the deletable objects
>>>> inside, reverting to the state when the first C_InitToken was called),
>>>> second test case I expect the C_InitToken will give me an error and not
>>>> reset the card.
>>>>
>>>> But that leads to the following problem: what to do if you forget the
>>>> SO PIN and that is why you want to *reset* the token completely?
>>>>  - The PKCS# 11 document answered that one here's what they said.
>>>> If the SO PIN is lost, then the  card  must  be  reinitialized  using
>>>> a  mechanism  outside  the  scope  of  this  standard.
>>>>
>>>> Second, if you look at the implementation of init_token() at
>>>> pkcs11-tool.c, you find, that it asks for the *new* SO PIN, not the
>>>> existing SO PIN. And that is true for the cards and tokens I'm working
>>>> with: I enter there any SO PIN I want and get a newly initialized token
>>>> with no data on it.
>>>>  - I understand, your explanation makes sense with the current source
>>>> code. But my problem is that, is it safe that way, because anyone can just
>>>> call the C_InitToken to reset the card and deleting all the keys inside.
>>>> How do you secure yourself from this scenario?
>>>>
>>>> Here's longer definition of C_InitToken from the PKCS# 11 document.
>>>> C_InitToken initializes a token. slotID is the ID of the token’s
>>>> slot;pPin points to the SO’s initial PIN (which need not be
>>>> null-terminated); ulPinLen is the lengthin bytes of the PIN; pLabel points
>>>> to the 32-byte label of the token (which must be padded with blank
>>>> characters, and which must not be null-terminated). This standard allows
>>>> PIN values to contain any valid UTF8 character, but the token may impose
>>>> subset restrictions. Ifthe token has not
>>>> beeninitialized(i.e.newfromthefactory),thenthe pPin parameterbecomes the
>>>> initial value of the SO PIN. If the token is being reinitialized, the
>>>> pPin parameter is checkedagainsttheexistingSOPINtoauthorize the
>>>> initialization operation. In both cases, the SOPINisthevaluepPin after the
>>>> function completes successfully. If the SO PIN is lost, then
>>>> thecardmustbereinitializedusingamechanismoutsidethescopeofthisstandard.The
>>>> CKF_TOKEN_INITIALIZED flag in the CK_TOKEN_INFO structure indicates the
>>>> action thatwillresultfromcalling C_InitToken.Ifset,thetokenwillbe
>>>> reinitialized,andtheclient must supply the existing SO password in pPin.
>>>> Source: https://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-11r1.pdf
>>>>
>>>> Thank you for your help!
>>>>
>>>> fightingsibuyas
>>>>
>>>>
>>>> On Mon, Oct 29, 2018 at 7:14 PM Paul Wolneykien <ma...@al...>
>>>> wrote:
>>>>
>>>>> 29.10.2018 12:59, Bob Backlund пишет:
>>>>> > Hi,
>>>>> >
>>>>> > Just some question on the C_InitToken implementation of OpenSC, the
>>>>> > PKCS#11 document states the following below.
>>>>> > /
>>>>> > If the token is being reinitialized, the *pPin parameter is checked
>>>>> > against the  existing SO PIN* to authorize the initialization
>>>>> operation.
>>>>> > /
>>>>> > When the token is reinitialized, the C_InitToken should verify the
>>>>> PIN
>>>>> > passed to it with the one provided on the first initialization.
>>>>> >
>>>>> > I tried to trace the source code but it seems this is not handled on
>>>>> the
>>>>> > C_InitToken layer, the C_InitToken will just pass the data (pin, pin
>>>>> > length, label) to PKCS#11 framework, or the pkcs15_initialize
>>>>> function.
>>>>>
>>>>>   Hi! It seems that the SO PIN you passed should be checked by the
>>>>> token
>>>>> itself. In other words it can be stated as: in order to re-initialize
>>>>> the token you have to *log on* to that token. But that leads to the
>>>>> following problem: what to do if you forget the SO PIN and that is why
>>>>> you want to *reset* the token completely?
>>>>>   Second, if you look at the implementation of init_token() at
>>>>> pkcs11-tool.c, you find, that it asks for the *new* SO PIN, not the
>>>>> existing SO PIN. And that is true for the cards and tokens I'm working
>>>>> with: I enter there any SO PIN I want and get a newly initialized token
>>>>> with no data on it.
>>>>>
>>>>>
>>>>> > On this function, it will check if there is an implementation for the
>>>>> > SC_CARDCTL_PKCS11_INIT_TOKEN command on the card level (card-*), the
>>>>> > data is passed on this function. Most of the driver did not implement
>>>>> > this one.
>>>>> > After the call on this function, sc_pkcs15init_erase_card is also
>>>>> > called, but data is not passed.
>>>>> >
>>>>> > After this, pkcs15nit_add_app is called, this is the function that do
>>>>> > the initialization, but until here the existing SO validation was not
>>>>> > handle, data was passed on this function.
>>>>> >
>>>>> > So, my question is if wanted to support the existing SO validation
>>>>> (as
>>>>> > stated in PKCS#11 document) for the C_InitToken, what will be my
>>>>> > approach? I was thinking of implementing
>>>>> SC_CARDCTL_PKCS11_INIT_TOKEN,
>>>>> > but this is on the card level and it doesn't know anything about the
>>>>> > PKCS#11 object or the PKCS# 15 structure.
>>>>> >
>>>>> > I appreciate if someone can put me on the direction or at least the a
>>>>> > document that I can read that discusses this part of OpenSC.
>>>>> >
>>>>> > Thank you very much!
>>>>> >
>>>>> >
>>>>> > Cheers,
>>>>> >
>>>>> > fightingsibuyas
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > Opensc-devel mailing list
>>>>> > Ope...@li...
>>>>> > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Opensc-devel mailing list
>>>>> Ope...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>
>>>> _______________________________________________
>>>> Opensc-devel mailing list
>>>> Ope...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>
>>> _______________________________________________
>> Opensc-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>

Re: [Opensc-devel] Question about C_InitToken reinitialize

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

There are other simulated smart card software available, and a number on
github
Search for github smartcard emulation. Check this one out:
https://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html

When writing a simulator it is easy to mix up the security layers between
the OpenSC driver and the simulated card. The reason for a physical card is
to protect the keys and PINs behind the cards security layer.  All of the
application and middleware like PKCS#11 and OpenSC are only tools to make
it easier to access the card. Anyone can take the OpenSC code and hack it
anyway they want.
i.e. "gain access to the PKCS#11 API"  But they can not hack the physical
card. It has its own protection including physical protection to destroy
memory if one tries to tamper with the card .(Better to destroy the card
then to expose the keys.) So you need to define first how your simulated
card is protected. Could a hacker gain access to you system or its backups
and copy the files and do a offline attack? Would the files be encrypted,
and how is the encryption key protected?

The C_Login for SO pin should result in the driver sending this to the
card  usually by a VERIFY APDU. Your simulated card will then have to
determine if it is valid, and set some login state.
Then as other APDUs are sent to the card it can check if the login state is
still valid. Some APDUs or resets will cause the login state to be lost.
The card should also keep track of consecutive failures
of the SO and User points and lock the use of the PIN.


On Mon, Oct 29, 2018 at 9:01 PM Bob Backlund <fig...@gm...>
wrote:

> Hi Douglas,
>
> Thank you for your reply.
>
> Do you have a specific card in mind?
>  - No specific card, I have a software that simulates the smart card
> operations, I also implemented my own OpenSC driver for this.
> Do you expect the user to do their own card administration? i.e. know the
> SO pin?
>  - No, the administrator that knows the SO pin will be different from the
> user (that knows user pin). Maybe my concern is summarized with the concern
> about the C_InitToken implementation. Because I got confused with the PKCS#
> 11 definition of the C_InitToken (the one I mentioned previously).
>
> I am not sure if I need to change the implementation of C_InitToken and
> add the verify/validate of the SO pin inside the C_InitToken or do I do it
> on the client application layer, call C_Login (for SO pin) first, if
> success proceed with C_InitToken, if fail return error.
>
> Another concern is about the security, with the current implementation of
> C_InitToken, if someone got access to the PKCS# 11 API, he could just call
> the C_InitToken and erase the contents of the card without knowing the SO
> pin or the user pin. How do you usually handle/secure this kind of stuff?
>
> Are you trying to be a card issuer and do remote administration over the
> web?
>  - None of anything like that as of now.
>
> Sorry if I am having problem explaining the problem, I am new to PKCS# 11
> and to OpenSC. Your expert view on this is greatly appreciated.
>
>
> Cheers,
>
> fightingsibuyas
>
> On Tue, Oct 30, 2018 at 1:19 AM Douglas E Engert <dee...@gm...>
> wrote:
>
>> You asked about OpenSC documentation. OpenSC attempts to present a PKC#11
>> interface for use by a user. But it really comes done to what the specific
>> token (card) allows. Many of the tokens do not support what you are trying
>> to do. OpenSC includes a number of card specific tools to help administer
>> cards.
>>
>> In many security environments, the card is issued by some organization
>> (company/university/gov) where the user never knows the SO pin (if there is
>> one)  Many of these cards use  a 3DES or AES key for authentication to do
>> card administration. The card administration is done in a secure
>> environment so the SO pin and 3DES or AES keys are kept secure. OpenSC is
>> not trying to support such environments.
>>
>> It sounds like you are in an environment where the user should know the
>> SO pin, as your question what if the user lost/forgot the SO pin. My answer
>> would to buy a new card.
>>
>> So some questions about what are you really trying to do:
>> Do you have a specific card in mind?
>> Do you expect the user to do their own card administration? i.e. know the
>> SO pin?
>> Are you trying to be a card issuer and do remote administration over the
>> web?
>> (As hinted at above there are many security issues with doing this.)
>>
>>
>>
>>
>>
>>
>> On Mon, Oct 29, 2018 at 9:03 AM Bob Backlund <fig...@gm...>
>> wrote:
>>
>>> Hi Paul,
>>>
>>> Thank you for your reply. I appreciate your help, I have some comments
>>> below.
>>>
>>> Hi! It seems that the SO PIN you passed should be checked by the token
>>> itself. In other words it can be stated as: in order to re-initialize the
>>> token you have to *log on* to that token.
>>>  - Do you mean that before I call the C_InitToken that the verification
>>> of the SO PIN should be done outside the C_InitToken, like calling the
>>> C_Login before the C_InitToken? The PKCS# 11 statement I mentioned is under
>>> the C_InitToken definition from my understanding the verification of the SO
>>> PIN should be done inside the C_InitToken. I am testing the C_InitToken
>>> with two test case, first test case is that I give the correct SO PIN,
>>> second case is I give the wrong SO PIN. On the first case my expectation is
>>> that C_InitToken will reset the card (deleting the deletable objects
>>> inside, reverting to the state when the first C_InitToken was called),
>>> second test case I expect the C_InitToken will give me an error and not
>>> reset the card.
>>>
>>> But that leads to the following problem: what to do if you forget the SO
>>> PIN and that is why you want to *reset* the token completely?
>>>  - The PKCS# 11 document answered that one here's what they said.
>>> If the SO PIN is lost, then the  card  must  be  reinitialized  using
>>> a  mechanism  outside  the  scope  of  this  standard.
>>>
>>> Second, if you look at the implementation of init_token() at
>>> pkcs11-tool.c, you find, that it asks for the *new* SO PIN, not the
>>> existing SO PIN. And that is true for the cards and tokens I'm working
>>> with: I enter there any SO PIN I want and get a newly initialized token
>>> with no data on it.
>>>  - I understand, your explanation makes sense with the current source
>>> code. But my problem is that, is it safe that way, because anyone can just
>>> call the C_InitToken to reset the card and deleting all the keys inside.
>>> How do you secure yourself from this scenario?
>>>
>>> Here's longer definition of C_InitToken from the PKCS# 11 document.
>>> C_InitToken initializes a token. slotID is the ID of the token’s
>>> slot;pPin points to the SO’s initial PIN (which need not be
>>> null-terminated); ulPinLen is the lengthin bytes of the PIN; pLabel points
>>> to the 32-byte label of the token (which must be padded with blank
>>> characters, and which must not be null-terminated). This standard allows
>>> PIN values to contain any valid UTF8 character, but the token may impose
>>> subset restrictions. Ifthe token has not
>>> beeninitialized(i.e.newfromthefactory),thenthe pPin parameterbecomes the
>>> initial value of the SO PIN. If the token is being reinitialized, the
>>> pPin parameter is checkedagainsttheexistingSOPINtoauthorize the
>>> initialization operation. In both cases, the SOPINisthevaluepPin after the
>>> function completes successfully. If the SO PIN is lost, then
>>> thecardmustbereinitializedusingamechanismoutsidethescopeofthisstandard.The
>>> CKF_TOKEN_INITIALIZED flag in the CK_TOKEN_INFO structure indicates the
>>> action thatwillresultfromcalling C_InitToken.Ifset,thetokenwillbe
>>> reinitialized,andtheclient must supply the existing SO password in pPin.
>>> Source: https://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-11r1.pdf
>>>
>>> Thank you for your help!
>>>
>>> fightingsibuyas
>>>
>>>
>>> On Mon, Oct 29, 2018 at 7:14 PM Paul Wolneykien <ma...@al...>
>>> wrote:
>>>
>>>> 29.10.2018 12:59, Bob Backlund пишет:
>>>> > Hi,
>>>> >
>>>> > Just some question on the C_InitToken implementation of OpenSC, the
>>>> > PKCS#11 document states the following below.
>>>> > /
>>>> > If the token is being reinitialized, the *pPin parameter is checked
>>>> > against the  existing SO PIN* to authorize the initialization
>>>> operation.
>>>> > /
>>>> > When the token is reinitialized, the C_InitToken should verify the PIN
>>>> > passed to it with the one provided on the first initialization.
>>>> >
>>>> > I tried to trace the source code but it seems this is not handled on
>>>> the
>>>> > C_InitToken layer, the C_InitToken will just pass the data (pin, pin
>>>> > length, label) to PKCS#11 framework, or the pkcs15_initialize
>>>> function.
>>>>
>>>>   Hi! It seems that the SO PIN you passed should be checked by the token
>>>> itself. In other words it can be stated as: in order to re-initialize
>>>> the token you have to *log on* to that token. But that leads to the
>>>> following problem: what to do if you forget the SO PIN and that is why
>>>> you want to *reset* the token completely?
>>>>   Second, if you look at the implementation of init_token() at
>>>> pkcs11-tool.c, you find, that it asks for the *new* SO PIN, not the
>>>> existing SO PIN. And that is true for the cards and tokens I'm working
>>>> with: I enter there any SO PIN I want and get a newly initialized token
>>>> with no data on it.
>>>>
>>>>
>>>> > On this function, it will check if there is an implementation for the
>>>> > SC_CARDCTL_PKCS11_INIT_TOKEN command on the card level (card-*), the
>>>> > data is passed on this function. Most of the driver did not implement
>>>> > this one.
>>>> > After the call on this function, sc_pkcs15init_erase_card is also
>>>> > called, but data is not passed.
>>>> >
>>>> > After this, pkcs15nit_add_app is called, this is the function that do
>>>> > the initialization, but until here the existing SO validation was not
>>>> > handle, data was passed on this function.
>>>> >
>>>> > So, my question is if wanted to support the existing SO validation (as
>>>> > stated in PKCS#11 document) for the C_InitToken, what will be my
>>>> > approach? I was thinking of implementing SC_CARDCTL_PKCS11_INIT_TOKEN,
>>>> > but this is on the card level and it doesn't know anything about the
>>>> > PKCS#11 object or the PKCS# 15 structure.
>>>> >
>>>> > I appreciate if someone can put me on the direction or at least the a
>>>> > document that I can read that discusses this part of OpenSC.
>>>> >
>>>> > Thank you very much!
>>>> >
>>>> >
>>>> > Cheers,
>>>> >
>>>> > fightingsibuyas
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Opensc-devel mailing list
>>>> > Ope...@li...
>>>> > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>> >
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Opensc-devel mailing list
>>>> Ope...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>
>>> _______________________________________________
>>> Opensc-devel mailing list
>>> Ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>
>> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

Re: [Opensc-devel] Question about C_InitToken reinitialize

[Bob B. <fig...@gm...>]

Hi Douglas,

Thank you for your reply.

Do you have a specific card in mind?
 - No specific card, I have a software that simulates the smart card
operations, I also implemented my own OpenSC driver for this.
Do you expect the user to do their own card administration? i.e. know the
SO pin?
 - No, the administrator that knows the SO pin will be different from the
user (that knows user pin). Maybe my concern is summarized with the concern
about the C_InitToken implementation. Because I got confused with the PKCS#
11 definition of the C_InitToken (the one I mentioned previously).

I am not sure if I need to change the implementation of C_InitToken and add
the verify/validate of the SO pin inside the C_InitToken or do I do it on
the client application layer, call C_Login (for SO pin) first, if success
proceed with C_InitToken, if fail return error.

Another concern is about the security, with the current implementation of
C_InitToken, if someone got access to the PKCS# 11 API, he could just call
the C_InitToken and erase the contents of the card without knowing the SO
pin or the user pin. How do you usually handle/secure this kind of stuff?

Are you trying to be a card issuer and do remote administration over the
web?
 - None of anything like that as of now.

Sorry if I am having problem explaining the problem, I am new to PKCS# 11
and to OpenSC. Your expert view on this is greatly appreciated.


Cheers,

fightingsibuyas

On Tue, Oct 30, 2018 at 1:19 AM Douglas E Engert <dee...@gm...> wrote:

> You asked about OpenSC documentation. OpenSC attempts to present a PKC#11
> interface for use by a user. But it really comes done to what the specific
> token (card) allows. Many of the tokens do not support what you are trying
> to do. OpenSC includes a number of card specific tools to help administer
> cards.
>
> In many security environments, the card is issued by some organization
> (company/university/gov) where the user never knows the SO pin (if there is
> one)  Many of these cards use  a 3DES or AES key for authentication to do
> card administration. The card administration is done in a secure
> environment so the SO pin and 3DES or AES keys are kept secure. OpenSC is
> not trying to support such environments.
>
> It sounds like you are in an environment where the user should know the SO
> pin, as your question what if the user lost/forgot the SO pin. My answer
> would to buy a new card.
>
> So some questions about what are you really trying to do:
> Do you have a specific card in mind?
> Do you expect the user to do their own card administration? i.e. know the
> SO pin?
> Are you trying to be a card issuer and do remote administration over the
> web?
> (As hinted at above there are many security issues with doing this.)
>
>
>
>
>
>
> On Mon, Oct 29, 2018 at 9:03 AM Bob Backlund <fig...@gm...>
> wrote:
>
>> Hi Paul,
>>
>> Thank you for your reply. I appreciate your help, I have some comments
>> below.
>>
>> Hi! It seems that the SO PIN you passed should be checked by the token
>> itself. In other words it can be stated as: in order to re-initialize the
>> token you have to *log on* to that token.
>>  - Do you mean that before I call the C_InitToken that the verification
>> of the SO PIN should be done outside the C_InitToken, like calling the
>> C_Login before the C_InitToken? The PKCS# 11 statement I mentioned is under
>> the C_InitToken definition from my understanding the verification of the SO
>> PIN should be done inside the C_InitToken. I am testing the C_InitToken
>> with two test case, first test case is that I give the correct SO PIN,
>> second case is I give the wrong SO PIN. On the first case my expectation is
>> that C_InitToken will reset the card (deleting the deletable objects
>> inside, reverting to the state when the first C_InitToken was called),
>> second test case I expect the C_InitToken will give me an error and not
>> reset the card.
>>
>> But that leads to the following problem: what to do if you forget the SO
>> PIN and that is why you want to *reset* the token completely?
>>  - The PKCS# 11 document answered that one here's what they said.
>> If the SO PIN is lost, then the  card  must  be  reinitialized  using  a
>> mechanism  outside  the  scope  of  this  standard.
>>
>> Second, if you look at the implementation of init_token() at
>> pkcs11-tool.c, you find, that it asks for the *new* SO PIN, not the
>> existing SO PIN. And that is true for the cards and tokens I'm working
>> with: I enter there any SO PIN I want and get a newly initialized token
>> with no data on it.
>>  - I understand, your explanation makes sense with the current source
>> code. But my problem is that, is it safe that way, because anyone can just
>> call the C_InitToken to reset the card and deleting all the keys inside.
>> How do you secure yourself from this scenario?
>>
>> Here's longer definition of C_InitToken from the PKCS# 11 document.
>> C_InitToken initializes a token. slotID is the ID of the token’s
>> slot;pPin points to the SO’s initial PIN (which need not be
>> null-terminated); ulPinLen is the lengthin bytes of the PIN; pLabel points
>> to the 32-byte label of the token (which must be padded with blank
>> characters, and which must not be null-terminated). This standard allows
>> PIN values to contain any valid UTF8 character, but the token may impose
>> subset restrictions. Ifthe token has not
>> beeninitialized(i.e.newfromthefactory),thenthe pPin parameterbecomes the
>> initial value of the SO PIN. If the token is being reinitialized, the
>> pPin parameter is checkedagainsttheexistingSOPINtoauthorize the
>> initialization operation. In both cases, the SOPINisthevaluepPin after the
>> function completes successfully. If the SO PIN is lost, then
>> thecardmustbereinitializedusingamechanismoutsidethescopeofthisstandard.The
>> CKF_TOKEN_INITIALIZED flag in the CK_TOKEN_INFO structure indicates the
>> action thatwillresultfromcalling C_InitToken.Ifset,thetokenwillbe
>> reinitialized,andtheclient must supply the existing SO password in pPin.
>> Source: https://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-11r1.pdf
>>
>> Thank you for your help!
>>
>> fightingsibuyas
>>
>>
>> On Mon, Oct 29, 2018 at 7:14 PM Paul Wolneykien <ma...@al...>
>> wrote:
>>
>>> 29.10.2018 12:59, Bob Backlund пишет:
>>> > Hi,
>>> >
>>> > Just some question on the C_InitToken implementation of OpenSC, the
>>> > PKCS#11 document states the following below.
>>> > /
>>> > If the token is being reinitialized, the *pPin parameter is checked
>>> > against the  existing SO PIN* to authorize the initialization
>>> operation.
>>> > /
>>> > When the token is reinitialized, the C_InitToken should verify the PIN
>>> > passed to it with the one provided on the first initialization.
>>> >
>>> > I tried to trace the source code but it seems this is not handled on
>>> the
>>> > C_InitToken layer, the C_InitToken will just pass the data (pin, pin
>>> > length, label) to PKCS#11 framework, or the pkcs15_initialize function.
>>>
>>>   Hi! It seems that the SO PIN you passed should be checked by the token
>>> itself. In other words it can be stated as: in order to re-initialize
>>> the token you have to *log on* to that token. But that leads to the
>>> following problem: what to do if you forget the SO PIN and that is why
>>> you want to *reset* the token completely?
>>>   Second, if you look at the implementation of init_token() at
>>> pkcs11-tool.c, you find, that it asks for the *new* SO PIN, not the
>>> existing SO PIN. And that is true for the cards and tokens I'm working
>>> with: I enter there any SO PIN I want and get a newly initialized token
>>> with no data on it.
>>>
>>>
>>> > On this function, it will check if there is an implementation for the
>>> > SC_CARDCTL_PKCS11_INIT_TOKEN command on the card level (card-*), the
>>> > data is passed on this function. Most of the driver did not implement
>>> > this one.
>>> > After the call on this function, sc_pkcs15init_erase_card is also
>>> > called, but data is not passed.
>>> >
>>> > After this, pkcs15nit_add_app is called, this is the function that do
>>> > the initialization, but until here the existing SO validation was not
>>> > handle, data was passed on this function.
>>> >
>>> > So, my question is if wanted to support the existing SO validation (as
>>> > stated in PKCS#11 document) for the C_InitToken, what will be my
>>> > approach? I was thinking of implementing SC_CARDCTL_PKCS11_INIT_TOKEN,
>>> > but this is on the card level and it doesn't know anything about the
>>> > PKCS#11 object or the PKCS# 15 structure.
>>> >
>>> > I appreciate if someone can put me on the direction or at least the a
>>> > document that I can read that discusses this part of OpenSC.
>>> >
>>> > Thank you very much!
>>> >
>>> >
>>> > Cheers,
>>> >
>>> > fightingsibuyas
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Opensc-devel mailing list
>>> > Ope...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>> >
>>>
>>>
>>>
>>> _______________________________________________
>>> Opensc-devel mailing list
>>> Ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>
>> _______________________________________________
>> Opensc-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>