Kapil Sachdeva's Blog - SmartCard Serenity

In 1998 when Schlumberger Smart Card Systems (now Axalto, Inc) introduced JavaCards, application development for smart cards saw a revolutionary change. Being able to program in high level object oriented language not only speeded up the application development but bring interoperability of applications with other card manufacturers. JavaCards are/were definitely a mile stone in SmartCard evolution.

Though JavaCards brought Java to SmartCards application model remained essentially the same i.e based on IS07816-4 commuication concepts (commonly known as APDUs). A developer of on-card and off-card applications need to be an expert of this constrained APDU protocol.

With .NET SmartCard we introduce a new Smart Card running a CLR, pure subset of ECMA framework libraries and state-of-art SmartCard operating system. This time we did not want to invent something new as far as appication frameworks are concerned as it not only make developers learn new apis but does not fit in existing off-card frameworks.

Here I am describing our communication framework and will blog other exciting feaures in coming days.

Application model for .NET SmartCard applications (or better call them services) is subset of .NET Remoting framework with transport channel based on IS07816-4 protocol for smart cards. The framework hides all the details of underlying transport protocol from developer. Lets look at the snippet of simple on-card application:

public class MySmartService : MarshalByRefObject{

      public static void Main(){
         APDUServerChannel channel = new APDUServerChannel(0x12);
         ChannelServices.RegisterChannel(channel);
         RemotingConfiguration.RegisterWellKnownServiceType(typeof(MySmartService), “MyService.rem“,  WellKnownObjectMode.Singleton);
      }

      public string SayHello(string name){
         return "Hello " + name;
      }
}

As you can see, other than Transport channel there is no difference between on-card & off-card remoting services.

Real benefit of this application model is encashed when we write client application where again only transport channel needs to be changed.

public class MyClient{

     public static void Main(){
          APUDClientChannel channel = new APDUClientChannel();
          ChannelServices.RegisterChannel(channel);

         MySmartService serv = (MySmartService)Activator.GetObject(typeof(MySmartService), "apdu:\\selfDiscover:na:0x12\MyService.rem");

         Console.WriteLine(serv.SayHello("Mr. Bill gates"));

    }

}

On-card Remoting framework is extensible also as you can write custom sinks.

Sometime back I also wrote a version of SoapChannel (ala WSE2.0 Custom transport channels) which provide seamless connectivity to .NET SmartCard Services from WebServices based on WSE2.0 application framework. Will do a writeup on this later.

Transactions and roll back of data form the core feature of smartcards. These features implied that if tearing or exception occurs during execution of method which was under a transaction then all the modifications made to the application data are discarded or contents should be rolled back to old values. This is all good and fine but sometimes need arise when you would want a particular method to be under transaction & some field/value to be updated irrespective of the fact that tearing occurred or not. The one famous example is that of PIN verification and try counter. PIN verification is under transaction and since this method plays with the try counter decrementation you want that try counter updates to be out of transaction else if card is pulled out during PIN verification, try counter won't decrement and thereby giving the hacker infinite chances to break your card. Mostly (I hope it should be the implementation in other vendor cards) PIN specific libraries take care of this.

In .NET SmartCard we expose this feature ie Out of Transaction counters as an API as we feel that there would be many places where such kind of counters will be required. The class is called TryCounter and have a look at its usage.

public class MyClass
{
  // counter which should be out of
  // transaction
  TryCounter _myOutOfTranCounter;

  MyClass(){
     // 0 here is the initial value
     _myOutOfTranCounter = new TryCounter(0);
  }

  // MyMethod which is under transaction
  [Transaction]
  void MyMethod(int paramA,int paramB){

    // Update the counter reflecting how
    // many times i am called whether or
    // not tearing occurs during execution
    myOutOfTranCounter.Value++;

  }
}

Other methods/properties available in this class are :

Reset() : Reset the counter value to the initial value (value specified as param to the TryCounter ctor).

InitialValue [property] : Get or Set the initial value of the TryCounter.