The two concepts of open source and smart cards have not gone well together. There are some projects about specific applications and corresponding terminal-side software, such as the Muscle project for Linux, and the JMRTD library for e-passports (if you have one that you want me to mention, let me know).
However, there are really few open source developments in the area of smart card operating systems and runtime environments. This is why the recent release of the OPAL library by the University of Limoges is significant. This library offers a client-side implementation of the latest GlobalPlatform specifications, greatly simplifying the development of applications that manage applications on smart cards.
In particular, this development could be the basis for interoperable and open smart card testing tools. For instance, the Mesure project, which defines benchmarks for Java Card, could use an open and complete GlobalPlatform implementation.
Now, can we go further than that? Is it possible to really get into the smart cards, and have open source operating systems, or parts of operating systems? Well, there are a few good reasons not to do it:
- Licenses. The specificatoins like GlobalPlatform and Java Card are free to access, but after going through a click-wrap license, including some restrictions. For GlobalPlatform, the restricions are limited, mostly because GlobalPlatform is a community effort, and both the license to use the specification and to sell products bassed on it are free. The Java Card license is more restrictive, because it is owned by Oracle. Java Card is free for developers, but implementers need to pay a license.
- IP rights. The smart card industry is highly competitive, and has not always been very open source-friendly in the past. There are literally thousands of patents that have been filed on the technology, and it is hard not to infringe on any of them while writing a smart card operating system. Companies don’t have to enforce their IP, but they can, which means that any open source project is in under a constant threat.
- Security. This argument may not be as strong, but the smart card security community is very well organized, with manufacturers, labs, national authorities, etc. They have developed a significant set of documentation and guidelines aound Common Criteria certifications of cards, which is one of the best industry efforts available today. The industry may not be eager to see an active open-source community working on attacks and countermeasures in parallel to their own efforts. And if they are not happy, they may activate the IP rights argument.
Of course, there is here a difference between academic projects and industrial projects. Consider Simulity’s DKard project, a microcontroller (i.e., smart card) virtual machine based on Android’s Dalvik VM. Google may have published Android as an open-source project (we can assume that the spec lcense part is covered), but this doesn’t make them safe from IP rights. If they start encountering the slightest success, somebody will remember that they infringe on their IP; and since this somebody is likely to be much larger than Simulity, this is not good news.
From my point of view, we can close the industrial part. It would be foolish to start a company with a business model based on open source software for smart card operating systems, unless it is strongly backed by at least one major manufacturer, with the ability to protect the small player from IP claims by competitors.
Now, we are left with the academic projects. There is an active research community around smart cards, focusing in particular on security aspects, particularly in Europe. One of the main problems faced by this community is that they don’t have a good playground: there is no open smart card operating system platform on which they can experiment.
Card vendors are not too keen to see academics use their products for experiments and attacks, because they don’t want to see publications claiming that their card was broken. As a consequence, card development kits usually come with licenses and non disclosure agreements that do not allow the use of the cards for research purposes.
The “obvious” solution is to develop an open source platform, just for research purposes. But then, we get back to the licenses and IP and everything. There are several choices, every one with pros and cons:
- Implement Java Card. Here, a conflict is likely with the industry, especially if the implementation is good and can help outsiders develop/enhance their products.
- Implement something else. This could work, but the difficulty is to find the right balance between mimicking Java Card and differentiating from the spec.
I don’t believe that the solution is ready here. Without industry support, getting funding for the research will likely be difficult. And the industry players may not look forward to sueing a few academic institutions. In the end, the stakeholderes need to talk to each other, really looking for a solution that suits everybody. This discussion never really took place in the past, let’s hope that it will happen some day, so we can at least remember that we tried.
Thoughts and remarks welcome, as comments or direct contact.