Your Android phone is also a smartcard

An earlier post discussed the three different modes supported by the NFC controller on Android devices. In this post we look at a surprising consequence of one of these: card emulation.

To recap: in card emulation mode, the NFC controller is directly attached to the embedded secure element on the device. Traffic is routed directly between SE and external NFC receiver– such as point of sale terminal, in the case of mobile payments with Google Wallet– without traversing the host operating system at all. In other words, Android is not in the picture for shuttling these bits, except for the supervisory actions of enabling/disabling card emulation mode.

As the name implies, in this state the phone looks like a traditional smartcard. An easy way to demonstrate this is using the built-in smartcard support in Windows for logon. Ingredients for this demo:

• Recent vintage Windows PC running Vista or higher version of the operating system. Virtual machines are fine for this purpose.
• Machine joined to an Active Directory domain (** It is also possible to do this using stand-alone PC but that requires installing third-party software.)
• Contactless or dual-interface smartcard reader
• Android phone running Google Wallet

When  smart-card reader is attached to a recent vintage Windows machine (Vista and later) joined to a domain networks, it presents the option to logon using a smartcard instead of a password:

Clicking on the smart-card option, we are prompted to insert a smartcard:

At this point, turning the screen on and tapping it against the  contactless smart card reader leads to a flurry of activity, with the message “reading smartcard” briefly flashed under the tile, quickly followed by an error:

This is what might be called a succesful failure. Here is the sequence of events that transpired:

1. Turning the screen on enables card-emulation mode on Android devices by default. (Note it is not necessary to unlock the screen, similar to how payments can be executed by tapping the point-of-sale terminal.)
2. When the phone is introduced to the NFC field of the smartcard reader in this state, Windows smart-card service registers it as a card-present event.
3. Appearance of a new card triggers a discovery process, to determine what type of card the user has introduced. End goal is picking a suitable smart-card driver. Because applications using smart-card operate in terms of higher level of abstractions such as certificates and cryptographic keys, drivers are required to translate these into low-level commands that each type of card understands.
4. During the discovery process, the PC will exchange traffic over NFC with the secure element, to query its features.
5. Driver discovery fails. This is not surprising– the “card” in question is used for contactless payments. It does not implement any of the standard card edges built into Windows 7/8 (PIV and GIDS) and neither does the answer-to-reset (ATR) identifier returned by the secure element
6. Because no driver is located, the higher level application– in this case Windows logon– also fails in its attempt to locate credentials on the card, displaying the error in the last screenshot.

In the next post, we will look at another way to interact with an Android phone as smart-card, before posing the question: what if the emedded secure element did implement one of the recognized profiles such as PIV?

[continued]

CP