Thursday, September 25, 2008

Getting started with smartcardio

In Java 6, Sun has included a new package called javax.smartcardio. This was obtained from the work done by JSR 268: JavaTM Smart Card I/O API . Compared to previous frameworks (OCF, M.U.S.C.L.E ...) and proprietary libraries, this package is making it it easier for Java applications to access smart card. That's good in itself, and also good because it was a goal of this JSR.

Yet mailing lists are full of members asking what framework to use and how to get started, and unfortunately the example is slightly broken. So here is one that is fixed and show the selection of the Card Manager application on most Java - GlobalPlatform card in use toady.


/**
*
* This example is from http://pierreheuze.blogspot.com/2008/09/getting-started-with-smartcardio.html
*
* Using the javax.smartcardio package, it shows:
* - How to select a terminal
* - Connect to the card using a particular protocol
* - Send Command APDU to the card and process Response APDU.
* The Command APDU selects the CardManager, on a Java - GlobalPlatform card.
* So you need such a card to try this example, but it is easy to adapt the APDU to try
* on another kind of card.
*
* Copyright Pierre Heuze (r)
*
* This example is provided WITHOUT ANY WARRANTY either expressed or implied.
* You may study, use, modify, and distribute it for non-commercial and commercial
* purposes, in all cases you must acknowledge the copyright and keep this disclaimer.
*
* This particular example has been successfully compiled and tested using
* Eclipse 3.3.2 and Java 1.6.0_06. It is based on:
* http://java.sun.com/javase/6/docs/jre/api/security/smartcardio/spec/javax/smartcardio/package-summary.html
* But that one doesn't compile and doesn't show a meaningful APDU exchange.
* You should also look at the GlobalPlatform card specification http://www.globalplatform.org
* Comments welcome.
*
*/

import javax.smartcardio.*;
import java.util.*;

/**
* @author PHeuze
*
*/
public class ExSmartCardIO {

/**
* Utility function that converts a byte array into an hexadecimal string.
* @param bytes
*/
public static String toString(byte[] bytes)
{

final String hexChars = "0123456789ABCDEF";
StringBuffer sbTmp = new StringBuffer();
char[] cTmp = new char[2];

for (int i = 0; i <>> 4) & 0x0F);
cTmp[1] = hexChars.charAt(bytes[i] & 0x0F);
sbTmp.append(cTmp);
}

return sbTmp.toString();
}

/**
* @param args
*/
public static void main(String[] args) {

try
{
// Show the list of available terminals
// On Windows see HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\Readers
TerminalFactory factory = TerminalFactory.getDefault();
List terminals = factory.terminals().list();
System.out.println("Terminals: " + terminals);

// Get the first terminal in the list
CardTerminal terminal = terminals.get(0);

// Establish a connection with the card using
// "T=0", "T=1", "T=CL" or "*"
Card card = terminal.connect("*");
System.out.println("Card: " + card);

// Get ATR
byte[] baATR = card.getATR().getBytes();
System.out.println("ATR: " + ExSmartCardIO.toString(baATR) );

// Select Card Manager
// - Establish channel to exchange APDU
// - Send SELECT Command APDU
// - Show Response APDU
CardChannel channel = card.getBasicChannel();

//SELECT Command
// See GlobalPlatform Card Specification (e.g. 2.2, section 11.9)
// CLA: 00
// INS: A4
// P1: 04 i.e. b3 is set to 1, means select by name
// P2: 00 i.e. first or only occurence
// Lc: 08 i.e. length of AID see below
// Data: A0 00 00 00 03 00 00 00
// AID of the card manager,
// in the future should change to A0 00 00 01 51 00 00

byte[] baCommandAPDU = {(byte) 0x00, (byte) 0xA4, (byte) 0x04, (byte) 0x00, (byte) 0x08, (byte) 0xA0, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x03, (byte) 0x00, (byte) 0x00, (byte) 0x00};
System.out.println("APDU >>>: " + ExSmartCardIO.toString(baCommandAPDU));

ResponseAPDU r = channel.transmit(new CommandAPDU(baCommandAPDU));
System.out.println("APDU <<<: " + ExSmartCardIO.toString(r.getBytes()));

// Disconnect
// true: reset the card after disconnecting card.

disconnect(true);
}
catch(Exception ex) {
ex.printStackTrace();
}
}
}

