opensc-devel

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

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

https://github.com/OpenSC/OpenSC/pull/618 appear to address the issues from a PKCS#11
perspective, but it is not clear how they would work with a pin pad reader.

I have been taking a different approach, by trying to recognize if the state of the card has been
modified by some other application, before trying to login again. Thus to would work better with
a pin pad and could possibly allow the card to be logged in across multiple applications.
(opensc.conf disconnect_action = leave)

These two approaches could coexist, and be controllable via opensc.conf.

There are still some issues with my code, that could be a problem for #618.
Another application (call it B) could steal the card while our application (call it A) is in card_match or card_init.
Error recovery in this area is not handled well.

It appears that PCSC may return too soon after a card_reset done by (B) and pcsc_lock is released
but the reset is still active in the reader. (A) gets control sees that SCARD_W_RESET_CARD was returned
tries do a transmit and ends up in reader-pcsc.c here:

266                 /* unable to transmit ... most likely a reader problem */
267                 sc_debug(reader->ctx, SC_LOG_DEBUG_NORMAL, "unable to transmit");
I have not found the solution for this yet. I think it is problem in PCSC.


The simple way to test is to start FireFox (A) go to preferences->Advanced->view Certificates
This should prompt from the PIN, then show the certificates.

To steal the card opensc-tool cab be used as application (B). In another window:
opensc-tool -a
If opensc.conf has disconnect_action = reset;  this will cause a card_reset
and get FireFox (A) to have to recover from this.

To test with disconnect_action = leave;  this will switch the AID to the global platform
AID and my PIV card has both AIDs.
opensc-tool -s 00:A4:04:00:07:a0:00:00:01:51:00:00
I am still looking at the reset problem, but need to address this.

Error handling in OpenSC is too distributed across all layers, and PCSC will only
return to the next SCARD command SCARD_W_RESET_CARD  to (A) to indicate (B) has done a reset.

This will most likely be from the SCardBeginTranaction initiated from sc_lock.

I am still working on this, as it includes C_GetSessionInfo doing a sc_pkcs15_check_state
that gets the latest state of the card, and also tries to chenc the AID and login state
as reported be the card using a VERIFY class 1 APDU.

On 11/26/2015 8:21 AM, Frank Morgner wrote:
> I withdrew my original PR to create a new one:
>
>
>
> Please check if it fits your needs of statelessness!
>
> Am 15. November 2015 00:49:35 MEZ, schrieb Frank Morgner <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 Firefox9. 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 operati! on 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 so! me 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 d! river 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

-- 

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

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

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

Am Freitag, dem 27. November, um 14:48 Uhr schrieb Martin Vogt:
> Hello,
> 
> On Thu, Nov 26, 2015 at 3:21 PM, Frank Morgner <
> mo...@in...> wrote:
> 
> > I withdrew my original PR to create a new one:
> > https://github.com/OpenSC/OpenSC/pull/618
> > Please check if it fits your needs of statelessness!
> >
> 
> I looked at the patch/source, but I cannot test.
> The Problem is, my StarCos 3.2 card currently does not
> work with the D-Trust starcos 3.4 driver.

PRs are welcome ;-)

> I would have expected a different handling, with
> callback functions on the card driver level ,eg:
> 
> // callbacks into card plugins.
> 
> typedef void* sc_card_state_t;
> 
> sc_card_state_t* card_alloc_state();
> card_free_state(sc_card_state_t* sc_card_state);
> 
> int card_save_state(void** ptr);
> int card_restore_state(void* ptr);
> 
> Where the driver can store "what is needed" for this card.
> The pkcs11 layer then have to keep track for the slot<->void pointer, with
> a hash.
> 
> If a card supports auth cookies, it can do that in the void pointer, or if
> not
> it can store the directory/pin.
> This means the pkcs11 layer does not know about: "struct sc_pkcs11_login",
> but only
> manages a dummy typedef.

As far as I can see, all operations to use a card's key in C_Sign, for
example, is carried out automatically (except the login): select
application, set security environment, ... What should be the content of
some sc_card_state_t?

What are "auth cookies" and where are they stored/generated?

-- 
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 session locking support

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

Hello,


