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.