Wednesday, September 24, 2008

Narcissistic syndrome in multi-applications card issuance

The other day, I was browsing through a copy of a smart card magazine, which featured awards for card personalization. I could not but marvel at the ever-advancing combination of high degree of technological sophistications and well crafted artworks. Surely Issuers are proud of their cards and rightly so. Or should they be?

The industry has long promised that Issuers of multi-applications smart cards will have a bright feature. The added benefits of multi-applications will attract Cardholders to Issuer. Through advanced secure mechanisms Issuers are able to rent smart card space to 3rd party. This in turn should increase the services that Cardholders could enjoy.

Potential users are like the nymph Echo with Narcissus, they are attracted by the beauty of those cards, but unable to articulate their real needs and desires. Users and Issuers send messages to each other but don’t actually listen or communicate. Users and Issuers voices are echoing to each other but without proper progress being made. Issuers like Narcissus might become more concerned by their image and finally neglect their users leaving them unsatisfied. Third-party users become shy to rent space on such cards, as any positive service they could offer would likely reinforce the image of those cards and hence benefit more to the Issuer than to themselves.

In the end, the Issuers’ businesses do not prosper as they could. As in the tale told by Ovid, this could mean for many Issuers that they would struggle or least their multi-application smart cards scheme would starve. In the tale a beautiful flower grew where Narcissus died, so there is hope that other actors could take the place of the Issuers, and new offering would grow from this.

Tuesday, August 26, 2008

What do you mean by SCMS ?

As I was on holidays, I discussed my current job with an old friend. In the middle of the conversation my friend said to me you always speak about "Smart Card Management System" (SCMS), but what do you really mean by that ? So I explain what I meant by a SCMS to him.

Back on my computer, I wanted to check my interpretation of a SCMS. What I expected to be fairly straightforward didn't turn out to be the case. I think this confusion is best summarized in this quote from Frost & Sullivan "The definition of a SCMS is found to vary depending on its use or application. In general, a SCMS must be able to provide information on the different applications present on a card. This refers to the application’s expiration, the application’s access for a particular project, the type of data that can be viewed by individuals and so on. Another key aspect of any SCMS is to provide post issuance capabilities. This allows for other applications to be added on to a card."

In fairness the first sentence of this quote does well reflect the current situation, when we are all talking about SCMS, we are not talking about the same things. If you are not convinced do a search on the web... Or are we?

Well, it is time to get back to basic and use of one of the most commonly accepted definitions of a system "A system is a set of objects together with relationships between the objects and between their attributes." (in 'Definition of System' by Hall and Fagen, 1956).

So it is time to try and describe a SCMS, as in the quote from Frost & Sullivan, following this definition. A SCMS is a set of objects: Card Image Database[1], Card Personalisation System[2], Data Preparation[3] and Key Management[4], Post-Issuance Server[5], Card Management Server[6]... Wait, a minute here is one of the paradox we are facing. We are using the SCMS terminology for the whole system and one of its part - the Card Management Server. The next contreversial aspect is the application data, this often handled inconsistently. For example, in the above quote, consideration is given in terms of application data that can be viewed but post-issuance is limited to adding application on the card and not data application update. Then depending on the market where such SCMS are deployed, other features such as cardholder data or EMV parameters might be included. Those topics subject to interpretation have created the situation in which there isn't a clear definition of a SCMS.


I think there is merit in attempting to adopt a common definition of a SCMS, similar to what a RDBMS or an Application Server is. I think the SCMS should not manage cardholder or application data, this is best left to other systems. However the SCMS should be capable of performing any personalisation either during issuance or post-issuance using those data. The SCMS doesn't attach any semantics to those data, it handles them as opaque blob according to specified syntax rules regarding their format, encoding, length, type... As for removing the confusion between the whole system and its part maybe it is time to re-introduce the Card Life Cycle terminology to describe what the Card Management Server does.

