SCardGetAttrib by pcsc-lite

SCardGetAttrib()

An application may need to know specific values from a smart card reader/driver. It is the job of the SCardGetAttrib() function at the PC/SC level. The list of possible questions is:

• SCARD_ATTR_ASYNC_PROTOCOL_TYPES
• SCARD_ATTR_ATR_STRING
• SCARD_ATTR_CHANNEL_ID
• SCARD_ATTR_CHARACTERISTICS
• SCARD_ATTR_CURRENT_BWT
• SCARD_ATTR_CURRENT_CLK
• SCARD_ATTR_CURRENT_CWT
• SCARD_ATTR_CURRENT_D
• SCARD_ATTR_CURRENT_EBC_ENCODING
• SCARD_ATTR_CURRENT_F
• SCARD_ATTR_CURRENT_IFSC
• SCARD_ATTR_CURRENT_IFSD
• SCARD_ATTR_CURRENT_IO_STATE
• SCARD_ATTR_CURRENT_N
• SCARD_ATTR_CURRENT_PROTOCOL_TYPE
• SCARD_ATTR_CURRENT_W
• SCARD_ATTR_DEFAULT_CLK
• SCARD_ATTR_DEFAULT_DATA_RATE
• SCARD_ATTR_DEVICE_FRIENDLY_NAME
  Implemented by pcsc-lite if the IFD Handler (driver) returns IFD_ERROR_TAG. pcsc-lite then returns the same reader name as returned bySCardListReaders.
• SCARD_ATTR_DEVICE_IN_USE
• SCARD_ATTR_DEVICE_SYSTEM_NAME
• SCARD_ATTR_DEVICE_UNIT
• SCARD_ATTR_ESC_AUTHREQUEST
• SCARD_ATTR_ESC_CANCEL
• SCARD_ATTR_ESC_RESET
• SCARD_ATTR_EXTENDED_BWT
• SCARD_ATTR_ICC_INTERFACE_STATUS
• SCARD_ATTR_ICC_PRESENCE
• SCARD_ATTR_ICC_TYPE_PER_ATR
• SCARD_ATTR_MAX_CLK
• SCARD_ATTR_MAX_DATA_RATE
• SCARD_ATTR_MAX_IFSD
• SCARD_ATTR_MAXINPUT
• SCARD_ATTR_POWER_MGMT_SUPPORT
• SCARD_ATTR_SUPRESS_T1_IFS_REQUEST
• SCARD_ATTR_SYNC_PROTOCOL_TYPES
• SCARD_ATTR_USER_AUTH_INPUT_DEVICE
• SCARD_ATTR_USER_TO_CARD_AUTH_DEVICE
• SCARD_ATTR_VENDOR_IFD_SERIAL_NO
• SCARD_ATTR_VENDOR_IFD_TYPE
• SCARD_ATTR_VENDOR_IFD_VERSION
• SCARD_ATTR_VENDOR_NAME

The PC/SC call SCardGetAttrib is implemented by redirecting the question to the reader driver IFDHGetCapabilities() method.

My CCID driver implements some of them.

SCARD_ATTR_DEVICE_FRIENDLY_NAME

The case of SCARD_ATTR_DEVICE_FRIENDLY_NAME is different. The driver does not know the reader name used at the PC/SC level. The name is chosen by pcsc-lite, not by the driver. See also a previous blog article: What is in a PC/SC reader name?.

So what pcsc-lite does is first ask the driver about SCARD_ATTR_DEVICE_FRIENDLY_NAME, and if the driver returns the error IFD_ERROR_TAG then pcsc-lite will answer itself with the name pcsc-lite selected.

_A and _W variants

pcsc-lite does not support UNICODE or ASCII modes. On Unix Unicode is encoded as UTF-8 instead of UTF-16 as on Windows. Since UTF-8 includes ASCII you do not need to differentiate two configurations.

So when Windows defines SCARD_ATTR_DEVICE_FRIENDLY_NAME_A and SCARD_ATTR_DEVICE_FRIENDLY_NAME_W Unix only has SCARD_ATTR_DEVICE_FRIENDLY_NAME.

Remote desktop in mixed environment

Remote desktop solutions using RDP (Remote Desktop Protocol) like rdesktop or ICA (Independent Computing Architecture) like Citrix XenApp can also do remote smart card operation.
If the smart card reader is connected on a Unix system using pcsc-lite and the application is on a Windows system the remoting system must do some "translation" work. In particular if the application on the windows side ask for SCARD_ATTR_DEVICE_FRIENDLY_NAME_A the remote application must translate the question into SCARD_ATTR_DEVICE_FRIENDLY_NAME and convert it back to the correct encoding.

Different feature levels

An application designed and tested on Windows may be surprised by PC/SC answers when run through rdesktop or Citrix XenApp. In that case the answers from the PC/SC layer comes from pcsc-lite and not from the Windows winscard library. Some services may not be supported like SCARD_ATTR_DEVICE_FRIENDLY_NAME on Mac OS X but expected by the application.

The Windows application designers should keep in mind that the PC/SC layer they are talking to may not be the one provided by Windows. It can be a PC/SC layer running on GNU/Linux, Mac OS X, Solaris or some other even more bizarre Unixes.

Conclusion

An application may run inside a virtual machine. So the hardware seen by the application is not real.
A Windows application may run inside Wine. So the Windows is not a Microsoft one.
A Windows application may talk to a remote PC/SC layer with different features.