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.

Here is a transcript of my invited presentation at Cardis2010, or at least the things that I thought about before getting there. The slides are available on SlideShare.

I entered the smart card business writing Prolog virtual machines at a time when virtual machines were starting to migrate into smart cards. That was more than 12 years ago, and since then, I have been working a lot on card application frameworks. So, today, I want to take the opportunity to recall some of the history of these card application frameworks, and to derive a few answers to the question that is asked right here.

Everything started in the mid-nineties with the definition of the SIM Toolkit framework. SIM Toolkit was truly visionary, and a miracle for smart card vendors. The idea was to manage the user interactions on the phone directly from the SIM card.

This was made possible by the weakness of the handsets at that time, and it created the need for card application frameworks. The first frameworks were proprietary. At Gemplus, we had one based on the Forth language, and every vendor had its own framework.

Then, in 1996, came Java. A bunch of maniacs at Schlumberger figured that this rich and heavy language was the right choice for smart cards. Of course, they had strong constraints so the product that they created was very limited, and mostly allowed developers to write simple scripts.

These scripts were compiled into bytecode and then executed on the card. This introduced platform independence, and therefore platform interoperability and application portability. Well, this did not really happen, since no other vendor ever built a card compliant to Java Card 1.0.

And, they did not target SIM cards, at least at first.

A few months later, other vendors jumped on the bandwagon, and in April 1997, the Java Card Forum was created to work with Sun on a more advanced specification. By the end of 1997 we had released Java Card 2.0, which did not survive much. It took us another year and a half to get Java Card 2.1, which laid all the foundations that we needed.

The spec introduced the split VM model, the binary-level interoperable CAP file format, as well as the applet model that we still use today.

However, with this spec, we were still painfully interpreting APDU commands all the time.

Then came Java Card 2.2, around 2001, introducing Java Card RMI. It was now possible to write application using a clean model based on remote method invocation. No more APDU mess, and the future was bright.

But RMI, and even more Java Card RMI, is far from being a universal protocol, so there was still some room for improvement.

Improvement came from OMA, with the Smart Card Web Server.

Now, the applications communicate with HTTP, TLS, all these great universal protocols. Applications are now servlets rather than applets, and it is possible to include standard content on cards.

However, the model is very limited, there are many servlet features that can’t be used. And also, the underlying protocol remains APDU-based, which is a little slow.

Here comes Java Card 3.0, and in particular its Connected Edition. Now, all the limitations are gone, we have a 32-bit VM, a full-blown Web server, TCP/IP over USB, and even more that I don’t recall.

As of today, it is the ultimate card platform.

But, it cannot work by itself, because applications need to be managed.

Application management work started in the late 90’s, under the leadership of Visa. This led to the creation of the GlobalPlatform consortium in 2000, and the issuance of the GlobalPlatform 2.0.1’ specification. This introduced the notion of interoperable card management, allowing issuers to security load, install, and delete applications.

However, there were few provisions for multiple providers.

Here comes GlobalPlatform 2.2. As it exists today, GlobalPlatform 2.2 is the ultimate application management platform for NFC.

However, GP 2.2 remains APDU-based.

That will be addressed in 2010 by the release of GlobalPlatform 3.0, which is a companion spec for Java Card 3.0, and will support Smart Card Web Servers, while being fully based on IP over USB.

This is the ultimate card management platform, promising an even brighter future than Java Card 3.0 alone.

The result is impressive, as we have a framework with a lot of incredible qualities, making smart cards incredibly appealing for all kinds of services.

But …

These qualities may not be the ones required by our users.

Open sounds good, but not everybody likes this.

Consider China’s mobile operators. They have created their own application frameworks; more limited than Java, but better suited to their local market. They are proprietary, but the operators are big enough to motivate card vendors to develop these profiles for them.

Interoperability is something that everybody needs. Even the Chinese operators have specs that are detailed enough to allow vendors to develop interoperable products.

However, the problem with interoperability is that it is very difficult to achieve, and that it always results from a very long process. Functional interoperability takes years to achieve, and security interoperability remains a dream today.

Multiple applications. Well, obviously, very few people care, because there haven’t been that many applications. When there are multiple applications, they are often all activated throughout the lifetime of the card.

There have been a few use cases in the SIM area, but they remain quite limited.

