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

Re: [Opensc-devel] State of session locking support

[Frank M. <mo...@in...>]

Yes correct, If the card does not use sm. Same problem is discussed here https://github.com/OpenSC/OpenSC/issues/596

Am 16. November 2015 09:09:20 MEZ, schrieb Martin Vogt <mv...@gm...>:
>On Sun, Nov 15, 2015 at 12:49 AM, Frank Morgner <
>mo...@in...> wrote:
>
>> I quickly hacked my proposition; it's open for review/suggestions
>here:
>> https://github.com/OpenSC/OpenSC/pull/608
>>
>
>If I understand it correctly the card/reader is not locked, like in the
>"lock_login" case.
>Another user then can use my unlocked card to send signed emails?
>
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>Presto, an open source distributed SQL query engine for big data,
>initially
>developed by Facebook, enables you to easily query your data on Hadoop
>in a 
>more interactive manner. Teradata is also now providing full enterprise
>support for Presto. Download a free open source copy now.
>http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Opensc-devel mailing list
>Ope...@li...
>https://lists.sourceforge.net/lists/listinfo/opensc-devel

-- 
Frank Morgner

Re: [Opensc-devel] State of session locking support

[Martin V. <mv...@gm...>]

On Sun, Nov 15, 2015 at 12:49 AM, Frank Morgner <
mo...@in...> wrote:

> I quickly hacked my proposition; it's open for review/suggestions here:
> https://github.com/OpenSC/OpenSC/pull/608
>

If I understand it correctly the card/reader is not locked, like in the
"lock_login" case.
Another user then can use my unlocked card to send signed emails?

Re: [Opensc-devel] State of session locking support

[Frank M. <mo...@in...>]

I quickly hacked my proposition; it's open for review/suggestions here:
https://github.com/OpenSC/OpenSC/pull/608

Greets, Frank.

Am Freitag, dem 13. November, um 14:07 Uhr schrieb Frank Morgner:
> Please rephrase this problem to something like "session locking"!
> 
> Doug is correct, this can't be solved purely on the lower level. Your
> best bet would be the PKCS#11 Sessions. I just checked with Client
> authentication in Firefox and the workflow is something like this:
> 
> 1. Read card/token/certificates/slots/whatever
> 2. C_OpenSession(0x1)
> 3. C_Login
> 4. C_OpenSession(0x1)
> 5. C_SignInit/C_Sign
> 6. (immediately after signature) C_CloseSession
> 7. Go to 4. and repeat
> 8. Terminate Firefox
> 9. C_CloseAllSessions
> 
> As you can see, as soon as the PIN is verified Firefox expects to have
> exclusive access. Adding sc_lock/sc_unlock to C_OpenSession and
> C_CloseSession/C_CloseAllSessions should be a quick fix for your
> problem. Yes, it locks the card on the PC/SC level, but that's all a
> library without global knowledge can do.
> 
> Despite this quick win, the problems listed below by Doug still apply!
> Also, the card driver for your card needs to be reviewed in more depth.
> 
> As I am writing this I can see that sc_lock also tries to open an SM
> channel, which I'm pretty sure is not always a good idea... So all in
> all, you have a lot of testing ahead of you ;-)
> 
> Greets, Frank.
> 
> 
> Am Donnerstag, dem 12. November, um  8:26 Uhr schrieb Douglas E Engert:
> > Each applet, card or calling application may have its own issues. Can you say what applets, cards or applications you are trying to address?
> > 
> > There are a number of factors to consider, these are in particular order:
> > 
> > (1) PKCS#11 already has sessions that require login designed to give exclusive access.
> > But PKCS#11 on most systems, is at the application level not at the system level.
> > 
> > (2a) PC/SC is at the system level and can enforce exclusive access with a lock/unlock.
> > 
> > (2b) Remote desktop connections can make a card available over the network by transmitting PC/SC
> > calls. This could cause complications.
> > 
> > (3) OpenSC uses the pcsc lock/unlock for transactions, but this does not match the
> > PKCS#11 session level.
> > 
> > (4) Some cards are starting to use secure messaging, that needs to be reestablished if some other
> > application jumped in the middle.
> > 
> > (5) Some cards don't have an un-verify to reset the security state of the card. A ATR reset is used instead.
> > 
> > (6) How would you handle the caching of a card state of a read/write card, if some other application
> > changed files, keys or pins on the card?
> > 
> > (7) Many applications may keep a PKCS#11 session open for long periods, and they poll to see if the card has been removed.
> > 
> > (8) Some cards, users or applications may expect that once a card is unlocked by the user, any of the user's processes can use the card without reentering the PIN.
> > 
> > (9a) PIN caching may be against policy, PIN PAD readers may be required by policy. Don't count on pin caching as a solution.
> > 
> > (9b) Other ways to authenticate may be required other the PIN, such as fingerprint matching on card.
> > 
> > (10) OpenSC and PCSC already has some options to control releasing/holding of the locks.
> > 
> > (11) OpenSC already will try and uses a cached pin if a sign, decrypt or derive operation fails. Could this be extended?
> > To the user it looks stateless. (Did I say I don't like cached pins?)
> > 
> > (12) PKCS#11 has the concept of CKA_ALWAYS_AUTHENTICATE to force a reauthentication for selected keys. (Some cards enforce that a crytpo command for some keys must be proceeded by a VERIFY command 
> > with no other commands in between.) OpenSC already supports this. You may want to look at using this concept for all the keys even though the card does not require it.
> > Applications may not need any changes! The application is the responsible to do another C_Login.
> > 
> > (13) OpenSC does have an on disk cache of card objects for the eid card. This might help if you need to
> > reconnect to a card, you would not need to reread objects from the card. Microsoft's cert store does something like this.
> > 
> > (14) Adding "save"/"restore" calls to PKCS#11 will then require applications to call these. Many applications will not,
> > if only some uses these, will the concept still work?
> > 
> > 
> > (15) Many of the OpenSC bugs lately deal with multiple applications resetting the cards (or using multiple applets on the card) and issues with SM or
> > reestablishment of authentication. These are usually addressed in the card driver.
> > 
> > On 11/12/2015 5:03 AM, Martin Vogt wrote:
> > >
> > > On Thu, Nov 12, 2015 at 11:47 AM, Frank Morgner <mo...@in... <mailto:mo...@in...>> wrote:
> > >
> > >     Nobody is working on this. Could you state what you think the (security) problem currently is?
> > >
> > >
> > > I'm using closed source drivers, because opensc/pkcs11 cannot be used
> > > simultaneously. (since ~ 5 years now)
> > >
> > > Are there ideas how "stateless" support should be implemented?
> > >
> > > My idea was to add two methods to a driver plugin "save"/"restore" state,
> > > and call this from maybe the pkcs11 layer(?)
> > >
> > > I would like to ask for an advice how it should be done.
> > >
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------------------------------------------------------
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> > 
> 
> -- 
> 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



> ------------------------------------------------------------------------------

> _______________________________________________
> 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] State of stateless support

[NdK <ndk...@gm...>]