On Fri, Nov 27, 2015 at 5:08 PM, Frank Morgner <
mo...@in...> wrote:

> Am Freitag, dem 27. November, um 14:48 Uhr schrieb Martin Vogt:
> > I looked at the patch/source, but I cannot test.
> > The Problem is, my StarCos 3.2 card currently does not
> > work with the D-Trust starcos 3.4 driver.
>
> PRs are welcome ;-)
>

I will see ;-). The ATR/Pin encoding patches are easy, but the testsuite
is not working.



>
>
> > typedef void* sc_card_state_t;
> >
>
> As far as I can see, all operations to use a card's key in C_Sign, for
> example, is carried out automatically (except the login): select
> application, set security environment, ... What should be the content of
> some sc_card_state_t?
>

This depends on the card. I would say that for starcos 3.x its the
directory path
and the password, this should work.

Thus:

typedef struct sc_starcos_card_state_s {
  char* path;
  char* password;
  int pass_encoding;
} sc_startcos_card_state_t;


I don't have that much experience in OpenSC, this was only a guess
how it could be done.
And if some cards have different needs, like these "auth cookies",
it can be handles in the card driver.



>
> What are "auth cookies" and where are they stored/generated?
>

it was mentioned in this thread, but I never used it.

> On Fri, Nov 13, 2015 at 2:38 PM, Alon Bar-Lev <alo...@gm...>
wrote:
>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.


regards,

Martin

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

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

Hi!

>  https://github.com/OpenSC/OpenSC/pull/618 appear to address the issues from 
>  a PKCS#11
>  perspective, but it is not clear how they would work with a pin pad reader.

With forced PIN-pad usage it doesn't work. But to be clear: This problem
can't be solved with a PIN-pad reader regardless of the approach taken.

