Smart Card Framework – Where’s my card at? – Part 2

If you have not read part one of this series, we are trying to build a framework for interacting with smart cards and readers on a windows based PC using the .NET framework. For more information on what the goals are for this framework please see Part 1. In this part we are going to concentrate on the composition model of detecting what smart card readers exist on our PC and notifications when a card is inserted or removed from a reader. I recommend you first download the SmartCard code base for this project from http://smartcardframework.codeplex.com. The project may seem large initially, but most of the code currently is stubbed for future implementation. The best place to start is with execution of the unit tests that exist in the SmartCard.Framework.UnitTests project.  As long as you have at least 1 PC/SC Complient smart card connected to your PC then all unit tests should pass. 
As described in part 1, we want to support multiple smart card API’s for communication with various readers. In order to prove this functionality out I have stubbed two readers in our application. The first reader is based on PC/SC and the other reader is a reader based on the windows file system. The project structure for these two readers is displayed on the right. As we continue development of the API we will always ensure that both of these API’s are in use. The purpose of the file system will serve as the baseline for testing components where physical interaction with a reader would be required. Now onto the unit tests!
The way I have decided to support multiple card readers is through a couple design and technology decisions. MEF will be used for plug-in composition, and a centralized management class will be used to provide a single communication for reader notifications. The Microsoft Extensibility Framework (MEF) is a new to Silverlight and .NET 4.0. It provides a standardized plugin and discovery approach to disparate components across a system. If you are interested in learning more see the MEF CodePlex site http://mef.codeplex.com/. The code snippet below is from the DefaultFrameworkCardReaderManager and shows how we will aggregate and find a set of readers using MEF.

 1 /// <summary>
 2 /// reader discovery modules
 3 /// </summary>
 4 [ImportMany(AllowRecomposition = false)]
 5 private IEnumerable<ISmartCardReaderDiscovery> _readerDiscoveryModules = null;
 6 …
 7 … construction code here, that calls compose, and find reader
 8 …
 9 private void Compose()
10 {
11    // TODO: use a different catalog to acquire data.  and we also probably
12    // use a composition model that allows for multiple catalogs
13    // ... save that for later though.
14    AssemblyCatalog catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());
15    var container = new CompositionContainer(catalog);
16    container.ComposeParts(this);
17 }

If you look in the source code, there is nothing that actually “news up” the _readerDiscoveryModules field. This field is actually populated by MEF during its composition process. The ISmartCardReaderDiscovery interface is a contract that must be implemented by developers who create new API abstractions for our framework. The interface exposes a single method Discover(), that is responsible for returning a list of smart card readers it knows about. This model allows for a loose coupling between how the management class receives a set of concrete ISmartCardReaderDiscovery objects. The below code snippet displays how the interface is used later in the management class to actually receive the list of readers that will be managed.

 1 private List<IsmartCardReader> FindReadersToManage()
 2 {
 3    var readersToManage = new List<ISmartCardReader>();
 4    foreach (var discoveryProcess in _readerDiscoveryModules)
 5    {
 6       var discoveredReaders = discoveryProcess.Discover();
 7       readersToManage.AddRange(discoveredReaders);
 8    }
 9  
10    return readersToManage;
11 }
12 
13 private void AttachToReaderNotifications()
14 {
15    foreach (var managedReader in _managedReaders)
16    {
17       managedReader.CardInserted += managedReader_CardInserted;
18       managedReader.CardRemoved += managedReader_CardRemoved;
19       managedReader.ReaderError += managedReader_ReaderError;
20    }
21 }

So, now that we have the manager in place and we have created the contract for discovery of new readers, let’s go ahead and discuss/create the PC/SC implementation. For the purpose of this article we will cover only the topics of detecting an approach to card insertion, card removal, and reader detection using the PC/SC API. The next post will cover how we communicate with the card in a reader.
PC/SC is comprised of numerous functions, but in order to detect card insertion and the set of readers that exist on the system there are only a couple API calls of importance.

• SCardListReaders – This API call provides a listing of a set of PC/SC compliant smart card readers by name. This is what our PC/SC discovery process uses to find all reader in the system.
  
• SCardGetStatusChange – This API call provides the current state of a set of readers, and we use a polling mechanism in our code track potential changes in reader state.