Il 12/11/2015 22:51, Frank Morgner ha scritto:
> Could you give a step-by-step guide how to reproduce your problem with
> OpenSC caused by operating "non-statelessly"? I don't understand why you
> think OpenSC "cannot be used simultaneously" in multiple processes...
Never tried to use a single smartcard with multiple certs both to
authenticate to websites (via Firefox) and sign/decrypt emails (from
Thunderbird)?
They both want to have exclusive access :(

BYtE,
 Diego

Re: [Opensc-devel] State of stateless support

[NdK <ndk...@gm...>]

Il 13/11/2015 09:42, Martin Vogt ha scritto:

> and because its a different functionality, the resulting pkcs11 lib
> needs another name for example "pkcs11stateless.so"...
To me, that sounds more like pkcs11-proxy.so : it intercepts all the
calls to the lower level PKCS11 layer and adds some functionality
depending on its own state. And maybe issues some other calls to the
lower level driver and/or handles caching of card objects.

BYtE,
 Diego

Re: [Opensc-devel] State of session locking support

[Alon Bar-L. <alo...@gm...>]

On 13 November 2015 at 16:51, Douglas E Engert <dee...@gm...> wrote:
>
>
> On 11/13/2015 7:38 AM, Alon Bar-Lev wrote:
>>
>> On 13 November 2015 at 15:22, Douglas E Engert <dee...@gm...> wrote:
>>>
>>> Dave's and Frank's comments show some promise. The PKCS#11 RPC would put
>>> the PKCS#11
>>> as a single service at the system level where it should be. It can then
>>> control access so a user could use their card across
>>> multiple applications and could actually setup a single SM to the card
>>> used by all the applications.
>>
>>
>> What context will this "service" be run under? user? system?
>> How will you manage the authentication to daemon?
>> How will remote access to smartcard, such as PC/SC redirection will
>> work? Examples: qemu/rdesktop.
>
>
>
> Those are all good questions. I don't have many answers. But the state we
> are in today
> has lots of problems.
>
> The smart card device could be treated like a camera, microphone, speakers
> DVD or other device attached to a computer
> designed to interface with the user the logged in user at the console.
> But what about a HSM type device that is not a user's card but a device?
> It could be if a process can authenticate to the device, all processes
> sharing the OS security,
> for example run under the same UID gain access.

it is not entirely correct to compare devices such as smartcard to
cdrom, you should compare it to mouse or keyboard.

when you login into remote machine the smartcard should be redirected
similar to your keyboard/mouse, maybe in future we will see smartcards
as hid instead ccid.

> To the host OS a virtual machine may need access to these user interface
> devices too.
> I have not studied rdesktop closely. But as i understand it, its the PCSC
> messages are transported
> between client (with the card) and server with the application. Its not
> clear how locking
> is done on client, server or both.

the locking is done at pc/sc level, the lock/unlock requests are
delegated as well.

> The slots returned by C_GetSlotList could also be the slots that the system
> allows the current process to access.
> Does PCSC enforce any of these user controls?

ps/sc should provide access to readers user can access, in perfect
world pc/sc would live in user context and not be system process while
user can access the reader directly while it is allocated to him.

in Windows this behaviour is somewhat implemented as when you login to
windows remotely you see only these readers that are available to you
via redirection.

>
>
>>
>>> With PKCS#11 in each application, the save/restore state in a local
>>> application needs to consider that the state on the card
>>> will change as other applications access the card. The restored of a
>>> state by an application
>>> may not match the state in the card Only by reestablishing a connection
>>> and reauthentication can you get the card
>>> working again. (I don't consider caching the PIN to be good a security
>>> practice.)
>>
>>
>> This is why a card should support authentication cookie as I outlined
>> and some do.
>> You use credentials to establish authentication and accept a cookie as
>> a response.
>> This cookie can be used to re-establish security context, is lost
>> after timeout and/or poweroff.
>> The cookie is not effected or expired by pin change so card is not
>> locked when pin is modified and several low level application are
>> accessing the card.
>
>
> That would be nice, be we have to support cards that are not under our
> control,
> many are issued by governments to their citizens.

for these that do not support cookies, framework should cache the pin
as a solution, not the best but valid.

> Current card can have multiple applets and concurrent access to these may or
> may not
> be allowed by the card. That also needs to be addressed.

caching pin will provide a good solution for all these cards that have
no better interface, this will at least provide a solution.

>
>
>>
>>> On 11/13/2015 7:07 AM, Frank Morgner wrote:
>>>>
>>>> Please rephrase this problem to something like "session locking"!
>>>>
>>>> Doug is correct, this can't be solved purely on the lower level. Your
>>>> best bet would be the PKCS#11 Sessions. I just checked with Client
>>>> authentication in Firefox and the workflow is something like this:
>>>>
>>>> 1. Read card/token/certificates/slots/whatever
>>>> 2. C_OpenSession(0x1)
>>>> 3. C_Login
>>>> 4. C_OpenSession(0x1)
>>>> 5. C_SignInit/C_Sign
>>>> 6. (immediately after signature) C_CloseSession
>>>> 7. Go to 4. and repeat
>>>> 8. Terminate Firefox
>>>> 9. C_CloseAllSessions
>>>>
>>>> As you can see, as soon as the PIN is verified Firefox expects to have
>>>> exclusive access. Adding sc_lock/sc_unlock to C_OpenSession and
>>>> C_CloseSession/C_CloseAllSessions should be a quick fix for your
>>>> problem. Yes, it locks the card on the PC/SC level, but that's all a
>>>> library without global knowledge can do.
>>>>
>>>> Despite this quick win, the problems listed below by Doug still apply!
>>>> Also, the card driver for your card needs to be reviewed in more depth.
>>>>
>>>> As I am writing this I can see that sc_lock also tries to open an SM
>>>> channel, which I'm pretty sure is not always a good idea... So all in
>>>> all, you have a lot of testing ahead of you ;-)
>>>>
>>>> Greets, Frank.
>>>>
>>>>
>>>> Am Donnerstag, dem 12. November, um  8:26 Uhr schrieb Douglas E Engert:
>>>>>
>>>>> Each applet, card or calling application may have its own issues. Can
>>>>> you say what applets, cards or applications you are trying to address?
>>>>>
>>>>> There are a number of factors to consider, these are in particular
>>>>> order:
>>>>>
>>>>> (1) PKCS#11 already has sessions that require login designed to give
>>>>> exclusive access.
>>>>> But PKCS#11 on most systems, is at the application level not at the
>>>>> system level.
>>>>>
>>>>> (2a) PC/SC is at the system level and can enforce exclusive access with
>>>>> a lock/unlock.
>>>>>
>>>>> (2b) Remote desktop connections can make a card available over the
>>>>> network by transmitting PC/SC
>>>>> calls. This could cause complications.
>>>>>
>>>>> (3) OpenSC uses the pcsc lock/unlock for transactions, but this does
>>>>> not match the
>>>>> PKCS#11 session level.
>>>>>
>>>>> (4) Some cards are starting to use secure messaging, that needs to be
>>>>> reestablished if some other
>>>>> application jumped in the middle.
>>>>>
>>>>> (5) Some cards don't have an un-verify to reset the security state of
>>>>> the card. A ATR reset is used instead.
>>>>>
>>>>> (6) How would you handle the caching of a card state of a read/write
>>>>> card, if some other application
>>>>> changed files, keys or pins on the card?
>>>>>
>>>>> (7) Many applications may keep a PKCS#11 session open for long periods,
>>>>> and they poll to see if the card has been removed.
>>>>>
>>>>> (8) Some cards, users or applications may expect that once a card is
>>>>> unlocked by the user, any of the user's processes can use the card without
>>>>> reentering the PIN.
>>>>>
>>>>> (9a) PIN caching may be against policy, PIN PAD readers may be required
>>>>> by policy. Don't count on pin caching as a solution.
>>>>>
>>>>> (9b) Other ways to authenticate may be required other the PIN, such as
>>>>> fingerprint matching on card.
>>>>>
>>>>> (10) OpenSC and PCSC already has some options to control
>>>>> releasing/holding of the locks.
>>>>>
>>>>> (11) OpenSC already will try and uses a cached pin if a sign, decrypt
>>>>> or derive operation fails. Could this be extended?
>>>>> To the user it looks stateless. (Did I say I don't like cached pins?)
>>>>>
>>>>> (12) PKCS#11 has the concept of CKA_ALWAYS_AUTHENTICATE to force a
>>>>> reauthentication for selected keys. (Some cards enforce that a crytpo
>>>>> command for some keys must be proceeded by a VERIFY command
>>>>> with no other commands in between.) OpenSC already supports this. You
>>>>> may want to look at using this concept for all the keys even though the card
>>>>> does not require it.
>>>>> Applications may not need any changes! The application is the
>>>>> responsible to do another C_Login.
>>>>>
>>>>> (13) OpenSC does have an on disk cache of card objects for the eid
>>>>> card. This might help if you need to
>>>>> reconnect to a card, you would not need to reread objects from the
>>>>> card. Microsoft's cert store does something like this.
>>>>>
>>>>> (14) Adding "save"/"restore" calls to PKCS#11 will then require
>>>>> applications to call these. Many applications will not,
>>>>> if only some uses these, will the concept still work?
>>>>>
>>>>>
>>>>> (15) Many of the OpenSC bugs lately deal with multiple applications
>>>>> resetting the cards (or using multiple applets on the card) and issues with
>>>>> SM or
>>>>> reestablishment of authentication. These are usually addressed in the
>>>>> card driver.
>>>>>
>>>>> On 11/12/2015 5:03 AM, Martin Vogt wrote:
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 12, 2015 at 11:47 AM, Frank Morgner
>>>>>> <mo...@in... <mailto:mo...@in...>>
>>>>>> wrote:
>>>>>>
>>>>>>       Nobody is working on this. Could you state what you think the
>>>>>> (security) problem currently is?
>>>>>>
>>>>>>
>>>>>> I'm using closed source drivers, because opensc/pkcs11 cannot be used
>>>>>> simultaneously. (since ~ 5 years now)
>>>>>>
>>>>>> Are there ideas how "stateless" support should be implemented?
>>>>>>
>>>>>> My idea was to add two methods to a driver plugin "save"/"restore"
>>>>>> state,
>>>>>> and call this from maybe the pkcs11 layer(?)
>>>>>>
>>>>>> I would like to ask for an advice how it should be done.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>
>>>
>>> --
>>>
>>>    Douglas E. Engert  <DEE...@gm...>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Opensc-devel mailing list
>>> Ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>>
>
> --
>
>  Douglas E. Engert  <DEE...@gm...>
>

Re: [Opensc-devel] State of session locking support

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

On 11/13/2015 7:38 AM, Alon Bar-Lev wrote:
> On 13 November 2015 at 15:22, Douglas E Engert <dee...@gm...> wrote:
>> Dave's and Frank's comments show some promise. The PKCS#11 RPC would put the PKCS#11
>> as a single service at the system level where it should be. It can then control access so a user could use their card across
>> multiple applications and could actually setup a single SM to the card used by all the applications.
>
> What context will this "service" be run under? user? system?
> How will you manage the authentication to daemon?
> How will remote access to smartcard, such as PC/SC redirection will
> work? Examples: qemu/rdesktop.


Those are all good questions. I don't have many answers. But the state we are in today
has lots of problems.

The smart card device could be treated like a camera, microphone, speakers DVD or other device attached to a computer
designed to interface with the user the logged in user at the console.
But what about a HSM type device that is not a user's card but a device?
It could be if a process can authenticate to the device, all processes sharing the OS security,
for example run under the same UID gain access.

To the host OS a virtual machine may need access to these user interface devices too.
I have not studied rdesktop closely. But as i understand it, its the PCSC messages are transported
between client (with the card) and server with the application. Its not clear how locking
is done on client, server or both.

The slots returned by C_GetSlotList could also be the slots that the system allows the current process to access.
Does PCSC enforce any of these user controls?


>
>> With PKCS#11 in each application, the save/restore state in a local application needs to consider that the state on the card
>> will change as other applications access the card. The restored of a state by an application
>> may not match the state in the card Only by reestablishing a connection and reauthentication can you get the card
>> working again. (I don't consider caching the PIN to be good a security practice.)
>
> This is why a card should support authentication cookie as I outlined
> and some do.
> You use credentials to establish authentication and accept a cookie as
> a response.
> This cookie can be used to re-establish security context, is lost
> after timeout and/or poweroff.
> The cookie is not effected or expired by pin change so card is not
> locked when pin is modified and several low level application are
> accessing the card.

That would be nice, be we have to support cards that are not under our control,
many are issued by governments to their citizens.

Current card can have multiple applets and concurrent access to these may or may not
be allowed by the card. That also needs to be addressed.


>
>> On 11/13/2015 7:07 AM, Frank Morgner wrote:
>>> Please rephrase this problem to something like "session locking"!
>>>
>>> Doug is correct, this can't be solved purely on the lower level. Your
>>> best bet would be the PKCS#11 Sessions. I just checked with Client
>>> authentication in Firefox and the workflow is something like this:
>>>
>>> 1. Read card/token/certificates/slots/whatever
>>> 2. C_OpenSession(0x1)
>>> 3. C_Login
>>> 4. C_OpenSession(0x1)
>>> 5. C_SignInit/C_Sign
>>> 6. (immediately after signature) C_CloseSession
>>> 7. Go to 4. and repeat
>>> 8. Terminate Firefox
>>> 9. C_CloseAllSessions
>>>
>>> As you can see, as soon as the PIN is verified Firefox expects to have
>>> exclusive access. Adding sc_lock/sc_unlock to C_OpenSession and
>>> C_CloseSession/C_CloseAllSessions should be a quick fix for your
>>> problem. Yes, it locks the card on the PC/SC level, but that's all a
>>> library without global knowledge can do.
>>>
>>> Despite this quick win, the problems listed below by Doug still apply!
>>> Also, the card driver for your card needs to be reviewed in more depth.
>>>
>>> As I am writing this I can see that sc_lock also tries to open an SM
>>> channel, which I'm pretty sure is not always a good idea... So all in
>>> all, you have a lot of testing ahead of you ;-)
>>>
>>> Greets, Frank.
>>>
>>>
>>> Am Donnerstag, dem 12. November, um  8:26 Uhr schrieb Douglas E Engert:
>>>> Each applet, card or calling application may have its own issues. Can you say what applets, cards or applications you are trying to address?
>>>>
>>>> There are a number of factors to consider, these are in particular order:
>>>>
>>>> (1) PKCS#11 already has sessions that require login designed to give exclusive access.
>>>> But PKCS#11 on most systems, is at the application level not at the system level.
>>>>
>>>> (2a) PC/SC is at the system level and can enforce exclusive access with a lock/unlock.
>>>>
>>>> (2b) Remote desktop connections can make a card available over the network by transmitting PC/SC
>>>> calls. This could cause complications.
>>>>
>>>> (3) OpenSC uses the pcsc lock/unlock for transactions, but this does not match the
>>>> PKCS#11 session level.
>>>>
>>>> (4) Some cards are starting to use secure messaging, that needs to be reestablished if some other
>>>> application jumped in the middle.
>>>>
>>>> (5) Some cards don't have an un-verify to reset the security state of the card. A ATR reset is used instead.
>>>>
>>>> (6) How would you handle the caching of a card state of a read/write card, if some other application
>>>> changed files, keys or pins on the card?
>>>>
>>>> (7) Many applications may keep a PKCS#11 session open for long periods, and they poll to see if the card has been removed.
>>>>
>>>> (8) Some cards, users or applications may expect that once a card is unlocked by the user, any of the user's processes can use the card without reentering the PIN.
>>>>
>>>> (9a) PIN caching may be against policy, PIN PAD readers may be required by policy. Don't count on pin caching as a solution.
>>>>
>>>> (9b) Other ways to authenticate may be required other the PIN, such as fingerprint matching on card.
>>>>
>>>> (10) OpenSC and PCSC already has some options to control releasing/holding of the locks.
>>>>
>>>> (11) OpenSC already will try and uses a cached pin if a sign, decrypt or derive operation fails. Could this be extended?
>>>> To the user it looks stateless. (Did I say I don't like cached pins?)
>>>>
>>>> (12) PKCS#11 has the concept of CKA_ALWAYS_AUTHENTICATE to force a reauthentication for selected keys. (Some cards enforce that a crytpo command for some keys must be proceeded by a VERIFY command
>>>> with no other commands in between.) OpenSC already supports this. You may want to look at using this concept for all the keys even though the card does not require it.
>>>> Applications may not need any changes! The application is the responsible to do another C_Login.
>>>>
>>>> (13) OpenSC does have an on disk cache of card objects for the eid card. This might help if you need to
>>>> reconnect to a card, you would not need to reread objects from the card. Microsoft's cert store does something like this.
>>>>
>>>> (14) Adding "save"/"restore" calls to PKCS#11 will then require applications to call these. Many applications will not,
>>>> if only some uses these, will the concept still work?
>>>>
>>>>
>>>> (15) Many of the OpenSC bugs lately deal with multiple applications resetting the cards (or using multiple applets on the card) and issues with SM or
>>>> reestablishment of authentication. These are usually addressed in the card driver.
>>>>
>>>> On 11/12/2015 5:03 AM, Martin Vogt wrote:
>>>>>
>>>>> On Thu, Nov 12, 2015 at 11:47 AM, Frank Morgner <mo...@in... <mailto:mo...@in...>> wrote:
>>>>>
>>>>>       Nobody is working on this. Could you state what you think the (security) problem currently is?
>>>>>
>>>>>
>>>>> I'm using closed source drivers, because opensc/pkcs11 cannot be used
>>>>> simultaneously. (since ~ 5 years now)
>>>>>
>>>>> Are there ideas how "stateless" support should be implemented?
>>>>>
>>>>> My idea was to add two methods to a driver plugin "save"/"restore" state,
>>>>> and call this from maybe the pkcs11 layer(?)
>>>>>
>>>>> I would like to ask for an advice how it should be done.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>
>> --
>>
>>    Douglas E. Engert  <DEE...@gm...>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Opensc-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

-- 

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

Re: [Opensc-devel] State of session locking support

[Martin V. <mv...@gm...>]

On Fri, Nov 13, 2015 at 2:07 PM, Frank Morgner <
mo...@in...> wrote:

> Please rephrase this problem to something like "session locking"!
> Doug is correct, this can't be solved purely on the lower level. Your
> best bet would be the PKCS#11 Sessions. I just checked with Client
> authentication in Firefox and the workflow is something like this:
>
> 1. Read card/token/certificates/slots/whatever
> 2. C_OpenSession(0x1)
> 3. C_Login
> 4. C_OpenSession(0x1)
> 5. C_SignInit/C_Sign
> 6. (immediately after signature) C_CloseSession
> 7. Go to 4. and repeat
> 8. Terminate Firefox
> 9. C_CloseAllSessions
>
>
So this means, the state can be  stored on the pkcs11 layer and
restore/save+destroy it
in the driver, if a pkcs11 call is entered (or returns)?

On Fri, Nov 13, 2015 at 2:22 PM, Douglas E Engert <dee...@gm...>
wrote:
>The restored of a state by an application may not match the state in the
card
>Only by reestablishing a connection and reauthentication can you get the
card
>working again. (I don't consider caching the PIN to be good a security
practice.)

>From my commercial drivers I see from the apdu, that they always
logout from the card and login/change directory.
(So the pkcs11 driver stores the pin internally.)

Re: [Opensc-devel] State of session locking support

[Alon Bar-L. <alo...@gm...>]

On 13 November 2015 at 15:22, Douglas E Engert <dee...@gm...> wrote:
> Dave's and Frank's comments show some promise. The PKCS#11 RPC would put the PKCS#11
> as a single service at the system level where it should be. It can then control access so a user could use their card across
> multiple applications and could actually setup a single SM to the card used by all the applications.

What context will this "service" be run under? user? system?
How will you manage the authentication to daemon?
How will remote access to smartcard, such as PC/SC redirection will
work? Examples: qemu/rdesktop.

> With PKCS#11 in each application, the save/restore state in a local application needs to consider that the state on the card
> will change as other applications access the card. The restored of a state by an application
> may not match the state in the card Only by reestablishing a connection and reauthentication can you get the card
> working again. (I don't consider caching the PIN to be good a security practice.)

This is why a card should support authentication cookie as I outlined
and some do.
You use credentials to establish authentication and accept a cookie as
a response.
This cookie can be used to re-establish security context, is lost
after timeout and/or poweroff.
The cookie is not effected or expired by pin change so card is not
locked when pin is modified and several low level application are
accessing the card.

> On 11/13/2015 7:07 AM, Frank Morgner wrote:
>> Please rephrase this problem to something like "session locking"!
>>
>> Doug is correct, this can't be solved purely on the lower level. Your
>> best bet would be the PKCS#11 Sessions. I just checked with Client
>> authentication in Firefox and the workflow is something like this:
>>
>> 1. Read card/token/certificates/slots/whatever
>> 2. C_OpenSession(0x1)
>> 3. C_Login
>> 4. C_OpenSession(0x1)
>> 5. C_SignInit/C_Sign
>> 6. (immediately after signature) C_CloseSession
>> 7. Go to 4. and repeat
>> 8. Terminate Firefox
>> 9. C_CloseAllSessions
>>
>> As you can see, as soon as the PIN is verified Firefox expects to have
>> exclusive access. Adding sc_lock/sc_unlock to C_OpenSession and
>> C_CloseSession/C_CloseAllSessions should be a quick fix for your
>> problem. Yes, it locks the card on the PC/SC level, but that's all a
>> library without global knowledge can do.
>>
>> Despite this quick win, the problems listed below by Doug still apply!
>> Also, the card driver for your card needs to be reviewed in more depth.
>>
>> As I am writing this I can see that sc_lock also tries to open an SM
>> channel, which I'm pretty sure is not always a good idea... So all in
>> all, you have a lot of testing ahead of you ;-)
>>
>> Greets, Frank.
>>
>>
>> Am Donnerstag, dem 12. November, um  8:26 Uhr schrieb Douglas E Engert:
>>> Each applet, card or calling application may have its own issues. Can you say what applets, cards or applications you are trying to address?
>>>
>>> There are a number of factors to consider, these are in particular order:
>>>
>>> (1) PKCS#11 already has sessions that require login designed to give exclusive access.
>>> But PKCS#11 on most systems, is at the application level not at the system level.
>>>
>>> (2a) PC/SC is at the system level and can enforce exclusive access with a lock/unlock.
>>>
>>> (2b) Remote desktop connections can make a card available over the network by transmitting PC/SC
>>> calls. This could cause complications.
>>>
>>> (3) OpenSC uses the pcsc lock/unlock for transactions, but this does not match the
>>> PKCS#11 session level.
>>>
>>> (4) Some cards are starting to use secure messaging, that needs to be reestablished if some other
>>> application jumped in the middle.
>>>
>>> (5) Some cards don't have an un-verify to reset the security state of the card. A ATR reset is used instead.
>>>
>>> (6) How would you handle the caching of a card state of a read/write card, if some other application
>>> changed files, keys or pins on the card?
>>>
>>> (7) Many applications may keep a PKCS#11 session open for long periods, and they poll to see if the card has been removed.
>>>
>>> (8) Some cards, users or applications may expect that once a card is unlocked by the user, any of the user's processes can use the card without reentering the PIN.
>>>
>>> (9a) PIN caching may be against policy, PIN PAD readers may be required by policy. Don't count on pin caching as a solution.
>>>
>>> (9b) Other ways to authenticate may be required other the PIN, such as fingerprint matching on card.
>>>
>>> (10) OpenSC and PCSC already has some options to control releasing/holding of the locks.
>>>
>>> (11) OpenSC already will try and uses a cached pin if a sign, decrypt or derive operation fails. Could this be extended?
>>> To the user it looks stateless. (Did I say I don't like cached pins?)
>>>
>>> (12) PKCS#11 has the concept of CKA_ALWAYS_AUTHENTICATE to force a reauthentication for selected keys. (Some cards enforce that a crytpo command for some keys must be proceeded by a VERIFY command
>>> with no other commands in between.) OpenSC already supports this. You may want to look at using this concept for all the keys even though the card does not require it.
>>> Applications may not need any changes! The application is the responsible to do another C_Login.
>>>
>>> (13) OpenSC does have an on disk cache of card objects for the eid card. This might help if you need to
>>> reconnect to a card, you would not need to reread objects from the card. Microsoft's cert store does something like this.
>>>
>>> (14) Adding "save"/"restore" calls to PKCS#11 will then require applications to call these. Many applications will not,
>>> if only some uses these, will the concept still work?
>>>
>>>
>>> (15) Many of the OpenSC bugs lately deal with multiple applications resetting the cards (or using multiple applets on the card) and issues with SM or
>>> reestablishment of authentication. These are usually addressed in the card driver.
>>>
>>> On 11/12/2015 5:03 AM, Martin Vogt wrote:
>>>>
>>>> On Thu, Nov 12, 2015 at 11:47 AM, Frank Morgner <mo...@in... <mailto:mo...@in...>> wrote:
>>>>
>>>>      Nobody is working on this. Could you state what you think the (security) problem currently is?
>>>>
>>>>
>>>> I'm using closed source drivers, because opensc/pkcs11 cannot be used
>>>> simultaneously. (since ~ 5 years now)
>>>>
>>>> Are there ideas how "stateless" support should be implemented?
>>>>
>>>> My idea was to add two methods to a driver plugin "save"/"restore" state,
>>>> and call this from maybe the pkcs11 layer(?)
>>>>
>>>> I would like to ask for an advice how it should be done.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>
> --
>
>   Douglas E. Engert  <DEE...@gm...>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel

Re: [Opensc-devel] State of session locking support

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

Dave's and Frank's comments show some promise. The PKCS#11 RPC would put the PKCS#11
as a single service at the system level where it should be. It can then control access so a user could use their card across
multiple applications and could actually setup a single SM to the card used by all the applications.


With PKCS#11 in each application, the save/restore state in a local application needs to consider that the state on the card
will change as other applications access the card. The restored of a state by an application
may not match the state in the card Only by reestablishing a connection and reauthentication can you get the card
working again. (I don't consider caching the PIN to be good a security practice.)

On 11/13/2015 7:07 AM, Frank Morgner wrote:
> Please rephrase this problem to something like "session locking"!
>
> Doug is correct, this can't be solved purely on the lower level. Your
> best bet would be the PKCS#11 Sessions. I just checked with Client
> authentication in Firefox and the workflow is something like this:
>
> 1. Read card/token/certificates/slots/whatever
> 2. C_OpenSession(0x1)
> 3. C_Login
> 4. C_OpenSession(0x1)
> 5. C_SignInit/C_Sign
> 6. (immediately after signature) C_CloseSession
> 7. Go to 4. and repeat
> 8. Terminate Firefox
> 9. C_CloseAllSessions
>
> As you can see, as soon as the PIN is verified Firefox expects to have
> exclusive access. Adding sc_lock/sc_unlock to C_OpenSession and
> C_CloseSession/C_CloseAllSessions should be a quick fix for your
> problem. Yes, it locks the card on the PC/SC level, but that's all a
> library without global knowledge can do.
>
> Despite this quick win, the problems listed below by Doug still apply!
> Also, the card driver for your card needs to be reviewed in more depth.
>
> As I am writing this I can see that sc_lock also tries to open an SM
> channel, which I'm pretty sure is not always a good idea... So all in
> all, you have a lot of testing ahead of you ;-)
>
> Greets, Frank.
>
>
> Am Donnerstag, dem 12. November, um  8:26 Uhr schrieb Douglas E Engert:
>> Each applet, card or calling application may have its own issues. Can you say what applets, cards or applications you are trying to address?
>>
>> There are a number of factors to consider, these are in particular order:
>>
>> (1) PKCS#11 already has sessions that require login designed to give exclusive access.
>> But PKCS#11 on most systems, is at the application level not at the system level.
>>
>> (2a) PC/SC is at the system level and can enforce exclusive access with a lock/unlock.
>>
>> (2b) Remote desktop connections can make a card available over the network by transmitting PC/SC
>> calls. This could cause complications.
>>
>> (3) OpenSC uses the pcsc lock/unlock for transactions, but this does not match the
>> PKCS#11 session level.
>>
>> (4) Some cards are starting to use secure messaging, that needs to be reestablished if some other
>> application jumped in the middle.
>>
>> (5) Some cards don't have an un-verify to reset the security state of the card. A ATR reset is used instead.
>>
>> (6) How would you handle the caching of a card state of a read/write card, if some other application
>> changed files, keys or pins on the card?
>>
>> (7) Many applications may keep a PKCS#11 session open for long periods, and they poll to see if the card has been removed.
>>
>> (8) Some cards, users or applications may expect that once a card is unlocked by the user, any of the user's processes can use the card without reentering the PIN.
>>
>> (9a) PIN caching may be against policy, PIN PAD readers may be required by policy. Don't count on pin caching as a solution.
>>
>> (9b) Other ways to authenticate may be required other the PIN, such as fingerprint matching on card.
>>
>> (10) OpenSC and PCSC already has some options to control releasing/holding of the locks.
>>
>> (11) OpenSC already will try and uses a cached pin if a sign, decrypt or derive operation fails. Could this be extended?
>> To the user it looks stateless. (Did I say I don't like cached pins?)
>>
>> (12) PKCS#11 has the concept of CKA_ALWAYS_AUTHENTICATE to force a reauthentication for selected keys. (Some cards enforce that a crytpo command for some keys must be proceeded by a VERIFY command
>> with no other commands in between.) OpenSC already supports this. You may want to look at using this concept for all the keys even though the card does not require it.
>> Applications may not need any changes! The application is the responsible to do another C_Login.
>>
>> (13) OpenSC does have an on disk cache of card objects for the eid card. This might help if you need to
>> reconnect to a card, you would not need to reread objects from the card. Microsoft's cert store does something like this.
>>
>> (14) Adding "save"/"restore" calls to PKCS#11 will then require applications to call these. Many applications will not,
>> if only some uses these, will the concept still work?
>>
>>
>> (15) Many of the OpenSC bugs lately deal with multiple applications resetting the cards (or using multiple applets on the card) and issues with SM or
>> reestablishment of authentication. These are usually addressed in the card driver.
>>
>> On 11/12/2015 5:03 AM, Martin Vogt wrote:
>>>
>>> On Thu, Nov 12, 2015 at 11:47 AM, Frank Morgner <mo...@in... <mailto:mo...@in...>> wrote:
>>>
>>>      Nobody is working on this. Could you state what you think the (security) problem currently is?
>>>
>>>
>>> I'm using closed source drivers, because opensc/pkcs11 cannot be used
>>> simultaneously. (since ~ 5 years now)
>>>
>>> Are there ideas how "stateless" support should be implemented?
>>>
>>> My idea was to add two methods to a driver plugin "save"/"restore" state,
>>> and call this from maybe the pkcs11 layer(?)
>>>
>>> I would like to ask for an advice how it should be done.
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>

-- 

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

Re: [Opensc-devel] State of session locking support

[Frank M. <mo...@in...>]

Please rephrase this problem to something like "session locking"!

Doug is correct, this can't be solved purely on the lower level. Your
best bet would be the PKCS#11 Sessions. I just checked with Client
authentication in Firefox and the workflow is something like this:

1. Read card/token/certificates/slots/whatever
2. C_OpenSession(0x1)
3. C_Login
4. C_OpenSession(0x1)
5. C_SignInit/C_Sign
6. (immediately after signature) C_CloseSession
7. Go to 4. and repeat
8. Terminate Firefox
9. C_CloseAllSessions

As you can see, as soon as the PIN is verified Firefox expects to have
exclusive access. Adding sc_lock/sc_unlock to C_OpenSession and
C_CloseSession/C_CloseAllSessions should be a quick fix for your
problem. Yes, it locks the card on the PC/SC level, but that's all a
library without global knowledge can do.

Despite this quick win, the problems listed below by Doug still apply!
Also, the card driver for your card needs to be reviewed in more depth.

As I am writing this I can see that sc_lock also tries to open an SM
channel, which I'm pretty sure is not always a good idea... So all in
all, you have a lot of testing ahead of you ;-)

