On 7/29/2010 3:41 PM, Ludovic Rousseau wrote: > 2010/7/29 Douglas E. Engert<deeng...@anl.gov>: >> Today I sent a message to the Muscle list, that said: >> >>> The situation I was running into is with the ccid-1.3.13/src/commands.c >>> The SecurePINVerify routine takes a TxBuffer described in PCSC part10 >>> section >>> 2.5.2 PIN_VERIFY. Section 2.5.1 say the structures in section 2.5 will be: >>> "Byte ordering is decided by machine architecture". The routine then copies >>> parts of the PIN_VERIFY to what USB CCID describes in section 6.1.11.2 "PIN >>> Verification Data Structure" This needs to use little endian. No conversion >>> from machine to CCID ordering is done during the copy. >>> >>> The problem is the SecurePINVerify is expecting the caller to provide the >>> wPINMaxExtraDigit, wLangid and ulDataLength in little endian. >>> >>> The way I read pcsc part 10 is that wPINMaxExtraDigit, wLangid and >>> ulDataLength >>> and any other USHORT or ULONG in any of the structures in 2.5 should be >>> passed >>> in machine order, and the SecurePINVerify while copying these fields should >>> do >>> the byte ordering conversion. The caller to SecurePINVerify should not be >>> doing this. >>> >>> The way I ran into this is the OpenSC was not doing the conversion >>> correctly, >>> (and it should not have had to do it at all.) This situation only fails on >>> big >>> endian machine trying to use a PIN Pad reader. >> >> So I think the problem is in both the CCID and OpenSC. The ulDataLength >> and the wPINMaxExtraDigit and wLangId should all be in host byte order. > > The bytes order has changed "many" times in the PCSCv2 part 10 specification. > The only driver I know that can support both SecurePIN and big endian > machine is my own CCID driver. So I decided to define the convention > myself.
I was not aware of the history, that explains a lot. It is also a lessen to OpenSC that it should be using the PCSC reader.h, and not copy parts of reader.h to the OpenSC internal-reader.h. There was a similar problem recently where the PCSC specs dropped two fields from one structure. (Or PCSC needs to have the pin structures in a separate hearer file, like readerpin.h that could be included in reader.h and in internal-reader.h.) > > The PCSC workgroup is doing really stupid things. The first stupid > thing is to do NO public review before publishing a specification. And > since they are all Windows guys they think (mostly) Windows and Intel > only. That explains even more! > >> OpenSC should not be using the HOST_TO_CCID at all, >> and the SecurePINVerify routing should be converting the fields as they >> are copied to the cmd[] to be sent. > > Maybe the CCID driver should try to guess the byte order so that any > order with work. It should be easy since we have: > uint32_t ulDataLength; /**< length of Data to be sent to the ICC */ > I would be very surprised to have ulDataLength> 0x10000 > Yes, or test for TxLength = ulDataLength + sizeof(PIN_VERIFY_STRUCTURE) trying both ways. > I will try to implement that when time permits. Unless someone has a > better idea. I am on vacation next week but can look at this some more when I get back. > > >> The issue was the OpenSC code did not use the PCSC/readeri.h, but >> used the OpenSC internal-reader.h where it just defined >> >> #define HOST_TO_CCID_16(x) (x) >> #define HOST_TO_CCID_32(x) (x) > > Yes. That was a bad idea. > >> But as I suggest above, if the conversion should be done in CCID, then >> HOST_TO_* are not needed in any application including OpenSC. > > Exact. See my point above. > > Bye > Thanks. -- Douglas E. Engert <deeng...@anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