What about supporting multiple providers. When you think about it naively, this is a killer feature. However, when you start considering liability, brand management, and other crucial factors, multiple providers are at least annoying.

NFC is bringing great hope in this area, because the whole NFC story requires multiple application providers to be represented on the same card or token. However, there still isn’t any guarantee that this issue is not going to kill the NFC story.

High-level protocols. Well, here, the pain almost gets personal. At one point, I was one of the promoters of Java Card RMI, and I remain proud of our 1997 demo. 10 years later, we know for sure that nobody ever used it commercially, and last year, I even asked Sun to deprecate it officially from the Java Card spec.

Basically, smart card developers have no say in application frameworks.

Standard protocols are very standard elsewhere, but the standard for cards is APDUs.

Adoption of Smart Card Web Server has been minimal so far, and the main blocking point is that handset vendors have been very slow to support SCWS on their devices, and also that they are reluctant to support a high-speed interface with the SIM.

All of this may have sounded extremely negative, so some explanation is required here

First, cards are tokens. The primary use of a banking card is authentication; a banking card may be a programmable authentication token, but few people tend to see it as an open software platform.

Of course, this first example is a bit simplistic

A SIM card definitely is more than a token. Many people realize that applications can be downloaded into it. In fact, operators have been using STK applications for many things, and they largely benefitted from it.

Well, that may in fact be part of the problem. The mobile operator is the only one that benefits from the SIM card, sometimes with a few close partners. In an open and connected world, such a closed platform rapidly loses value. This business model was very nice last century, but it doesn’t look like the best one for this century. And also, handsets have largely overcome the limitations that led to SIM Toolkit in the first place

Basically, STK is toast, it’s a thing of the past.

NFC, of course, will solve all that. Sure, NFC will be put on SIM cards. If you have the impression that you have seen large NFC deployments with mature business models, please let me know. Most of the ideas I have heard about are very much closed and competitive, bringing little value on the card, except the dematerialization of already existing cards.

In such a context, innovation is a true challenge.

OK, all that did not seem that optimistic, so is there a future for cards?

First, cards have a few assets. They are secure, of course, and this conference is going to be all about this. They are also small and relatively cheap; even high-end smart card you can imagine only costs a few dollars to produce, which makes it one of the cheapest computers available. In addition, because of the application frameworks, and because of GlobalPlatform and similar specifications, smart cards are manageable: protocols exist to manage the content on these cards.

Finally, cards are personalizable. The smart card industry is very good at producing billions of tokens every year, putting one person’s data on each token, and sending the token to the right person. Mobile phone manufacturers don’t know how to do that.

Overall, a smart card is the ultimate personal device. It is interesting because it is attached to a person, and this is its most defining property.

The environment is also changing rapidly. All our services are moving to the cloud, where everything is more or less interconnected, and where all data is readily accessible. The cloud solves a lot of problems, but it also raises one, about identity. Just like for cards, many technologies exist, but nobody seems to be able to find the appropriate business model. Maybe there’s something here.

Then, there is the mobile. When we are using our mobile, we are most often thinking of here and now. When I look for a restaurant on my home computer, I may be looking for a restaurant to organize a birthday party in 3 months. If I do it with my mobile, I am most likely looking for a place to eat in the next few minutes. In addition, a mobile is a generative device, that we, or at least our children, use to create new content and publish it instantly. Finally, a mobile is interactive; we can interact with it, but more importantly, we can use it to interact with others, like the Paypal mobile application where we bump phones.

If we combine that, we all live in a cloud. In this cloud, there is ME, and things become interesting because there is also YOU. Things become really really interesting because we are both HERE. And then, we get in a relationship, and we want everything in this relationship to happen naturally. And especially, we don’t want this cloud to get in our way.

To make things happen naturally, we need at least two things: First, we need context, with the right mix of local and distant factors to make a great user experience. Today, this user experience often involves a mobile application and a few sensors. Then, we need trust, and here, we need to remember what trust is about: trust is about lowering security barriers because of the current context.

Now, this opens a few doors.

Well, these doors may be opening, but I wouldn’t say that everything is clear in that direction. So, let’s take some time to look at a few research challenges.

First, open card platforms. I said earlier that the technology was here. Well, I was lying. Some things are missing.