[1] That provides persistence storage

[2] That performs chip and magnetic stripe encoding and card surface printing, embossing and lamination

[3] That retrieves data from the Card Image Database and External Application and formats it for personalisation (Issuance and Post-Issuance) purposes.

[4] That provides secure persistent key storage, cryptographic services using those keys and key exchange and configuration.

[5] That supports secure post-issuance personalisation, authenticating the card and performing card updates (usually chip encoding).

[6] That provides interfaces to external systems and users and control the status and operations those systems attempts to perform on the card delegating keys and cyrytpographic operations and personalisation to other systems (KMS and SCPS)

Wednesday, August 6, 2008

A Software Tale on the Allegory of the Cave and the Prometheus Myth

Although not short of standardization bodies the IT industry (and the smart card sector in particular) is full of proprietary solutions, often but not always due to the Customer's demands for innovation.

In the smart card space, one of the major bodies is GlobalPlatform who has set itself the mission to simplify and accelerate the development, deployment and management of smart card applications. I have worked on GlobalPlatform specifications for over 9 years, back when they were called OpenPlatform and originated from a small group at Visa International. So I am definitely biased and I think there is something positive in their approach, so you have been warned.

Recently, CardBASE the company I am working for has delivered two Smart Card Management Systems, to my surprise in both cases the Customer was but impressed with some GlobalPlatform features. Some of their complaints were related to the complexity of the GlobalPlatform Messaging and the verbosity of the Profiles definition.

I felt like the prisoner in Plato's cave, and started to wonder if GlobalPlatform hasn't seen the reality but only a representation of it? Surely my Customer's criticisms were at the heart of GlobalPlatform's mission to simplify and accelerate the development.

Standardization is hard work. And credit to GlobalPlatform they have done a good job on the card specifications, which have been re-used by many others (e.g. in JavaCard 3.0), and the GlobalPlatform Card Committee has demonstrated a rather effective organisation. However the idiosyncrasies of integration and interoperability are definitely giving trouble to the GlobalPlatform System Committee. Since they issued specifications 5 years ago (a lifetime in the current technology world), there had been no major updates. The expected revisions of Profiles and Scripting have disappeared of their web site. If they have set a clear direction, they haven't made it publicly known.

In terms of system integration and interoperability, this is a strategic mistake. It would be beneficial for GlobalPlatform to become more open in order to be the Prometheus they wish to be. The Profiles and Scripting were an attempt at tackling real life integration and interoperability problem. The world is moving, and it would be beneficial for the GlobalPlatform System Committee to take into account technical advances such as web-services. Being more open would facilitate the exchange with the open source communities who are leading the way in the middleware integration and interoperability space.

As often there is a fine line between being Prometheus or the prisoner in Plato's Cave.

Wednesday, July 23, 2008

The déjà vu Java Card 3.0

Soon, the Java Card 3.0 should be widely available to developers. Looking at the list of new features and specifications I can’t help to have this déjà vu feeling, and I am not talking about the classic edition here.

Here it goes:
Multithreading
Network Communications
Access Control


