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