exclusive vs. shared smart card access

[Achim Pietig]

Hi all,

as Andreas told the most secure way to communicate with a smart card is a secure channel, several wide spread cards like GeldKarte or eGK (health card) in Germany work with that.
But these card systems work with x.509-certificates and the cards have an inbuilt root-certificate and accept only certificates from the same authority - at the begining of a communication a secure
messaging channel is established from the pub keys of both partners, resulting in AES session keys.

In the OpenPGP world we do not have such an authority, the OpenPGP card allows secure messaging with a closed symmetric scheme - that is designed for companies, universities etc.
But it will not help here because there is no way to store the needed secret in the PC of the user - it will work only with HSMs or severs.
I think other protocols have the same problem - where can we store the secrets for the communication channel?

For that reason it is important to have exclusive access to the card if a security condition like password is fulfilled.
At the end of a session a card should be powered down so that it looses all internal access states.

It will be helpful if scdaemon can release the card including power down by a special command that can be used from other applications.
Or the user can define a timeout (e. g. in gpg.conf) after that the card is released if he works with several independant card tools at the same PC.

Regards
Achim



Am 01.09.2015 um 10:06 schrieb NIIBE Yutaka:
> On 09/01/2015 04:38 PM, Andreas Schwier wrote:
>> Sharing a card is O.K while the PIN is not authenticated. Once the PIN
>> is authenticated, an application should have exclusive access.
>>
>> However this period should be as short as possible and an application
>> must release exclusive access either explicitly by user request or time-out.
> 
> Thank you for the clarification.  I understand well.  I'll
> try to improve scdaemon following this practice.
> 
> The situation of OpenPGPcard is that, (when it is configured as
> not-forcing PIN authentication for every signing request,) the period
> is forever currently.
>