Problems comunicating with windows ccid driver.

Hello,

I’m developing a USB smart card device conforming to the 1.1 CCID specification, and I’m having some problems making the device work with the windows usbccid.sys driver.

I have a sample application on top of the driver that allows me to interact with a smart card device (send, get, reset commands).

This is the ATR that I return on power on:

0x3f, 0xfc, 0x13, 0x25, 0x02, 0x50, 0x00, 0x0f, 0x33, 0xb0, 0x08, 0xff, 0xff, 0x4a, 0x50, 0x90, 0x00, 0x00, 0x49, 0x4f.

And the CCID descriptor:

length = 0x36;
descriptor_type = 0x21;
release_number = 0x0100;
max_slot_index = 0;
voltage_support = 0x01;
protocols = 0x00000001;
default_clock = 0x000012c0;
maximum_clock = 0x000012c0;
num_clock_supported = 0x00;
data_rate = 0x00002580;
max_data_rate = 0x00002580;
num_data_rate_supported = 0x00;
max_ifsd = 0x000000FE;
sync_protocols = 0x00000000;
mechanical = 0;
desc->features = 0x0000003e;
(AUTOMATIC_PARAMETER_CONFIG
AUTOMATIC_ACTIVATION_ICC_ON_INSERTING
AUTOMATIC_ICC_VOLTAGE_SELECTION
AUTOMATIC_ICC_CLOCK_FREQ
AUTOMATIC_BAUD_RATE )

max_ccid_message_length = 0x0000010f;
class_get_response = 0xff;
class_envelope = 0xff;
lcd_layout = 0;
pin_support = 0;
max_ccid_busy_slots = 1;

When the device is attached, it gets power off, power on, to which I reply with the above ATR, Set parameters (11, 00, 02, 0f, 00) which I return, and set freq and baud rate with the only values that I specified in the descriptor, which I also return.

Now I can connect to the device with the sample application. I’m getting the ATR and the card status (inserted/not inserted), but as I try any command, I’m getting errors:

This is what I get when trying the send command : 48 72 00 00 01 data: aa

USB bus: The out transfer (xfer_block)is successful.
Then I’m getting the token from the host for the in transfer (data_block with data 90 00), and the device sends the data (which is correct), Now the host should ack the transfer (a USB ack), which it never does.

I’m getting the following errors in the event viewer:

Event
Type : Error
Source: USBCCID
Category: None
Event ID: 0

