Inspecting communications from a smart card (1/2)


A previous post featured communication logged in transit to/from the secure element of an Android phone tapped against an NFC reader attached to a Windows 7 machine. This article provides a brief description of how such traces can be obtained, providing a glimpse into the internals of the smart card stack.

To recap the Windows architecture detailed earlier, here is a simplified depiction of  code paths invoked when an application is using a smart card:

Communication flow to a smart card

There are a lot of moving pieces here. Starting from the top:

  1. An application interested in performing a cryptographic operation. Typically this is user land application such as IE or Outlook, although it could be part of the operating system as in the case of Bitlocker disk encryption or winlogon process for login to the OS.
  2. The application calls into platform cryptographic API. To complicate matters, there are two of these in recent versions of Windows: the “legacy” but-not-quite-deprecated CAPI which has existed since NT4 days and the shiny new CNG introduced in Vista.
  3. Depending on which API the application targets, the code paths diverge. CAPI and CNG have different extensibility mechanisms for abstracting cryptographic hardware. The former defines cryptographic service providers (CSP) while the latter has key storage providers (KSP).
  4. But the paths converge again downstream as the smart card module associated with CAPI and CNG itself defines an extensibility scheme based on the same notion of smart card mini drivers.
  5. These drivers communicate with the card using PC/SC  (Personal Computer Smart Card) API. This is a standard initially developed by MSFT and later ported to OS X and Linux with an open-source clone called pcsclite.
  6. Transceive operation in PC/SC in turn results in data being funneled to a device driver for the card reader. Typically this is the CCID class driver in Windows, although some manufacturers also provide drivers unique to their particular hardware.
  7. This kernel mode driver communicates to the card reader hardware using a channel such as USB.
  8. Finally the reader communicates with the card via a physical layer, in this case NFC.

When the objective is observing the way Windows interacts with cards in a given scenario, there is a sweet spot in this stack: between the card driver and PC/SC.  Above that layer, there are no APDUs in the picture, only higher level semantics such as “verify PIN.” Below PC/SC layer, APDUs are encapsulated in lower level protocols which typically fragment them and envelop the content in additional metadata, which will eventually get stripped away by the reader when final APDU contents are being delivered to the card. While one could attempt to reconstruct the final contents closer to the source, this would require special hardware such as the Proxmark for intercepting NFC transmissions or the Smart Card Detective for contact cards. By contrast watching APDUs at the PC/SC layer can be done entirely in software, by intercepting a couple of entry points in the DLL that implement PC/SC.

Side note: certain cross-platform applications such as Firefox do not use the Windows cryptography API, and instead require alternative mechanism such as PKCS11 modules for smart card support. These applications bypass the first couple of layers in the above picture, but still rely on PC/SC for card communication. As such techniques that rely on intercepting PC/SC calls continue to work, in contrast to those operating at the higher layer.

[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