2010/7/29 Douglas E. Engert <[email protected]>:
> 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.
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.
> 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
I will try to implement that when time permits. Unless someone has a
better idea.
> 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 supgest 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
--
Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
[email protected]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