One of the main issues we face today is making sure that the security level of a smart card, token, service, whatever, is predictable. Or at least, predictable enough to ensure that we get the security that we need to implement a service. This is the main shortcoming that we face today in terms of interoperability: platforms can be guaranteed to do the same thing, but it remains hard to ensure that they present a common level of security.

And when that will be addressed, we will then need to ensure that this security level remains predictable over time, both in the presence of new attacks and in the presence of hardware and software evolutions. Here, we have challenges across the board, and in particular in the area of certification, which becomes very hard to manage in an interoperable and maintainable way, AND with a sustainable cost. Basically, what we need here is not sustainable development, but also sustainable certification.

Next, let’s remember that we are interested in developing smart card applications, so we should also concentrate on the competitive advantages of smart cards in comparison to smart phones, the cloud, and other devices. Well, one of them is the privacy that can be achieved through a good level of confidentiality and integrity. Some things can be kept more private on my card than anywhere else, just because smart cards are more difficult to break into.

Another one is availability. If you are a traveling smart phone addict like me, you know what I mean. All these wonderful cloud-based services disappear when your operator tells you that it will cost you 50 euros for 2 days of unlimited data roaming. And then, you get angry that Google Maps is not able to use a cache to hold map information that you looked at just before to go, and that has become unavailable when you most need it. Well, maps may not be the best example, but local data stored on a smart card is always there when you need it.

Another one is control. You can decide for instance that some content in the cloud may be available to others, but only after an explicit authorization from yourself. Well, if the crypto key required for the authorization is stored on your local smart card, you know that the only way to access your data is to go through that key. Nobody can access my private data when my phone is off.

That may not be the best use of locality, but it is compelling in the sense that it provides a level of assurance that is difficult to achieve with a cloud-based application. Finding these uses definitely is a strong challenge for the smart card community.

OK, the next challenge starts by admitting that “We will not win”. Mobile devices will be around, and applications will continue their migration to the cloud. A card is never by itself, including when managing security. Let’s consider mobile authentication: in most cases, some interaction is required, which will be handled on the mobile device, possibly through a specific secure UI, which offers some level of security guarantees. Also, in most cases, a remote server will be used to verify the signature or whatever proof of authentication has been generated by the card.

What I mean here is that smart card security must be thought at the system level, at least to make sure that the use of the card actually brings some value to the system. For instance, let’s consider a One Time Password System, in which a password is displayed on a mobile phone in order to allow a user to connect to a mobile banking Web site on a PC. We can claim that computing this password on the SIM card is mandatory for security, but the reality is that the security improvement comes from the fact that the credential is computed on the phone and used on the PC: what is the probability that a hacker has taken control over both your PC and your phone? Low, or at least much lower than that it has taken control of your PC. And that’s what count: making attacks more difficult. So, when thinking about smart card systems, let’s not forget that the smart card is inserted in a larger system.

To take a recent example, Cambridge’s man-in-the-middle attack on Chip&PIN is a perfect example of system integration gone wrong. The EMV protocol is correct, but it makes it hard to implement correctly, and of course, some banks didn’t implement it correctly. This should be predictable, so why did it take so long to find this out?

Now, let’s consider one of the most interesting factors in the system: the human. We humans are an endless source of bugs and problems, and most likely the most unpredictable part of the system. This means that one of the major objectives of any computer system should be to make sure that the human factor will actually work.

For security, this is extremely important. Humans will choose 1234 as passwords; if you force them to use complex passwords, they will write them down or use the same password everywhere. People who don’t understand that end up forcing us to change our complex passwords all the time and make our lives miserable.

Understanding the human side of security and trust is extremely important, especially in a mobile environment, because we focus on human interactions.

The final challenge is by far the hardest: how to get to trust, of course using smart cards?

Basically, trust is about protocols between users, devices, and servers. And it’s about authentication and authorization. The idea is here to ensure that we have the protocols that we need, and that they provide the appropriate security level. I don’t want to deploy a full PKI infrastructure just to control how photos of me get tagged on Internet, but I would like to have some control over this. So, how should I do that? There is definitely room.

On that area, I am a big fan of Telenor’s work on Wifi-enabled SIM card, and in particular of Thomas Carlyle’s Master’s Thesis about trust models in Wifi-enabled smart card Web servers. It is just a starting point, but it links important things.

