Hello, I would like to introduce the ability to perform a "secure PIN management" in my CCID driver (and also in pcsc-lite).
A secure PIN management can be used when the smart card reader has a keypad or keyboard. You enter the PIN on the keyboard of the reader and the PIN is sent directly to the card without going to the PC host. So a malicious software on the PC will not get the PIN. We (the Muscle community) already had a discussion [1] on this subject but without real conclusion. In particular we did not choose a specific tag for IFDGetCapabilities to indicate the support of the Secure PIN feature by the reader/driver. One solution seems to use the CT-BCS [2] standard. I could use that and transform a CT-BCS command in the CCID PC_to_RDR_Secure command for a CCID reader. The CCID PC_to_RDR_Secure has more features so we would loose possibilities in the transformation. My proposition is to use SCardControl() (I don't think we have another choice here) to transport a CCID PC_to_RDR_Secure data structure from the application to the driver. This structure is defined in the CCID specification [3] on page 40. It is composed of: - bBWI: Used to extend the CCIDs Block Waiting Timeout for this current transfer. - wLevelParameter: Use changes depending on the exchange level reported by CCID in the functional descriptor - bPINOperation: Used to indicate the PIN operation: - abPINDataStructure: PIN Verification Data Structure The PIN Verification Data Structure is: - bTimeOut: Number of seconds. - bmFormatString: Several parameters for the PIN format options - bmPINBlockString: Defines the length in bytes of the PIN block to present in the APDU command - bmPINLengthFormat: Allows the insertion of the PIN length in the APDU command - wPINMaxExtraDigit: Minimum/Maximun PIN size in digit - bEntryValidationCondition: - bNumberMessage: Number of messages to display for the PIN Verification management. - wLangId: Language used to display the messages. - bMsgIndex: Message index in the Reader CCID message table - bTeoPrologue: T=1 I-block prologue field to use. - abData: APDU to send to the ICC We do not have to change anything in pcsc-lite since pcsc-lite would just be transparent. We should just document this but... Under Windows the SCardControl interface is different [5] and, I think, more clean since a dwControlCode is used to indicate the operation to perform instead of just bufferIn and bufferOut in pcsc-lite. When I talked about this difference [4] and asked for comment I only received an answer from Damien Sauveron indicated that pcsc-lite should align with Microsoft PC/SC and I agree with this. If you have arguments against this change please tell us. We then need a way for the application to know if the reader has this "secure PIN management" feature. The PC/SC specification defines (in part 3, page 7) a tag value (0x0142) for "User Authentication Input Device". Value 0x00000002 is for "Numeric (that is PIN) pad" and value 0x00000004 is for "keyboard". Of course I don't know which one to use :-) I think 0x00000002 is the correct choice. These tags are defined for IFDHGetCapabilities between the driver and the middleware (pcscd). Part 5 of PC/SC specification defines (page 26) GetReaderCapabilities and SetReaderCapabilities for the applications but these functions are not present in Microsoft PC/SC implementation (they should be called SCardGetReaderCapabilities and SCardSetReaderCapabilities). Maybe this will be implemented in future Microsoft implementation (possibly with PC/SC version 2.0). Maybe we should go ahead of Microsoft and implement it in pcsc-lite. So I plan to: - modify SCardControl to match Microsoft interface. I will change the library major version since this modifies the API and ABI. You will need to recompile to use (link to) the new lib. - implement SCardGetReaderCapabilities/SCardSetReaderCapabilities in pcsc-lite - Select an arbitrary tag value for SCardControl to indicate it is a "secure PIN management" command. We can have one tag value for the CCID way and another tag value for the CT-BCS way. Only the application and the driver need to be in sync, no impact on pcsc-lite (except documentation in an appendix of pcsc-lite doc). My preference is 0x42000001. 0x42 [6] may be a pcsc-lite prefix. I would like you to: - comment on the proposals above Regards, [1] http://archives.neohapsis.com/archives/dev/muscle/2004-q1/0152.html [2] http://www.linuxnet.com/documentation/files/ctbcs.html [3] http://www.usb.org/developers/devclass_docs/ccid_classspec_1_00a.pdf [4] http://archives.neohapsis.com/archives/dev/muscle/2003-q4/0178.html [5] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/scardcontrol.asp [6] http://en.wikipedia.org/wiki/The_Answer_to_Life,_the_Universe,_and_Everything -- Dr. Ludovic Rousseau [EMAIL PROTECTED] -- Normaliser Unix c'est comme pasteuriser le camembert, L.R. -- _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
