OS X Yosemite bug: SCardTransmit (pioSendPci not checked)

This is part of the series: "OS X Yosemite and smart cards: known bugs".

SCardTransmit

SCardTransmit() fails to detect wrong value for pioSendPci parameter.

If you use NULL for pioSendPci parameter then you get a crash (Segmentation fault: 11) of the application instead of getting the error 0x80100004 that is SCARD_E_INVALID_PARAMETER.

See also

Apple bug report #19231406 "PC/SC function SCardTransmit: pioSendPci not checked".

Sample code

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#ifdef __APPLE__
#include <PCSC/winscard.h>
#include <PCSC/wintypes.h>
#else
#include <winscard.h>
#endif

int main(int argc, const char * argv[]) {
    SCARDCONTEXT hContext;
    LPSTR mszReaders;
    DWORD err = SCardEstablishContext(SCARD_SCOPE_SYSTEM, NULL, NULL, &hContext);
    if (err != SCARD_S_SUCCESS) {
        printf("ScardEstablishedContext : %08x\n",err);
  return -1;
    }

 DWORD cchReaders = 0;
 err = SCardListReaders(hContext, "SCard$AllReaders", NULL, &cchReaders);
 if (err != 0) {
  printf("ScardListReaders : %08x\n",err);
  return -1;
 }
 mszReaders = calloc(cchReaders, sizeof(char));
 if (!mszReaders) {
  printf("calloc\n");
  return -1;
 }
 err = SCardListReaders(hContext,"SCard$AllReaders", mszReaders, &cchReaders);
 if (err != SCARD_S_SUCCESS) {
  printf("ScardListReaders : %08x\n",err);
  return -1;
 }

 printf("Reader : %s\n", mszReaders);

 SCARDHANDLE hCard;
 DWORD dwActiveProtocol;
 err = SCardConnect(hContext, mszReaders, SCARD_SHARE_SHARED, SCARD_PROTOCOL_T0 | SCARD_PROTOCOL_T1, &hCard, &dwActiveProtocol);
 unsigned char cmd[] = {0, 0, 0, 0, 0};
 unsigned char resp[255];
 DWORD resp_len = sizeof resp;

 err = SCardTransmit(hCard, NULL, cmd, sizeof cmd, NULL, resp, &resp_len);
 if (err != SCARD_S_SUCCESS) {
  printf("ScardTransmit : %08x\n",err);
  return -1;
 }

 SCardDisconnect(hCard, SCARD_LEAVE_CARD);
 SCardReleaseContext(hContext);

    return 0;
}

Result (on Yosemite)

$ CFLAGS="-framework PCSC" make main 
cc -framework PCSC    main.c   -o main

$ ./main
Reader : Gemalto PC Twin Reader
Segmentation fault: 11

