Smartphone as smart card– Android meets Windows


Continuing on the theme of using an Android smartphone as smart card, this post looks at how Windows interacts with smartcards and the moving pieces required to transparently substitute a phone for traditional smart-card scenarios such as login to the machine.

Windows has an elaborate smart card stack, with automatic discovery and installation for “drivers” (in quotes, because these are not kernel-mode device drivers in the traditional sense of mediating hardware access, but user-mode constructs that translate cryptography API features to low-level smart card commands)  This is described in great detail in the smart card mini driver specification on MSDN. For our purposes, there are two quick ways to observe how that stack reacts to an Android device in card emulation mode.

1. Using the GUI. Tapping the phone in card emulation mode against a contactless reader will trigger the driver discovery. This requires that the screen is on because Android ties card emulation state to the display being powered. (The screen does not have to be unlocked, although the built-in timeout that turns off the display after idling on the lock screen can lead to an abrupt disconnect.) This will lead to a sequence of device discovery notifications along the lines of:

DriverInstallInProgress    DeviceDriverNotInstalled

Clicking on the error message for additional details:

DriverInstallDetails

The implication is that the Android phone was recognized as a smart card. Windows 7 unsuccessfully tried to locate an appropriate driver, which includes a cloud check at Windows update, but there were no suitable candidates and the system eventually threw in the towel.

2. From the command line using certutil -scinfo, with the phone tapped against a contactless card reader. (Recall that the screen must be on, because Android ties card-emulation mode to the display being powered on.) Below is an example of what could happen:

UnknownSmartcard_AndroidSE

Parsing the rather verbose diagnostic output here, the takeaways are:

  • Windows treats the tap event as smart card being present in the reader. While the user gesture is different for contactless cards (tapping against the NFC surface instead of pushing the card into the reader slot) the PC/SC API abstracts aways that difference and unifies both under a card present event.
  • It observed an ATR (answer-to-reset) from the card of 3b 8a 80 01 00 31 c1 73  c8 40 00 00 90 00 90. Strictly speaking this is another case of playing loose with terminology: contactless cards do not have an ATR,  they have an answer-to-select or ATS. A quick search suggests this particular value is similar to ATRs returned from other versions of JCOP, consistent with the NXP hardware present on this particular Galaxy Nexus device.
  • Here is where it gets strange: the phone is categorized “Identity Device (NIST SP 800-73 [PIV])”– in other words, a card implementing the US government Personal Identity Verification standard. PIV is a successor to the Common Access Card, going back to a presidential directive from 2004 mandating strong identification requirements for federal employees. PIV is one of two smart card standards recognized out-of-the-box in Windows 7, the alternative being GIDS.
  • Problem is, a stock Android secure element initialized for Google Wallet has nothing to do with PIV. Attempting to treat it as a PIV card will not end well, as this example demonstrates. The error dialog appearing in front of the command prompt states the obvious: the “card” in question does not conform to the expected behavior. Without a PIV applet present, APDUs sent to the secure element will not produce expected outcome, eventually forcing the driver to give up.

This suggests two ways out of the current predicament of mismatched drivers:

  1. Getting the Android device to implement a PIV or GIDS, the two card edges recognized out of the box in Windows 7 without any middleware required. This effectively turns the current incorrect Windows assumption above into reality.
  2. Installing a driver that is specific to the Android device to avoid using the incorrect driver. While this will avoid the error messages, it turns out to be a dead-end. The primary beneficiary of the smart card stack is the cryptography API, which expects the card to have certain capabilities such as managing secret keys and credentials.  Without that functionality present in the secure element, the driver can not translate these requests into appropriate commands issued to the phone.

[continued]

CP

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s