Precise Biometrics
2010-06-30 12:56:28 UTC
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
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,
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
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
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,
00 06 06 01 ...
But using Le=258 (258+2) = 260 (one more than CCID recieve buffer) you'll
get an error,
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.
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
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 = 0As 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,
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 = 000 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
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 = 0But 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
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 = 000 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 = 000 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 = 1783And 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.