Thursday, April 24, 2014

USB issues with a Raspberry Pi

Some people report problems with my CCID driver and a Raspberry Pi. The problem is not with the CCID driver but with the Raspberry Pi itself.

I don't know if the problem is hardware, software or a combination of the two. I found a description of the problem on the excellent website For example from the article "Cook and Hold with Raspberry Pi (video)" you can read:

There is one caveat on the Raspberry Pi : the USB support is still somewhat buggy perfectible, and we will need to configure it to make it work reliably. The problem is, the RasPi will occasionally drop USB packets for "full-speed" peripherals (such as keyboard, mouse, modems, as well as some audio devices) when working in standard "high-speed" mode. The problem is less acute with the most recent firmware, but it is not completely solved. The only reliable workaround for now is to force all peripherals to run in "full-speed" mode. This will have the negative side effect of limiting all peripherals (including the on-board network adapter) to 1.5 MBytes/s, but anyway, the Raspberry Pi is not designed to be a race horse...

To force USB to run in "full-speed" mode, simply add dwc_otg.speed=1 to the /boot/cmdline.txt file, as follows:

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200
dwc_otg.speed=1 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4
elevator=deadline rootwait

Saturday, April 12, 2014

CCID descriptor statistics: dwMechanical

Article from the serie "CCID descriptor statistics"

The dwMechanical field is a number value from the CCID USB descriptor:
The value is a bitwise OR operation performed on the following values:
• 00000000h No special characteristics
• 00000001h Card accept mechanism
• 00000002h Card ejection mechanism
• 00000004h Card capture mechanism
• 00000008h Card lock/unlock mechanism
A footnote in the specification also indicates:
These mechanisms of the dwMechanical parameter have been included for completeness; however, these functions of motorized CCIDs are not covered by this release of the specification. A future release may attempt to standardize the interface to these mechanical functions.

0x0000000024696.85 %
0x0000000172.76 %
0x0300000010.39 %

The normal value should be 0x00000000: "No special characteristics" since this field is not covered by the CCID specification.

1 reader is using 0x03000000 (that should be 0x00000003)

7 readers are using 0x00000001 "Card accept mechanism"
  • FujitsuTechnologySolutions GmbH SmartCase KB SCR eSIG
  • Hewlett-Packard Company HP USB CCID Smartcard Keyboard
  • Identive Identive CLOUD 4500 F Dual Interface Reader
  • Identive Identive CLOUD 4510 F Contactless + SAM Reader
  • Identive Identive CLOUD 4700 F Dual Interface Reader
  • Identive Identive CLOUD 4710 F Contactless + SAM Reader
  • Lenovo Lenovo USB Smartcard Keyboard
  • SCM Microsystems Inc. SCL010 Contactless Reader
  • SCM Microsystems Inc. SCL01x Contactless Reader

CCID descriptor statistics: dwProtocols

Article from the serie "CCID descriptor statistics"

The dwProtocols field is a number value from the CCID USB descriptor:
RRRR –Upper Word- is RFU = 0000h
PPPP –Lower Word- Encodes the supported protocol types. A ‘1’ in a given bit position indicates support for the associated ISO protocol.
0001h = Protocol T=0
0002h = Protocol T=1
All other bits are reserved and must be set to zero. The field is intended to correspond to the PCSC specification definitions. See PCSC Part3. Table 3-1 Tag 0x0120.
Example: 00000003h indicates support for T = 0 and T = 1.

0x0000 0x000320781.50 %
0x0000 0x00022710.63 %
0x0000 0x0001197.48 %
0x0000 0x030010.39 %

The value 0x0300 is bogus and is used by the reader:

Some readers (7.48%) only supports the T=0 protocol. They are:
  • ATMEL AT91SC192192CT-USB ICCD reader
  • ATMEL VaultIC420 Smart Object
  • ATMEL VaultIC440
  • ATMEL VaultIC460
  • BIFIT iBank2Key
  • Gemalto Hybrid Smartcard Reader
  • Gemalto SA .NET Dual
  • Gemalto Smart Enterprise Guardian Secure USB Device
  • Gemalto Smart Enterprise Guardian Secure USB Device
  • INSIDE Secure VaultIC 405 Smart Object
  • INSIDE Secure VaultIC 441 Smart Object
  • Inside Secure VaultIC 420 Smart Object
  • Inside Secure VaultIC 440 Smart Object
  • Inside Secure VaultIC 460 Smart Object
  • KEBTechnology KONA USB SmartCard
  • Kingtrust Multi-Reader
  • RSA RSA SecurID (R) Authenticator
  • SchlumbergerSema SchlumbergerSema Cyberflex Access
  • SecuTech SecuTech Token
  • Softforum Co., Ltd XecureHSM
  • TianYu CCID Key TianYu CCID SmartKey

