Smart cards are the most versatile two factor authentication devices and essential for secure PKI deployments. Two factors means that for successful use, you need to have something (a smart card) and know something (a PIN code). While still better than simple passwords, a PIN code entered like a password through standard computer keyboard is exposed to host software and thus easily intercepted by the worst kind of malware - trojans, which could then abuse your inserted card and do covert transactions with the card once the PIN code has been captured by the trojan (or keylogger).
To protect against such attacks, secure PIN entry devices (commonly known as pinpad readers) exist. Such devices are supposed to be with specially designed hardware which guarantee that PIN codes travel directly from the device keypad to the smart card, without passing through the host computer and thus not visible to possibly hostile software on the host computer.
This is a reminder to not be fooled by marketing alone. A device with Hewlett-Packard logo (model KUS0133) claims secure PIN entry and modification capability in the CCID descriptor but in fact does not enforce the secure PIN entry promise - the entered code can be read by host software. This behavior was discovered by accident - the device *seems* to work flawlessly on Linux but have a look what happens on Mac OS X 10.6.6:
mrtn:~ martin$ opensc-tool -l
# Detected readers (pcsc)
Nr. Card Features Name
0 No PIN pad HP USB Smart Card Keyboard 00 00
mrtn:~ martin$ pkcs11-tool --login --test --slot 1 --module /Library/OpenSC/lib/opensc-pkcs11.so
1234
error: PKCS11 function C_Login failed: rv = CKR_GENERAL_ERROR (0x5)
Small explanation:
- After the keyboard has been connected and identified to Mac OS X, OpenSC detects the reader and the advertised pinpad capability
- Trying to do some operations with the inserted smart card leads to the point where the software sends the correct command to the reader to do a secure PIN entry operation and the "secure PIN entry" led on the keyboard is turned on, signaling that the PIN code should be entered on the numpad of the keyboard. On Linux, keys other than ESC (which cancel the transaction) and ENTER (which confirms the entered PIN) don't work in this mode (nothing appears on the screen at least).
- Now the unexpected happens: the entered PIN ("1234" in this example) is shown on standard input! In fact, all keys work and entry to stdin is possible. The expected output should be the tool showing test results of operations with keys on the card without any keyboard input.
Without further investigation I can guess there are two possibilities of what's going on:
- It is possible for the host software to set the device firmware to a state where the pinpad is malfunctioning and sends keyboard input to the host
- The entered PIN code is always transmitted over USB but Linux "correctly" routes those packets to /dev/null
Either way the reader can't be considered as a secure PIN entry device as the host software can affect the functioning of the device and the secure PIN entry mode is not enforced by the keyboard firmware.
What next?
- The next release of OpenSC shall disregard the advertised pinpad capability of this reader and enforce normal (no pinpad) mode
- Probably an upcoming release of the open source CCID driver shall have the pinpad feature disabled already in the driver layer
- The myth that devices that claim to do everything actually do nothing well got reassured. If you are worried about the secrecy of your PIN code, buy a dedicated pinpad reader with tamper evident features (like a hologram sticker and certified firmware)
- Remember to keep your computer up to date with security patches and don't install software or visit websites you don't trust - the best protection against trojans. Also make sure that you remove your smart card from the reader as soon as you have finished using it, to limit the time when hostile software could abuse your connected smart card