One last point here is the research community also happens to be a community of educators, who teach students, write textbooks, etc. Here, there is a tremendous work to be done on the education of users on trust topics: how to make users actually care about this important problem? And in return, maybe that we can learn from the users about how to propose solutions that actually meet their requirements.

We are getting close to the end, and no mention so far about app stores. So, where is our smart card app store? Well, you may have guessed that it is quite unlikely to come. I am not saying that smart card software will never come together with an app store application, but we all have to realize that smart cards are actually in most cases part of an infrastructure, like SIM cards are an important part of a network operator’s security infrastructure.

As such, they are important, but they won’t get app stores, because they are lacking one important thing:

Color. Interactivity. What users want to get from an app store are services, interactive services. These services may use smart cards in their implementation, some may even rely heavily on smart card services, like SIM Toolkit or another technology. But in the end, users want a mobile application.

This doesn’t mean that smart cards and smart card research are useless. The computing infrastructure behind internet has never been as complex as today, and smart cards have an important role to play in bringing trust and locality to these systems.

But sorry, no app store for us.

What do we need? We need a really good webserver you can put in your pocket and plug in any place. In other words, it shouldn’t be any larger than the charger for your cell phone and you should be able to plug it in to any power jack in the world and any wire near it or sync it up to any wifi router that happens to be in its neighborhood. It should have a couple of USB ports that attach it to things. It should know how to bring itself up. It should know how to start its web server, how to collect all your stuff out of the social networking places where you’ve got it. It should know how to send an encrypted backup of everything to your friends’ servers. It should know how to microblog. It should know how to make some noise that’s like tweet but not going to infringe anybody’s trademark. In other words, it should know how to be you …oh excuse me I need to use a dangerous word – avatar – in a free net that works for you and keeps the logs. You can always tell what’s happening in your server and if anybody wants to know what’s happening in your server they can get a search warrant.

And if you feel like moving your server to Oceana or Sealand or New Zealand or the North Pole, well buy a plane ticket and put it in your pocket. Take it there. Leave it behind. Now there’s a little more we need to do. It’s all trivial. We need some dynamic DNS and all stuff we’ve already invented. It’s all there, nobody needs anything special. Do we have the server you can put in your pocket? Indeed, we do. Off the shelf hardware now. Beautiful little wall warts made with ARM chips. Exactly what I specked for you. Plug them in, wire them up. How’s the software stack in there? Gee, I don’t know it’s any software stack you want to put in there.

In fact, they’ll send it to you with somebody’s top of the charts current distro in it, you just have to name which one you want. Which one do you want? Well you ought to want the Debian Gnu Linux social networking stack delivered to you free, free as in freedom I mean. Which does all the things I name – brings itself up, runs it’s little Apache or lighttpd or it’s tiny httpd, does all the things we need it to do – syncs up, gets your social network data from the places, slurps it down, does your backup searches, finds your friends, registers your dynamic DNS. All is trivial. All this is stuff we’ve got. We need to put this together. I’m not talking about a thing that’s hard for us. We need to make a free software distribution device. How many of those do we do?

We need to give a bunch to all our friends and we need to say, here fool around with this and make it better. We need to do the one thing we are really really really good at because all the rest of it is done, in the bag, cheap ready. Those wall wart servers are $99 now going to $79 when they’re five million of them they’ll be $29.99.

Then we go to people and we say $29.99 once for a lifetime, great social networking, updates automatically, software so strong you couldn’t knock it over it you kicked it, used in hundreds of millions of servers all over the planet doing a wonderful job. You know what? You get “no spying” for free. They want to know what’s going on in there? Let them get a search warrant for your home, your castle, the place where the 4th Amendment still sort of exists every other Tuesday or Thursday when the Supreme Court isn’t in session. We can do that. We can do that. That requires us to do only the stuff we’re really really good at. The rest of it we get for free. Mr. Zuckerberg? Not so much.

More a Marvell plug than a Smart Card Web Server, but still, the reasons leading to it are interesting. This speech is really, really worth reading entirely.

Android does not offer a Secure Element interface. Of course, Android phones are able to interact with SIM cards, but applications have no access to the cards, or to any other Secure Element (SE). And of course, forget about NFC access. Will that last? Of course not, as manufacturers and other service providers will make sure that they can build Android applications that use secure elements.