The reader discovery process for PC/SC is less than 100 lines in total (including comments). The manager class will find this implementation using MEF and will call discove adding the discovered readers to the managed collection.

 1 internal class PcscSmartCardReaderDiscoveryProcess : ISmartCardReaderDiscovery
 2 {
 3   public IEnumerable<ISmartCardReader> Discover()
 4   {
 5     var readerNames = GetInstalledReaders();
 6     var readers = new LinkedList<ISmartCardReader>();
 7     foreach (var readerName in readerNames)
 8     { readers.AddLast(CreateReader(readerName)); }
 9     return readers;
10   }
11 
12   private PcscSmartCardReader CreateReader(string readerName)
13   {
14     // TODO: revisit how we will determine
15     // the reader type.  (name inference, injection, etc)
16     return new PcscSmartCardReader(readerName, eReaderType.Unknown);
17   }
18 
19   /// <summary>
20   /// Returns the string names of all of the
21   /// smart card readers currently available on the system.
22   /// </summary>
23   /// <returns></returns>
24   private IEnumerable<string> GetInstalledReaders()
25   {
26     // get the length of buffer needed for all string names
27     UInt32 bufferLength = 0;
28     int retVal = 0;
29 
30     // get the buffer size required for getting all readers.
31     retVal = PcscInvokes.SCardListReaders(0, IntPtr.Zero, null, ref bufferLength);
32     if ((ePcscErrors)retVal != ePcscErrors.Success)
33     { throw new PcscException("", (ePcscErrors)retVal); }
34 
35     // now load the buffer up
36     byte[] mszReaders = new byte[bufferLength];
37     retVal = PcscInvokes.SCardListReaders(0, IntPtr.Zero, mszReaders, ref bufferLength);
38     if ((ePcscErrors)retVal != ePcscErrors.Success)
39     { throw new PcscException("", (ePcscErrors)retVal); }
40 
41     ASCIIEncoding encoding = new ASCIIEncoding();
42     string encoded = encoding.GetString(mszReaders);
43     string[] split = encoded.Split('\0');
44     return split.Where((x) => !string.IsNullOrWhiteSpace(x));
45   }
46 }

There are a couple things I should point out. In the CreateReader method, there is a TODO comment around determining if a reader is contact or contactless. At this point we are just setting this flag to unknown. The PC/SC API does not give us any indication of whether a reader is contact or contactless, so we will have to come up with a technique to determine what type of reader we are dealing with. Also, at the bottom of the GetInstalledReaders call you will notice some string tokenization around a byte array that was converted to ASCII. The SCardListReaders function returns a multi-string value, and there is no corresponding type in .NET. Side note… This code will break if the multi-string is a Unicode value. It is probably best that this code be pulled out into a MultiString class. Movin on… the screenshot to the right shows the execution of a unit test that exercises the discovery process. You can see from the results that my laptop has a single “Broadcom Corp Contacted Smartcard 0” reader that supports the PC/SC API.

Notice the PcscSmartCardReaderDiscoveryProcess class is declared as internal, yet it can still be referenced in the unit tests? Add the below line to a AssemblyInfo.cs file and you can keep your assembly external interface clean while still providing tests for some internal code.  [assembly: InternalsVisibleTo(“SmartCard.Framework.UnitTests”)] in your assembly info file then the assembly referenced will have access to assembly internals.

At this point this feels like an awfully large amount of code to just find out if a card is inserted (about 1000 lines), but this is code that only need be written once and will allow for consistent interaction with smart cards as new readers and API’s are introduced.  I wanted to test the card insertion logic using a real smart card (I was going to use my SIM card from my phone, but I need to get a PC/SC reader that can take this device). So, it turns out I need to go do some purchasing, I found a reader that will work great and have it on order. Best deal I could find for a PC/SC compliant reader was http://www.amazon.com/gp/product/B0045BIUGG. Hope it gets here sometime next week. When it gets here I will throw up some quick info on what is in my card and we will start designing how card features are integrated into the framework, Goal is to have an example of retrieving contacts from the SIM card through he API next week.  We will try and concentrate on how we expose features that a card supports to application developers interacting with the cards.