>  I have been taking a different approach, by trying to recognize if the state 
>  of the card has been
>  modified by some other application, before trying to login again. Thus to 
>  would work better with
>  a pin pad and could possibly allow the card to be logged in across multiple 
>  applications.
>  (opensc.conf disconnect_action = leave)
> 
>  These two approaches could coexist, and be controllable via opensc.conf.
> 
>  There are still some issues with my code, that could be a problem for #618.
>  Another application (call it B) could steal the card while our application 
>  (call it A) is in card_match or card_init.
>  Error recovery in this area is not handled well.
> 
>  It appears that PCSC may return too soon after a card_reset done by (B) and 
>  pcsc_lock is released
>  but the reset is still active in the reader. (A) gets control sees that 
>  SCARD_W_RESET_CARD was returned
>  tries do a transmit and ends up in reader-pcsc.c here:
> 
>  266                 /* unable to transmit ... most likely a reader problem 
>  */
>  267                 sc_debug(reader->ctx, SC_LOG_DEBUG_NORMAL, "unable to 
>  transmit");
>  I have not found the solution for this yet. I think it is problem in PCSC.
> 
> 
>  The simple way to test is to start FireFox (A) go to 
>  preferences->Advanced->view Certificates
>  This should prompt from the PIN, then show the certificates.
> 
>  To steal the card opensc-tool cab be used as application (B). In another 
>  window:
>  opensc-tool -a
>  If opensc.conf has disconnect_action = reset;  this will cause a card_reset
>  and get FireFox (A) to have to recover from this.
> 
>  To test with disconnect_action = leave;  this will switch the AID to the 
>  global platform
>  AID and my PIV card has both AIDs.
>  opensc-tool -s 00:A4:04:00:07:a0:00:00:01:51:00:00
>  I am still looking at the reset problem, but need to address this.
> 
>  Error handling in OpenSC is too distributed across all layers, and PCSC will 
>  only
>  return to the next SCARD command SCARD_W_RESET_CARD  to (A) to indicate (B) 
>  has done a reset.
> 
>  This will most likely be from the SCardBeginTranaction initiated from 
>  sc_lock.
> 
>  I am still working on this, as it includes C_GetSessionInfo doing a 
>  sc_pkcs15_check_state
>  that gets the latest state of the card, and also tries to chenc the AID and 
>  login state
>  as reported be the card using a VERIFY class 1 APDU.

I highly doubt that it is possible to *reliably* detecting a
modification/usage of the card's state by an other application. If this
detection mechanism does not work 100% then your card is open for
misusage by other applications.

The only solution I see is to always save and restore the complete state
of the card. And, seen from a PKCS#11 perspective, the only volatile
state is whether some user is logged in or not (correct me if I'm
wrong). Validating the PIN on a PIN-pad always modifies the card's
state, that's why the state *must* be restored by entering the PIN on
the PIN-Pad again and again and again for every transaction. Thus,
solving this problem with a PIN-pad reader is either really really
annoying or simply impossible.

Why solve this problem on the PKCS#11 level? This only needs to be
solved in PKCS#11; tokend and minidriver have their OS-builtin
mechanisms for avoiding interfering applications.

>  On 11/26/2015 8:21 AM, Frank Morgner wrote:
> > I withdrew my original PR to create a new one:
> >
> >
> >
> > Please check if it fits your needs of statelessness!
> >
> > Am 15. November 2015 00:49:35 MEZ, schrieb Frank Morgner 
> > <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 Firefox9. 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 operati! on 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 so! me 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 d! river 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
> 
>  -- 
> 
>   Douglas E. Engert  <DEE...@gm...>
> 

-- 
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 session locking support

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

On 11/27/2015 10:44 AM, Frank Morgner wrote:
> Hi!
>
>>   https://github.com/OpenSC/OpenSC/pull/618 appear to address the issues from
>>   a PKCS#11
>>   perspective, but it is not clear how they would work with a pin pad reader.
>
> With forced PIN-pad usage it doesn't work. But to be clear: This problem
> can't be solved with a PIN-pad reader regardless of the approach taken.

I agree. If the card is reset or or has lost its login state, then the pin
must be sent to the card.

But I am also looking for at what happens if the card's login state is preserved
across applications and disconnect_action = leave; is set. (And other applications
like Java based may still reset the card.)

(And yes I know this could be a security risk if any of the
user's other applications can access the card, and if the OS or PCSC is not
restricting access to the reader from processes of other users.
These would be addressed later.)

>
>>   I have been taking a different approach, by trying to recognize if the state
>>   of the card has been
>>   modified by some other application, before trying to login again. Thus to
>>   would work better with
>>   a pin pad and could possibly allow the card to be logged in across multiple
>>   applications.
>>   (opensc.conf disconnect_action = leave)
>>
>>   These two approaches could coexist, and be controllable via opensc.conf.
>>
>>   There are still some issues with my code, that could be a problem for #618.
>>   Another application (call it B) could steal the card while our application
>>   (call it A) is in card_match or card_init.
>>   Error recovery in this area is not handled well.
>>
>>   It appears that PCSC may return too soon after a card_reset done by (B) and
>>   pcsc_lock is released
>>   but the reset is still active in the reader. (A) gets control sees that
>>   SCARD_W_RESET_CARD was returned
>>   tries do a transmit and ends up in reader-pcsc.c here:
>>
>>   266                 /* unable to transmit ... most likely a reader problem
>>   */
>>   267                 sc_debug(reader->ctx, SC_LOG_DEBUG_NORMAL, "unable to
>>   transmit");
>>   I have not found the solution for this yet. I think it is problem in PCSC.
>>
>>
>>   The simple way to test is to start FireFox (A) go to
>>   preferences->Advanced->view Certificates
>>   This should prompt from the PIN, then show the certificates.
>>
>>   To steal the card opensc-tool cab be used as application (B). In another
>>   window:
>>   opensc-tool -a
>>   If opensc.conf has disconnect_action = reset;  this will cause a card_reset
>>   and get FireFox (A) to have to recover from this.
>>
>>   To test with disconnect_action = leave;  this will switch the AID to the
>>   global platform
>>   AID and my PIV card has both AIDs.
>>   opensc-tool -s 00:A4:04:00:07:a0:00:00:01:51:00:00
>>   I am still looking at the reset problem, but need to address this.
>>
>>   Error handling in OpenSC is too distributed across all layers, and PCSC will
>>   only
>>   return to the next SCARD command SCARD_W_RESET_CARD  to (A) to indicate (B)
>>   has done a reset.
>>
>>   This will most likely be from the SCardBeginTranaction initiated from
>>   sc_lock.
>>
>>   I am still working on this, as it includes C_GetSessionInfo doing a
>>   sc_pkcs15_check_state
>>   that gets the latest state of the card, and also tries to chenc the AID and
>>   login state
>>   as reported be the card using a VERIFY class 1 APDU.
>
> I highly doubt that it is possible to *reliably* detecting a
> modification/usage of the card's state by an other application. If this
> detection mechanism does not work 100% then your card is open for
> misusage by other applications.

We are back to what does the user want? enter pin for every application,
where each application may cache it. It also depends on the card. If
the card is writable, and if SM must be reestablished (with or without a PIN.)

I am looking for one login for all the user's applications.
The PIV may be capable of this, and is not writable by a user,
and user_consent/CKA_ALWAYS_AUTHENTICATE is enforced for the signing key,
but not the Authentication key. So for signing the user will have to enter
the PIN.)

>
> The only solution I see is to always save and restore the complete state
> of the card. And, seen from a PKCS#11 perspective, the only volatile
> state is whether some user is logged in or not (correct me if I'm
> wrong).

Card could have multiple applets (AIDs), like the Neo with OpenPGP and PIV
applets. Or official gov issued cards with CAC and PIV applets.
PIV specs say login state of PIV applet must be reset if other AID is selected.


> Validating the PIN on a PIN-pad always modifies the card's
> state, that's why the state *must* be restored by entering the PIN on
> the PIN-Pad again and again and again for every transaction. Thus,
> solving this problem with a PIN-pad reader is either really really
> annoying or simply impossible.

Some card issuers may set policy the pin pad reader is required. Yes
it is ugly.

>
> Why solve this problem on the PKCS#11 level? This only needs to be
> solved in PKCS#11; tokend and minidriver have their OS-builtin
> mechanisms for avoiding interfering applications.
>
>>   On 11/26/2015 8:21 AM, Frank Morgner wrote:
>>> I withdrew my original PR to create a new one:
>>>
>>>
>>>
>>> Please check if it fits your needs of statelessness!
>>>
>>> Am 15. November 2015 00:49:35 MEZ, schrieb Frank Morgner
>>> <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 Firefox9. 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 operati! on 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 so! me 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 d! river 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
>>
>>   --
>>
>>    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...>]