Greets, Frank.


Am Donnerstag, dem 12. November, um  8:26 Uhr schrieb Douglas E Engert:
> Each applet, card or calling application may have its own issues. Can you say what applets, cards or applications you are trying to address?
> 
> There are a number of factors to consider, these are in particular order:
> 
> (1) PKCS#11 already has sessions that require login designed to give exclusive access.
> But PKCS#11 on most systems, is at the application level not at the system level.
> 
> (2a) PC/SC is at the system level and can enforce exclusive access with a lock/unlock.
> 
> (2b) Remote desktop connections can make a card available over the network by transmitting PC/SC
> calls. This could cause complications.
> 
> (3) OpenSC uses the pcsc lock/unlock for transactions, but this does not match the
> PKCS#11 session level.
> 
> (4) Some cards are starting to use secure messaging, that needs to be reestablished if some other
> application jumped in the middle.
> 
> (5) Some cards don't have an un-verify to reset the security state of the card. A ATR reset is used instead.
> 
> (6) How would you handle the caching of a card state of a read/write card, if some other application
> changed files, keys or pins on the card?
> 
> (7) Many applications may keep a PKCS#11 session open for long periods, and they poll to see if the card has been removed.
> 
> (8) Some cards, users or applications may expect that once a card is unlocked by the user, any of the user's processes can use the card without reentering the PIN.
> 
> (9a) PIN caching may be against policy, PIN PAD readers may be required by policy. Don't count on pin caching as a solution.
> 
> (9b) Other ways to authenticate may be required other the PIN, such as fingerprint matching on card.
> 
> (10) OpenSC and PCSC already has some options to control releasing/holding of the locks.
> 
> (11) OpenSC already will try and uses a cached pin if a sign, decrypt or derive operation fails. Could this be extended?
> To the user it looks stateless. (Did I say I don't like cached pins?)
> 
> (12) PKCS#11 has the concept of CKA_ALWAYS_AUTHENTICATE to force a reauthentication for selected keys. (Some cards enforce that a crytpo command for some keys must be proceeded by a VERIFY command 
> with no other commands in between.) OpenSC already supports this. You may want to look at using this concept for all the keys even though the card does not require it.
> Applications may not need any changes! The application is the responsible to do another C_Login.
> 
> (13) OpenSC does have an on disk cache of card objects for the eid card. This might help if you need to
> reconnect to a card, you would not need to reread objects from the card. Microsoft's cert store does something like this.
> 
> (14) Adding "save"/"restore" calls to PKCS#11 will then require applications to call these. Many applications will not,
> if only some uses these, will the concept still work?
> 
> 
> (15) Many of the OpenSC bugs lately deal with multiple applications resetting the cards (or using multiple applets on the card) and issues with SM or
> reestablishment of authentication. These are usually addressed in the card driver.
> 
> On 11/12/2015 5:03 AM, Martin Vogt wrote:
> >
> > On Thu, Nov 12, 2015 at 11:47 AM, Frank Morgner <mo...@in... <mailto:mo...@in...>> wrote:
> >
> >     Nobody is working on this. Could you state what you think the (security) problem currently is?
> >
> >
> > I'm using closed source drivers, because opensc/pkcs11 cannot be used
> > simultaneously. (since ~ 5 years now)
> >
> > Are there ideas how "stateless" support should be implemented?
> >
> > My idea was to add two methods to a driver plugin "save"/"restore" state,
> > and call this from maybe the pkcs11 layer(?)
> >
> > I would like to ask for an advice how it should be done.
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > 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
> 

