About e-Smart: Java Card attacks

I was not at e-Smart this year, but here are some early reports from colleagues who attended the sessions. Over the coming days, I will comment on a few selected presentations. First, one of my favorite topics, which was covered Friday morning: attacks on the Java Card platform. There were two presentations this morning on this topic, both of them challenging the often accepted simplistic view on bytecode verification.

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.


  • Nice post, Eric. It’s a pleasure to follow your blog.

    It hits me that the most simple and effective way to collaborate would be to share test suites.

    Do you think this is achievable?



  • Sharing test suites is the obvious part.

    Now, we are talking (1) about security evaluation labs, and (2) about smart cards. We share a lot of values, but sharing isn’t one of them.

    I hope that we will be able to advance on that topic, but it will take some time, and even if some sharing occurs, it may never become public.

    I’ll repeat my conclusion: We’ll see …

  • […] to ensure that they won’t interfere with their own applications (after all, I have designed logical attacks in the past). Java Card provides some solutions, with the firewall that isolates applications, and […]

Leave a Reply

Your email is never shared.Required fields are marked *