Description:
The description for Event ID ( 0 ) in Source ( USBCCID ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: , IOCTL TRANSMIT failed with status 0xc0000001.

Data:
0000: 00 00 00 00 02 00 58 00 …X.
0008: 00 00 00 00 00 00 00 00 …
0010: 00 00 00 00 00 00 00 00 …
0018: 00 00 00 00 00 00 00 00 …
0020: 00 00 00 00 00 00 00 00 …

Event
Type: Error
Source: SCardSvr
Category: None
Event ID: 610

Description:
Smart Card Reader ‘Card 0’ rejected IOCTL TRANSMIT: A device attached to the system is not functioning.

I have another smart card, which is working fine with the driver, and the sample application. I’ve tried to emulate the exact same USB bus transfers with my device, but the windows driver sends me different set parameters command, and my reply does not satisfy it, and after 3 retries it stops trying and I cant connect to the device with the sample app. It seems that when I specify different baud rate and clock frequency, the windows driver is not happy with my reply to set parameters.
Can the windows class driver detect baud rate/clock frequency of the device over the USB?

I’m guessing that there are some inconsistencies with the ATR and/or ccid descriptor that I specify, that the windows driver finds not to its liking.

I have tried a different driver for ccid (Omnikey cardman), and by emulating the usb transfers of the Omnikey reader, I was able to use my device to send and get data.

I’m hoping that someone has some clue to the reason I’m getting errors from the usbccid driver.

Thanks,
Tamir.

Sorry, off topic, but I see your from Jungo…

Could you explain a little about your companies product here… I’ve seen it
before, just never used it.

Further, I’ve have seen it mentioned here quite a few times, but every time
it is mentioned it seems
no one knows anything about it.

What are the benifits of it, and why would anyone here want to use it?
(sorry, don’t mean to sound
jerkish there).

I would love to hear about it, as I’m sure most people in this group
would…

Regards,

Matt

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Monday, January 07, 2008 7:25 AM
Subject: [ntdev] Problems comunicating with windows ccid driver.

> Hello,
>
> I’m developing a USB smart card device conforming to the 1.1 CCID
> specification, and I’m having some problems making the device work with
> the windows usbccid.sys driver.
>
> I have a sample application on top of the driver that allows me to
> interact with a smart card device (send, get, reset commands).
>
> This is the ATR that I return on power on:
>
> 0x3f, 0xfc, 0x13, 0x25, 0x02, 0x50, 0x00, 0x0f, 0x33, 0xb0, 0x08,
> 0xff, 0xff, 0x4a, 0x50, 0x90, 0x00, 0x00, 0x49, 0x4f.
>
> And the CCID descriptor:
>
> length = 0x36;
> descriptor_type = 0x21;
> release_number = 0x0100;
> max_slot_index = 0;
> voltage_support = 0x01;
> protocols = 0x00000001;
> default_clock = 0x000012c0;
> maximum_clock = 0x000012c0;
> num_clock_supported = 0x00;
> data_rate = 0x00002580;
> max_data_rate = 0x00002580;
> num_data_rate_supported = 0x00;
> max_ifsd = 0x000000FE;
> sync_protocols = 0x00000000;
> mechanical = 0;
> desc->features = 0x0000003e;
> (AUTOMATIC_PARAMETER_CONFIG
> AUTOMATIC_ACTIVATION_ICC_ON_INSERTING
> AUTOMATIC_ICC_VOLTAGE_SELECTION
> AUTOMATIC_ICC_CLOCK_FREQ
> AUTOMATIC_BAUD_RATE )
>
> max_ccid_message_length = 0x0000010f;
> class_get_response = 0xff;
> class_envelope = 0xff;
> lcd_layout = 0;
> pin_support = 0;
> max_ccid_busy_slots = 1;
>
> When the device is attached, it gets power off, power on, to which I reply
> with the above ATR, Set parameters (11, 00, 02, 0f, 00) which I return,
> and set freq and baud rate with the only values that I specified in the
> descriptor, which I also return.
>
> Now I can connect to the device with the sample application. I’m getting
> the ATR and the card status (inserted/not inserted), but as I try any
> command, I’m getting errors:
>
> This is what I get when trying the send command : 48 72 00 00 01 data: aa
>
> USB bus: The out transfer (xfer_block)is successful.
> Then I’m getting the token from the host for the in transfer (data_block
> with data 90 00), and the device sends the data (which is correct), Now
> the host should ack the transfer (a USB ack), which it never does.
>
> I’m getting the following errors in the event viewer:
>
> Event
> Type : Error
> Source: USBCCID
> Category: None
> Event ID: 0
>
> Description:
> The description for Event ID ( 0 ) in Source ( USBCCID ) cannot be found.
> The local computer may not have the necessary registry information or
> message DLL files to display messages from a remote computer. You may be
> able to use the /AUXSOURCE= flag to retrieve this description; see Help
> and Support for details. The following information is part of the event: ,
> IOCTL TRANSMIT failed with status 0xc0000001.
>
> Data:
> 0000: 00 00 00 00 02 00 58 00 …X.
> 0008: 00 00 00 00 00 00 00 00 …
> 0010: 00 00 00 00 00 00 00 00 …
> 0018: 00 00 00 00 00 00 00 00 …
> 0020: 00 00 00 00 00 00 00 00 …
>
>
> Event
> Type: Error
> Source: SCardSvr
> Category: None
> Event ID: 610
>
> Description:
> Smart Card Reader ‘Card 0’ rejected IOCTL TRANSMIT: A device attached to
> the system is not functioning.
>
> I have another smart card, which is working fine with the driver, and the
> sample application. I’ve tried to emulate the exact same USB bus transfers
> with my device, but the windows driver sends me different set parameters
> command, and my reply does not satisfy it, and after 3 retries it stops
> trying and I cant connect to the device with the sample app. It seems that
> when I specify different baud rate and clock frequency, the windows driver
> is not happy with my reply to set parameters.
> Can the windows class driver detect baud rate/clock frequency of the
> device over the USB?
>
> I’m guessing that there are some inconsistencies with the ATR and/or ccid
> descriptor that I specify, that the windows driver finds not to its
> liking.
>
> I have tried a different driver for ccid (Omnikey cardman), and by
> emulating the usb transfers of the Omnikey reader, I was able to use my
> device to send and get data.
>
> I’m hoping that someone has some clue to the reason I’m getting errors
> from the usbccid driver.
>
> Thanks,
> Tamir.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Hello Matt,

I’m not sure that this is appropriate place to advertise our products. With a permission of the moderators we can provide a brief description of what Jungo has to offer.
In any case you are welcome to contact jacob at jungo dot com, that will be glad to assist you.

Best Regards,
Ilya Lifshits.


R&D Manager, Connectivity Software Division
Jungo Software Technologies

Maybe these clarifying questions will get more replies:

  1. Is there a a checked version of the ccid class driver for windows xp? And if so, where can I get it?
  2. Is there another way to get more output from the driver? Some logs that I’m not aware of?

Thanks,
Tamir.

xxxxx@jungo.com wrote:
> I have another smart card, which is working fine with the driver,
> and the sample application.

What is the ATR of the working card?

If it works with another card it may be useful to check the card
differences, too (ATR, convention, PPS, card responses, etc.).

[…] trying the send command : 48 72 00 00 01 data: aa

If you can, intercept the communication between smart card and reader
and compare the response to your APDUs. (If possible, post them.)

Useful link for ATR analysis (preview page from the Rankl/Effing “Smart
Card Handbook”, ch. 6.2.1 “ATR characters”):
http://books.google.com/books?id=Oi85gPhUFx4C&printsec=frontcover#PRA1-PA381,M1

-H

Hagen:
I’m working with a development board. There is no actual smart card/reader there. I’m emulating all smart card functionality via software. I took the ATR from a working smart card I have. All transfers that go on the USB bus are exactly the same on the working smart card, and my board, excluding the following: 1. The EP0 size is different (my board in 64byte, whereas the smart card’s is 8byte). This is fixed, depending on the usb controller.
2. After power on/power off, The windows driver sends set parameters command with different values. bmFindexDindex is 0x11 on my board, and 0x13 on the smart card. (baud rate conversion factor differs.)
I don’t think that EP0 size should matter to the windows driver, as this is a low level USB parameter, and should be invisible to a class driver.
But I’m bewildered by the ability of the class driver to detect differences between the 2 hardwares.
Do transfer timings play a roll here? Is my board sending some response to early/late?

Thanks,
Tamir.

xxxxx@jungo.com wrote:

I’m working with a development board. There is no actual smart card/reader there.

Ah! Now I know what you mean by “USB smart card device” - I had to read
up on USB CCID.

Hmm… as I see it, you have to choose your requested ATR FI/DI values
in a way that the clock frequency/baud rate values for your CCID (CAD -
Card Acceptance Device) are met.

Your (simulated) smart card ATR states:
0x13, TA1: FI=1 (372) DI=3 (4) -> div = 372/4 = 93 clocks per etu/bit

Your CCID descriptor states:
default_clock = 0x000012c0; // = 4800kHz
maximum_clock = 0x000012c0; // = 4800kHz
num_clock_supported = 0x00;
data_rate = 0x00002580; // = 9600baud
max_data_rate = 0x00002580;

Clock = 4.8MHz, Baud rate = 9600.
This would require an ETU divider of 500, but your card requests a
maximum of 93. This won’t work.

E.g. you could set the default clock to 9600 * (372 / 4) = 892.800Hz =
ca. 892kHz.
Or you could set TA1 to 0x11 and select the default clock to be 9600 *
372 = 3571.200Hz = ca. 3570kHz.

Or choose a different TA1 combination altogether, and adapt baud rate
and clock values accordingly.

My assumption is that usbccid.sys does some sanity checking, and if the
FI/DI values reported in the ATR can not be met by your CCID descriptor
clock/baud rate it just reports a failure. Seems reasonable.

But I’m bewildered by the ability of the class driver to detect
> differences between the 2 hardwares.
Do transfer timings play a roll here?

The class driver can (and probably does) compare the requested ETU value
from the smart card ATR to the available clock/baud values in your CCID
descriptor. If the values supported by your (virtual) card reader would
be too fast for the (virtual) smart card, it has to reject the device
and report a failure – because with a real smart card no communication
would be possible with these parameters.

Luckily you do emulate everything and therefore have full control over
ATR and you CCID descriptor. :slight_smile:

Hope it helps,
-H

Hagen,

Thanks! After changing the clock frequency, I can connect to the windows driver with my sample application and send/get data.
For some reason it works only when I specify only one baud rate and clock frequency. Any more then that (and the automatic baud rate/clock frequency detection feature on), and the windows driver fails. But at least I have a working use case to build on.

Regards,
Tamir.