-- 
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] State of stateless support

[Alon Bar-L. <alo...@gm...>]

On 13 November 2015 at 14:59, Martin Vogt <mv...@gm...> wrote:

<snip>

> Maybe it cannot be fixed universally for all cards at once, ok.
> Why it's such a problem to start with one card?
>
> I wrote the starcos3.2 support 5 years ago, then abandoned my work,
> the driver was lately adopted in opensc (thanks to fancycode)  and
> simultaneous access is still not solved.
>
> How could a possible implementation looks like? (for one card, at the
> beginning)
> Should it be fixed/hacked/worked around on the pkcs11 layer?

What is missing in[1]? I wrote a specific sequence.

[1] https://www.opensc-project.org/opensc/ticket/186

Re: [Opensc-devel] State of stateless support

[Martin V. <mv...@gm...>]

Hello all,

On Fri, Nov 13, 2015 at 12:29 PM, Alon Bar-Lev <alo...@gm...>
wrote:
>David, please stop trying to push p11-kit to people, it is a problem
>not a solution.
>
>PKCS#11 spec clearly state how it should behave in multi-application
>environment.
>OpenSC's PKCS#11 provider does not comply with this and other
>requirements, unless configured to use insecure mode.
>[...]

I know that simultaneous access works with my commercial drivers, but I
always thought that its a hack and the SPEC was designed not
multi-application
aware.



