Smart cards are becoming more prevalent in everyday life. The US government has placed smart card PIV mandates on their inter-government issued credentials. In addition, the SIM cards, US Passports, credit cards, and European countries are all starting to more heavily adopt the technology as a secure medium for financial transactions, personal identity storage/verification, and even authentication into computer systems.
Unfortunately, interacting with smart card devices using .NET in a Windows environment is not extremely intuitive. Interaction is usually performed via the PC/SC API which does provide some abstractions, but still requires some low level development communicating via application protocol data unit (APDU) messages. PC/SC is an abstraction that smart card manufactures can implement to standardize and ease the way application developers communicate with the hardware. For the sake of these articles, PC/SC is best described as a set of win32 API calls that all start with the prefix SCard[[VERB]]. For more information on PC/SC, visit http://www.gemalto.com/techno/pcsc and http://msdn.microsoft.com/en-us/library/aa379473(v=VS.85).aspx (Windows API, search for SCard).
The goal of this series of blogs is to develop a framework that allows for simplification when interacting with smart card readers when using .NET. In addition, individuals developing support for new cards should also have a framework to work in that provides a consistent mechanism for exposing new features of a card. Because there is no requirement that a vendor implement the PC/SC specification, the framework should support an abstraction for the various smart card reader API’s that may exist. For instance, MAGTEK provides smart card readers that operate well in kiosk environments, but they do not provide a PC/SC implementation; instead they implement their proprietary MCP API. This framework should provide the application developer a seamless experience regardless of underlying communication API. I have identified some additional goals for the framework to assist during the development and design.
- Easy recognition of features a specific card may support (e.g., Address book retrieval).
- Ability to enable verbose logging of APDU messages being sent through API’s (nice for debugging).
- Auto-detection of when a card is inserted in the PC.
- Support for multiple physical card readers implemented by different API’s (e.g., PC/SC and MCP) via a single management endpoint.
- Pluggable support for new card types and features (don’t want to re-compile code if a developer wants to add support for a feature of a new card in the market).
- Unit testability and “mockability.” If testing an application that is reliant on a specific smart card type, I do not want to require the physical card or physical reader to be present.
- Assume support for .NET 3.5 and up. Would like to leave the door open for Windows CE/Mobile support in the future.
In addition, I have provided an example of what it may be like to interact with the framework; of course nothing is concrete at this point, it’s a blurry vision.
Well, that’s it for this entry. In part 2 we will concentrate on getting a skeleton class library and test client up and running. We will get the framework to detect via the framework the list of readers registered in the Windows PC and see what happens when a card is inserted into one of the readers.
To get more of a primer on what smart cards on and how they are used today, I find Wikipedia and a simple Google/Bing search to be the best starting points. Below are some links that may help provide a better grounding of what smart cards are, how we communicate with them, and where the development environment is today.
- Smart Card API (Windows) - http://msdn.microsoft.com/en-us/library/dd627645(v=vs.85).aspx. This is Microsoft’s current abstraction for cards that implement authentication and cryptographic features. It is reliant on card manufactures providing a driver that implements the specification outlined in the Smart Card Minidriver spec. Just nice to know it is out there.
- CardWerk – This is a company that has provided a framework for PIV application development. In addition to providing an abstraction from the communication API, this company also implements standards for many cards that exist in the market today. This framework will be similar, accept we will concentrate on a more open platform design. http://smartcard-api.com/professional.shtml.
- APDU – information on what an APDU is, gotta love Wikipedia. http://en.wikipedia.org/wiki/Smart_card_application_protocol_data_unit, or for the bold http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816.aspx.