A few weeks ago, a friend sent me a link to the Cardis program, with the message “A bug in the verifier?”. Looking at the program, I saw a paper entitled Manipulating frame information with an Underflow attack undetected by the Off-Card Verifier, by Thales Communications and Security. This sounded like bad news, so I got a copy of the paper and read it.

The good news is that there is no bug. Nevertheless, reading the paper made me unhappy. As a consequence, the first version of this blog post was a flame, in which I qualified the paper of “dishonest, not innovative, and misleading”.

Publishing the flame triggered some discussions, with people at Thalès and with other people, in particular with Jean-Louis Lanet of XLIM. They provided me their views on the topic, and I have decided to revise my original flame into a more mundane and constructive post.

Dishonest, or just a bad title.

As mentioned above, the paper’s title is”Manipulating frame information with an Underflow attack undetected by the Off-Card Verifier”. However, section 3.2 of the paper surprisingly starts with the sentence: “The standard Oracle bytecode verifier detects the underflow attack”. There is no other reference to a verifier that would not detect that attack, and that makes the title sound really dishonest, at least the “undetected” part of it.

More specifically, it seems that the objective of the paper is not to point to an issue in the off-card verifier, as the title seems to, but rather to point to the fact that there exist ways to bypass the verification. A revision of the title in the proceedings would do just fine.

Not innovative, or not published.

The paper describes an attack that uses the dup_x instruction to perform a stack underflow. This stack underflow allows the authors to access the content of a stack frame, including the current context, and to change it. The question is: is this a new attack? As a virtual machine implementer and evaluator, I would say no immediately. This attack very easily comes to mind as soon as you know the content of a stack frame (as an implementer does). This attack has therefore been in my “bag of tricks” when I was an evaluator, and was even quite a practical one.

Now, the smart card industry is secretive, and evaluators are even more secretive. Very few actual attacks have been described in scientific papers. It seems that the attack to mention stack underflow is the EMAN2 attack described by Bouffard et al. at Cardis in 2011. However, they only abuse the return address, labeling the current context “unknown value”. In that context, it seems that this paper describes something that has not been published before. For this one, my apologies, as I forgot the secrecy of the industry, and kudos for actually publishing this rather than keeping it secret.

So now, the community knows that, unverified bytecode can lead on some cards to allowing an attacker to run attacker-provided code in a chosen context. This is about as bad as it gets, and now, additional attacks will fall in my “tricks” category, in which an attacker/evaluator uses a new illegal bytecode combination because the previously known ones don’t work on a card. I hope that we won’t see more scientific papers about such tricks (see Jean-Louis Lanet’s second comment about this).

Misleading, or missing its target.

Of course, since the off-card verifier catches all of these logical attacks, they are not supposed to occur in real life, where bytecode verifiers are systematically used.

Let’s make a parallel between two typical components, RSA and a virtual machine. RSA is a crypto algorithm, a function RSA(K,M) that takes as input a key K and a message M, and produces a result. Similarly, a virtual machine is a function VM(P,I), where P is a program (in bytecode) and I some input data, and produces a result. The RSA and VM functions share something important: the key K and the program P need to obey some properties. If the don’t, the algorithms don’t work.

If the RSA prime factors are not prime numbers, or if the program provided to the VM is not valid, their results may not be satisfactory: although they are functionally correct, they will not have the expected security properties. In order to avoid bad keys and bad programs, we use appropriate algorithms to perform primality checks, and to verify bytecode. Just as it is important to ensure that an attacker cannot tamper with the key generation scheme, it is important to ensure that bytecode is verified before to be executed. But is it sufficient?

Well, that may be sufficient if you run your VM or your RSA on a device that is physically protected from attackers. But on a smart card, it isn’t sufficient, at least for RSA. There have been many attacks published on smart card implementations of RSA, using fault induction, power analysis, and more. The VM is just as sensitive to these attacks; in particular, combined attacks can be used to dynamically create illegal code on a card, as mentioned in the paper.

If we continue the analogy, RSA is still used on cards, even though attacks exist. During security evaluations, the robustness of the implementation is verified by a lab, which ensures that well-known attacks don’t work. Naturally, the same thing must be done with the VM: a high-security implementation must include significant countermeasures against attacks on VM, such as combined attacks. The implementers have the choice of the countermeasures; they can include additional checks in the virtual machine, attempt to detect the faults, or both, or anything else, as long as it works.

According to my discussion with Thales, this is more or less the point that the paper tries to make, in particular in its last part. However, the paper insists on the malicious application rather than on the attacks, especially in its last sentence:

