UPDATED: Added slideshare link.
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.
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.