Since then, there have been many debates about bytecode verification, and my own position has evolved over the years. Today, my opinion is a bit contrasted, some may even say contradictory. Nevertheless, here it is:

• Bytecode verification has limited use for Java Card runtime security.
• Extended bytecode verification is a very good tool for application vetting.

Let me give a few more details about these two opinions.

Bytecode verification and runtime security

The idea of runtime verification is that it is performed after getting the code, and right before to run it. The code that runs is therefore known correct, at least regarding bytecode execution (unrelated attacks remain possible, of course).

The first big issue with bytecode verification is that, in Java Card, with the split virtual machine model, verification is not performed on the card, but outside of the card, before/during/after converting the application into Java Card’s specific binary format (CAP file). Then, the application is sent to the card over some channel that may be attacked. Here, we rely on GlobalPlatform’s cryptography-based security to protect the integrity of the code. So, basically, we still need to establish trust, and we must say goodbye to the power of running untrusted code from arbitrary developers.

This is not a big issue in practice, because there is no business model that allows arbitrary code to be loaded on cards. However, this causes an organizational problem, as the verification process needs to be well organized. Researchers from Nijmegen and Limoges have shown that it is possible to fool the verification process with fake export files, and then load on a card verified code that will perform type confusion attacks.

Going beyond that, some people have designed applications that can be verified, but have been designed to be attacked through hardware attacks (fault induction, usually). Such attacks, usually known as hybrid attacks, completely fool the bytecode verification process.

Most security experts will then remind you at this point of the discussion that bytecode verification is only one part of the process, that GlobalPlatform is also important, that the origin of code is usually known, that this makes it very difficult to include attack code in an application, etc. By doing this, they are just about accepting the fact that bytecode verification is useless or at best marginally useful: the real security of cards is in the trust between issuers and application providers, and some cryptographic process. Basically, this works because the ecosystems are small enough to be controlled (which is true for cards, and fine for me).

Finally, some vendors claim to have developed defensive virtual machines, which do not require a bytecode verifier, and perform enough runtime verifications to accept any bytecode, good or bad, without any risk. In that case, bytecode verification is really useless, and I believe that it makes things much simpler. Of course, such virtual machines are difficult to design and implement efficiently, but this is definitely possible, and I think that it has been done in the past (or at least that some people has come very close to it).

To conclude, I will get back many years ago. In 2000, Trusted Logic was very proud of its on-card bytecode verifier; the technology worked, but it has not been widely adopted. I believe that the first factor was performance, as verification made the loading and linking process much slower. I also believe that a second factor, less obvious, is that on-card bytecode verification makes the card’s security more brittle, by encouraging VM developers to rely too much on static verification rather than runtime checks (which also prevent other runtime attacks, for instance using fault induction). More than ten years later, most people admit that this was not the way to go, and I just go one step further by stating that bytecode verification is not that useful for runtime security.

Bytecode verification and application vetting

Bytecode verification simply consists of a very simple static analysis of the application code. Basically, this is is a program proof, but a very simple one, whose complexity can be controlled. The objective of such simple proofs is not to demonstrate that a program is correct with respect to its specification, but that this program obeys a predefined set of properties.

For Java bytecode verification, these properties are related to the proper ues of the bytecode instructions. However, the same algorithms can be extended in order to prove many more properties, covering many aspects of application security. Among the things that can be proven, we have the following:

• Method M is not called.
• Method M is not called with arguments A1, …, An.
• Method M is always called before/after method N.
• Method M never throws a NullPointerException (or any other exception).
• Command INS can only return status codes SW1, …, SWn
• Toolkit buffers are only used when they are available.
• and many more.

Of course, there is no magic. When extending static analysis to many properties, it becomes more and more difficult to avoid false positives, i.e. errors that are caused by weaknesses in the algorithms. Put simply, an application is rejected although it is in fact correct.

Apart from working on the algorithms to make them better, there are two ways to deal with this issue:

