On the road to Bandol

We are getting very close to the release of Java Card 3, which should be available within a quarter from now. The impact of this release is very significant, and will introduce an entirely new way to work with smart cards. Before the release, I will discuss a few issues about this new spec.

Since this is now my specialty, I will start by the issue of security: Does the Connected Edition provide the same security guarantees as previous releases of Java Card?

The first thing to remember is that Java Card 3 will run on smart cards. The core security functions remain the same, based on smart card technology. The application’s critical assets, such as keys and authentication data, are protected by the Java Card Runtime Environment, just like they were before. These protections against classical attacks are buried deep in the operating systems, and will be around. In addition, Java Card 3 will only run on the latest hardware, on which we can expect to find the latest hardware countermeasures.

On the sofftware side, things are even better. In many ways, the Connected Edition provides a better level of security than the previous releases: on-card bytecode verification is now mandatory, the firewall and sharing mechanisms have been greatly improved, a permission model has been defined to better control the access to sensitive resources. And many more little things have been added.

Of course, all this additional security has not been added for the fun of it. The Connected Edition is much larger than the previous spec. It includes many new features, and it provides network connectivity. This means that there are many new potential attack paths, and that the new and/or improved security features are required to provide an adequate security level to these new features. On-card verification comes with a CLDC machine, permissions come with a Web server capability, etc.

Overall, the main security challenge of Java Card 3 comes from its added complexity. We all know that security is the worst enemy of complexity. Complex systems are hard to get right, and their security is even more of a challenge. With Java Card 3, we are getting a much more complex system, with a much more complex security systems. This was already the case when we moved from native cards to Java Card 2: the complexity grew, and the problems grew with it.

The consequences were not that bad. Naturally, a few vulnerabilities and bugs have been found, and Trusted Labs had its share of findings. However, hackers did not find the vulnerabilities, so they have not been exploited. In addition, since the release of Java Card 2, smart card security specialists have had to deal with two major attacks: DPA and fault induction. Most of the focus has been on exploiting these attacks, and little time has been sent of Java Card.

There is no guarantee that the same thing will happen on Java Card 3, and the level of risk will depend greatly on the level of success of the technology. If it moves closer to the mainstream, than we may know in the future the notion of “zero-day vulnerability”. Well, we’ll see …