Prev: DocumentEvent messages not being received on win64
Next: USB CDC ACM driver for windows XP,vista,7
From: Precise Biometrics on 30 Jun 2010 08:56
Problem Description
A customer of ours reported that their Card Management System (CMS) product,
does not work with Precise 250 MC reader (a combined fingerprint/smartcard
reader, see http://www.precisebiometrics.com/?id=2718&cid=2723 for details)
on the Windows Vista or Windows 7 platforms. The same product works on
Windows XP (since Precise Biometrics has developed own drivers for XP).

The CMS product is able to detect and identify the smart card. But when
trying to access the certificates and keys tab in the software, only
fragments of the data from the smart card is shown.

The smart card uses T=1 protocol. The Precise 250 MC uses APDU level of
exchange.


Analysis
The initial analysis was performed on Windows 7 which also showed the same
symptoms but in a different way, see the corresponding Vista analysis in the
end of the analysis description.

Traces on APDU command request and responses in the Precise 250 MC reader do
not show any errors or strange behavior. But further investigation has lead
us to focus on this APDU command which seems to fetch the certificate:

-> 80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 02 00
<- 0 6 6 1 1 8 9 0 0 0 0 4 0 0 0 0 0 1 0 0 1 1 0 2 0 0 1 0 0 3 ...

The response from this APDU command is 270 bytes as revealed by traces taken
from Precise 250 MC. Traces also show that the USB communication works as
expected. The host fetches all data.

When this command is issued from a simple smartcard test application the
result is:

> 80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 02 00
SCARD_S_SUCCESS: Received = 0 bytes, error code = 0

As we see there is no error indication but no data is actually returned. So
it appears that the message has been corrupted on the way, but as it turns
out it is the Microsoft CCID driver, usbccid.sys, that probably cannot handle
the CCID message since it is too large for the driver's receive buffer.

But first an experiment by modifying the APDU request length expected, Le,
value. Setting it to 257 will request a smaller chunk of data from the card:

> 80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 01 01
SCARD_S_SUCCESS: Received = 259 bytes, error code = 0
00 06 06 01 01 ....

With Le=257 we get 257+2=259 bytes result including the status code, and
this time we indeed get all requested data. As it turns out this is the
absolute limit on how much data can be handled. Le=258 does not work:

> 80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 01 02
SCARD_S_SUCCESS: Received = 0 bytes, error code = 0

But why can the driver handle 259 bytes, seems like an odd number? Larger
than a short APDU result (258 bytes) but not even close to handle a larger
sized extended APDU (65538 bytes).

Oddly as it seems the value 259 can be shown to be connected to the readers'
dwIFSD value. The IFSD value is used in the T=1 protocol and specifies how
much payload the card may send to the card in one T=1 packet. It does not
have anything to do with the CCID message sizes - but as we see it - it does
in this case.

The Precise 250 MC dwIFSD has the value of 254, not an uncommon value, the
largest possible value for the T=1 protocol. A T=1 packet has 3 bytes header
and up to 2 bytes CRC. And it just so happens that 254+5 = 259!

And it turns out that Microsoft CCID driver, usbccid.sys, actually uses the
dwIFSD value when allocating the receive buffer. This can be seen from the
result of the following experiment. The dwIFSD value in the Precise 250 MC
firmware is changed from 254 to 255 and the command that just failed is now
accepted:

> 80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 01 02
SCARD_S_SUCCESS: Received = 260 bytes, error code = 0
00 06 06 01 01 ....

Microsoft's own description of the CCID driver, usbccid.sys, is that it
works best in TPDU exchange mode, which means that it handles the T=1
protocol by itself. In this scenario the largest sized CCID message will
indeed be exactly the size allocated by the driver and work perfect and
handle any sized result.

Is the Microsoft CCID driver, usbccid.sys, using a too small receive buffer?
Well, the CCID specification includes the dwMaxCCIDMessageLength parameter.
It is a device property just like the dwIFSD. The Precise 250 MC reader has
it defined to 65550. This is a very large value when compared to any other
reader but still within the acceptable range as specified in the CCID
specification.

But what is the semantics of this property? It is clear that no CCID message
that is sent may be larger that this value. It can be showed that Microsoft
CCID driver, usbccid.sys, honors the dwMaxCCIDMessageLength in one case. If a
message is larger than this value it sends the data in two or more parts. But
more interestingly is that Microsoft CCID driver, usbccid.sys, does not split
an APDU into several request unless it is larger than dwMaxCCIDMessageLength.

But is a CCID driver required to support receiving dwMaxCCIDMessageLength
sized messages? We believe that the only possible conclusion is yes. There is
no other parameters or commands allowing the driver to lower the maximum
value, hence the maximum becomes the minimum size of the receive buffer -
otherwise the device has no clue what value it can use.

Eventhough the Microsoft CCID driver, usbccid.sys, does not support
receiving dwMaxCCIDMessageLength sized APDU responses it does support
receiving CCID Escape data of this size. This also suggest there is no
underlying issue behind not being able to do the same for APDU messages.

As conclusion means that the Microsoft CCID driver, usbccid.sys, is not
compliant to the specification and the consequence is that the Precise 250 MC
cannot be used to exchange extended APDUs with the smart card, which fails
the customer's CMS application and most likely any other application that
uses extended APDU responses. Since there is no clear error code in Windows 7
there may be very subtle errors and perhaps even data corruption.

As stated earlier the same problem exists in the Windows Vista environment
but with a small difference. While Windows 7 does not give an error code the
Vista version does give an error and after this the device is hung and must
be removed and inserted into the computer again to get it to work:

With Le=257 there is no problem,

>80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 01 01
SCARD_S_SUCCESS: Received 259 bytes, error code = 0
00 06 06 01 ...

But using Le=258 (258+2) = 260 (one more than CCID recieve buffer) you'll
get an error,

> 80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 01 02
UNKNOWN CODE: 0x6f7 (1783) Recived 65568 bytes, error code = 1783

And at this time the reader must be disconnected from the USB bus and
inserted again to get it to work again.

I hope the above analysis provides this forum with enough information. I'm
looking forward to hearing any comments about this matter.

From: Doron Holan [MSFT] on 30 Jun 2010 12:28
I think you need to open an incident with WDK support. IIRC, if this is a
bug in the microsoft stack, you will not be charged.

d

"Precise Biometrics" wrote in message
news:C4EE5B59-73BF-47AF-9B16-0DA371A43350(a)microsoft.com...

Problem Description
A customer of ours reported that their Card Management System (CMS) product,
does not work with Precise 250 MC reader (a combined fingerprint/smartcard
reader, see http://www.precisebiometrics.com/?id=2718&cid=2723 for details)
on the Windows Vista or Windows 7 platforms. The same product works on
Windows XP (since Precise Biometrics has developed own drivers for XP).

The CMS product is able to detect and identify the smart card. But when
trying to access the certificates and keys tab in the software, only
fragments of the data from the smart card is shown.

The smart card uses T=1 protocol. The Precise 250 MC uses APDU level of
exchange.


Analysis
The initial analysis was performed on Windows 7 which also showed the same
symptoms but in a different way, see the corresponding Vista analysis in the
end of the analysis description.

Traces on APDU command request and responses in the Precise 250 MC reader do
not show any errors or strange behavior. But further investigation has lead
us to focus on this APDU command which seems to fetch the certificate:

-> 80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 02 00
<- 0 6 6 1 1 8 9 0 0 0 0 4 0 0 0 0 0 1 0 0 1 1 0 2 0 0 1 0 0 3 ...

The response from this APDU command is 270 bytes as revealed by traces taken
from Precise 250 MC. Traces also show that the USB communication works as
expected. The host fetches all data.

When this command is issued from a simple smartcard test application the
result is:

> 80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 02 00
SCARD_S_SUCCESS: Received = 0 bytes, error code = 0

As we see there is no error indication but no data is actually returned. So
it appears that the message has been corrupted on the way, but as it turns
out it is the Microsoft CCID driver, usbccid.sys, that probably cannot
handle
the CCID message since it is too large for the driver's receive buffer.

But first an experiment by modifying the APDU request length expected, Le,
value. Setting it to 257 will request a smaller chunk of data from the card:

> 80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 01 01
SCARD_S_SUCCESS: Received = 259 bytes, error code = 0
00 06 06 01 01 ....

With Le=257 we get 257+2=259 bytes result including the status code, and
this time we indeed get all requested data. As it turns out this is the
absolute limit on how much data can be handled. Le=258 does not work:

> 80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 01 02
SCARD_S_SUCCESS: Received = 0 bytes, error code = 0

But why can the driver handle 259 bytes, seems like an odd number? Larger
than a short APDU result (258 bytes) but not even close to handle a larger
sized extended APDU (65538 bytes).

Oddly as it seems the value 259 can be shown to be connected to the readers'
dwIFSD value. The IFSD value is used in the T=1 protocol and specifies how
much payload the card may send to the card in one T=1 packet. It does not
have anything to do with the CCID message sizes - but as we see it - it does
in this case.

The Precise 250 MC dwIFSD has the value of 254, not an uncommon value, the
largest possible value for the T=1 protocol. A T=1 packet has 3 bytes header
and up to 2 bytes CRC. And it just so happens that 254+5 = 259!

And it turns out that Microsoft CCID driver, usbccid.sys, actually uses the
dwIFSD value when allocating the receive buffer. This can be seen from the
result of the following experiment. The dwIFSD value in the Precise 250 MC
firmware is changed from 254 to 255 and the command that just failed is now
accepted:

> 80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 01 02
SCARD_S_SUCCESS: Received = 260 bytes, error code = 0
00 06 06 01 01 ....

Microsoft's own description of the CCID driver, usbccid.sys, is that it
works best in TPDU exchange mode, which means that it handles the T=1
protocol by itself. In this scenario the largest sized CCID message will
indeed be exactly the size allocated by the driver and work perfect and
handle any sized result.

Is the Microsoft CCID driver, usbccid.sys, using a too small receive buffer?
Well, the CCID specification includes the dwMaxCCIDMessageLength parameter.
It is a device property just like the dwIFSD. The Precise 250 MC reader has
it defined to 65550. This is a very large value when compared to any other
reader but still within the acceptable range as specified in the CCID
specification.

But what is the semantics of this property? It is clear that no CCID message
that is sent may be larger that this value. It can be showed that Microsoft
CCID driver, usbccid.sys, honors the dwMaxCCIDMessageLength in one case. If
a
message is larger than this value it sends the data in two or more parts.
But
more interestingly is that Microsoft CCID driver, usbccid.sys, does not
split
an APDU into several request unless it is larger than
dwMaxCCIDMessageLength.

But is a CCID driver required to support receiving dwMaxCCIDMessageLength
sized messages? We believe that the only possible conclusion is yes. There
is
no other parameters or commands allowing the driver to lower the maximum
value, hence the maximum becomes the minimum size of the receive buffer -
otherwise the device has no clue what value it can use.

Eventhough the Microsoft CCID driver, usbccid.sys, does not support
receiving dwMaxCCIDMessageLength sized APDU responses it does support
receiving CCID Escape data of this size. This also suggest there is no
underlying issue behind not being able to do the same for APDU messages.

As conclusion means that the Microsoft CCID driver, usbccid.sys, is not
compliant to the specification and the consequence is that the Precise 250
MC
cannot be used to exchange extended APDUs with the smart card, which fails
the customer's CMS application and most likely any other application that
uses extended APDU responses. Since there is no clear error code in Windows
7
there may be very subtle errors and perhaps even data corruption.

As stated earlier the same problem exists in the Windows Vista environment
but with a small difference. While Windows 7 does not give an error code the
Vista version does give an error and after this the device is hung and must
be removed and inserted into the computer again to get it to work:

With Le=257 there is no problem,

>80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 01 01
SCARD_S_SUCCESS: Received 259 bytes, error code = 0
00 06 06 01 ...

But using Le=258 (258+2) = 260 (one more than CCID recieve buffer) you'll
get an error,

> 80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 01 02
UNKNOWN CODE: 0x6f7 (1783) Recived 65568 bytes, error code = 1783

And at this time the reader must be disconnected from the USB bus and
inserted again to get it to work again.

I hope the above analysis provides this forum with enough information. I'm
looking forward to hearing any comments about this matter.

From: Precise Biometrics on 1 Jul 2010 10:04
Ok, will do. Thanks for your reply.

"Doron Holan [MSFT]" wrote:

> I think you need to open an incident with WDK support. IIRC, if this is a
> bug in the microsoft stack, you will not be charged.
>
> d
>
> "Precise Biometrics" wrote in message
> news:C4EE5B59-73BF-47AF-9B16-0DA371A43350(a)microsoft.com...
>
> Problem Description
> A customer of ours reported that their Card Management System (CMS) product,
> does not work with Precise 250 MC reader (a combined fingerprint/smartcard
> reader, see http://www.precisebiometrics.com/?id=2718&cid=2723 for details)
> on the Windows Vista or Windows 7 platforms. The same product works on
> Windows XP (since Precise Biometrics has developed own drivers for XP).
>
> The CMS product is able to detect and identify the smart card. But when
> trying to access the certificates and keys tab in the software, only
> fragments of the data from the smart card is shown.
>
> The smart card uses T=1 protocol. The Precise 250 MC uses APDU level of
> exchange.
>
>
> Analysis
> The initial analysis was performed on Windows 7 which also showed the same
> symptoms but in a different way, see the corresponding Vista analysis in the
> end of the analysis description.
>
> Traces on APDU command request and responses in the Precise 250 MC reader do
> not show any errors or strange behavior. But further investigation has lead
> us to focus on this APDU command which seems to fetch the certificate:
>
> -> 80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 02 00
> <- 0 6 6 1 1 8 9 0 0 0 0 4 0 0 0 0 0 1 0 0 1 1 0 2 0 0 1 0 0 3 ...
>
> The response from this APDU command is 270 bytes as revealed by traces taken
> from Precise 250 MC. Traces also show that the USB communication works as
> expected. The host fetches all data.
>
> When this command is issued from a simple smartcard test application the
> result is:
>
> > 80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 02 00
> SCARD_S_SUCCESS: Received = 0 bytes, error code = 0
>
> As we see there is no error indication but no data is actually returned. So
> it appears that the message has been corrupted on the way, but as it turns
> out it is the Microsoft CCID driver, usbccid.sys, that probably cannot
> handle
> the CCID message since it is too large for the driver's receive buffer.
>
> But first an experiment by modifying the APDU request length expected, Le,
> value. Setting it to 257 will request a smaller chunk of data from the card:
>
> > 80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 01 01
> SCARD_S_SUCCESS: Received = 259 bytes, error code = 0
> 00 06 06 01 01 ....
>
> With Le=257 we get 257+2=259 bytes result including the status code, and
> this time we indeed get all requested data. As it turns out this is the
> absolute limit on how much data can be handled. Le=258 does not work:
>
> > 80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 01 02
> SCARD_S_SUCCESS: Received = 0 bytes, error code = 0
>
> But why can the driver handle 259 bytes, seems like an odd number? Larger
> than a short APDU result (258 bytes) but not even close to handle a larger
> sized extended APDU (65538 bytes).
>
> Oddly as it seems the value 259 can be shown to be connected to the readers'
> dwIFSD value. The IFSD value is used in the T=1 protocol and specifies how
> much payload the card may send to the card in one T=1 packet. It does not
> have anything to do with the CCID message sizes - but as we see it - it does
> in this case.
>
> The Precise 250 MC dwIFSD has the value of 254, not an uncommon value, the
> largest possible value for the T=1 protocol. A T=1 packet has 3 bytes header
> and up to 2 bytes CRC. And it just so happens that 254+5 = 259!
>
> And it turns out that Microsoft CCID driver, usbccid.sys, actually uses the
> dwIFSD value when allocating the receive buffer. This can be seen from the
> result of the following experiment. The dwIFSD value in the Precise 250 MC
> firmware is changed from 254 to 255 and the command that just failed is now
> accepted:
>
> > 80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 01 02
> SCARD_S_SUCCESS: Received = 260 bytes, error code = 0
> 00 06 06 01 01 ....
>
> Microsoft's own description of the CCID driver, usbccid.sys, is that it
> works best in TPDU exchange mode, which means that it handles the T=1
> protocol by itself. In this scenario the largest sized CCID message will
> indeed be exactly the size allocated by the driver and work perfect and
> handle any sized result.
>
> Is the Microsoft CCID driver, usbccid.sys, using a too small receive buffer?
> Well, the CCID specification includes the dwMaxCCIDMessageLength parameter.
> It is a device property just like the dwIFSD. The Precise 250 MC reader has
> it defined to 65550. This is a very large value when compared to any other
> reader but still within the acceptable range as specified in the CCID
> specification.
>
> But what is the semantics of this property? It is clear that no CCID message
> that is sent may be larger that this value. It can be showed that Microsoft
> CCID driver, usbccid.sys, honors the dwMaxCCIDMessageLength in one case. If
> a
> message is larger than this value it sends the data in two or more parts.
> But
> more interestingly is that Microsoft CCID driver, usbccid.sys, does not
> split
> an APDU into several request unless it is larger than
> dwMaxCCIDMessageLength.
>
> But is a CCID driver required to support receiving dwMaxCCIDMessageLength
> sized messages? We believe that the only possible conclusion is yes. There
> is
> no other parameters or commands allowing the driver to lower the maximum
> value, hence the maximum becomes the minimum size of the receive buffer -
> otherwise the device has no clue what value it can use.
>
> Eventhough the Microsoft CCID driver, usbccid.sys, does not support
> receiving dwMaxCCIDMessageLength sized APDU responses it does support
> receiving CCID Escape data of this size. This also suggest there is no
> underlying issue behind not being able to do the same for APDU messages.
>
> As conclusion means that the Microsoft CCID driver, usbccid.sys, is not
> compliant to the specification and the consequence is that the Precise 250
> MC
> cannot be used to exchange extended APDUs with the smart card, which fails
> the customer's CMS application and most likely any other application that
> uses extended APDU responses. Since there is no clear error code in Windows
> 7
> there may be very subtle errors and perhaps even data corruption.
>
> As stated earlier the same problem exists in the Windows Vista environment
> but with a small difference. While Windows 7 does not give an error code the
> Vista version does give an error and after this the device is hung and must
> be removed and inserted into the computer again to get it to work:
>
> With Le=257 there is no problem,
>
> >80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 01 01
> SCARD_S_SUCCESS: Received 259 bytes, error code = 0
> 00 06 06 01 ...
>
> But using Le=258 (258+2) = 260 (one more than CCID recieve buffer) you'll
> get an error,
>
> > 80 30 B0 00 00 00 0E 8A 81 06 41 54 48 45 4E 41 8B 81 02 06 01 01 02
> UNKNOWN CODE: 0x6f7 (1783) Recived 65568 bytes, error code = 1783
>
> And at this time the reader must be disconnected from the USB bus and
> inserted again to get it to work again.
>
> I hope the above analysis provides this forum with enough information. I'm
> looking forward to hearing any comments about this matter.
>
> .
>
 | 
Pages: 1
Prev: DocumentEvent messages not being received on win64
Next: USB CDC ACM driver for windows XP,vista,7