These 20 years have been quite an interesting ride. Java Card is an amazing technology, just as successful as it is understated. Java Card has been deployed on over 15 billion devices since the first deployments in 2000, its deployment numbers have been growing steadily for 15 years. With the current movements in the SIM industry, it is hard to guarantee that this growth will be sustained over the next years, but Java Card is at least guaranteed to have a very fat and very long tail before it disappears.

I will publish a few entries on Java Card, starting here with a few comments on how improbable this success has been over the years.

An immature technology for an immature industry

Initial work on Java Card started in 1996 at Schlumberger’s research team (now part of Gemalto), as all card vendors were looking for solutions to run scripts on smart cards, mostly for supporting the SIM Toolkit framework. At the time, every major vendor had developed a proprietary solution, usually based on an existing programming framework.

In 1997, smart card issuers were starting to ask for interoperability between vendors. The Java Card Forum was founded in the spring as an answer, although few of its members were convinced that it was the way to go forward. Sun Microsystems was invited as owner of the Java technology, smart card vendors became Java Card licensees, and Sun Microsystems took the responsibility of managing the specification and related technologies (reference implementation and compliance kit). Sun didn’t have any experience about smart cards, and in the first meetings, their representatives clearly showed it. Sun then hired Integrity Arts (a Gemplus spin-off) as consultant, and rapidly acquired them, getting expertise in-house.

Java was not well suited to the smart cards available then. The language was easy to learn, but the virtual machine brought an overhead in both size and performance. At the time, it would have been possible to design a more suitable standard for programming smart cards, but the industry has not been able to organize in order to define such a standard.

Java Card became an API specification rapidly with version 2.0, but this version was short-lived, and quickly replaced by version 2.1, which also included a virtual machine specification, and allowed binary Interoperability between products. At about that time, the mobile operators became really interested, a SIM toolkit API was defined, and the deployment began around 2000.

15 years later, this adoption of a poorly adapted technology by an immature industry has become an asset. Because Java Card was a bit too ambitious at the time, and thanks to the continuing success of the Java language, Java Card has now become a mainstream technology, which in 2015, fits the needs of the smart card market, and is present on most open smart cards, and roughly half of the microprocessor cards sold worldwide. In the end, it pays to be inadapted.

Mostly an ecosystem

In the late 1990’s, the first marketing sentences for Java Card were directly taken from Java, like “Millions of developers”, or “Write once, run anywhere”. The one specific marketing argument was about “Running multiple applications on your card”. Fifteen years later, here is a factual status:

• Hundreds of developers (tens of expert developers), mostly working for smart card vendors or for a few specialized consulting firms.
• Most applications written for a single card, or at least for a single issuer.
• Most applications written by a card vendor, and running only on a single vendor’s cards.
• Most cards running a single application.

The next question is: why is Java Card still around if it is not used? Well, in fact, it is being used, just not in the ways that people initially planned. In fact, an essential factor in the success of Java Card has been the certification of cards. In many cases, once a card is deployed, there is no (efficient) procedure to update the card to fix a bug or a vulnerability. Therefore, cards are heavily tested before to be deployed, and most vendors require several levels of certification, including a functional certification and a security certification.

These certification processes are costly, both in developer resources and in laboratory fees. Over the years, efficient certification has become an essential aspect of card development, and Java Card facilitated this in several ways:

• A reference for core functionality. The Java Card specification defines a set of core functions which can then be used to develop applications (cryptography, I/O, storage, appication isolation and sharing). It then becomes possible to test separately these core functions (by evaluating a Java Card platform) and the application using them (by evaluating a Java Card applet). This can lead to economies of scale.
• Reference applications. Some issuers and actors, notably Visa, have written reference versions of their applications, which have been thoroughly tested on compliant Java Card implementations. Vendors who use these reference implementations can simplify the certification process.
• Building experience beyond developers. Laboratories, certification authorities, security consultants all have worked with many Java Card platforms and applications over the years, and now feel confident about their ability to use, test and certify such cards in different configurations. This is the ecosystem part.

In the past few years, the strength of this ecosystem has been a key asset for Java Card, together with the fact that it remains today the dominant platform for defining APIs for smart cards, regardless of the target vertical (once again an ecosystem aspect).

Not dead, not frozen, just slow and conservative

