Ludovic Rousseau's blog: April 2014

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 yoctopuce.com. 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.

dwMechanical	#	%
0x00000000	246	96.85 %
0x00000001	7	2.76 %
0x03000000	1	0.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)

MYSMART MySMART PAD V2.0

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.

dwProtocols	#	%
0x0000 0x0003	207	81.50 %
0x0000 0x0002	27	10.63 %
0x0000 0x0001	19	7.48 %
0x0000 0x0300	1	0.39 %

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

MYSMART MySMART PAD V2.0

Some readers (7.48%) only supports the T=0 protocol. They are:

ATMEL AT91SC192192CT-USB ICCD reader
ATMEL AT98SC032CT-USB
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
IID AT90S064 CCID READER
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
ASK-RFID CPL108
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.