On the road to Bandol

This argument is often used by Java Card foes, often in conjunction to the “Java Card is slow” argument. The statement is effective, because most people don’t even bother to look deeper into its meaning. Here, we do not look at detailed figures and analyses, but we do look at possible reasons why this statement may (or not) be true.

The main differences between Java Card and a native operating system are not related to Java, but to the its basic properties. A Java Card card is programmable, interoperable, and to a lesser extent, open, and the consequences of these properties are significant:

• Programmable. In Java Card, it is possible to load code into the card. There are other systems in which this is possible, including proprietary ones (a few years ago, it was possible to dynamically load SIM Toolkit applications in many proprietary SIM cards). Naturally, this ability includes a lot of risks, in particular since it allows attackers to load their own applications on the cards they attack.
• Interoperable. A Java Card application is supposed to behave in the same way on all Java Card implementations. This property is interesting for issuers, and also for attackers, who may be able to reuse the same attack on different platforms.
• Open. Java Card is not completely open, since the source of its reference implementation is not available to the general public. However, this reference implementation is available in binary form

Then, there are a few additional properties of Java Card that may make it less secure:

• Complex. Java Card is complex, and complexity is not good for security. However, the core security measures in Java Card are not that complex, and the risks are mostly functional.
• Available. For many vendors, it is far easier to buy a development kit for their Java Card implementation than for their proprietary cards. Attackers therefore have more opportnity to get cards to prepare their attacks.

All these reasons seem to imply that Java Card cards are less secure than native cards. But of course, they also imply that a Java Card card offers many more possibilities to issuers, for instance post-issuance application loading, and a relative independence from the manufacturer. In addition, these reasons also imply some advantages:

• Programmable. With Java Card, applications can evolve independently of the platform. This may allow an application provider to strengthen the security of an application aftr its issuance. Even more easily, the deployed application can evolve at a rapid pace, without requiring new masks at each iteration.
• Interoperable. Since application are portable, some countermeasures can be implemented at the application level. For instance, redundancy countermeasures are difficult to put in place. Developers are more likely to do it on portable code, because they can monitor the amount of work to be performed
• Open. The Java Card specifications have been refined for years, and the core specifications now take into account minute details and minor security issues. These specifications have also been reviewed in great details by security researchers. Some issues were even identified while building a formal model of the Virtual Machine.
• Complex. The complexity of Java Card also means that subtle things are possible. For instance, the sharing model is complex, but it also make possible interesting collaboration schemes between applications, while keeping a high level of security.
• Available. The large availability of development kits does not apply only to attackers, but also to students, security researchers, etc. This openness is good for Java Card.

The conclusion is that the above statement is not generally true. A card that includes Java Card also includes a few additional vulnerabilities, but they are well-known, and countermeasures exist for most of them. And in many cases, these vulnerabilities are balanced by the possibility to upgrade the application code more frequently.

I would therefore propose a few different statements:

• Programmable systems include more risks than closed systems.
  This is the one that Java Card foes use most, by confusing the general properties of programmable systems with the specific properties of Java Card.
• In the long run, open systems are more secure than proprietary systems.
  This issue is not specific to smart cards. For security, openness, experience, and peer review do help.
• Java Card is the most secure programmable system available for smart cards.
  This is of a personal opinion, most likely not shared by Multos people. But I believe that the amount of work put in the develoment, securization, and evaluation of Java Card systems largely surpasses whatever its competitors, including Multos, have done.