Finally, this paper shows that during open platform evaluations, it is necessary to take into account malicious applications, and make detailed analysis of each requirement included in the platform guidance.

I definitely agree on the platform guidance aspect. Requiring bytecode verification is not sufficient, as the management of the verification context is also important to avoid logical attacks. However, during evaluations, malicious applications are not the real issue, attacks on the virtual machine are. In that context, malicious applications are for now tied to combined attacks, where a fault triggers the logical attack. What the community often fails to understand is that, on a smart card, a virtual machine is a component like any other: it can be subject to physical attacks. And that’s the reason why specific countermeasures are required.

So what?

In Cardis, the proceedings are collected after the conference, so authors have an opportunity to revise their paper before publication. After our exchanges, I hope that some revisions will be made before publication, in particular on the title and on the last part (making a stronger point about evaluation requirements). And so, I replaced my flame with this.

The first question is to understand why automated analysis is required for NFC. One of the issues of NFC is the scalability of security evalution processes. There are good schemes forf so-called sensitive applets, which are relate to payment, identity, or other schemes that have strong certification requirements, usually requiring a full evaluation, incouding attacks.

The other applications, so called non-sensitive, are provided by security companies who do not require security certification. Some analysis is required, at least to make sure that they don’t interfere with the sensitive applications. Today, this analysis is performed manually by laboratories, which is error-prone, effort intensive, and not scalable.

Static analysis is a technology that allows us to completely automate this security analysis. This is done directly on the binary CAP file, without running the application, but simply by analyzing how the code could behave. It is possible to verify plenty of rules, including those defined by AFSCM or by GlobalPlatform. Luckily for Arya Security, these rules have been defined by people who were actually thinking about static analysis, and who made sure that the rules would be easy enough to analyze.

I strongly believe in static analysis, and I have written and talked about it multiple times. I am quite happy that some people get in this market and propose a tool for Java Card. I haven’t directly tried their tool, but I hope that its algorithms are good enough to avoid lost of false positives, and that they will be adopted.

The main barrier for them is actually NFC adoption. However, if it works, I am quite convinced that static analysis is the only way to go, because any non-automated techniques are not going to be scalable enough. Another company whose fate is linked to the success of NFC (in card emulation mode).

Well, that may change. researchers for the University of Pittsburgh’s RFID Center for Excellence have invented a on/off switch for cards, that simply requires you to put your finger on a specific spot on a contactless card to allow it to work (see a picture here).

Comment on the various articles around the topic are quite typical, ranging from the “This is very dumb because it is unpractical” to the “You have to give up some practicality for security”, and all variants in the middle. I would have liked to see the inventors’ arguments, but I haven’t found a reference to a paper/report.

From previous experience, user experience often wins, in particular when, like with contactless cards, practicality is a selling point of a technology.Also, since the idea is to protect your cards in your wallet, I would think that it is easier for security-conscious to use wallets that include some kind of wire mesh or other wave-blocking technology. Since the on/off switch requires you to actually get the card out of your wallet, it is more or less equivalent, and it only annoys security-conscious people. The other guys will still be able totap their wallet (until, of course, they start having several contactless cards in there, in which case this optimization may not work any more).

This invention does not look flexible enough. The threat of someone performing transactions without you knowing is not significant enough to justify this kind of generalized measure for payment cards. On the other hand, it sounds much better as privacy-protecting technology on ID cards, since an ID card. Ensuring that the data about your identity will not leak from your wallet is interesting, and since an ID card is typically pulled out of the wallet before to be used, the technology is not an annoyance any more. But of course, in research like in politics, the fears associated to credit card theft remain more powerful than those associated to privacy protection (although identity theft is gaining traction).

The technology is now ready, and it has not evolved greatly in the past few years. Java Card and GlobalPlatform are mature, widely deployed technologies; many companies are able to develop and deploy cards. Of course, there are a few technical challenges remaining, to keep engineers busy. One of the most challenging tasks is the establishment of trust between the various actors of the industry; today, formal security certification is at the heart of this, but something a bit more innovative will most likely be required here.

The new frontier for cards and secure elements are applications. This is much harder than implementing technology, and requires a lot of innovation. Will we be able to differentiate smart cards from tags? Will we find a room for card applications between basic SIM authentication and TEE applications? Will there at some point be a way to work on this? That’s the Chip-to-Cloud challenge, and I hope to get a few interesting answers next September.

