EstEID: match card only based on presence of application.

[martinpaljak]

Contact cards have ATR-s, contactless not. Only contact
cards should be broken enough so that they answer 0x9000 to application
selection, so this should be failsafe.

This allows to work with an EstEID card over contactless interface.

[CardContact]

Actually contactless cards have an ATR, at least a synthetic ATR generated by PC/SC from the ATS. See PC/SC Part 3, chapter 3.1.3.2.3.

Sending SELECT(AID) to probe for a card type may lead to problems with cards that have a secure messaging channel established. It's much safer to compile a list of candidates based on the ATR and then do the probing.

[martinpaljak]

Not really.

1. It is already a common practice in OpenSC (starting from as ancient as muscle driver or see PIV for example). Changing the order in the detected drivers list might be necessary as well, so that ATR-only cards would be before "AID-detect drivers", thanks for noticing that.
2. The issue of stateless access has been discussed ad infinitum in the context of OpenSC and "the one right path to implement". If you establish a "stream oriented" secure channel to a card, you'd better make sure the access is exclusive (SCardBeginTransaction) or do it on a separate channel (I don't know how this plays up with standards and actual card implementations, but this should be an option). For a fresh "card" detection (that have no established session in the context of this application) probing for application identifiers should be an (or only?) acceptable solution. While OpenSC caters for a "multiple cards on a single system and single application" some kind of common sense and probability theory needs to be applied. Most of the time it is a single card with a single active application (both on the card and on the host) and the behaviour of OpenSC should be tuned for that. The likelihood of different national eID-s for example is not a very common thing but a national ID card + OpenPGP card might be a very popular combination.
3. The "magic" of ATR detection is broken as soon as you have multiple applications on the card. The mentioned card (more precisely, a application system) has both EstEID and OpenPGP apps. In theory the GlobalPlatform default selected capability should dictate which gets selected, in practice this is cumbersome (pkcs15-tool now has --aid but what about PKCS#11 or other interfaces). But this should be definitely thought about, indeed.
4. One specific use case I have is emulating an EstEID card through Android 4.4 Host Card Emulation. The same problem described in point 3 applies. The only controllable thing is the application AID and I have no idea nor capability to test how this looks with different phones (and/or different applications)

[martinpaljak]

I'll just leave here for the reference how it looks like:

$ opensc-tool -lv
# Detected readers (pcsc)
Nr.  Card  Features  Name
0    Yes             Gemalto Prox Dual USB PC LinkReader 00 00
     3b:80:80:01:01 MICARDO 2.1 / EstEID 1.0 - 3.0 
1    No              Gemalto Prox Dual USB PC LinkReader 00 01

http:https://smartcard-atr.appspot.com/parse?ATR=3b80800101

[viktorTarasov]

Thanks,
applied in 8d00077.