On Fri, Nov 13, 2015 at 1:09 PM, David Woodhouse <dw...@in...>
wrote:

> I think you are quite right that this should be fixed in OpenSC... but
> it's been 7 years now since you documented it, and still it doesn't
> seem to be universally understood let alone show any signs of being
> fixed.
>

Maybe it cannot be fixed universally for all cards at once, ok.
Why it's such a problem to start with one card?

I wrote the starcos3.2 support 5 years ago, then abandoned my work,
the driver was lately adopted in opensc (thanks to fancycode)  and
simultaneous access is still not solved.

How could a possible implementation looks like? (for one card, at the
beginning)
Should it be fixed/hacked/worked around on the pkcs11 layer?


Best regards,

Martin

Re: [Opensc-devel] State of stateless support

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

On Fri, 2015-11-13 at 13:29 +0200, Alon Bar-Lev wrote:
> 
> PKCS#11 spec clearly state how it should behave in multi-application
> environment.
> OpenSC's PKCS#11 provider does not comply with this and other
> requirements, unless configured to use insecure mode.
> It is long pending issue, I documented it explicitly 7 years ago[1] so
> people will be aware.
> It is one of the reason why opensc framework cannot be used in real life.

Hi Alon,

As ever, it's nice to hear from you.

I think you are quite right that this should be fixed in OpenSC... but
it's been 7 years now since you documented it, and still it doesn't
seem to be universally understood let alone show any signs of being
fixed.