Some readers (10.63%) only supports T=1 protocol. They are:
  • ACS ACR122U PICC Interface
  • Aktiv Co., ProgramPark Rutoken Magistra
  • Aktiv PINPad Ex
  • Aktiv PINPad In
  • Aktiv Rutoken ECP
  • Aktiv Rutoken lite
  • BIFIT USB-Token iBank2key
  • CCB eSafeLD
  • Crypto Stick Crypto Stick v1.4
  • Feitian ePass2003
  • Free Software Initiative of Japan Gnuk
  • Gemalto PDT
  • German Privacy Foundation Crypto Stick v1.2
  • Giesecke & Devrient GmbH Star Sign Card Token 350 (ICCD)
  • Giesecke & Devrient GmbH Star Sign Card Token 550 (ICCD)
  • GoldKey Security PIV Token
  • IIT E.Key Almaz-1C
  • Macally NFC CCID eNetPad
  • OCS ID-One Cosmo Card USB Smart Chip Device
  • Philips Semiconductors JCOP41V221
  • Philips Semiconductors SmartMX Sample
  • REINER SCT cyberJack RFID basis
  • Watchdata W5181
  • Yubico Yubikey NEO CCID
  • Yubico Yubikey NEO OTP+CCID
  • id3 Semiconductors CL1356A_HID
  • id3 Semiconductors CL1356T5
  • id3 Semiconductors CL1356T
  • ubisys 13.56MHz RFID (CCID)
Many of the readers with support of only 1 protocol are tokens with an integrated smart card. Since you can't change the card only the protocol used by the card is declared. So it is not really a limitation of the reader.

CCID descriptor statistics: dwSynchProtocols

Article from the serie "CCID descriptor statistics"

The dwSynchProtocols field is a number value from the CCID USB descriptor:
• RRRR-UpperWord- is RFU=0000h
• PPPP-Lower Word- encodes thes upported protocol types. A ‘1’ in a given bit position indicates support for the associated protocol.
0001h indicates support for the 2-wire protocol
0002h indicates support for the 3-wire protocol
0004h indicates support for the I2C protocol
All other values are outside of this specification, and must be handled by vendor-supplied drivers.

A footnote in the specification also indicates:
This release of the specification does not support devices with the 2-wire, 3-wire, and I2C protocol so PPPP = 0000h. This field is intended to be forward compatible with the PCSC specification.
I imagine this value is for synchronous cards only.

0x0000000021885.83 %
0x000000073513.78 %
0x0000000110.39 %

The normal value should be PPPP = 0000h. Most of the readers provide this value.

The reader with value 0x00000001 is:

The readers with value 0x00000007 are:
  • Akasa AK-CR-03
  • Alcor Micro AU9520
  • Alcor Micro AU9522
  • Alcor Micro AU9540
  • Alcor Micro SCR001
  • C3PO KBR36
  • C3PO LTC31 v2
  • C3PO LTC32
  • C3PO LTC36
  • Cherry GmbH SmartBoard XX44
  • Cherry GmbH SmartTerminal ST-1275
  • Cherry GmbH SmartTerminal XX44
  • Feitian bR301
  • Fujitsu Siemens Computers SmartCard Keyboard USB 2A
  • Fujitsu Siemens Computers SmartCard USB 2A
  • GIS Ltd SmartMouse USB
  • Giesecke & Devrient GmbH StarSign Crypto USB Token
  • KOBIL KAAN Advanced
  • OMNIKEY 6321 CLi USB
  • OMNIKEY AG CardMan 3021
  • OMNIKEY AG CardMan 3121
  • OMNIKEY AG CardMan 3621
  • OMNIKEY AG CardMan 3821
  • OMNIKEY AG CardMan 5121
  • OMNIKEY AG CardMan 5125
  • OMNIKEY AG CardMan 6121
  • OMNIKEY AG Smart Card Reader
  • OMNIKEY CardMan 1021
  • OMNIKEY CardMan 4321
  • OMNIKEY CardMan 5321
  • Precise Biometrics Sense MC
  • Sitecom Sitecom USB simcard reader MD-010
  • THRC Smart Card Reader
  • VASCO DP905v1.1
  • Watchdata W5181
  • XIRING Teo