The Call for Papers is out now, so go ahead, propose things. I am convinced that this conference will remain one of the places where academics, industrial R&D, and technical marketing people are able to meet and exchange. See you there!

Although this draft was officially authored by Sun Microsystems, Schlumberger played an important role there. This is why I am quite sure that the spec was released at the end of the month, since one of Schlumberger’s main patents on the topic was filed on October 25, 19996. The main topic of this patent is to use a high-level language to program a microcontroller, and it claims in particular the transformation of a class file into a more optimized format. Quite a good idea, at least sufficient to include this patent in the suit against Google‘s Android (which may be a proof that Android is yet another derivative of Java Card).

Good idea, but everybody trying to fit something on a card was ddoing just the same. The really brilliant idea was not to generate an optimized format, but to believe that it would be possible to start from something as different as Java. This was brilliant at the time, especially since in 1996, Java was definitely not mainstream technology, and was often considered as too expensive or too slow even on a PC. Now, that’s something for which the guys in Schlumberger can be congratulated.

Of course, they were not the only ones to try fitting unlikely things into a smart card. Researchers in Gemplus were more focused on object oriented technology, in particular Corba. And naturally, they needed to think about optimization in order to fit this into a card. They were using Forth as their base language for the Combo virtual machine. Even before that, as mentioned in this history of bytecode interpreters for smart cards, researchers at RD2P designed a bytecode interpreter, as early as 1990 (I can’t even imagine the memory sizes of cards at that time; if somebody knows, please leave a comment).

Now, the interesting part is that a patent has been filed in France (sorry, in French only). And one of the key elements of this patent was the fact that the programs are later compiled for the specific embedded virtual machine.

Not quite Java Card, though, because the patent only mentioned direct compilation from source code, not using an intermediary format (a.k.a. Java class file). The difference is slim, and I would be tempted to credit the French guys with the invention of optimized smart card code. However, there is something that the Schlumberger guys did much better: timing. The French patent, filed in 1990, was never extended into an international patent, whereas the American patent has been extended and mainained to this day.

As a final trivia note, did you smile when I mentioned that Android was a derivative of Java Card? Well, very indirectly, but somehow, a little bit. Java Card, after being initiated by Schlumberger, was maintained by Sun Microsystems. Sun’s Java Card team later convinced Sun to develop a slightly larger VM, the KVM, to address very small devices. This VM was then extended into MIDP, which became the leading platform for phones. And everybody knows that the Android team includes a number of ex-Sun employees who used to work on MIDP. So, yes, indeed, Android a a distant heir of Java Card.

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.

Interestingly, the current presenter is Guillaume Barbu, from Oberthur, who is presenting an interesting attack based on the same principle: we load a perfectly legal application on the card, and “magically” make it illegal by using a physical attack. My technique is to replace an instruction with a nop, and his technique is to block the throwing of an exception (execution continues even though it should have failed).

This doesn’t sound very interesting, and not a real novelty. After all, we were already able to get type confusion with simple logical attacks. The main difference is here that the applications we use are actually legal, and that their behavior is modified dynamically (one of my colleagues calls them mutant applications, which makes this really scary). In the microcosm of evaluation labs, this is a game changer, because the main argument used against logical attacks until now was “Bytecode verification is mandatory, so your attacks won’t work”. With mutant applications, this argument doesn’t hold anymore.

But does it really change things when we get out of the evaluation lab? Not really. Writing an attack application may be easy, but exploiting it remains very hard. Smart cards are highly controlled environments, and traceability remains the norm. Our attacker A must be an insider in a company that actually develops an applications. This attacker A then needs to plant a Trojan horse in one of his company’s applications, and have it loaded on a number of platforms. So far, so good.

The problems come by when the attack is actually exploited: with the kind of traceability we have on smart cards, as soon as the attack will be triggered, it will be noticed, and labs will trace the attack back to that application. If you combine that with the fact that this attack required physical access to the smart card that is being attacked, its practical impact becomes quite limited. It is mostly useful if you have a brittle security system, in which disclosing a key breaks the entire system. But in that case, the problem is not really in the Java Card implementation, but in the system itself. Even without this attack, this key would have been compromised.

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.

Proving programs is hard, but the hardness of the proof greatly depends on what you want to prove. We can split proofs in two groups:

• Proving generic properties on programs. In that case, we are simply trying to prove that a given program (for instance, a Java Card program), satisfies a given property. This can be very simple. For instance, the property “The program does not use sharing” can be proven simply by ensuring that the program does not refer to any shareable interface. In such a case, a syntactical check (which does not look at all at what the program actually does) is sufficient. Sometimes, the proof is not as simple. For instance, the property “The program only sends SMS’s to French phone numbers” (on a MIDP program) is more complex to prove, because it requires an analysis of the data used by the program. In that case, the prover needs to simulate the way in which the program works in order to figure out all possible phone numbers that can be used to send SMS’s, and then analyze that. In that case, a semantic check (which somehow looks at what the program does) is required.
• Proving that a program actually implements its specification. Now, this is the hard part. The first difficulty is actually to write the specification in a way that can be understood by a prover (i.e., a formal specification). Many languages exist to do that, and they are quite complicated. On Java Card, a famous result has been to prove that the verifier actually does its work and guarantees that programs run safely. Multos also had a similar result, in which they proved that running a program was safe(memory-wise). In both cases, it resulted to high-level security certifications (good for publicity and marketing).

Now, how useful are these results?

The first kind of proof is called static analysis. We actually think about using this technique in the deployment of certified NFC applications, because it allows us to prove that an application does not interfere with other applications. And we also have been using this technique in the security evaluation of applications for years. Its main advantage is that is works on binary code, which means that it integrates easily in a signature scheme (a program is signed only if static analysis succeeds).

For formal proofs, we are not as close to direct exploitation. In the case of Java Card, it resulted in the discovery of a few interesting bugs in the specification of the Java Card Virtual Machine and API, which have been fixed in subsequent releases. This often occurs, as the construction of a formal specification forces developers to look into minute details of the spec, which often happen to be the source of issues and bugs.

In quite recent news, an Australian team (NICTA) has announced that they have built a complete formal proof of an operating system kernel, which could be used in mobile devices. This piece of software represents 7500 lines of code, but the formal proof represents 200,000 lines, and it took 4 years to a team of 12 people to build it. Even if they didn’t work on this full time, this means that we are not going to see such proofs on a daily basis. However, this could become more common, because of the side results of this work, as explained by its leader in the press release:

“This work goes beyond the usual checks for the absence of certain specific errors. Instead, it verifies full compliance with the system specification. The project has yielded not only a verified microkernel but a body of techniques that can be used to develop other verified software.”

Hopefully, we will see more of it, since proving programs can definitely lead to more stable programs, and we need that.

Another good news is that the technology is apparently open source, and that it will be transferred to Open Kernel Labs, a well-known Australian company in the field of mobile hypervisors.

Once again, it reminds us that mobile security is a hot topic, and there is still hope that our mobile devices will not become our next PC platform, ridden with vulnerabilities and malware.

I won’t even start claiming that I understand anything about DPA, and I will carefully avoid commenting on the “maximum likelihood method with a bivariate known model” he is using (I did not choose to emphasize the “known” word; somebody else did). However, if I get the result right, the result of this contest is that Christophe has been able to break a DES key with 142 traces (in fact, 43 traces, since the rules of the contest stated that the algorithm needed to remain stable for 100 rounds to win) on average, for 100 tries. This means that in some cases, he was able to make it with 30 traces, or may be even less.

A DES key broken on average with 43 traces? What does it mean for us developers?

Well, the usual way to battle against DPA is to limit the number of possible tries. In many cases, the limit is set quite high, in the hundreds or thousands, even 32767 or 65535 (basic values for 16-bit oriented people). If it becomes possible to break a key with 42 traces, some of the limits will need to get down. For some applications, this will not be a problem; let’s just recompile with a new value, or even send an administrative command to update a value. For many others, the limit is enforced by a counter that is used for other purposes (typically, a transaction counter, limited to 32767 or 65535 for the lifetime of the card). This may not work that well any more.

Of course, in most cases, we are not using DES, but triple-DES. And the rules of the contest made it easier on the contestants, since they knew the value of the key to start with, so the algorithm could be tailored to that key. And there were no hardware countermeasures activated on these traces. And probably many more things.

So, no need to get nervous, and to stop the deployment of our current cards. Nevertheless, because our cards need to live for quite a while, we need to consider that this result is an advanced warning of the problems to come, and that we will eventually need to upgrade our countermeasures. New countermeasures may be invented in hardware, or in low-level software. However, application-level software remains the easier level to update/improve.

This was the first contest of this kind, and another one should be organized next year. The topic and rules are currently under discussion, but we can hope that this will help make the state-of-the-art attack techniques more well-known to the community, and also that it will encourage more labs to show off what they can do.