So perhaps it isn't entirely out of order to suggest how someone might
work around it at a higher level. But I should have said 'work around'
rather than 'solve'. Thanks for correcting me.

Note that there are plenty of implementations of PKCS#11 RPC. The one
in p11-kit is only one of them.

-- 
David Woodhouse                            Open Source Technology Centre
Dav...@in...                              Intel Corporation

Re: [Opensc-devel] State of stateless support

[Alon Bar-L. <alo...@gm...>]

On 13 November 2015 at 13:06, David Woodhouse <dw...@in...> wrote:

<snip>

> Such an approach would probably be outside the scope of OpenSC; it
> lives in a more generic PKCS#11 management tool, such as p11-kit. Which
> does indeed already have RPC facilities.

David, please stop trying to push p11-kit to people, it is a problem
not a solution.

PKCS#11 spec clearly state how it should behave in multi-application
environment.
OpenSC's PKCS#11 provider does not comply with this and other
requirements, unless configured to use insecure mode.
It is long pending issue, I documented it explicitly 7 years ago[1] so
people will be aware.
It is one of the reason why opensc framework cannot be used in real life.
There are solutions, I outlined several of these in the bug, any
require significant effort within what was then the implementation,
maybe there is a change.
All solutions should assume another application (also non PKCS#11) can
also share the card.

Regards,
Alon

[1] https://www.opensc-project.org/opensc/ticket/186

Re: [Opensc-devel] State of stateless support

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

On Thu, 2015-11-12 at 11:47 +0100, Frank Morgner wrote:
> Nobody is working on this. Could you state what you think the
> (security) problem currently is?

As I understand it, the problem is that once *one* client has
authenticated to the device, other clients can make use of that
authenticated state — there's no way for the device to know that
actually this request is coming from a *different* client to the one
that gave the correct PIN.

This depends on the applet in use, of course, and the way it
communicates with OpenSC. Some might actually have digital signatures
on each request, so that the rogue client *can't* make a request that
looks like it came from the genuine client. Most don't.


One way to solve this problem might be to *enforce* exclusive access,
by a single dæmon process. The actual users (the web browser, and the
VPN client in Martin's case) would just use a simple PKCS#11 RPC module
instead.

Then all the session management is within *one* process and the problem
should be easily solvable (and indeed should be handled correctly by
the various existing implementations of PKCS#11 RPC).

Such an approach would probably be outside the scope of OpenSC; it
lives in a more generic PKCS#11 management tool, such as p11-kit. Which
does indeed already have RPC facilities.

-- 
David Woodhouse                            Open Source Technology Centre
Dav...@in...                              Intel Corporation

Re: [Opensc-devel] PKCS#11 Interface of OpenSC with customized Middleware

[Vincent Le T. <vin...@my...>]

IAS-ECC applets have already their own "card driver" in OpenSC. You should
investigate this lead.

Note: there are specialized companies (like mine - mysmartlogon.com) that
you can hire providing services to implement / modify minidriver / csp or
card driver in OpenSC if you are new on that subject.
(testing is very complicated and most of the people are missing test cases
....)

regards,
Vincent

2015-11-13 10:20 GMT+01:00 Rasmus Risse <ras...@gm...>:

> Hello,
>
>
>
> I´m not quite sure if this is the right way to ask this question, so
> please correct me if not.
>
>
>
> I´m working for a Company, which manufactures Smartcards and implements
> the Applets for the Cards. I´ve got an old Middleware + PKCS#11 Module for
> this card written by another Company, but this Software is out-dated and
> can´t be used by new Versions of Windows and so on. So I thought I could
> use the PKCS#11 Interface and Carddriver from OpenSC to write a new one,
> but the Applets on the Card don´t seem to be compatible with OpenSC. Is it
> possible to use my own Middleware API or my APDUs for the PKCS#11 Module?
> The most important thing would be signing a PDF (I´m currently using Adobe)
> with the one of the two Certificates stored in the IAS Applet, where one is
> secured with the Card PIN and the other with a Signature PIN.
>
>
>
> Can you help me what I need to do if I want to develop that on a Windows 7
> PC, preferably on MSVS 2008 in C++.
>
>
>
> Contact me if you can help me and if you need more information.
>
>
>
> Thanks in advance,
>
> Rasmus Risse
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
>


-- 
--
Vincent Le Toux

My Smart Logon
www.mysmartlogon.com

[Opensc-devel] PKCS#11 Interface of OpenSC with customized Middleware

[Rasmus R. <ras...@gm...>]

Hello,



I´m not quite sure if this is the right way to ask this question, so please
correct me if not.



I´m working for a Company, which manufactures Smartcards and implements the
Applets for the Cards. I´ve got an old Middleware + PKCS#11 Module for this
card written by another Company, but this Software is out-dated and can´t
be used by new Versions of Windows and so on. So I thought I could use the
PKCS#11 Interface and Carddriver from OpenSC to write a new one, but the
Applets on the Card don´t seem to be compatible with OpenSC. Is it possible
to use my own Middleware API or my APDUs for the PKCS#11 Module? The most
important thing would be signing a PDF (I´m currently using Adobe) with the
one of the two Certificates stored in the IAS Applet, where one is secured
with the Card PIN and the other with a Signature PIN.



Can you help me what I need to do if I want to develop that on a Windows 7
PC, preferably on MSVS 2008 in C++.



Contact me if you can help me and if you need more information.



Thanks in advance,

Rasmus Risse

Re: [Opensc-devel] State of stateless support

[Martin V. <mv...@gm...>]

On Thu, Nov 12, 2015 at 5:38 PM, Douglas E Engert <dee...@gm...>
wrote:

>     Each applet, card or calling application may have its own issues.
>
>>     Can you say what applets, cards or applications you are trying to
>> address?
>> Starcos 3.2 from Thunderbird/Firefox/Cisco VPN, like some time ago:
>> (*) https://www.opensc-project.org/opensc/ticket/373
>>
>
> How about:
>
> https://github.com/OpenSC/OpenSC/pull/357
> "Code inspired by experimental STARCOS 3 driver by Martin Vogt"
> Are you in github.com/OpenSC ?
> Last commit for card-starcos.c was July 31.
>
> OpenSC has many developers, but unlike other projects, developers only
> have one or maybe two cards that they are interested in.
> (Starcos is not on my list, PIV is.) So to get the attention of a
> developer rephrase your concern with the card you are interested in.
>

I like to have the "stateless" support for the STARCOS3 driver.
My idea was to extend the card-starcos.c plugin with two callback functions.
The driver knows how to save/restore its state, but it does not know when.
But I think the pkcs11 layer does.

Then every entry/exit to a pkcs11 function looks up the driver, by a pkcs11
session handle, after the reader is locked
and tries to restore the previous state. If the thread exists the pkcs11
function it saves the state and logout of the card.
The state is a PIN/directory structure.

I think this is what the commercial software does.
This will have some issues with with pinpad readers, (Therefore the pkcs11
driver cannot be used for these readers)
and because its a different functionality, the resulting pkcs11 lib needs
another name for example "pkcs11stateless.so"...



> But have you looked at the opensc.conf for PCSC?
> Not sure if these would work for you.
>
>                 # Connect to reader in exclusive mode?
>
>[snip]


The last time I looked at it (*) the config options didn't help. It leaves
the card unlocked for every application in some
circumstances.

  > [point 1-25]
>>
>> All are valid points.
>> I assume that the commercial pkcs11 driver won't work in some cases.
>> Maybe they return an error if the state restore fails.
>> But for me, it looks the majority of the application do not behave
>> evil/that way.
>>
>>
> I would assume if they don't understand the save/restore pkcs11 attributes
> or new calls
> they wont use it, and just do what they do now, which is have problems if
> some other application
> grabs the card.
>

The modification should not be visible to the outside, eg "pkcs11.h". Its
an internal modification.
Thunderbird or firefox do a C_Login on start and keep the card locked the
whole time.
The pkcs11 driver internally has to do the "logout" and keep the state
associated with a pkcs11 session handle.

I haven't looked at the pkcs11 code yet, so that's only my idea how it may
work...
Therefore I would like to have some advise, how it may be done.
(Or if there a other ways how to do it.)

Best regards,

Martin

Re: [Opensc-devel] State of stateless support

[Frank M. <mo...@in...>]

Could you give a step-by-step guide how to reproduce your problem with
OpenSC caused by operating "non-statelessly"? I don't understand why you
think OpenSC "cannot be used simultaneously" in multiple processes...

Greets, Frank.


Am Donnerstag, dem 12. November, um 12:03 Uhr schrieb Martin Vogt:
> On Thu, Nov 12, 2015 at 11:47 AM, Frank Morgner <
> mo...@in...> wrote:
> 
> > Nobody is working on this. Could you state what you think the (security)
> > problem currently is?
> >
> 
> I'm using closed source drivers, because opensc/pkcs11 cannot be used
> simultaneously. (since ~ 5 years now)
> 
> Are there ideas how "stateless" support should be implemented?
> 
> My idea was to add two methods to a driver plugin "save"/"restore" state,
> and call this from maybe the pkcs11 layer(?)
> 
> I would like to ask for an advice how it should be done.

-- 
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] State of stateless support

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

Each applet, card or calling application may have its own issues. Can you say what applets, cards or applications you are trying to address?

There are a number of factors to consider, these are in particular order:

(1) PKCS#11 already has sessions that require login designed to give exclusive access.
But PKCS#11 on most systems, is at the application level not at the system level.

(2a) PC/SC is at the system level and can enforce exclusive access with a lock/unlock.

(2b) Remote desktop connections can make a card available over the network by transmitting PC/SC
calls. This could cause complications.

(3) OpenSC uses the pcsc lock/unlock for transactions, but this does not match the
PKCS#11 session level.

(4) Some cards are starting to use secure messaging, that needs to be reestablished if some other
application jumped in the middle.

(5) Some cards don't have an un-verify to reset the security state of the card. A ATR reset is used instead.

(6) How would you handle the caching of a card state of a read/write card, if some other application
changed files, keys or pins on the card?

(7) Many applications may keep a PKCS#11 session open for long periods, and they poll to see if the card has been removed.

(8) Some cards, users or applications may expect that once a card is unlocked by the user, any of the user's processes can use the card without reentering the PIN.

(9a) PIN caching may be against policy, PIN PAD readers may be required by policy. Don't count on pin caching as a solution.

(9b) Other ways to authenticate may be required other the PIN, such as fingerprint matching on card.

(10) OpenSC and PCSC already has some options to control releasing/holding of the locks.

(11) OpenSC already will try and uses a cached pin if a sign, decrypt or derive operation fails. Could this be extended?
To the user it looks stateless. (Did I say I don't like cached pins?)

(12) PKCS#11 has the concept of CKA_ALWAYS_AUTHENTICATE to force a reauthentication for selected keys. (Some cards enforce that a crytpo command for some keys must be proceeded by a VERIFY command 
with no other commands in between.) OpenSC already supports this. You may want to look at using this concept for all the keys even though the card does not require it.
Applications may not need any changes! The application is the responsible to do another C_Login.

(13) OpenSC does have an on disk cache of card objects for the eid card. This might help if you need to
reconnect to a card, you would not need to reread objects from the card. Microsoft's cert store does something like this.

(14) Adding "save"/"restore" calls to PKCS#11 will then require applications to call these. Many applications will not,
if only some uses these, will the concept still work?


(15) Many of the OpenSC bugs lately deal with multiple applications resetting the cards (or using multiple applets on the card) and issues with SM or
reestablishment of authentication. These are usually addressed in the card driver.

On 11/12/2015 5:03 AM, Martin Vogt wrote:
>
> On Thu, Nov 12, 2015 at 11:47 AM, Frank Morgner <mo...@in... <mailto:mo...@in...>> wrote:
>
>     Nobody is working on this. Could you state what you think the (security) problem currently is?
>
>
> I'm using closed source drivers, because opensc/pkcs11 cannot be used
> simultaneously. (since ~ 5 years now)
>
> Are there ideas how "stateless" support should be implemented?
>
> My idea was to add two methods to a driver plugin "save"/"restore" state,
> and call this from maybe the pkcs11 layer(?)
>
> I would like to ask for an advice how it should be done.
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

-- 

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

Re: [Opensc-devel] State of stateless support

[Martin V. <mv...@gm...>]

On Thu, Nov 12, 2015 at 11:47 AM, Frank Morgner <
mo...@in...> wrote:

> Nobody is working on this. Could you state what you think the (security)
> problem currently is?
>

I'm using closed source drivers, because opensc/pkcs11 cannot be used
simultaneously. (since ~ 5 years now)

Are there ideas how "stateless" support should be implemented?

My idea was to add two methods to a driver plugin "save"/"restore" state,
and call this from maybe the pkcs11 layer(?)

I would like to ask for an advice how it should be done.

Re: [Opensc-devel] State of stateless support

[Frank M. <mo...@in...>]

Nobody is working on this. Could you state what you think the (security) problem currently is?

Am 12. November 2015 10:29:03 MEZ, schrieb Martin Vogt <mv...@gm...>:
>Hello list,
>
>is anyone working on this?
>
>https://www.opensc-project.org/opensc/ticket/186
>
>The use case is:
>
>The smartcard is used in thunderbird/firefox/IE and used by an Cisco
>VPN
>software simultaneously.
>
>regards,
>
>Martin
>
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Opensc-devel mailing list
>Ope...@li...
>https://lists.sourceforge.net/lists/listinfo/opensc-devel

-- 
Frank Morgner

[Opensc-devel] State of stateless support

[Martin V. <mv...@gm...>]

Hello list,

is anyone working on this?

https://www.opensc-project.org/opensc/ticket/186

The use case is:

The smartcard is used in thunderbird/firefox/IE and used by an Cisco VPN
software simultaneously.

regards,

Martin

Re: [Opensc-devel] Issue with signatures with D-TRUST card 3.0 (STARCOS 3.4) smart card

[Ferdinand R. <ra...@we...>]

Hi Andreas,

here is another log, recorded with OPENSC_DEBUG=2 (like this, Thunderbird does not freeze). Again, I am prompted to enter my PIN once before Thunderbird presents the error message.

I am wondering about these lines, but I am not sure this is related to my issue:
0xb73f3700 08:31:19.130 [opensc-pkcs11] card-starcos.c:1713:starcos_pin_cmd: returning with: -1408 (Not supported)
0xb73f3700 08:31:19.130 [opensc-pkcs11] sec.c:206:sc_pin_cmd: returning with: -1408 (Not supported)

Best,
Ferdinand


0xb73f3700 08:31:13.755 [opensc-pkcs11] reader-pcsc.c:1122:pcsc_detect_readers: returning with: 0 (Success)
0xb73f3700 08:31:13.756 [opensc-pkcs11] reader-pcsc.c:301:refresh_attributes: returning with: 0 (Success)
0xb73f3700 08:31:13.756 [opensc-pkcs11] reader-pcsc.c:377:pcsc_detect_card_presence: returning with: 5
0xb73f3700 08:31:13.756 [opensc-pkcs11] card.c:148:sc_connect_card: called
0xb73f3700 08:31:13.757 [opensc-pkcs11] reader-pcsc.c:301:refresh_attributes: returning with: 0 (Success)
0xb73f3700 08:31:13.858 [opensc-pkcs11] card-starcos.c:621:starcos_select_file: called
0xb73f3700 08:31:15.285 [opensc-pkcs11] card-starcos.c:609:starcos_select_fid: returning with: 0 (Success)
0xb73f3700 08:31:15.320 [opensc-pkcs11] card-starcos.c:609:starcos_select_fid: returning with: 0 (Success)
0xb73f3700 08:31:16.672 [opensc-pkcs11] card-starcos.c:621:starcos_select_file: called
0xb73f3700 08:31:16.690 [opensc-pkcs11] card-starcos.c:472:starcos_select_aid: returning with: 0 (Success)
0xb73f3700 08:31:16.691 [opensc-pkcs11] card-starcos.c:621:starcos_select_file: called
0xb73f3700 08:31:16.715 [opensc-pkcs11] card-starcos.c:609:starcos_select_fid: returning with: 0 (Success)
0xb73f3700 08:31:16.728 [opensc-pkcs11] card-starcos.c:621:starcos_select_file: called
0xb73f3700 08:31:16.756 [opensc-pkcs11] card-starcos.c:609:starcos_select_fid: returning with: 0 (Success)
0xb73f3700 08:31:16.772 [opensc-pkcs11] card-starcos.c:621:starcos_select_file: called
0xb73f3700 08:31:16.788 [opensc-pkcs11] card-starcos.c:609:starcos_select_fid: returning with: 0 (Success)
0xb73f3700 08:31:16.809 [opensc-pkcs11] card-starcos.c:609:starcos_select_fid: returning with: 0 (Success)
0xb73f3700 08:31:16.835 [opensc-pkcs11] card-starcos.c:609:starcos_select_fid: returning with: 0 (Success)
0xb73f3700 08:31:16.859 [opensc-pkcs11] card-starcos.c:621:starcos_select_file: called
0xb73f3700 08:31:16.886 [opensc-pkcs11] card-starcos.c:609:starcos_select_fid: returning with: 0 (Success)
0xb73f3700 08:31:18.948 [opensc-pkcs11] card-starcos.c:621:starcos_select_file: called
0xb73f3700 08:31:18.958 [opensc-pkcs11] card-starcos.c:555:starcos_select_fid: returning with: -1201 (File not found)
0xb73f3700 08:31:18.959 [opensc-pkcs11] pkcs15-syn.c:140:sc_pkcs15_bind_synthetic: called
0xb73f3700 08:31:18.959 [opensc-pkcs11] pkcs15-itacns.c:854:sc_pkcs15emu_itacns_init_ex: called
0xb73f3700 08:31:18.959 [opensc-pkcs11] pkcs15-piv.c:1028:sc_pkcs15emu_piv_init_ex: called
0xb73f3700 08:31:18.959 [opensc-pkcs11] pkcs15-piv.c:234:piv_detect_card: called
0xb73f3700 08:31:18.959 [opensc-pkcs11] pkcs15-gemsafeGPK.c:168:gemsafe_detect_card: called
0xb73f3700 08:31:18.959 [opensc-pkcs11] pkcs15-esinit.c:82:sc_pkcs15emu_entersafe_init_ex: called
0xb73f3700 08:31:18.959 [opensc-pkcs11] pkcs15-esinit.c:38:entersafe_detect_card: called
0xb73f3700 08:31:18.959 [opensc-pkcs11] pkcs15-oberthur.c:1041:sc_pkcs15emu_oberthur_init_ex: called
0xb73f3700 08:31:18.959 [opensc-pkcs11] pkcs15-oberthur.c:1028:oberthur_detect_card: called
0xb73f3700 08:31:18.962 [opensc-pkcs11] card-starcos.c:621:starcos_select_file: called
0xb73f3700 08:31:18.976 [opensc-pkcs11] card-starcos.c:472:starcos_select_aid: returning with: 0 (Success)
0xb73f3700 08:31:18.976 [opensc-pkcs11] card-starcos.c:621:starcos_select_file: called
0xb73f3700 08:31:18.987 [opensc-pkcs11] card-starcos.c:555:starcos_select_fid: returning with: -1201 (File not found)
0xb73f3700 08:31:18.988 [opensc-pkcs11] pkcs15-syn.c:140:sc_pkcs15_bind_synthetic: called
0xb73f3700 08:31:18.988 [opensc-pkcs11] pkcs15-itacns.c:854:sc_pkcs15emu_itacns_init_ex: called
0xb73f3700 08:31:18.988 [opensc-pkcs11] pkcs15-piv.c:1028:sc_pkcs15emu_piv_init_ex: called
0xb73f3700 08:31:18.988 [opensc-pkcs11] pkcs15-piv.c:234:piv_detect_card: called
0xb73f3700 08:31:18.988 [opensc-pkcs11] pkcs15-gemsafeGPK.c:168:gemsafe_detect_card: called
0xb73f3700 08:31:18.988 [opensc-pkcs11] pkcs15-esinit.c:82:sc_pkcs15emu_entersafe_init_ex: called
0xb73f3700 08:31:18.988 [opensc-pkcs11] pkcs15-esinit.c:38:entersafe_detect_card: called
0xb73f3700 08:31:18.988 [opensc-pkcs11] pkcs15-oberthur.c:1041:sc_pkcs15emu_oberthur_init_ex: called
0xb73f3700 08:31:18.988 [opensc-pkcs11] pkcs15-oberthur.c:1028:oberthur_detect_card: called
0xb73f3700 08:31:18.991 [opensc-pkcs11] card-starcos.c:621:starcos_select_file: called
0xb73f3700 08:31:19.015 [opensc-pkcs11] card-starcos.c:472:starcos_select_aid: returning with: 0 (Success)
0xb73f3700 08:31:19.015 [opensc-pkcs11] card-starcos.c:621:starcos_select_file: called
0xb73f3700 08:31:19.025 [opensc-pkcs11] card-starcos.c:555:starcos_select_fid: returning with: -1201 (File not found)
0xb73f3700 08:31:19.025 [opensc-pkcs11] pkcs15-syn.c:140:sc_pkcs15_bind_synthetic: called
0xb73f3700 08:31:19.025 [opensc-pkcs11] pkcs15-itacns.c:854:sc_pkcs15emu_itacns_init_ex: called
0xb73f3700 08:31:19.025 [opensc-pkcs11] pkcs15-piv.c:1028:sc_pkcs15emu_piv_init_ex: called
0xb73f3700 08:31:19.025 [opensc-pkcs11] pkcs15-piv.c:234:piv_detect_card: called
0xb73f3700 08:31:19.025 [opensc-pkcs11] pkcs15-gemsafeGPK.c:168:gemsafe_detect_card: called
0xb73f3700 08:31:19.025 [opensc-pkcs11] pkcs15-esinit.c:82:sc_pkcs15emu_entersafe_init_ex: called
0xb73f3700 08:31:19.025 [opensc-pkcs11] pkcs15-esinit.c:38:entersafe_detect_card: called
0xb73f3700 08:31:19.025 [opensc-pkcs11] pkcs15-oberthur.c:1041:sc_pkcs15emu_oberthur_init_ex: called
0xb73f3700 08:31:19.025 [opensc-pkcs11] pkcs15-oberthur.c:1028:oberthur_detect_card: called
0xb73f3700 08:31:19.028 [opensc-pkcs11] reader-pcsc.c:301:refresh_attributes: returning with: 0 (Success)
0xb73f3700 08:31:19.028 [opensc-pkcs11] reader-pcsc.c:377:pcsc_detect_card_presence: returning with: 5
0xb73f3700 08:31:19.028 [opensc-pkcs11] reader-pcsc.c:301:refresh_attributes: returning with: 0 (Success)
0xb73f3700 08:31:19.028 [opensc-pkcs11] reader-pcsc.c:377:pcsc_detect_card_presence: returning with: 5
0xb73f3700 08:31:19.028 [opensc-pkcs11] reader-pcsc.c:301:refresh_attributes: returning with: 0 (Success)
0xb73f3700 08:31:19.028 [opensc-pkcs11] reader-pcsc.c:377:pcsc_detect_card_presence: returning with: 5
0xb73f3700 08:31:19.028 [opensc-pkcs11] card-starcos.c:1713:starcos_pin_cmd: returning with: -1408 (Not supported)
0xb73f3700 08:31:19.028 [opensc-pkcs11] sec.c:206:sc_pin_cmd: returning with: -1408 (Not supported)
0xb73f3700 08:31:19.130 [opensc-pkcs11] reader-pcsc.c:301:refresh_attributes: returning with: 0 (Success)
0xb73f3700 08:31:19.130 [opensc-pkcs11] reader-pcsc.c:377:pcsc_detect_card_presence: returning with: 5
0xb73f3700 08:31:19.130 [opensc-pkcs11] card-starcos.c:1713:starcos_pin_cmd: returning with: -1408 (Not supported)
0xb73f3700 08:31:19.130 [opensc-pkcs11] sec.c:206:sc_pin_cmd: returning with: -1408 (Not supported)
0xa80feb40 08:31:19.228 [opensc-pkcs11] reader-pcsc.c:1122:pcsc_detect_readers: returning with: 0 (Success)
0xa80feb40 08:31:19.228 [opensc-pkcs11] reader-pcsc.c:301:refresh_attributes: returning with: 0 (Success)
0xa80feb40 08:31:19.229 [opensc-pkcs11] reader-pcsc.c:377:pcsc_detect_card_presence: returning with: 5
0x9b8feb40 08:31:31.923 [opensc-pkcs11] card-starcos.c:621:starcos_select_file: called
0x9b8feb40 08:31:31.941 [opensc-pkcs11] card-starcos.c:472:starcos_select_aid: returning with: 0 (Success)
0x9b8feb40 08:31:31.942 [opensc-pkcs11] reader-pcsc.c:301:refresh_attributes: returning with: 0 (Success)
0x9b8feb40 08:31:31.942 [opensc-pkcs11] reader-pcsc.c:377:pcsc_detect_card_presence: returning with: 5
0x9b8feb40 08:31:38.724 [opensc-pkcs11] card-starcos.c:1713:starcos_pin_cmd: returning with: 0 (Success)
0x9b8feb40 08:31:38.724 [opensc-pkcs11] sec.c:206:sc_pin_cmd: returning with: 0 (Success)
0xa80feb40 08:31:38.732 [opensc-pkcs11] reader-pcsc.c:1122:pcsc_detect_readers: returning with: 0 (Success)
0xa80feb40 08:31:38.732 [opensc-pkcs11] reader-pcsc.c:301:refresh_attributes: returning with: 0 (Success)
0xa80feb40 08:31:38.732 [opensc-pkcs11] reader-pcsc.c:377:pcsc_detect_card_presence: returning with: 5
0xb73f3700 08:31:47.923 [opensc-pkcs11] ctx.c:799:sc_release_context: called