exclusive vs. shared smart card access

[Thomas Duboucher]

Hi all,


First of all, sorry if this response seems confuse as I will try to
answer several things at once. :)


Currently, exclusive access is not considered as a good practice; If the
application that requests exclusive access hang, then the users is
required to cold reset the smartcard, i.e. remove it, in order to use it
again. Shared access is the de-facto way to go.

Even then, exclusive access does not solve everything. Before closing
the channel, the application should also reset PIN states, for instance
by issuing a warm reset. If the application is closed before, then any
other application connecting to the card will have the PIN already verified.


A few weeks ago there was a short discussion on Twitter concerning usage
of PGPCard over NFC in a smartphone and Yubikey setup. The raised issue
was the PIN in the VERIFY PIN command is sent in cleartext over a radio
channel.

The common pattern here is how can we prove knowledge of a PIN over an
unreliable network without requiring to authenticating first with e.g.
an asymmetric scheme using public certification authority?

One of the answer is the PACE key agreement protocol. This protocol
provides mutual proof of a knowledge of a low entropy secret, e.g. a
PIN, during agreement of a strong high entropy secret. It is
already commonly used in smartcard applications such as passports.


PACE is described in:
 - Technical Guideline TR-03111, Elliptic Curve Cryptography, Version
2.0[TR3111], for an introduction of PACE over elliptic curves
 - Supplemental Access Control for Machine Readable Travel Documents
Version 1.01[SAC], for an introduction of PACE for smartcards
Additionally:
 - ISO/IEC 7816-4, for a description of GENERAL AUTHENTICATE


I started drafting a proposal to add PACE support as an optional
replacement for PIN in PGPCard. However, I still have a few questions to
answer before:
 - PACE is *mostly* patent-unencumbered and I still have to sort this out.
 - I am not sure yet if my company would agree me working during my
spare time on the specification of another smartcard application.


Please, feel free to comment on this. I'll give more details tomorrow if
you are interested or have questions on the subject.


Regards,


[TR3111]
https://www.bsi.bund.de/cae/servlet/contentblob/471398/publicationFile/30615/BSI-TR-03111_pdf.pdf
[SAC]
http://www.icao.int/security/mrtd/downloads/technical%20reports/technical%20report.pdf

Le 01/09/2015 10:48, Achim Pietig a écrit :
> 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

-- 
Thomas Duboucher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150902/3af803bd/attachment-0001.sig>