Smart Card Framework – Part 1

Summary
Smart Cards are becoming more prevalent in every day life. The government has put mandates on their inter-government issued credentials for them to support the PIV specification (http://csrc.nist.gov/publications/PubsSPs.html). In addition the SIM cards in our phones are smart cards, and smart cards are used heavily in European countries. US Passports have a contactless chip in them, and I assume that as time progresses our identification cards will start to have contactless and contact chips embedded in them.

Interacting with smart card devices in a windows environment is not one of the most intuitive things I have done.  It is primarily performed through the PC/SC API’s which provide some standard functions for communicating with smart card readers.  See http://www.gemalto.com/techno/pcsc/ for more information on PC/SC specification.  PC/SC provides a nice abstraction from the IO communication, but it is still highly reliant on the APDU (Application Protocol Data Unit) communication required to perform operations on the card.  I wanted to start writing a series on a framework to simplify the way we communicate with these cards using the Microsoft .NET framework (in this case 4.0).  I don’t know how many parts this series will be, but by the end of the series my goal is to have a extensible smart card framework that can support smart cards you may be using today.

For more information on an APDU see the WIKIPEDIA entry at http://en.wikipedia.org/wiki/Smart_card_application_protocol_data_unit.  We will be diving into what at APDU is when we start designing and developing the communication layers of the framework.  Much of this process will be a learning experience for me as well and we get further into the design.

Lets start
I have written abstractions in front of the windows PC/SC smart card API’s before, but there were many things learned as the API was developed.  I am taking this blog series as an opportunity to start from the ground up and apply lessons learned.  As with many projects I start, I usually like to establish a set of design goals.  With my previous knowledge of smart card development my list of goals for this framework is below.

1. Full abstraction from card communication protocol as a client application.  If I am using the API to talk to a defined card type, I do not want to know APDU’s are behind the scene.
   
2. Type safe communication with a card as a client
   
3. Optional verbose logging of all APDU messages behind the scene
   
4. Auto-detection when a card is inserted
   
5. Automatic discovery of inserted card type
   
6. Pluggable support for new card types and features (no need to recompile core code)… maybe use MEF
   
7. Unit testability at numerous layers of the framework.  for instance the ability to test without a physical card.  We will get into the framework model in a future series.
   
8. The ability to support multiple card readers simultaneously that are using different driver API’s.  For instance support for PC/SC compliant readers and MCP readers from MAGTEK.
   
9. Assume support from .NET 3.5 and up.  There may be a desire to support windows mobile environments using .NET CF 3.5

I also have a rough idea for what I would like the end users usage experience to be like; an example is below.

 1 // prior to working with the cards, we have a management class
 2 // that controls all interaction with the readers
 3 ISmartCardReaderManager manager = new AutoDetectionReaderManager();
 4 manager.CardInserted += CardInserted;  // a card was inserted
 5 manager.CardRemoved += CardRemoved;    // a card was removed
 6 manager.ReaderError += ReaderError;    // error interacting with reader(s)
 7 
 8 // example of the callback method that would handle reader messages
 9 public void CardInserted(object sender, CardInsertedEventArgs eventArgs)
10 {
11   // we can access both the card and the reader from the args
12   var card = eventArgs.InsertedCard;
13   var reader = card.Reader;
14 
15   // there is a feature collection in the card that we can query
16   // to interact with the card
17   foreach (var feature in card.Features)
18   {
19     Console.WriteLine(feature.GetType().FullName);    
20   }
21 
22   // we could fetch a feature from the card to use
23   IAddressBookFeature feature = card.Features.TryGet<IAddressBookFeature>();
24   if (feature != null)
25   {
26     // we could then get the list of contacts for instance
27     // feature.Contacts...
28   }
29 
30   // reader.Type is a property that would contain Contact/Contactless/Unknown
31 
32   // we can also disconnect from the card, and the interface implements
33   // the disposable pattern at this time
34   card.Disconnect();
35   card.Dispose();
36 }

I think this is a good spot to stop this entry. I expect to have part 2 in place in the next couple of days. In part 2, I will begin to cover the various layers of abstraction and encapsulation that will be provided through the API to allow for un to interact with a smart card in a way similar to below. I will probably also start a skeleton project and put it up on CodePlex for viewing.

Addition Information
Microsoft currently provides an abstraction to handle how different cards implement similar functionality, for instance verifying a pin code.  This API requires that card vendors also implement a interface specification defined by Microsoft.  The desire of the framework we are designing is not to redo this Microsoft API functionality but to supplement it.  It is possible that the framework we develop will use this API behind the scenes for some implementation, but since we can not assume a card vendor will always implement the Smart Card Minidriver Specification we must supplement the existing base.  For instance, the mini-driver specification also does not provide a façade for features some cards have such as fingerprint verification, and personal identity data retrieval.  For more information on the Microsoft Smart Care API see http://msdn.microsoft.com/en-us/library/dd627645(v=vs.85).aspx.

There is also a company CardWerk’s that has implemented a supported framework for smart card development in the .NET framework.  You can find a link to their website at http://smartcard-api.com/professional.shtml.  Although I have not used the API, it seems to share some similarities to what we will be designing/developing through this series.