On the road to Bandol

The notion of defensive virtual machine is a bit awkward. The official presentation of the Java (Card) Virtual Machine describes it as inherently secure, so the notion of defensive is a bit contradictory with this message.

In fact, the notion of defensive virtual machine is the result of a long process:

• Virtual machines usually present the advantage to introduce a good level of control. For instance, to name a few things available on Java, good typing is guaranteed, only existing and initialized local variables can be accessed, and it is not possible to access data out of the bounds of arrays.
• Performing all these checks makes a virtual machine slow, so the designers of the Java Virtual Machine (JVM) have designed the code to be statically verifiable. This means that most of the checks (basically, all but the array bounds checks) are performed once and for all by analyzing the code at load time. Thanks to these optimizations, the performance of the JVM is rather good, while keeping its security.
• On a platform like Java Card, which can be attacked, this raises security issues. If code is modified in an attack, the guarantees do not hold any more. We then get to the defensive virtual machine, which performs redundant checks. Some of the original checks are performed, in order to have some guarantees or correct execution even in the hypothesis of an attack.

In Java Card, there is an additional reason to resort to defensive virtual machines: the bytecode verifier is not run on the execution platform, but on a separate platform. This provides an attacker with many additional opportunities to modify the code and perform an interesting attack. It is therefore more tempting to include additional defences.

Many smart card manufacturers claim that their Java Card VM is defensive, but this word covers a wide variety of things. Some VM’s simply include a few redundant bounds check, whereas some others include complete bounds checks, as well as some typing checks. When confronted with badly typed applets (the ultimate attack that defensive VM’s defend against), the simplest ones simply cause the attacker to think a few more minutes; with the most complex ones, badly typed code becomes very inefficient, and usually leads to no interesting result.

In the end, defensive virtual machines are yet another instance of the perpetual dilemma between performance and security.