The previous post described how Windows picks drivers for unfamiliar smart cards. The low-level operation of that process can be observed by looking a trace of the communications occurring when the system encounteres an “unfamiliar” type of card, such as an NFC-enabled Android phone in card-emulation mode.
First, some background on the host to card communication. The logical format for exchanging data with a smart card is the Application Protocol Data Units, or APDU for short. These can be viewed as the analog to packets in a networking protocol. These building blocks come in two variants, command and response. Usually cards operate in passive mode: the host initiates communication by sending request APDUs, cards reply with response APDUs. (There are a few exceptions to this model such as SIM application toolkit, when the card is calling the shots.) Basic structure of APDUs were defined in ISO7816 part #4. For a request APDU, there are a few mandatory bytes at the beginning with special significance defined by the standard, such as the instruction type and parameters. That header is followed by a variable length payload upto 256 bytes. The logical structure of the payload itself is completely up to the card application to define. In practice compact binary encodings such as ASN1 with BER are de rigeur. Response APDUs have even less structure. Two bytes at the end are reserved for a mandatory status word. These are preceded by an arbitrary response payload, also capped at 256 bytes. ISO7816 defines categories of status words corresponding to succesful operations as well as a litany of error codes.
For completeness, it’s worth mentioning that later updates also introduced extended length APDUs. These allow sending/receiving upto 64K of data at once. The catch is that support for extended length is not universal in card operating systems. Windows follows a least-common denominator approach and the built-in PIV/GIDS drivers do not use this feature. Neither does the discovery process, but it would have made little difference given that only small amounts of data are exchanged, as the trace reveals. In the case of the secure element in Android, support depends on the interface. It is possible to send extended length APDUs over NFC but not over wired interface from the Android side.
With that background, we can look at an APDU trace. This contains raw APDU dumps from three identical rounds of discovery on the Android secure element. A couple of differences from the driver specification jump out in the trace. The first request/response pair goes according to expectation, an attempt to select the MSFT-defined discovery applet by its AID. Status word 6A82 means file not found in ISO7816 error codes. So far so good. But the second request/response attempts to obtain the device ID record from the non-existent applet. This is strange to say the least. If an application does not exist, it is hardly reasonable to ask that application to perform additional tasks. Instead the command was routed to the currently selected applet, which happens to be the Global Platform card manager. Luckily the card manager had no information associated with the proprietary Windows tag and returns an error corresponding to “referenced data not found” instead of returning some unrelated object that could have confused the discovery process.
Windows next proceeds with trying to select the PIV applet by its AID. Here is another divergence from the discovery spec: attempt to select the master file is skipped, in favor of directly looking for PIV. After getting another 6A82 it tries the same with GIDS by using that AID. These well-known AIDs are documented in appendix D of the driver specification.) Because no GIDS applet exists on this stock Android device, Windows gives up at this point and falls back to using the ATR historical bytes to construct a device ID. All of this happens in less than a tenth of a second, barely perceptible compared to the time required for users to move the phone into the RF field.) While this is not reflected in the APDU trace, the OS would have checked for a driver at Windows Update using that identifier. Since there is none published for the Android embedded secure element, the discovery process concludes with the driver installation error observed in the experiment.
Next post will briefly discuss how this APDU trace was obtained.