Mitigating Type Confusion on Java Card

Abstract

International audienceOne of the challenges for smart card deployment is the security interoperability. A smart card resistant to an attack on a given platform should be able to guarantee the same behavior on another platform. But the current implementations do not comply with this requirement. In order to improve such standardization we propose a framework based on annotations with an external pre-processing to switch the Java Card Virtual Machine (JCVM) into a secure mode by activating a set of countermeasures. An example has been proposed in this paper for implementing a countermeasure against type confusion with a fault attack. Smart cards are often the target of software, hardware or combined attacks. In recent days most of the attacks are based on fault injection which can modify the behavior of applications loaded onto the card, changing them into mutant applications. This countermeasure requires a transformation of the original program byte codes which remain semantically equivalent. It needs a modification of the JCVM which stays backward compatible and a dedicated framework to deploy these applications. Thus, the proposed platform can resist to a fault enabled mutant

Countering type confusion and buffer overflow attacks on Java smart cards by data type sensitive obfuscation

“…Therefore, JVM countermeasures should be transparent to an applet and its programmer. Furthermore, no off-card applet pre-processing should be needed to enable the countermeasure because industrial applet providers do not want to change their applets in any way; for example, they are not willing to add additional data into an applet as proposed in [13,7,19,18]. Additional data in an applet increase the risk of interoperability issues between different applets and Java Cards.…”

“…This bytecode encryption counteracts the security threat of jumping out of the actual method code and executing undefined data. Another countermeasure proposed in [7,11] counteracts the threat of type confusion between the two main data types integralData and reference. All elements of one main data type are pushed and popped onto their specific OS.…”

“…The countermeasure needs no off-card pre-processing of a Java applet, as required by other countermeasures [18,5,19,17,7,11,13]. Furthermore, the countermeasure consumes no additional run-time memory for storing the Java type information during run-time as in [11].…”

The ultimate control flow transfer in a Java based smart card

“…During the access of an element, the JCRE checks the associated bit value to avoid a type confusion attack from the Java Card stack. Dubreuil et al, as described in Dubreuil et al (2013), designed a lightweight typed stack. As the Java Card frame is statically defined, it can be split into two parts.…”

Security automaton to mitigate laser-based fault attacks on smart cards

“…A checksum can be used to verify the manipulated value for each operation. Another low cost countermeasure approach, to protect stack element against FI attack was explained by Dubreuil et al (2013). Their countermeasure implements the principle of a dual stack where each value is pushed from the bottom and growing up into the stack element.…”