On the road to Bandol

The certification of smart cards is a recurrent issue. Most issuers have their own requirements, which can vary greatly, even in the same industry. In addition, regulators can also get involved and make additional requirements.

Let’s start by one example, the banking industry. Most issuers don’t define specifications, nor do they perform security certifications. Instead, they delegate these tasks to specialized companies, like Visa, MasterCard, or JCB. At that stage, things start becoming difficult. Although the three companies cited above share common specifications in EMVCo, their processes are completely different. Some focus on a process that defines a common minimum level, whereas some others prefer more flexible solutions that encourage all vendors to improve security. Of course, some of the largest issuers can add their own requirements. In addition to that, national bodies and bank associations can add their own country-specific requirements (this is very common in particular in countries that have been using smart cards for a long time, like in France).

Other industries have their own issues. The Pay-TV industry has very strong security requirements, and every solution provider has its own set of security requirements, which they of course don’t want to share with their competitors. Digital signatures require a Common Criteria certification with a specific Protection Profile. Various identity programs have their own requirements. Of course, let’s not forget that many issuers require several sources, so porting on different chips has always been an important activity.

This looks really ugly, and we look like a doomed industry. Well, things were not that bad a while ago. A different product was developed for every market/ association/ country/ issuer, and each one had its own certification process. The entire process was very expensive, but smart cards were (relatively) expensive, and the entire thing was healthy.

In the recent years, things have changed greatly, in many different ways:

• Many products are often based on the same base, often a Java Card platform.
• The smart card market has grown in numbers, and the proce of smart cards has considerably fallen.

The use of open platforms has allowed vendors to save on development effort, by reusing the same platform code, and also by using high-level languages, allowing some code to be directly reused, without porting it. At the same time, the price of certification has not fallen; instead, it has increased, as new attacks kept on coming, and as the processes became more formal, for instance with ITSEC, and then Common Criteria. The consequence is that the relative cost of certification keeps on increasing, and over the years, it has become a bottleneck.

Vendors have started to complain bitterly about these high costs, and in particular about the fact that they pay laboratories again and again for performing the same work (or at least, very similar work). These complaints take many forms, but I think that I can group them in two categories:

• All private evaluations must be replaced by a single Common Criteria evaluation for each product. This line is pretty simple: make sure that every product is only certified once. The problem, of course, is that this certification must cover all requirements for that product (see above for a reminder of the problem), which is not always realistic.
• The Common Criteria process is too heavy, too slow, and too bureaucratic to be compatible with our industrial process.. The point is here clearly a reaction to the Common Criteria process: an evaluation can take over a year, it requires a big documentation effort, and laboratories can be tempted to focus more on bureaucracy (verifying paperwork) than on the quality of their vulnerability assessment. As a result, faster and more focused certification processes sometimes yield better results.

Both complaints are somehow right: repeated certifications are inefficient, and Common Criteria can also be inefficient. However, none of them brings a realistic solution. How can Common Criteria deal with the conflicting requirements of multiple issuers? If we remove Common Criteria, who will be in charge of defining the certification criteria?

Very recently, issuers (in particular in the telecom industry) have started to embrace true multi-application cards, on which sensitive applications (which require some kind of certification), owned by multiple providers, can be added after the issuance of the card. Here, the efficiency issue becomes a feasibility issue, as we don’t necessarily have the complete list of target applications when the card is first deployed.

I believe that the principles of the solution are quite simple:

• Multiple certification requirements and formal processes cannot be avoided. We will not make all issuers agree on security requirements, and if we remove Common Criteria, we will have to replace it with another similar scheme.
• The certification process must be optimized in a way similar to the development process. The idea is here to save by reusing the certification of the platform, and by limiting the porting costs from one platform to another.

In order to put these principles in action, we need to work on a few items:

• Optimize the composition of certifications.
• Define and maintain detailed and accepted security requirements for Java Card platforms and applications.
• Include these principles in the definition of future platforms, and encourage issuers and their representatives to consider them in the revision of their security requirements.

Some people in the industry are already working on this, and I hope that we can succeed in the (not too) long run. If you are interested in joining this effort, let me know…