On the road to Bandol

The discussions in the Java Card Forum, and between Sun and its licensees are of course private and confidential, but there have been several presentations (including the presentation by Thierry Violleau at e-Smart [VR06]) about this topic. Everybody can therefore derive that the next release of Java Card will define a smart card as some kind of a personal micro-server.

This is a significant move from the existing framework, which is based on smart-card specific standards such as ISO7816. Of course, a smart card remains a small object (at least compared to a standard server), so we can’t take the entire J2EE framework. This means that some subsetting is required, which is a difficult problem.

We faced the problem before, at a different level. For Java Card 2.0, we had to subset the Java language, and for 2.1, the Java virtual machine. However, the problem is much more difficult this time, because of the sheer size of the thing to subset.

The first thing to do is to check the features that will be required:

• Network connectivity. The card needs to be connected through TCP/IP, and some of its applications will be servlets.
• Static and dynamic content. An application needs to be able to include static content (for instance, its look and feel) as well as dynamic content (the actual content, whether it comes from the card itself or from elsewhere).
• Access to mass storage. If cards have a lot of memory, it definitely is a good idea to make this memory accessible for applications, for matters like DRM (business-correct) or private data encryption (nerd-correct).
• Smart card security. Whatever marketers say, security remains a major differentiator for smart cards, and most likely one of its most important use cases. But this security is not your server security, because a card is not a typical server.

All we need exists in Java today, and most of it even exists in Java ME. However, we have to subset, to make hard decisions about each feature: keep it or throw it? Designing such subsets is difficult, and especially when the uses of the API being designed are not completely known.

I will just illustrate this on the security issue. The security model that has been disclosed by Sun at JavaOne and e-Smart is quite complex, and also quite similar to the one in use on servers. However, there are significant differences between a server in a rack and a server in a pocket:

• The server in a pocket has been designed to host several applications, which may collaborate even if they only share limited trust.
• The server in a pocket includes things like GlobalPlatform to manage its applications. It can host several applications, possibly by people that don’t trust each other, but they will always share some trust somewhere.
• The server in a pocket is quite likely to be difficult to reach for malware, for instance because of private networks, or more simply because it sits (unconnected) in a pocket.

There are many more differences like that, more or less subtle. These differences should of course be taken into account in the design of the new Java Card platform. Hopefully, we will take them into account, and make a nice platform.