When is the last time you saw such an announcement of combined technologies? Well in my view it is around 1993, when Microsoft decided to introduce Windows For Workgroup. At that time there were a lot of talks regarding the “peer-networking capabilities as a security risk” (http://www.byte.com/art/9402/sec10/art3.htm) and today things aren’t that different (http://javacard.vetilles.com/2007/12/17/countdown-which-security-in-java-card-3/)

The other analogy is the relatively low recognition of the importance of the multithreading feature. A Google search for “Java Card”+ security did return 259,00 hits, while the search for “Java Card”+ multithreading did only return 639 hits!
But think about it, today’s acceptance of computer applications is based on multithreading not security or brute power. Multithreading is the key, at the desktop users wouldn’t accept anymore to switch between applications, email/rss feeds running, download have to happen silently in the background; at the server side things aren't much different multithreading is key to scalability and performance. Users are willing to compromise (e.g. the internet before broadband) as long they could do simultaneous things.

So am I snubbing Java Card 3.0? Not at all, I just believe that the most powerful technology in Java Card 3.0 is multithreading, and it seems overlooked. It allows other technologies (Web Applications, Transactions, Inter Application Communications…) to deliver their full potential. We have the potential to see there a revolution similar to what was the Internet to the PC back in the mid 1990’s, then to B2C and B2B applications.

So is multithreading, communications, access control enough to make a smart card revolution? Probably not, a killer app is required, as what the web browser and search engine were to the web. And by the way such a killer app and its usage is likely to suck up most of the resources that a moment ago seems to be unlimited.

Java Card 3.0 has the potential to bring a breath of fresh air, to a confused card industry. But more efforts have to be made to make it sexy, the best new concept in the world won't make money unless people know it's interesting and become enthusiastic about it.

So what will make you say hello to Java Card ?

Wednesday, July 16, 2008

The Sisyphean Challenge of Security

Recently, the news broke that NXP is suing Radboud University Nijmegen (in the Netherlands), to block publication of a research paper, “A Practical Attack on the MIFARE Classic”.

Well what’s the big deal? Mifare was always known to be very weak, a brute force attack would take only days. So have the researchers done more damage? Well they have exposed two flaws:
  • Through reverse engineering they have identified new vulnerability of the MIFARE card and its cryptographic algorithm that makes attack works even faster.
  • NXP adopted a security by obfuscation approach for the MIFARE card that has lead to poor design and above vulnerability.
The second flaw is embarrassing, but there is nothing new. History will tell that as far back people invented cryptographic mechanisms other people found ways (sometime inventive ways) to break it.

A very good example is the work by Paul Kocher on Simple and Differential Power Analysis (SPA/DPA). In the mid 1990’s people look at smart card as a practical media to securely store and perform cryptographic operations using secrete and private keys. Such keys are stored in unreadable memory and the cryptographic operations rely on practically unbreakable algorithm (e.g. RSA algorithm security is based on the difficulty to factor large numbers into prime factors). None of those criteria were successfully challenged at that time (neither they are today, but it doesn’t mean they won’t be tomorrow). But the combination of the two was surprisingly insecure. By carefully measuring the power consumption (or its variation) during cryptographic operations, the researchers thanks to the knowledge of the algorithm involved managed to discover characteristics of the key and eventually recover the key itself.

The reality is that you should never under-estimate your opponent. In 1857, this costs the life of Mary Queens of Scots. While she was plotting to murder Queen Elizabeth, she sent encrypted messages to her supporters. Those messages were intercepted and decrypted, and Mary Queens of Scots was decapitated.

Events like this lead August Kerckhoffs to say as far back as in 1883, “any ciphering method can be known to the enemy and the security of the whole system depends only on the choice of key”. Today, this principle is still valid. Essentially it means that the design of a cryptographic system should be published and be subject to peer review, the less secret in the cryptographic system the higher the chance for it to be secure. Delaying the publication of such design often only delay the identification of flaws and increase embarrassment of the designer and the cost of fixing it. Unfortunately it is only a matter of time, as theoretical and technical advances are made, for even the most scrutinized cryptographic systems to reveal flaws.

So this is a never-ending quest, but the cryptographer should take comfort like Sisyphus that "The struggle itself towards the heights is enough to fill a man's heart."

1- In P. Kocher, J. Jaffe, B. Jun, "Differential Power Analysis," Advances in Cryptology - Crypto 99 Proceedings, Lecture Notes In Computer Science Vol. 1666, M. Wiener, ed., Springer-Verlag, 1999.
2- In August Kerckhoffs « La cryptographie militaire », Journal des sciences militaires, vol. IX, pp. 5–38, Janvier 1883, pp. 161–191, Février 1883“toute méthode de chiffrement est connue de l’ennemi et la sécurité du système ne dépend que du choix des clés.”
3- In Albert Camus, Le Mythe de Sisyphe, Paris, Gallimard, 1942. ” La lutte elle-même vers les sommets suffit à remplir un cœur d’homme. Il faut imaginer Sisyphe heureux.”

Tuesday, July 8, 2008

Adaptogens for Software System ?

A general problem of Card Systems is that their high level of complexity is hindering their adoption. This complexity comes from the high number of components and technologies employed (databases, application servers, web-based interfaces for users and systems, cryptographic and security mechanisms, imaging and printing...). For the system to work as a whole each components and technologies must work individually as well as integrated within one single system.

In fact complication, rather than complexity, would be a better term to describe the situation, as the root cause of the problem is the number of interactions due to the aggregation of many components and technologies. Complexity would rather apply to components which are more than the linear functions of their properties. In Card Systems security or biometrics mechanisms are intrinsically complex since you can not comprehend their whole behaviour without complete knowledge of all its properties and rules that governs them, e.g. the factoring problem in public key (PK) cryptography. But many components (databases, application servers, printers….) are straightforward enough and can be described in simple –albeit lengthy, terms.

So having make this clear distinction between complexity and complication, I am now taking the artistic license to use complexity in place of complication.

This complexity problem is nothing new, and it is faced by any large modern distributed computing system. Organisations are employing large-scale computer networks to deploy their systems. Those systems are performing a wide variety of tasks ranging from database processing, workflow, to presenting web content and to helpdesk… Often if one task aborts unexpectedly the whole system is put to a halt or don’t perform correctly.

So how do we tackle this problem? The industry has come with various solutions, that we will review shortly then we will see what further steps we could take.

Looking at the hardware and software stacks, we first find fault tolerant systems that address hardware issues. Here redundancy is the key word. UPS (uninterruptible power supply) powered computers run on multiple CPU (central processing units) and rely on RAID (Redundant Array of Independent Disk) system to store data, on dual network cards to access the network. All those hardware components are hot-swappable making the system tolerant to hardware fault.

However in any computer systems there is much more than hardware that can go wrong. Taking an analogy with the human body, it is great to have 2 kidneys, 2 lungs, 2 eyes, 2 hears, 2 hands… but you also need mechanisms to regulate your heartbeat, to control temperature, to alert you when you require food… Similarly in computer you also need mechanisms to load balance processing request, to control i/o activity.

IBM, in its effort toward tackling the skill shortage within the IT industry, has come up with the concept of autonomic system. And right now, the autonomic technology from IBM and other vendors build-up on mechanisms designed for fault tolerant systems to provide more resilient and responsive IT infrastructures. This includes monitoring application; supporting cluster-based deployment with and automatic node switch over, managing basic network and database parameters. Such innovations are really in the right directions. For example, in today’s world there is no reason why a database application should fail because a tablepsace got filled-up and didn’t extend automatically. As Alfred North Whitehead said "Civilization advances by extending the number of important operations which we can perform without thinking about them.", so would computer systems it seems; or a more exact paraphrase would be "Computer Systems advance by extending the number of important operations which they can perform without a Human thinking about them.”. This is similar to the reflex system in the human body, you don’t need to engage the brain to remove your hand from an hot source that will prevent you to get burn or to increase your heart beat in response to an additional effort.

Still there is more to be done, computer systems need to evolve to consistently adapt to their ever changing environment. So I am very hopeful of initiatives such as Spring Dynamic Modules for OSGi(tm). As for the human body, computer system should have the ability to take on new skills, update existing ones and get rid of bad old habits. The ability to dynamically add, remove, and update modules in a running system, goes a long way toward this goal.

These mechanisms are important as they provide a way to adapt to radical changes to the environment. However, what seems still to be lacking is the ability for software system to counter adverse user interaction, unexpected request or response with other systems. Today’s solution is in the initial design that can be validated through negative testing. But we haven’t engineered yet something like adaptogens, which are non-toxic metabolic regulators that can enhance metabolic homeostasis during stress, or in simpler terms increase the body’s resistance to adverse physical, chemical, or biological stressors by raising non-specific resistance toward such stress. This isn’t like Dynamic Modules, discussed in the previous paragraph, such mechanisms should work without a Human thinking about them.