We have still a good lesson to learn from this paper: think globally not locally. I explain. The EMAN2 attack used the absence of check on the local variables. But the problem was not about locals. We were using what Aurelien pointed out in his PhD : ROP (Return Oriented Programming) modify the control flow of the return mechanism to jump where you need. In fact, there is an asset to protect in integrity i.e. the return address register. With our preferred Java Card (from attacker POV), in 2012 the smart card manufacturer modified its firmware in such a way that our attack did not run anymore. Bad news ? Not at all. They just modify the card in a way that the attack path on the locals is now a dead end. A trick. No more no less. We just found another way to access the return address with less knowledge from the attacker and it runs again. A weak counter measure… a trick. Designing counter measure in a bottom up approach is not a good idea. Think top down, think globally. Find the asset and protect it whatever the path is. Maybe there are some implementation or economic constraints that lead card designers to think like this. But from a scientific POV it is not satisfactory. This is the real lesson from this paper.
jl

Thanks for your comment. On the innovative section, I still consider that the paper introduces little innovation on top of EMAN2.

And I also agree that not all cards include significant security measures on the VM. But then, not all cards are designed to withstand the most sophisticated attacks.

I have had the opportunity to read also the paper. You are right the title does not reflect the content. They do not bypass the BCV. On that point I agree with you.

But I disagree on the NOT INNOVATIVE section. I never see any publication on it except the paper on the EMAN2 attack. At that time, we paid a lot of attention on the state of the art without finding any paper related to an underflow attack on Java Card. Perhaps, I did not use the google scholar enough, but I search also in the Barbu’s PhD thesis without any success. Probably in the industry you share such an information, but from an academic point of view it is an unpublished work. A trick you said ? Humm, I tried it, and it runs on several cards. Maybe a generic trick ? Counter measure are known you said, but it looks like that some Card designers forgot to implement them ? No ?

rgds,
jl

First, she didn’t like the fact that I have qualified the paper “dishonest”. I stand by the fact that the title can be considered dishonest, but I of course admit that this may not reflect the author’s intention, and could be a bad wording.

Then, about the lack of innovation, she claims that no attack has been published before that allows the attacker to modify the current context, and that it is important to let the community that this is possible. I am surprised that this can be new for people in the field, but I admit that I haven’t seen it in research publications at this time. However, this attack has been known forever from the industry, and used in many evaluations.

Finally, and most interestingly, we discussed of the objective of the paper. If I understood well, the objective is here to convince people from the industry that the bytecode verifier is not by itself a sufficient protection for a virtual machine.

Here, we completely agree. The bytecode verifier checks that an applet functionally complies to the spec. It is somewhat similar to checking that a DES key is not one of the known weak keys. The virtual machine is a component of the smart card operating system. Just like all the DES implementation or all other components, it can be attacked. And just like the DES implementation, a secure virtual machine needs to include countermeasures.

Nathalie suggested to make editorial changes to the paper, and these would be most welcome. As we agree on the conclusions, let’s make sure that message is brought properly. I will try to reinforce soon with another blog.