Another striking feature of Java Card is its lack of evolution. The core features of the platform have remained vastly unchanged since release 2.1. Several attempts to make the platform evolve have failed over the years:

• Java Card RMI was introduced with Java Card 2.2, with the objective of making it easier to design new smart card applications, but it was never adopted by the community. Support of Java Card RMI has been optional in the latest releases, and it was close from being deprecated a few times.
• Java Card 3.0 Connected was a bolder attempt at reaching new markets, this time arounod Smart Card Web Servers. This specification is very nice, and it defines a Web application model that can be implemented in half a megabyte, all included (OS, VM, Web container, content management, and a few apps). Yet, smart card web servers never caught, and this specification has never been implemented in a real product since its 2009 release.
• An annotation framework for security interoperability was added recently, but the industry hasn’t been able to agree on a semantics for these annotations, and it has not been adopted.

In the latest 3.0.5 release, we have attempted to add a few simple things, hoping that they will be adopted, but this will only happen in a while, because of another interesting specificity of Java Card. It takes around a year to develop a new platform after the release of a specification, at least another year to get a full certification (functional and security), and another year to sell, produce and deploy it. That’s about 3 years between the specification and the actual availability of products.

This development rate partly explains the slow evolution of Java Card. The smart card ecosystem globally evolves very slowly, and to observers who are used to Web-like evolution, it may look life completely frozen. However, it keeps evolving at its specific and very slow rate. Since 2009, Java Card has become much better adapted to contactless cards, it has adopted a number of cryptographic technologies, and a few other features have evolved to follow the evolution of smart card hardware. Such changes are invisible to the non-specialist, but they keep the Java Card framework in synch with smart card technology, and this is what really counts.

The value of the first wave was in the information itself (static Web, a.k.a. Web 1.0); the value of the second wave was in the sharing of information (social web, a.k.a. Web 2.0); the value of the third wave will be in the personalization of the Web experience. One of the key points is here the selection of information, the curation of information, as we are increasingly overflowed with information and content. Companies like Louis Ray’s my6sense are proposing to do just that.

On his post, Doc Searls compares the client-server relationship to a calf-cow relationship, with a strong dependency relationship between a service provider and its users, as exemplified by Facebook, Twitter, and many more. This kind of relationship puts the entire control in the hands of the service provider, which seems very wrong. Doc Searls’ example of Apple’s App Store conditions is the perfect example of this flawed relationship.

Everybody agrees that the personal Web includes personal mobile devices like smartphones and tablets, combined with contextual information, in particular location information. Personal devices will be important for building the personal Web, but not every application running on these devices belongs to the Personal Web. Old-style social services and information feeds will still be around, but making them “personal” on a mobile device is not sufficient.

A personal application needs to truly aim at providing the user with the best possible experience. In this best possible experience, of course, spam, unwanted ads, and other useless content should be gone. This can of course be considered as a threat to a flourishing business model by mobile marketers around the world. However, some other guys will see that as a wonderful opportunity: how to work with the users to bring them commercial information that they value? After all, most of us are actually considering a few purchases at any given time, and timely information about the offer would have a wonderful conversion rate. Let me take an example: I am currently looking for a bed for my son, because his bad quality bed broke. Today, I have two solutions to get information about beds: (1) take my car and drive around the area looking at furniture stores, or (2) Google what I am looking for, and search individually on each site. Both approaches are terribly ineffective, I just want to find a “bed for a 5-year-old boy, including plenty of storage, and if possible a small pull-out desk”. Well, this search is almost intractable, and I can’t find what I am looking for.

Of course, that is what VRM is about. Together with personalized curation, this is an important part of the Personal Web, but there is more into it. In particular, I want to regain ownership on my data, because it is mine. And I want to decide with whom I want to share it, and be able to change my mind.

If we go beyond VRM applications, the Personal Web will affect all aspects of computing. Let’s consider one of my favorite examples, Java Card 3.0 Connected. So far, this technology has failed to find a market. The main idea was to sell super-SIM cards to MNOs, allowing them to push more (static) content and more (social) services to their (captive) users. It didn’t work, for many reasons, but mostly because “smartphones ate our market”.

