Live from e-Smart: Nijmegen strikes again

Wojciech Mostowski is a researcher from the Radboud University Nijmegen, and he is a frequent speaker at e-Smart. He even wa a finalist for the Java Card Forum a while ago. He has been spending years looking very closely at the Java Card specifications, trying to find issues in cards. Today, he is getting at the firewall.

It seems that logical attacks on Java Card are quite trendy these days, as several teams seem to work on them. On the firewall, the idea is here that the Java Card specifications assume type correctness, but that this correctness is not actually guaranteed, because in most cases, bytecode verification is not performed on the card, which means that incorrect applications can be loaded.

The presentation starts with a few compliance tests, of course based on cornercases. They found a few issues, but nothing really bad. It may be possible in some cases to get the type of an object when you shouldn’t, or to use a transient array when it should not be accessible, but in the end, there is no way to get anythingreally interesting done.

The next item is much more interesting. His idea is to create type confusion on files that are apparently correct, simply by using two different definitions of the Shareable interface: one for the client, and one for the server, with different definitions. For instance:

On the client side:

public interface Bad extends Shareable {
  public void doDamage(AID aid);
}

On the server side:

public interface Bad extends Shareable {
  public void doDamage(byte[] ba);
}

If you verify the client with its definition of the interface, and the server with its own version, verification will succeed in both cases. However, the type confusion is obvious. And in this case, the “bad” part is that the AID is a JCRE entry-point object, with high privileges. and this allows an attacker to do bad things. I won’t go further here, but details are available on the slides.

Overall, it is nice to see that Java Card logical attacks get exposed. The potential impact is in practice minimal, because it is very difficult for hackers to load applications in deployed cards (since a GlobalPlatform authentication is typically required). Nevertheless, with NFC and other “open” schemes, the number of downloaded applications is likely to raise quite fast, and the risk of getting malware in the card may slightly increase (developers remain well identified, so the risk is likely to remain low).

This means that bytecode verification needs to be systematically performed, and that this verification needs to be performed by taking into account the actual context in which the application will be exploited. The exploit above is only possible because the server and client have been verified with respect to different contexts.

Recent multi-application projects, such as the Pegasus project in France, have defined strong requirements in this matter, and we are getting closer to exploiting a complete verification environment, which was my first assignment as a Trusted Logic employee, about 8 years ago. Time to get this code out of the closet…

Oh, I almost forgot. Of course, Java Card 3.0 addresses this issue, at least in its Connected edition, where on-card bytecode verification is mandatory.

No Comments

Leave a Reply

Your email is never shared.Required fields are marked *