State of stateless support

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

State of stateless support

Martin Vogt

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: State of stateless support

Frank Morgner
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 <[hidden email]>:

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

--
Frank Morgner
------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: State of stateless support

Martin Vogt

On Thu, Nov 12, 2015 at 11:47 AM, Frank Morgner <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: State of stateless support

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 <[hidden email] <mailto:[hidden email]>> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: State of stateless support

Frank Morgner
In reply to this post by Martin Vogt
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 <
> [hidden email]> 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

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

attachment0 (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: State of stateless support

Martin Vogt
In reply to this post by Douglas E Engert


On Thu, Nov 12, 2015 at 5:38 PM, Douglas E Engert <[hidden email]> 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




------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: State of stateless support

David Woodhouse
In reply to this post by Frank Morgner
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
[hidden email]                              Intel Corporation


------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: State of stateless support

Alon Bar-Lev
On 13 November 2015 at 13:06, David Woodhouse <[hidden email]> 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

------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: State of stateless support

David Woodhouse
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
[hidden email]                              Intel Corporation


------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: State of stateless support

Martin Vogt

Hello all,

On Fri, Nov 13, 2015 at 12:29 PM, Alon Bar-Lev <[hidden email]> 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 <[hidden email]> 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



------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: State of stateless support

Alon Bar-Lev
On 13 November 2015 at 14:59, Martin Vogt <[hidden email]> 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

------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: State of session locking support

Frank Morgner
In reply to this post by Douglas E Engert
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 <[hidden email] <mailto:[hidden email]>> 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
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/opensc-devel
> >
>
> --
>
>   Douglas E. Engert  <[hidden email]>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

attachment0 (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: State of session locking support

Douglas E Engert
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 <[hidden email] <mailto:[hidden email]>> 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
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>
>>
>> --
>>
>>    Douglas E. Engert  <[hidden email]>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Opensc-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: State of session locking support

Alon Bar-Lev
On 13 November 2015 at 15:22, Douglas E Engert <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>
>>>
>>> --
>>>
>>>    Douglas E. Engert  <[hidden email]>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Opensc-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>
>>
>
> --
>
>   Douglas E. Engert  <[hidden email]>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel

------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: State of session locking support

Martin Vogt
In reply to this post by Frank Morgner


On Fri, Nov 13, 2015 at 2:07 PM, Frank Morgner <[hidden email]> 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 <[hidden email]> 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.)





------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: State of session locking support

Douglas E Engert
In reply to this post by Alon Bar-Lev


On 11/13/2015 7:38 AM, Alon Bar-Lev wrote:
> On 13 November 2015 at 15:22, Douglas E Engert <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>
>>>>
>>>> --
>>>>
>>>>     Douglas E. Engert  <[hidden email]>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Opensc-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>
>>>
>>
>> --
>>
>>    Douglas E. Engert  <[hidden email]>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Opensc-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: State of session locking support

Alon Bar-Lev
On 13 November 2015 at 16:51, Douglas E Engert <[hidden email]> wrote:

>
>
> On 11/13/2015 7:38 AM, Alon Bar-Lev wrote:
>>
>> On 13 November 2015 at 15:22, Douglas E Engert <[hidden email]> 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
>>>>>> <[hidden email] <mailto:[hidden email]>>
>>>>>> 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
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>     Douglas E. Engert  <[hidden email]>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> Opensc-devel mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>
>>>>
>>>
>>> --
>>>
>>>    Douglas E. Engert  <[hidden email]>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Opensc-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>>
>
> --
>
>  Douglas E. Engert  <[hidden email]>
>

------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: State of stateless support

NdK-3
In reply to this post by Martin Vogt
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


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: State of stateless support

NdK-3
In reply to this post by Frank Morgner
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


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: State of session locking support

Frank Morgner
In reply to this post by Frank Morgner
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 <[hidden email] <mailto:[hidden email]>> 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
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/opensc-devel
> > >
> >
> > --
> >
> >   Douglas E. Engert  <[hidden email]>
> >
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Opensc-devel mailing list
> > [hidden email]
> > 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

attachment0 (985 bytes) Download Attachment
12