Java Card 3.0 Connected has some advantages, though: it is local, it is secure, it provides a Web interface. And it is really personal, in particular when it sits in a mobile phone. So, maybe that we can try to find someone (MNO for a SIM, but maybe also a phone manufacturer for an embedded SE, or anybody else for a secure SD Card) who would like to exploit this personal, interactive, secure token to bring elements of the Personal Web to their users. Plenty of applications are possible; the business model don’t necessarily exist today, but the space will be taken before the business model is ready.

So, let’s see who takes the space …

Connecting home appliances sounds kind of obvious, and the ubiquitous availability of smartphones and tablets makes it even more obvious. I have many times left my clean laundry sit in the washer for hours, just because I turned the thing on and forgot about it; no doubt that a message on the phone in my pocket would be a welcome reminder.

The devices shown by LG seem to be rather high-end stuff, with rather large LCD screens for the interface (and no buttons, so these screens must be tactile). Apparently, these devices are running Android, which could mean that we will soon find Android applications targeted at washers and refrigerators. This is great news at least for one point: I have no doubt that independent developers can imagine applications on appliances that LG wouldn’t dream about, and opening this market could lead to real improvements.

Now, I am wondering: do we need a smartphone in every home appliance? Do we need a 7″ screen on every appliance? A few rich geeks may answer yes, but most people are quite likely to stick with much simpler interfaces and cheaper electronics. You may have guessed already where I am heading: Java Card 3.0 Connected is the way to go. It has many qualities required to do that:

• Web-based application model. A Java Card 3.0 servlet can provide the required communication link between an appliance and the controlling device, using a fairly simple and well-known application model.
• Dynamic management of applications. With the addition of GlobalPlatform specs, Java Card 3.0 supports a wide range of application management models, and it could in particular be used in an application store model. For those who doubt, we can remind that the Java Card/GlobalPlatform is already used on a few billion devices, so scaling up is not a major issue here.
• Small footprint, possible single-chip integration. Adding a full Android device to a US$1,000 washer is not a big issue, but adding the same device to a US$100 coffee machine will have a significant impact on its price.

Of course, it lacks a few things, in particular regarding I/O’s. In order to control an appliance, Java Card 3.0 needs to be able to control a few I/O ports, including a small display. But these APIs already exist in other embedded Java dialects such as MIDP, so why not doing it?

The bottom line is here that we can achieve with Java Card 3.0 Connected results that are quite similar to what is possible with Android, while making it accessible to a much wider range of devices. The only question is: Who is going to define the few missing APIs and make a reference design for a network extension board for appliances? I would definitely like to be part of that, but I’m not the one who will do the electronics part.

The first presentation was given by Guillaume Barbu, from Oberthur, about combined attacks on Java Card 3 Connected. Combined attacks are interesting in principle, because they suppose that the attackers are intelligent enough to avoid bytecode verification, while still having the possibility to perform attacks.

A very short reminder on what this is about: in a combined attack, a legal Java Card application is designed to include code that is vulnerable by design to well-known hardware attacks. When the hardware attacks are applied, the legal application becomes a malicious application and performs an attack on the hosting card.

Nothing new here. Guillaume made a first presentation about this last year, and we made presentation about the same topic at Cardis in April. The novelty comes from the exploitation that Guillaume makes of combined attacks. Since he is targeting Java Card 3 Connected, his target is the pool of interned strings. Since strings are everywhere in JC3 Connected, and since they are often used to make security decisions, this attack could be very powerful. For instance, the parameters of permissions are strings, and playing with these strings could greatly extend the permissions granted to an application. These attacks are interesting, but, from the feedback I got, the countermeasures proposed by Guillaume are a bit weak. Well, this reminds us that Java Card 3 Connected remains an implementation challenge.

The other presentation was given by Emilie Faugeron, from Thales ITSEF. Thales has found a bug in a bytecode verifier, and discusses the consequences of such a bug. This story has been unfolding for a while, as the bug has been known from the card security community for a while. I am glad that it finally becomes public, which allows us to comment on it.

When there is a bug in the verifier, it means that a potential attacker could load a malicious applet on a card without being detected by the verifier. The consequences are basically the same as for combined attacks, with the advantage that there is no hardware attack to perform after the loading.

The question is here to know what we should do about it. Thales proposes to evaluate the bytecode verifiers (on-card and off-card) during a Common Criteria process. This sounds obvious at first, but there are significant differences between a bytecode verifier and a Java Card Virtual Machine:

• First, a bytecode verifier is a highly standardized piece of software. On other platforms, VM vendors are not allowed to modify the verifier’s reference implementation. The specification of a verifier is always the same, and it changes very rarely.
• In Java Card, there is an exception with on-card verifiers. Because of the high level of optimization required, a few differences may be expected. For instance, Trusted Logic’s verifier requires an initial normalization phase before to load the application; however, the combination of normalizer and verifier implements exactly the same specification as other verifiers.
• There are very few implementations of verifiers that are publicly used. The verifiers are always the same, and I would assume that Oracle’s verifier is the most commonly used. In that context, building a viable certification environment is hard.
• There already exists significant test suites for Java Card bytecode verifiers. Trusted Logic has one, of course, to test its own verifier. Oracle has a very significant one, which it uses to test its verifiers. And obviously, Thales has one now. And I assume that other actors have some.
• Testing a bytecode verifier is a hard task. A bytecode verifier is a static code analysis tool, and these tools are well-known to be very difficult to test, because of the level of abstraction required.

So, what can we do? One option is to follow Thales’ advice. This sounds tempting for me; I have strong ties with Trusted Labs, which could perform such evaluations, we have access to a test suite, and we have been developing and testing static analysis tools for about ten years. If I am wrong about the potential business, this is likely to happen.

The alternative way is to remind ourselves that a bytecode verifier should follow a reference design, preferably provided b yOracle. This is what happens on all other platforms, and there is no reason to keep a Java Card exception. For such pieces of sofftware, which evolve very slowly, nothing beats public scrutiny. There are many researchers (for instance, wy friends from Limoges and Nijmegen) who would love to take a look at a bytecode verifiers and its tests.

I don’t have a plan for this, but it really looks like, in this matter, collaboration between all actors sounds much better than competition between evaluation laboratories. We’ll see what happens.

A Java Card 3.0 card has plenty of countemreasures against logical attacks

• Context isolation. Objects from an application can’t be accessed from another application. This “firewall” si specific to Java Card.
• Code isolation. Code from an application cannot be accessed from other applications, making it difficult to indirectly access assets. This is the clas loader mechanism, inherited from Java.
• Bytecode verifier. Will reject all kinds of malicious applets, so logical attacks based on “bad” code can’t work any more.

A combined attack consists in loading an application that is well-formed, and will nevertheless attempt to act illegally, for instance by accessing another application’s data. Under normal conditions, the firewall will make this impossible. But if we add a fault attack at the right time, we can allow the illegal access.

The example given by the student consists in illegally accessing a method from another application. The class loader hierarchy normally makes this invisible. The idea behind the attack is to use a class with exactly the same definition on the attacker’s side.

Of course, if you attempt to cast a remote object into the attacker’s class, the different class loaders will lead to an exception. By putting a fault on the checkcast instruction, we can actually perform this cast and invoke the targeted method.

Of course, this is only the first step. The next step is to use another perturbation to defeat the firewall itself. Oberthur plans on using multithreading to do so (by abusing the context switches), but this is work in progress. There are other ways to achieve the same thing, but the multithreading idea is quite neat.

Their first attack (on checkcast) allows all previously published logical attacks based on type confusion to be made again.

The proposed countermeasure (redundancy) is not really good, as the virtual machine is being attacked here, and adding redundancy at that level could have a significant effect on the overall performance of the cards.

Logical attacks and combined attacks have been available for a while in evaluation labs. It is very nice, from an evaluator’s point of view, to see that this kind of work is now being published. This could mean that the level of paranoia is lowering in the smart card industry. The fact that a card vendor is publishing this makes it even stronger.

Now, the challenge is on the manufacturers, especially since the attacks described in the presentation also work perfectly on Java Card 2 cards. We now are in a state where there is a published vulnerability, which needs to be industrialized, and then exploited. Luckily, this will require significant efforts of reverse engineering, which will be made more difficult by what remains of the industry’s paranoia.

Also, let’s see what the academics working on attacks will make with that. There are still plenty of ideas and details of these attacks that remain confined in laboratories.

The slides were about requirements, and there was one particular slide providing high-level guidelines.

JCF high-level guidelines for JC3.0

