2009/11/23 Martin Paljak <[email protected]>: > 2009/11/23 Ludovic Rousseau <[email protected]>: >> 2009/11/23 Martin Paljak <[email protected]>: >>> Out of the control codes supported by the CCID ifdhandler, it is somewhat >>> premature for these control codes (which, as I understand, do not result in >>> card communication, ever): >>> IOCTL_SMARTCARD_VENDOR_IFD_EXCHANGE and IOCTL_FEATURE_MCT_READERDIRECT (not >>> 100% sure as I have not implemented those) >>> CM_IOCTL_GET_FEATURE_REQUEST >>> IOCTL_FEATURE_IFD_PIN_PROPERTIES >>> >>> But valid for these (which will do card communication and where card events >>> make sense): >>> IOCTL_FEATURE_VERIFY_PIN_DIRECT >>> IOCTL_FEATURE_MODIFY_PIN_DIRECT >>> >>> As the card state is checked on pcsc-lite level, it is not OK or even >>> possible to check the semantics of the control codes. One way could be >>> postponing the check for reader event states after the ifdhandler returns >>> an error. >> >> You would then send a VERIFY_PIN command to a card that has been >> reseted or even changed? > > That would not be OK, as the card might be swapped to a hostile one. > That was the simplest solution I had in mind. > > >> >>> So both return codes are valid from SCardControl, but returned at bad >>> times, IMO? I could write a patch for this, if this solution is OK. >> >> What is the problem to have RFCheckReaderEventState() in all cases? >> Does the problem happen in practice? > > The problem lies with mostly SCARD_SHARE_DIRECT mode, which explicitly > talks to the reader, not to the card. I made some tests with a pyscard > test application, based on the sample_pinpad.py script, which is also > attached. > > Here are the results: > > Windows: > c:\build>c:\Python25\python.exe scardcontrol.py > Context established! > PCSC Readers: ['OMNIKEY CardMan 3821 0'] > Trying to Control reader: OMNIKEY CardMan 3821 0 > Enter card and press enter > > Connected with active protocol 0 > Remove card and press enter > > [6, 4, 0, 49, 48, 12, 7, 4, 0, 49, 48, 16, 10, 4, 0, 49, 48, 8] > can do verify pin: 0x0031300C > [6, 4, 0, 49, 48, 12, 7, 4, 0, 49, 48, 16, 10, 4, 0, 49, 48, 8] > can do modify pin: 0x00313010 > Disconnected > Released context. > press Enter to continue > > on Linux: > > $ python scardcontrol_direct.py > Context established! > PCSC Readers: ['OmniKey CardMan 3821 00 00'] > Trying to Control reader: OmniKey CardMan 3821 00 00 > Enter card and press enter > > Connected with active protocol 0 > Remove card and press enter > > Disconnected > <class 'scard.error'> SCardControl failed: Card was removed. > Released context.
I can reproduce the problem on Linux and also on Mac OS X (10.6) (after patching the code to use SCARD_PROTOCOL_T0 | SCARD_PROTOCOL_T1 instead of 0). I do not have the problem when I do not insert any card at all. So yes pcsc-lite should be corrected. > So the behavior is different. On Linux I even managed to get a "Card > was reset" from the same test case if Firefox was running. > > So at least direct mode should be fixed (can send a patch). Yes, please send a patch. > I could not test with any other reader under Windows if the behaviour > is uniformly applied on winscard level or it depends on the reader > driver, but IMHO, even if the card is removed, those SCardControl > commands that do not talk to the card itself could succeed if the card > is removed in SCARD_SHARING_SHARE mode. The behaviour of different > Windows drivers should be tested to see how it works. You should be able to test even without a pinpad reader. > The problem occurred with stress-testing OpenSC when I discovered that > extensive "playing with the card" (inserting and removing) resulted in > some missing pinpad feature detections. The detection logic goes like > this: try to connect with direct mode, if it fails with a sharing > violation, try to connect in shared mode with any protocol" and then > use SCardControl to detect features. Instead of receiving a valid SCardControl return buffer OpenSC gets an error so the pinpad feature is disabled. I see the problem now. Under Windows, is it possible to send a PIN_VERIFY command using SCardControl in SCARD_SHARE_DIRECT and with _no_ card inserted in the reader? What happens then? And what happens if the card has been removed and inserted? Bye -- Dr. Ludovic Rousseau _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