$ lldb ./main
(lldb) target create "./main"
Current executable set to './main' (x86_64).
(lldb) r
Process 6169 launched: './main' (x86_64)
Reader : Gemalto PC Twin Reader
Process 6169 stopped
* thread #1: tid = 0x7472a, 0x0000000100004b6d PCSC`__SCardTransmit_block_invoke + 17, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x0000000100004b6d PCSC`__SCardTransmit_block_invoke + 17
PCSC`__SCardTransmit_block_invoke + 17:
-> 0x100004b6d:  movl   (%rax), %edx
   0x100004b6f:  leaq   0x6901(%rip), %rsi        ; "proto"
   0x100004b76:  movq   %r14, %rdi
   0x100004b79:  callq  0x10000b0c2               ; symbol stub for: xpc_dictionary_set_uint64

Expected result (on Debian)

CFLAGS=`pkg-config --cflags libpcsclite` LDFLAGS=`pkg-config --libs libpcsclite` make main

$ ./main
Reader : Gemalto PC Twin Reader (70D7E2EE) 00 00
ScardTransmit : 80100004

Known workaround

Do not use NULL for pioSendPci. It is a wrong value.

Update

This bug is now fixed in Mac OS X El Capitan 10.11.0.

OS X Yosemite and smart cards: known bugs

Yosemite: OS X 10.10

Yosemite contains a rewrite of pcsc-lite. See "OS X Yosemite and smart cards status". The problem is that the rewrite introduced (many) bugs.

Bug list

I will list known (by me) bugs and will try to maintain the list in the future if/when the bugs are fixed.

  1. SCardDisconnect

Fixed in OS X 10.10.2

  1. SCardReconnect(..., SCARD_RESET_CARD, ...)
  2. SCardBeginTransaction() after a card reset
  3. SCardStatus() after a card reset
  4. SCardStatus returns SCARD_E_INSUFFICIENT_BUFFER
  5. SCARD_E_PROTO_MISMATCH not returned
  6. T=0 is used instead of T=1 on dual protocol cards

Fixed in OS X 10.10.3

  1. SCardTransmit returns SCARD_W_UNPOWERED_CARD

Fixed in El Capitan 10.11.0

  1. SCardGetAttrib
  2. SCardTransmit (pioSendPci not checked)
  3. SCardGetStatusChange blocks forever
  4. OS X Yosemite bug: SCardConnect blocks in SCARD_SHARE_SHARED mode

Bugs that will not be fixed

  1. PC/SC functions crash after a fork(2)

Conclusion

I hope the bugs will be fixed during Yosemite lifetime. But I am afraid it will not happen before the next major version of OS X (OS X 10.11) is out.

This reminds me when Mac OS X 10.5 Leopard has been released in 2007 with lots of important bugs like ATR corruption. At that time it was also a major deviation from pcsc-lite. See "Evolution of Apple pcsc-lite (from Jaguar to Mavericks)".

OS X Yosemite bug: SCardGetAttrib

This is part of the series: "OS X Yosemite and smart cards: known bugs".

SCardGetAttrib

SCardGetAttrib() do not work any more on Yosemite.

The function returns with 8010000c that is SCARD_F_INTERNAL_ERROR.

See also

"Problem With SCardGetAttrib on Mac OS X 10.10 (Yosemite)" at https://smartcardservices.macosforge.org/trac/ticket/139.

Apple bug report #19231112 "PC/SC function SCardGetAttrib is broken on Yosemite".
#19231112 closed as duplicate of #16366962.

Sample code

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#ifdef __APPLE__
#include <PCSC/winscard.h>
#include <PCSC/wintypes.h>
#else
#include <winscard.h>
#endif

#define SCARD_ATTR_VALUE(Class, Tag) ((((ULONG)(Class)) << 16) | ((ULONG)(Tag)))
#define SCARD_CLASS_ICC_STATE       9   /**< ICC State specific definitions */
#define SCARD_ATTR_ATR_STRING SCARD_ATTR_VALUE(SCARD_CLASS_ICC_STATE, 0x0303) /**< Answer to reset (ATR) string. */

int main(int argc, const char * argv[]) {
    SCARDCONTEXT hContext;
    LPSTR mszReaders;
    DWORD err = SCardEstablishContext(SCARD_SCOPE_SYSTEM, NULL, NULL, &hContext);
    if (err != SCARD_S_SUCCESS) {
        printf("ScardEstablishedContext : %08x\n",err);
    } else {
        DWORD cchReaders = 0;
        err = SCardListReaders(hContext, "SCard$AllReaders", NULL, &cchReaders);
        if (err != 0) {
            printf("ScardListReaders : %08x\n",err);
            return -1;
        }
        mszReaders = calloc(cchReaders, sizeof(char));
        if (!mszReaders) {
            printf("calloc\n");
            return -1;
        }
        err = SCardListReaders(hContext,"SCard$AllReaders", mszReaders, &cchReaders);
        if (err != SCARD_S_SUCCESS) {
            printf("ScardListReaders : %08x\n",err);
            return -1;
        }

        printf("Reader : %s\n", mszReaders);

        SCARDHANDLE hCard;
        DWORD dwActiveProtocol;
        err = SCardConnect(hContext, mszReaders, SCARD_SHARE_SHARED, SCARD_PROTOCOL_RAW, &hCard, &dwActiveProtocol);
        if (err != SCARD_S_SUCCESS) {
            printf("ScardConnect : %08x\n",err);
        } else {
            DWORD dwAtrLen = 32;
            err = SCardGetAttrib(hCard, SCARD_ATTR_ATR_STRING, NULL, &dwAtrLen);
            printf("ATR LENGTH : %1d\n", dwAtrLen);
            if (err != SCARD_S_SUCCESS) {
                printf("SCardGetAttrib : %08x\n",err);
            } else {
                printf("ATR LENGTH %d\n", dwAtrLen);
                SCardDisconnect(hCard, SCARD_LEAVE_CARD);
                SCardReleaseContext(hContext);
            }
        }
    }
    return 0;
}

Result (on Yosemite)

$ CFLAGS="-framework PCSC" make main
cc -framework PCSC    main.c   -o main

$ ./main
Reader : Gemalto PC Twin Reader
ATR LENGTH : 32
SCardGetAttrib : 80100001

Expected result (on Debian)

$ CFLAGS=`pkg-config --cflags libpcsclite` LDFLAGS=`pkg-config --libs libpcsclite` make main
cc -pthread -I/usr/include/PCSC    -lpcsclite    main.c   -o main

$ ./main
Reader : Gemalto PC Twin Reader (70D7E2EE) 00 00
ATR LENGTH : 20
ATR LENGTH 20

Known workaround

None known.

Update

This bug is now fixed in Mac OS X El Capitan 10.11.0.

PCSC sample in Python using python-pcsclite

Here is a new PCSC sample in Python language for the series PC/SC sample in different languages.

I already presented, pyscard, a Python wrapper in "PCSC sample in Python". This wrapper is a different implementation and API.

Installation

The installation is easy on a Debian system. A .deb package is provided (but the project is not part of Debian).
Or you can rebuild the software from the source code. The current version is 0.13.

The web site is http://python-pcsclite.sourceforge.net/. The license is GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

Source code

#!/usr/bin/env python

import pcsclite
import binascii

SELECT = "\x00\xA4\x04\x00\x0A\xA0\x00\x00\x00\x62\x03\x01\x0C\x06\x01"
COMMAND = "\x00\x00\x00\x00"

try:
    context = pcsclite.Context()
    readers = context.list_readers()
    print "PCSC readers:", readers
    reader = readers[0]
    print "Using reader:", reader

    card = context.connect(reader)

    data = card.transmit(SELECT)
    print binascii.b2a_hex(data)

    data = card.transmit(COMMAND)
    print data
    print binascii.b2a_hex(data)

    card.disconnect()

    del card
    del context

except Exception, message:
    print "Exception:", message

Output

$ ./sample_pcsclite.py 
PCSC readers: ('Gemalto PC Twin Reader 00 00',)
Using reader: Gemalto PC Twin Reader 00 00
9000
Hello world!?
48656c6c6f20776f726c64219000

Comments

The python-pcsclite project started in 2007 according to the ChangeLog.txt file. I discovered the project only very recently and open some bugs to make it build on my Debian system. Russell Stuart, the maintainer, was very fast to fix the issues.

Compared to pyscard

python-pcsclite does not build on Mac OS X (see bug #5). I guess it also does not build on Windows but I have not tested it myself. So if you want a Python wrapper for GNU/Linux, Mac OS X and Windows you should use pyscard instead.

python-pcsclite may provide good ideas that I could reuse in pyscard :-)

As for pyscard, Python3 is not yet supported.

History

The python-pcsclite project started in 2007. At the same time the pyscard project is made public (according to the dates in the subversion repository but I guess the pyscard project was already developed since some time).

According to the python-pcsclite web site:
The obvious question is why use python-pcsclite instead of the official one. Python-pcsclite is a fairly direct implementation of C API provided by pcsclite, so direct the documentation for pcsclite applies to python-pcsclite. Pyscard on the other hand builds on pcsclite to provide it's own abstractions. I suspect the choice is more a matter of taste, and being an old C programmer I prefer the directness of the C API, which python-pcsclite emulates.
You have the freedom to select the wrapper you want to use. Compare the sample code above with the 2 examples at my previous article PCSC sample in Python to select the implementation you prefer.

Conclusion

I have not seen any advertising of this project on the Muscle mailing list. The project works fine (as far as I tested) and may benefit to be used by more users.

CCID descriptor statistics: completed!

The previous article "CCID descriptor statistics: dwFeatures" was the last of a series of 35 blog articles about CCID descriptor statistics. I started this series in April 2013 (19 months ago). It was not supposed to take so long to complete the series and study each and every field in a CCID USB structure.

Performance

I originally did plan to write one article per week (or one per day?). So I should have finished after only 9 months. My real "performance" is one blog article every 2.2 week. Not too bad after all.

My main problem is the lack of free time. I still have many ideas of blog articles but not enough free time and motivation to write them.

Evolution

When I started this work in April 2013 only 262 readers where present in my list. 19 months later there are 322 readers. That is 60 or 23% more readers.

All the numbers are from the initial 262 readers. I don't think that the 60 new readers would have significantly change of the results.

Support

If you want to support me work and encourage me please consider donations. See "How to help my projects? Send me bitcoins!". Thanks.

CCID descriptor statistics: dwFeatures

Article from the serie "CCID descriptor statistics".

The dwFeatures field is a number value from the CCID USB descriptor:

This value indicates what intelligent features the CCID has. The value is a bitwise OR operation performed on the following values:
  • 00000000h No special characteristics
  • 00000002h Automatic parameter configuration based on ATR data
  • 00000004h Automatic activation of ICC on inserting
  • 00000008h Automatic ICC voltage selection
  • 00000010h Automatic ICC clock frequency change according to active parameters provided by the Host or self determined
  • 00000020h Automatic baud rate change according to active parameters provided by the Host or self determined
  • 00000040h Automatic parameters negotiation made by the CCID (use of warm or cold resets or PPS according to a manufacturer proprietary algorithm to select the communication parameters with the ICC)
  • 00000080h Automatic PPS made by the CCID according to the active parameters
  • 00000100h CCID can set ICC in clock stop mode
  • 00000200h NAD value other than 00 accepted (T=1 protocol in use)
  • 00000400h Automatic IFSD exchange as first exchange (T=1 protocol in use)
Only one of the following values may be present to select a level of exchange:
  • 00010000h TPDU level exchanges with CCID
  • 00020000h Short APDU level exchange with CCID
  • 00040000h Short and Extended APDU level exchange with CCID
  • If none of those values is indicated the level of exchange is character.
Only one of the values 00000040h and 00000080h may be present. When value 00000040h is present the host shall not try to change the FI, DI, and protocol currently selected.

When an APDU level for exchanges is selected, one of the values 00000040h or 00000080h must be present, as well as the value 00000002h.

To support selective suspend:
  • 00100000h USB Wake up signaling supported on card insertion and removal
When bit 20th, as shown above, is set bit D5 in bmAttributes of the Standard Configuration Descriptor must be set to 1.

dwFeatures # %
0x00010230 36 14.17 %
0x000100BA 27 10.63 %
0x00020840 20 7.87 %
0x000207B2 19 7.48 %
0x00010030 18 7.09 %
0x000204BA 11 4.33 %
0x0002047E 10 3.94 %
0x000404B2 10 3.94 %
0x000406BA 10 3.94 %
0x000404BE 9 3.54 %
0x000404BA 8 3.15 %
0x000204BE 6 2.36 %
0x00010330 5 1.97 %
0x00040042 5 1.97 %
0x000101BA 4 1.57 %
0x000102BA 4 1.57 %
0x00000840 3 1.18 %
0x000100B6 3 1.18 %
0x00020472 3 1.18 %
0x000400FE 3 1.18 %
0x00000030 2 0.79 %
0x0001007A 2 0.79 %
0x00010200 2 0.79 %
0x0001023C 2 0.79 %
0x00020040 2 0.79 %
0x00020672 2 0.79 %
0x000206BA 2 0.79 %
0x0004047E 2 0.79 %
0x000404B0 2 0.79 %
0x000004B2 1 0.39 %
0x00010000 1 0.39 %
0x00010002 1 0.39 %
0x00010070 1 0.39 %
0x00010130 1 0.39 %
0x00010138 1 0.39 %
0x00010238 1 0.39 %
0x0001023A 1 0.39 %
0x000102B8 1 0.39 %
0x000103B1 1 0.39 %
0x000104BA 1 0.39 %
0x00020042 1 0.39 %
0x0002004E 1 0.39 %
0x0002005E 1 0.39 %
0x00020430 1 0.39 %
0x000204B2 1 0.39 %
0x000205B2 1 0.39 %
0x000205B8 1 0.39 %
0x00020870 1 0.39 %
0x000405F2 1 0.39 %
0x00040672 1 0.39 %
0x00040840 1 0.39 %


The dwFeatures field is the most complex field in a CCID descriptor. The numerical value is not really informative. You have to parse the value to extract every bit of information.

We will now parse dwFeatures field by field. I will not explain each possible value. Have a look at the CCID specification or my CCID driver file ifdhandler.c in the function IFDHSetProtocolParameters().

No special characteristics: 00000000h

No reader.


Undocumented bit: 00000001h

1 reader: OMNIKEY CardMan 1021


Automatic parameter configuration based on ATR data: 00000002h

151 readers


Automatic activation of ICC on inserting: 00000004h

37 readers


Automatic ICC voltage selection: 00000008h

108 readers


Automatic ICC clock frequency change according to active parameters provided by the Host or self determined: 00000010h

217 readers


Automatic baud rate change according to active parameters provided by the Host or self determined: 00000020h

216 readers


Automatic parameters negotiation made by the CCID: 00000040h

60 readers


Automatic PPS made by the CCID according to the active parameters: 00000080h

126 readers


CCID can set ICC in clock stop mode: 00000100h

34 readers


NAD value other than 00 accepted (T=1 protocol in use): 00000200h

87 readers


Automatic IFSD exchange as first exchange (T=1 protocol in use): 00000400h

102 readers


ICCD: 00000800h

25 readers


level of exhange

dwFeatures # %
Character 6 2.36 %
TPDU 113 44.49 %
Short APDU 83 32.68 %
Short and Extended APDU 52 20.47 %


USB Wake up signaling supported on card insertion and removal: 00100000h

No reader


Data analysis

It is difficult to say if a reader should or should not support a particular feature.

One easy case is the level of exchange. As explained in Extended APDU support not all readers can support extended APDUs. If your application and your card is using extended APDU you shall use a reader with extended APDU support. That is either a TPDU or a short and extended APDU reader. 44.49 % + 20.47 % = 64.96% of the readers support extended APDU.

Regarding the other features the choice is between:
  • a feature implemented by the reader
    • Simpler driver
    • Impossible to patch in the driver if the reader firmware or a smart card is bogus
  • a feature implemented by the driver
    • More complex driver
    • Possible to modify the driver to adapt the feature to special cases (bogus reader firmware or bogus smart card)

My CCID driver is already "complex" with support of most the features. Some features are not yet supported but nobody asked from them. So I imagine they are not important.

So, except for the extended APDU support, the other features presented here are not so important. It may be more important for you to check if the reader supports the communication speed of your smart card, or the voltage of your card.

CCID descriptor statistics: features

Article from the serie "CCID descriptor statistics"

The features field is NOT a value from the CCID USB descriptor. It is a field I added to indicate special features of some readers.

features # %
features PIN Verification 39 15.35 %
features PIN Modification 36 14.17 %
features contactless 31 12.20 %
features ICCD 25 9.84 %
features Multi interface reader 14 5.51 %
features 2 slots 11 4.33 %
features Second interface 7 2.76 %
features biometric 7 2.76 %
features 3 slots 3 1.18 %
features 5 slots 3 1.18 %
features ExpressCard 3 1.18 %
features firewall 3 1.18 %
features 4 slots 1 0.39 %
features serial 1 0.39 %


Some features can be extracted from the USB descriptor like PIN Verification, PIN Modification, ICCD, number of slot. But the other features are added manually.

A majority of readers have no special feature. It is not directly visible from the table above because some readers have 2 or more features at the same time. For example all readers with PIN modification can also do PIN verification. But the reverse is not true. 3 readers can do PIN verification but not PIN modification.

If you want to find readers with a special feature, like contactless, I recommend to sort the reader matrix by 'features' field. It is then easy to find the readers with the feature you are looking for.

CCID descriptor statistics: wLcdLayout

Article from the serie "CCID descriptor statistics"

The wLcdLayout field is a number value from the CCID USB descriptor:

Number of lines and characters for the LCD display used to send messages for PIN entry.
XX: number of lines
YY: number of characters per line. XXYY=0000h no LCD.

wLcdLayout # %
0x0000 237 93.31 %
0x0210 6 2.36 %
0x0211 5 1.97 %
0x020C 4 1.57 %
0x0818 1 0.39 %
0x1002 1 0.39 %


The majority (93,31%) of readers do not have a display so 0 lines and 0 characters per line.

We then have pinpad readers with a display. The most common configurations are 2 lines of 12, 16 or 17 characters.

One reader, VASCO DP865, has a big display with 8 lines and 24 characters per line.

One reader, REINER SCT cyberJack go, is bogus and has XX and YY reversed. The screen has 2 lines of 16 characters and not 16 lines of 2 characters. It is obvious when looking at the reader picture.

OS X Yosemite and smart card source code

Apple released the source code of the open source components they use in Yosemite (OS X 10.10 released October 2014). The components are available at OS X 10.10 Source.

The smart card related components are:

  • SecurityTokend
  • SmartCardServices
  • SmartcardCCID
  • Tokend
See "OS X Yosemite and smart cards status" for a general discussion of the changes in Yosemite.

SmartcardCCID

The version changed from 55005 in Mavericks to 55008 in Yosemite.

This reflect the change of the CCID driver from version 1.3.11 to version 1.4.14.
Apple also upgraded libusb from version 0.1.13b to version 1.0.9.

The CCID driver is now compiled with USE_COMPOSITE_AS_MULTISLOT option. That explains why composite devices are now supported.
It would have been better to support composite devices at the pcscd (or equivalent, com.apple.ifdreader.slotd?) level. USE_COMPOSITE_AS_MULTISLOT is a hack that does work only for Gemalto Prox DU and Prox SU readers.

SmartCardServices

The version changed from 55111 in Mavericks to ... 55111 in Yosemite.

The version have not changed dven if Apple made large changes in the PC/SC middleware: pcscd has been removed and replaced by something even more bizarre and inexplicable. So it is surprising to see that SmartCardServices has not been updated.

Tokend

Tokend and CDSA was deprecated since Lion (10.7 released in July 2011) more than 3 years and 4 major releases ago. See "Mac OS X Lion and tokend".

The Tokend component is no more delivered since its deprecation in 10.7. The latest version is 36720 from Mac OS X 10.6 (Snow Leopard).

This component contains (or contained) the BELBIC, CAC, MuscleCard and PIV tokend.

SecurityTokend

The version of SecurityTokend changed from 55107 to 55108.

The change is really minimal. The mig.mk script changed to use the command xcrun (xcrun - Run or locate development tools and properties) to run the command mig (mig - Mach Interface Generator).

The tokend is deprecated but still maintained (a bit). This project provides the SecurityTokend framework used by the different tokend in the Tokend component. The SecurityTokend framework is still provided by Xcode in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/
SDKs/MacOSX10.10.sdk/System/Library/PrivateFrameworks/SecurityTokend.framework
.

Conlusion

New version of the CCID driver.

New PC/SC layer. The source code of the replacement of pcsc-lite (com.apple.ctkpcscd.xpc and com.apple.ifdreader.slotd) is not (yet) available. Maybe Apple will never release it. So only Apple will be able to fix the numerous bugs present in this new component.

I do not like the evolution of the smart card layer to a closed source software.

CCID descriptor statistics: dwMaxCCIDMessageLength

Article from the serie "CCID descriptor statistics"

The dwMaxCCIDMessageLength field is a number value from the CCID USB descriptor:

For extended APDU level the value shall be between 261 + 10 (header) and 65544 +10, otherwise the minimum value is the wMaxPacketSize of the Bulk-OUT endpoint.

dwMaxCCIDMessageLength # %
271 bytes 184 72.44 %
1034 bytes 9 3.54 %
263 bytes 9 3.54 %
512 bytes 9 3.54 %
261 bytes 7 2.76 %
272 bytes 6 2.36 %
270 bytes 5 1.97 %
1400 bytes 2 0.79 %
273 bytes 2 0.79 %
278 bytes 2 0.79 %
432 bytes 2 0.79 %
65550 bytes 2 0.79 %
1014 bytes 1 0.39 %
1024 bytes 1 0.39 %
1041 bytes 1 0.39 %
138 bytes 1 0.39 %
2048 bytes 1 0.39 %
2100 bytes 1 0.39 %
256 bytes 1 0.39 %
262 bytes 1 0.39 %
266 bytes 1 0.39 %
280 bytes 1 0.39 %
288 bytes 1 0.39 %
522 bytes 1 0.39 %
536 bytes 1 0.39 %
586 bytes 1 0.39 %
64 bytes 1 0.39 %


The standard value for dwMaxCCIDMessageLength is 271.

On the 271 bytes :
  • 10 bytes are used for the CCID header
  • 4 bytes are used for the CLA, INS, P1, P2 APDU header
  • 1 byte for the data size
  • 256 bytes for the data

In the PC_to_RDR_XfrBlock CCID CCID command we note:
The block should never exceed the dwMaxCCIDMessageLength-10 in the Class Descriptor.
The value dwMaxCCIDMessageLength is related to dwMaxIFSD. See also "CCID descriptor statistics: dwMaxIFSD".

CCID Readers with dwMaxCCIDMessageLength < 271 and that are Short APDU level exchange readers are suspect. They are:
  • Aktiv Co., ProgramPark Rutoken Magistra: 261 bytes and ICCD Version B
  • Gemalto PDT: 261 bytes and ICCD Version B
  • IIT E.Key Almaz-1C: 264 bytes
  • OCS ID-One Cosmo Card USB Smart Chip Device: 261 bytes and ICCD Version B
  • Philips Semiconductors JCOP41V221: 261 bytes and ICCD Version B
  • Philips Semiconductors SmartMX Sample: 261 bytes and ICCD Version B
ICCD Version B devices are a special version of CCID and in this case the normal value is 261 bytes since the CCID header is not used. The command is sent using a control request and not a bulk message.

So only the IIT E.Key Almaz-1C reader is bogus and limited to a maximum of 249 bytes of data in an APDU.