I was quite amazed when I found this slide, because it is so close to reality. Let’s look at in more details.

• Reduce delta between Java and Java Card. That was already an objective, and that objective was clearly met. Even though some issues remain, Java Card 3.0 is much closer to Java than the previous versions were.
• Enhance the programmer experience. That item is interesting, and reminds us of the nature of the Java Card Forum. We are a technical-oriented forum, which focuses more on developers than on users. We changed that a bit in the following years, with more focus on end users, as we introduced the Web server interface, a clear successor to the text-based SIM Toolkit user interface.
• Fully exploit the 32-bit platform. Check. that was one of the starting points, and we of course achieved that. The Connected Edition explicitly targets 32-bit platforms.
• Keep an eye on the footprint. Uh oh. I knew it! Footprint was already identified as an issue to track. We did, and we still do, as some detractors are saying that Java Card 3.0 is bloated. I don’t agree, but this deserves a full post.
• Become THE computer. OK, this is our “rule the world” moment; I am not sure that we made that, but we are getting closer to that main objective.
• Assumption: forget about 8-bit? Yes and no. The Connected Edition will not work on a 8-bit card, but we also have kept the Classic Edition, which will allow us to keep issuing traditional Java Card cards with small memory and 8-bit processors.

A lot of things are already present. The only thing missing, which will take a while to arise, is the Web server. Other than that, the guidelines were not that bad. Nevertheless, it took us seven more years to get a finalized specification out.

But the thing that really attracted me is a quote from the CEO of On-Demand Books, Dane Neller:

“We believe this is a revolution. Content retrieval is now centralized and production is decentralized.”

Hmmmm. So, Google has the contents. Fine for me, as they give me a simple access to a massive amount of content. Of course, book printers have the printers. Fine for me as well, as their printers are far more efficient than mine in all aspects. But how is the link made? Who forwards the content to the printer? Who certifies that the content is actually free of rights? And if it isn’t, who certifies that I have the right to print a copy of it?

Google can do all of this, of course. But now, this is not really fine for me, as it gives too much power to Google. It is perfectly OK to have Google certify that the “free” content they provide actually is, but it should also stop there. I don’t really want them to make the link, and I also want to be able to print content from other origin, and in particular, books that I buy, and books that I write (one so far, with my daughter, available at Lulu).

So, our first problem is the missing link. And here, we get very close to VRM. Since we want to interface any (printable) content with any printer, this link must be something that we, as users, control. If books are published in an open format, I can perfectly imagine a small widget or mobile application doing just that: getting content from a content source, and forwarding it to my printer of choice.

Things that are quite similar are starting to pop up, like the systems that use OAuth. However, in such cases, a bilateral agreement is required between the content provider and the service provider. So, we are not yet giving back the power to the user. But of course, as soon as we remove this bilateral agreement, an issue of trust surfaces: how do I know that the person who requires the service actually has the right to use the content. Well, that will be discussed in another post.

Our second problem is that book printing is just a very simple example. Photograph printing is another one; many times, I have wished to be able to print a few pictures and distribute them on the spot rather than psting them on some virtual wall. And we can even extend the same idea to cases in which the notion of content is more general, as well as the notion of service.

Now, I can take back my Java Card hat. In the near future, there will be embedded Web servers everywhere around us, providing a wide range of content and services. You can call that Java Card 3.0, Web of things, Ambient intelligence, but it is basically the same thing: We have content providers (the thermometer), service providers (the thermostat), and a link between them. I like to think that this link can be my mobile phone, and I can use it to associate a new thermometer to my thermostat. The funny thing is that the problem is exactly the same as above, and that at the center of it, we have the same old issue: trust.

Of course, there are other issues. But hey, I am not a web services guy, I am a security guy. So I see security problems. I like this one, and I’ll get back about it.

The interest of this project is to combine the expressive power of Java Card 3.0 with the sensors offered by the SunSPOT, such as accelerometers. Because the SunSPOT platform is extensible, it is also possible to experiment with sensors that are not supported by default.

In terms of implementation, it is in fact two different projects:

• A Java Card 3.0 experimentation on SPOT. It is just an expeimentation, because there has been no real attempt to make this implementation compliant to the Java Card 3.0 specification.
• The PlaySIM daughter board project. The idea is here to connect a phone’s SIM connector to the PlaySIM card, itself connected to a SunSPOT. In order to make things easy, the PlaySIM board includes an actual SIM card, which takes care of the GSM network authentication. The PlaySIM board therefore filters incoming commands, processes those related to high-level services, and forwards the basic GSM commands to the actual SIM card.
• An eGSM daughter board. The idea is here to provide a terminal for PlaySIM. This then allows some M2M experiments with SIM cards, and experiment with connected objects.

An interesting part of this approach is that any protocol can be intercepted, including the very basic and very widely available SIM Toolkit protocol. The SunSPOT will insert proactive commands that corresponds to the thing.

The PlaySIM project is actually an open source project, whose idea is to cooperate with universities, SIM card vendors, and developers. The content will be available in a few weeks on java.net. The cards should also be available for sale in a few weeks.

Of course, there are extensions on the road, and one of them is to be able to simulate a WLANSIM, which is one or Telenor R&D’s pet projects.

Once again, this project is worth following. Hopefully, I will be able to tell you more in a few weeks.

• Step-by-Step Development of an Application for the Java Card 3.0 Platform, by Sun’s Anki Nelaturu and myself, is likely to be the most basic talk. We will follow a simple example and try to describe several topics.
• Java Card 3 Platform: A Platform for Embedded Systems, by Saqib Ahmad (Sun) and Laurent Lagosanto and Patrick Van Haver (Gemalto), will focus on the use of Java Card 3.0 outside of the smart card area. Expect a few interesting use cases, and possible directions for the technology.

Interestingly, a majority of the talks will be rather practical, about applications or integration with existing technologies:

• Integrating Java Card 3.0 Technology into the Desktop Environment, by Sun’s Sebastian Hans, will explain how Java Card 3.0 can be integrated with existing networks and applications.
• Project playSIM: Experimenting with Java Card 3 System Programming, by Eric Arseneau (Sun) and Fritjof Engelhardtsen (Telenor), will present a platform based on Sun SPOT that uses the Java Card 3 application framework, and that will allow you to experiment with Java Card 3 in a variety of embedded environments
• Demonstration of Electronic Health Records (EHR) on Java Card 3.0 Technology-Based Devices, by Nicolas Anciaux (INRIA) and Jean-Jacques Vandewalle (Gemalto) will be the most practical talk, with a real use case, and a rather hot one on top of it, for which Java Card 3 is a contender.

Finally, one of the presentations will be in a forma that is new for Java Card:

• Java Card Platform Puzzlers, by Alexander Glasman, Hema Kalsi, Thierry Violleau, and Lichun Zhan (all from Sun) will look at the Java Card 3.0 Connected Platform in an entertaining. Expect a good mix of of fun and highly technical information from these guys.

Overall, the lineup looks quite interesting, and I am looking forward to this conference, which is very much the official launch party for Java Card 3.0, as the official release of the TCK and RI next month will allow licensees to officially sell products based on the technology.

See you there!

I have been busy in the past week preparing a tutorial and training on Java Card, and this has included learning about JavaScript (yuk!), and a little bit about mashups. And of course, when you talk about mashups, Google Adsense is an interesting idea. So, I decided to sign in to Adsense, to see how it worked.

Well, it is definitely simple to use, and it only took me a few minutes to start, and less than two hours to tune. So now, this blog includes some ads. I also have included a Google-based search on the site, which happens to be work better than the default search, which reminds us of how Google started. If you have strong feelings about it (good or bad), just let me know by sending a comment.

The next question is: could I include such ads in a Java Card 3.0 ad?

Well, maybe, but at least, it won’t be easy. Here are a few of the reasons:

• Adsense wants to analyze your content, and it may not be that easy to analyze the content of a Java Card 3.0 application.
• When using Sun’s RI, the default URI is http://localhost:8019, and cards are quite likely to have a very local address. Not that easy for Google.

Obviously, Adsense has not been designed to work with Java Card 3.0, as Java Card 3.0 cards are a new kind of personal Web servers, with very personal Web applications. So personal that they are actually difficult to analyze with the traditional means. However, there is a potential market here, as these personal Web servers are quite likely to be able to serve very well targeted ads (remember, they are supposed to be used for really personal information).

Maybe the next step for Google.