Apparently, Giesecke&Devrient has really started that war, by announcing a security solution for devices running Android. This is a combination of two things: a MicroSD card that embeds a smart card chip, and software that allows the Android platform to access it.

Cartes is about 10 days from now, so we can expect a few more announcements and demos to be made there. Trusted Logic has already announced a NFC stack for Android, and I bet that more will come.

For now, we can take a closer look to the G&D solution, especially because they have published their software on a Google Code Project.

This project is still evolving, so what I am writing is is a snapshot of its state on November 4, 2009. One of the latest additions is a paper called Security and Trust for Android. This paper contains a lot of information, as well as a nice vision, but it is also a bit confusing, and remains a proposal, as stated in the introduction.

This paper deserves to be read, though. Its main vision is that there are many SE’s that can be used (SIM card, MicroSD, TrustZone, Software SE), with different properties, and in particular with different security levels. Nevertheless, the paper insists on the fact that all these SE’s should be accessible through a regular API, and that there should be a similar way to program applications on all these SE’s. Now, that’s an interesting vision, although it is kind of hard to achieve (for instance, SIMs and MicroSDs both use Java Card applets, whereas TrustZone and software SE’s are usually based on native applications.

I have not looked in great details at what they offer, and I have not tried to use the software. However, I did take a look at the samples, in particular at the one based on the native interface. This interface looks quite nice and simple, and the sample is far easier to read than the one based on PC/SC.

Basically, this effort looks like a good way of making a SE interface available on Android, and to offer a way to interface with a particular kind of SE. This looks like basic software, and I am sure that we will need to consider many more aspects, like security, access control, and more. However, this is not the goal here, as the proof-of-concept definitely is the important part. Completeness (and complexity) will come later.

I would love to say more about the technical details, but it is late, and trying these things out takes time. I will therefore come back later to that topic. For now, I will close with a few non-technical comments:

• I like the fact that G&D has made the software open source. Obviously, the Android drivers and APIs are not how they intend to make money, so this sounds like the natural thing to do. However, this is the smart card industry, and secret is usually considered better.
• Hopefully, G&D will also work with the other actors of the industry in order to make this API the best possible. Since this would add more weight to their proposal, it also sounds like a natural thing to do.
• Even more hopefully, the industry as a whole will make sure that the Android developer community actually understands how to use these Secure Elements. This will require a strong educational message, which is just started by the G&D white paper.

The last remark goes to the Secure MicroSD product, together with its Android integration. It is a composite product, integrating a large memory and a smart card microcontroller; in addition, it is integrated on a Web-oriented platform. Well, that sure looks like a great target for Java Card 3.0 and its servlets. This would even greatly simplify the API requirements at the Android level, and also greatly enhance the appeal of the solution to Android developers.

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.

At the same time, the major card manufacturers had a double agenda: they first needed to keep their current flow of revenue, which was mostly based on proprietary application frameworks, especially in the SIM area. At the same time, they were pushing the Java Card technology; at least, their R&D departments were pushing them, as well as the marketing teams who were trailing their competitors, all too happy to announce a forthcoming revolution that would make their competitors’ products obsolete (but not theirs, of course, since theyr were embracing the new technology).

That was 10 years ago, and we know where it led. Java Card has since become the leading application platform for smart cards, with billions of cards deployed over the years. Today, the industry is looking at another round of innovation, and will they be able to pull the same trick twice?

Let’s continue a bit the analysis of the situation 10 years ago. At that time, SIM Toolkit was an emerging technology. Mobile operators were starting to deploy applications on that framework, and they were already feeling the pain of proprietary platforms. At the same time, actors like Visa were starting to consider multi-application cards, which would allow them to leverage their base of users as a deployment platform for third-party applications, with a large potential revenue.

All these factors really profited the smart card industry, and Java Card came at the right time, with the right model. It had significant competitors, in particular the Multos system. However, this system was considered as locked by a single company, itself controlled by MasterCard. Although the Multos system was far better suited to the cards available at that time, this centralized PKI infrastructure was enough for Java Card and its open model to succeed.

All of this sounds awfully positive, and Java Card could not fail. Well, it also had a number of drawbacks: first, the industry was not used to seeing companies like Sun get in their space, so Java was not necessarily welcome. Then, even more importantly, Java Card suffered severe performance issues. The official hardware requirements for the first platform were 32k ROM and 256 bytes of RAM. Although it was actually possible to fit a Java Card runtime environment in such space, this was definitely not enough. Actual cards used more like 64k ROM andd 1k RAM (double that if you want public key cryptography). At the time, such figures were high-end cards, with a high price. In addition, in order to keep the Java Card promise, one also needed a significant amount of EEPROM, which made them even more expensive.

In addition, the performance of the first Java Card cards was not optimal. The virtual machine added some overhead, and the higher abstraction level made it more difficult to tightly optimize memory consumption. There was just one advantage: the application code was smaller than native code, at least without counting the underlying runtime environment.

So, how is the situation today, with the launch of Java Card 3.0? It is similar in many ways. First, in the SIM market, there is an ongoing revolution. ETSI has voted in favor of a high-speed interface between the SIM card and the handset, based on USB. In the same time, OMA has standardized the Smart Card Web Server (SCWS) technology. However, these techcnologies are either not really available (USB), or not yet widely deployed (SCWS). Nevertheless, the situation is quite similar to what it was 10 years ago. Even though Java Card 2.2 and SCWS are interoperable technologies, programming a servlet without Strings or without dynamic object allocation is at least painful and error-prone, which favors the emergence of another application framework.

Another very important aspect is that Java Card is today’s dominant technology, with over half of the market, and no real competitor. This is of course very positive, but it also has a few drawbacks. First, the technology has been really underused over the years. On the billions of cards deployed, how many
have seen applications downloaded after thier issuance? Or applications from different application providers? Not many, for sure. Java Card has been a success as a vector for interoperability, but multi-application cards have not become a reality. This may mean that, before to move to a new framework, we may need to make good use of the existing one.

Another problematic consequence of lready being the dominant technology is that Java Card now represents two platforms: the Classic platform, which is an evolution of the existing platform, and the Connected platform, which proposes an entirely new model. This brings some confusion on the Java Card brand, which now represents two very different models. In addition, positioning the two models in a way that promotes the new model without undermining the previous one is somewhat difficult.

Another element that may have an influence is the deployment of NFC technology. We all know now that this deployment will take some time, but there are positive signs, and this deployment may have two interesting consequences for the smart card market. First, it will push in favor of really multi-applicative cards. Mobile payment is hard to define, mostly because, for the first time, telcos and banks really need to talk to each other as industries. When appropriate models will be around, multi-application smart cards will be around. Then, these NFC applications will neeed a user interface, and there aren’t that many alternatives. They can use SIM Toolkit, but it is a bit outdated. They can deploy mobile applications, but then they will face numerous problems. Or they can embed their user interface with their applications, using a Web server technology. This solution is not guaranteed to win, but it has significant changes of success. If it does, it would make Java Card Connected Edition a very attractive platform.

Overall, the environment is challenging, but not more than it was 10 years ago. There are a few promising emerging technologies, like SCWS and NFC, which can emerge and succeed with the existing technologies, but will require a more powerful platform in order to really achieve its potential.

The major difference today is that the smart card market has matured in the past 10 years, with significant concentration. 10 years ago, most companies were private companies, or they were parts of much larger companies; in their case, the smart card business was small enoug to enjoy a good level of freedom and independence. Today, we are looking at a more consolidated market, with many
public companies, and including a giant company, which controls more than half of the market. The consequence is that conservative forces, who put a higher priority to next quarter’s revenue than to the development of a potential future market, are more powerful today than 10 years ago. As a consequence, the industry is not including much Java Card 3.0 in their plans, even when they promote SCWS technology.

There are other uncertainties, as well. Oracle now controls Sun, and of course Java Card. What will they do with thie technology? In a more open world, can a new competitor emerge, for instance from the open source community? Once again, we already faced new actors and fierce competition 10 years ago, and Java Card made it quite nicely.

Don’t be afraid!

• 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!

You have been warned in the previous posts. The Connected Edition of Java Card 3.0 is very different from Java Card 2.x. But, how exactly are these two versions different? Well, there are differences at all levels, from the virtual machine to the application model and the deployment framework.

So, let’s take a close look at all these differences, going from the low-level to the high-level differences.

At the virtual machine level

At the virtual machine level, the main difference is that the Java Card virtual machine is now strongly inspired from the 32-bit CLDC virtual machine, with which it shares a lot of characteristics. Among these characteristics, we have:

• 32-bit integer by default. Yes, some of the casts are now gone for good, as Java Card 3.0 now performs 32-bit computations.
• More basic types. Java Card 3.0 now supports all standard integral types, including the (unsigned 16-bit) char and (signed 64-bit) long types.
• Mandatory bytecode verification. A serious security flaw is now gone, and reverse engineering a Java Card 3.0 card may well be a difficult task. Since the inspiration comes from CLDC, the verification uses precomputed stack maps.
• Standard distribution formats. Java Card 3.0 classes are compiled into class files, which are distribution inside JAR files, using standard encoding and compression.

However, some things still didn’t come to Java Card. For instance, don’t expect any floating-point numbers, as there is little use for them, and the hardware coprocessors remain a bit too expensive.

At the runtime environment level

At the runtime environment level, there is one major change, memory management. Java Card 3.0 explicitly supports temporary objects, and objects are made persistent when they become reachable from a “persistence root”. The consequence is that it is now possible to allocate objects temporarily in RAM, and they will even be automatically garbage collected.

The transaction model has also been greatly enhanced, and it is now possible to use nested transactions, using a very flexible model. In particular, it is now possible to write libraries that use transactions in a clean way.

Finally, the sharing model has been enhanced. The firewall is still around, and the basic sharing mechanism remains the same. However, it has been complemented by a few mechanisms that allow two applications to exchange object instances, making the sharing framework really usable.

At the API level

At the API level, there are quite a few significant additions. The first one is of course the String class, which is quite mandatory is we are to handle HTML pages. Of course, this class does not come alone, and StringBuffer and a few other friends are also present.

In fact, a significant subset of java.util is present. In particular, it is now possible to manage data with other things than simple arrays, as Vector and Hashtable are available. However, these are the “old” versions of the classes, as the new container framework is too complex.

In addition to these basic utilities, the Generic Connection Framework (GCF) has been imported from the CLDC core library. It allows a Java Card application to open local and network connections, and to use stream-based I/O, which can be very useful, for instance to consume incoming data.

At the security level

The Java Card 2 security model is extremely simplified, mostly because there are very few resources to protect on a small smart card. With Java Card 3, this simplified model is not sustainable, because there are many more resources that need to be protected. Therefore, Java Card 3.0 defines a permission model that provides fine-grained access control to sensitive resources. Permissions are required for many operations, such as network accesses, local file accesses, context switching, shareable object access, and many more.

Naturally, the Web framework also comes with a security framework. Application-level security for Web applications is a subset of the standard servlet security framework, as used on J2EE servers. It controls how Web applications can be accessed from various kinds of clients.

Finally, Java Card 3.0 includes a declarative role-based security model, which separates the declaration of the security rules based on abstract roles, defined at development time, from the mapping of these abstract roles to actual users and authentication means.

At the application level

Naturally, the main change is the new servlet application model, which allow Web applications to be developed and deployed on a Java Card smart card. This change also comes with another related change, at a lower level; Java Card 3.0 now defines a TCP/IP-based communication model, which allows Java Card applications to serve Web requests and to establish connections with the outside using the Generic Connection Framework.

Another important evolution for applications is the enhanced sharing framework. A major shortcoming of the Java Card 2 sharing framework is the fact that it is very difficult to exchange data between applications, because only global arrays can be exchanged (in most cases, this means that only the APDU buffer can be used). Java Card 3.0 addresses this issue by allowing applications to transfer the ownership of some of their objects to another application. With this mechanism, it becomes possible to exchange data safely between two applications. In addition, the fine-grained permissions that control sharing provide an extra protection to applications that share objects.

At the deployment level

In Java Card 3.0, an application is not simply limited to a set of classes. It also includes some static content (Web pages, images, etc.), as well as several descriptors. One of them, the manifest, contains information that should be provided by the person/entity responsible for the deployment of the application rather than by the application developer. This separation of functions facilitates the development of portable applications.

To conclude, we can also recall that, even in its Connected Edition, Java Card 3.0 remains backward-compatible with Java Card 2.x. It remains possible to run all previously developed Java Card 2.x applications. The only constraint is that the binary files need to be converted in a new format.

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.