Hi!

> > > typedef void* sc_card_state_t;
> > >
> >
> > As far as I can see, all operations to use a card's key in C_Sign, for
> > example, is carried out automatically (except the login): select
> > application, set security environment, ... What should be the content of
> > some sc_card_state_t?
> >
> 
> This depends on the card. I would say that for starcos 3.x its the
> directory path
> and the password, this should work.
> 
> Thus:
> 
> typedef struct sc_starcos_card_state_s {
>   char* path;
>   char* password;
>   int pass_encoding;
> } sc_startcos_card_state_t;
> 
> 
> I don't have that much experience in OpenSC, this was only a guess
> how it could be done.
> And if some cards have different needs, like these "auth cookies",
> it can be handles in the card driver.
> 
> 
> 
> >
> > What are "auth cookies" and where are they stored/generated?
> >
> 
> it was mentioned in this thread, but I never used it.
> 
> > On Fri, Nov 13, 2015 at 2:38 PM, Alon Bar-Lev <alo...@gm...>
> wrote:
> >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.

Well, whatever authentication cookies are, no card driver in OpenSC
implements them. Also, what you outlined above for Starcos is exactly
what I implemented on the PKCS#11 level.

-- 
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 session locking support

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

In response to https://github.com/OpenSC/OpenSC/issues/596


Please have a look at https://github.com/OpenSC/OpenSC/pull/624

This tries to have C_GetSessionInfo do what it should do,that is determine
the state of the card right now by querying PCSC and doing a operations to the card
to check it state.

Have tested with FireFox with card_disconnect = reset; and card_disconnect = leave;
I have not tried adding sc_pkcs15_pincache_revalidate to sc_pkcs15_check_state yet.

In reader-pcsc.c: pcsc_lock if SCARD_W_RESET was returned, a sleep(1) was added.


-- 

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