• Providing the verification tool to developers, together with explanations about the rules to follow. Usually, it is rather simple for developers to ensure that their application can be verified, provided that they can use the tool throughout the development process.
• Use the tool in a vetting process as a guide for evaluators, who then perform additional verifications. In that case, broken rules are considered as warnings, and then verified by the evaluators. Simple applications can usually be verified easily, and more complex verification requires a few checks, simplified by the fact that the most boring tasks are performed automatically.

I believe in both approaches, but the second one has been proven efficient by my then colleagues of Trusted Labs. By using such a static analysis tool, they are able to optimize the vetting process of Java Card applications (and MIDlets, but this is another story) significantly, by allowing them to focus on the the most important parts of the applications.

In addition, this approach allows us to include many more security rules. For instance, hybrid applications must include code that can be modified into attack code through a simple attack. It is possible to build a library of patterns of such code sequences, and to check for them statically. Then, evaluators can be warned of the possible presence of an hybrid attack and check for it. This can be promising, because such checks (very boring to do, but very unlikely to lead to anything) are usually poorly performed by humans.

Finally, extended bytecode verification, or static analysis, has been proven to be a very efficient optimization tool. All optimizing compilers include a static analysis phase to perform their most complex optimizations. Java Card can take great advantage of this, because of the isolation between applications, and also because of the closed world hypothesis that is sometimes possible, when cards are closed (no additional applications can be downloaded).

So, bytecode verification has many uses in Java Card, but runtime security just isn’t the most compelling.

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.

GlobalPlatform is evolving, and the next specification (GP3) is under way. It will target the next generation of cards, and some of it has already been published in the GlobalPlatform Networked Framework. This specification supports networked cards, and it also allows the management of cards over TCP/IP, which is emerging as a new protocol on cards.

However, GP3 has the ambition of bringing back together the various documents produced by GlobalPlatform since Java Card 2.2, including all amendments. This is great news, because GP2.2 already did a great work at clearly defining and bringing together many different concepts that needed such a definition.

The future document will be based on a common architecture and security principles, with four additional parts:

• Secure communications. Building on the existing secure channel protocols, GP3 will add support for SCP81 (TLS), and for SCP20 (transport-independent security).
• Networked communications. How to manage applications over HTTP.
• Classic framework. The existing GP2.2 framework, with slight enhancements.
• Networked framework. Based on the just released GPNF, and included support for Java Card 3.0 (other frameworks could be supported in the future).

In addition, GP3 will define a set of profiles, that will implement a consistent subset of this specification. The components are mostly ready, and the intention is to work on the new specification during 2010.

Beyond specifications, there are migration issues, when someone wants to move from an APDU-based card to a networked card.

In terms of administration, there are a few major changes:

• The commands have changed from APDU’s to BER TLVs, which are defined in ASN.1 on the card.
• The secure channels have changed from specific protocols to standard Web protocols.
• Finally, although this is not related to GlobalPlatform, the formats used for downloading have changed from CAP files to WAR files.

Taken individually, all of these steps are rather easy to deal with. The principles of content management are not dramatically changed; only the protocols change. The real difficulty is to transition from APDU-based cards to networked cards. From the content management point of view, there are three solutions:

• Dual card. Such a card would fully support both mechanisms (CAP files, APDU-based GlobalPlatform on one side, WAR files and networked communication on the other). This is very simple to manage, but these cards will be too expensive.
• Migration card. In such a card, the runtime environment is unique (networked card, with WAR files), but both administration formats are supported (APDU or Web). This is an interesting intermediary point, since it will support “old” administrative tools, while allowing the deployment of Web applications.
• Connected card. In that case, all operations must be migrated to the connected network

An alternative way to deal with the migration issue is to develop an automated converter, that will transform GP2 commands into GP3 commands, and allow the management of classic applications.

From the secure channel point of view, the situation is approximately the same, with one major difference: one of the secure channel protocls (SCP81, or TLS), will be supported on all cards, at least in the SIM market.

Well, administration tool developers have some work to do. However, if card vendors produce “migration card”, things should be made quite easy on them. It is nice to see that GP is thinking about migration even before to write the final spec, as it increases the chances that we eventually get a workable migration path. This is much more important for GP than it is for Java Card, as card management tools are an important asset of the industry, making a smooth migration mandatory.