opensc-devel

[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] 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

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

[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

[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

[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

[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

[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 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] 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 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

[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

[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 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 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

[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

[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...>]

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

[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

[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 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...>]

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

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

My contribution: how Windows is sharing cards between applications

You have one service whose call is to manage the card driver. It is the
endpoint for the PCSC API (scardsrv)
Then each application can use the smartcard. They lock the card before
doing authentication, do some authenticated things, then unlock the card.
(the card is locked for a maximum of a few seconds).

The PIN is cached into the "driver" (CSP) when it is know to work. For
pinpad, the card is supposed to ask for a session pin which is reused for
the next authentication.

When you are asking to select a certificate then sign some code, you have :
- lock
get all certificates
- unlock
show all certificate and the user pick one
ask for pin
- lock
try the pin
-unlock
put it in cache
-lock
authenticate with the previous pin
sign
-unlock & reset

=> no pin share / state between applications

But there are caches at many level (public key, certificates, ...)
1) Inside the CSP (current process)
2) At the smart card service level (SCardReadCache)

Because there is a lot of reset, Windows recommend to implement a
deauthentication APDU (for example verify with FF as described in the
latest iso 7816-4)

What can be done in OpenSC is to have a function "restarting" the card
after a reset (for example select the applet), an optional deauthentication
function (by default a reset) and to mimic the lock / unlock behavior of
Windows

regards,
Vincent

2015-11-16 9:31 GMT+01:00 Frank Morgner <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
>
>
> ------------------------------------------------------------------------------
> 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
>
>


-- 
--
Vincent Le Toux

My Smart Logon
www.mysmartlogon.com

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

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

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!

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 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
>
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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...>]

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.

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.

regards,

Martin