Live from #esmart: Fault attacks on Java Card 3.0

That talk, from Guillaume Barbu, an Oberthur and Telecom ParisTech Ph.D. student, really talks to me, by bringing together two of my favorite discussion topics. The main task is about combined attacks, which sounds really good.

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

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

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

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

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

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

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

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

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

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

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

No Comments

Leave a Reply

Your email is never shared.Required fields are marked *