Live from Cardis2010: Combined attacks on Java Card

I just made my second presentation at Cardis2010, about combined attacks on Java Card (joint work with Anthony Ferrari, now in charge of these things at Trusetd Labs). Sorry, no “public” slides this time, this is related to security evaluation.

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.

One Comment

  • Thiebeauld Hugues wrote:

    I would just like to add few comments on your interesting post and go further in the discussion.

    For the kind of attack, like we have presented with Guillaume at CARDIS, I consider you can see it under several angles. Let me just depict several of these angles:
    1- the attack consists mainly in another type confusion. Nothing really new on that point of view, you’re right
    1 bis – to perform the attack, a single fault injection was necessary, aiming at skipping some instructions in the normal execution flow. Once again, it’s not new, as it is common in the smartcard industry.
    2- it is an illustration how a previous legal application becomes illegal, ill formed, by using a physical perturbation. From this angle, this attack’s principle is very close to your concept of mutant application. It reveals that the security should not be based only on a single protection, but rather on regular, and preferably dynamic, controls.
    3- the must interesting angle, from my opinion, is how new features, or new services, not necessarily directly linked with the security, can be tampered with to defeat the security of a product. Our article outlined how the new class object exploitation led to a potential weakness, if no security consideration have been taken into account in its implementation.

    Regarding the last angle, such papers are very important. They reveal that new feature or functionality should not be added without a strong understanding of their impact in the product security. This should be done in accordance with the environment specificities the product is supposed to embrace, taking into account the specific threats and vulnerabilities.

    Hope this post will be worth of interest.

Leave a Reply

Your email is never shared.Required fields are marked *