A Dynamic Syntax Interpretation for Java Based Smart Card to Mitigate Logical Attacks

Abstract

International audienceOff late security problems related to smart cards have seen a significant rise and the risks of the attack are of deep concern for the industries. In this context, smart card industries try to overcome the anomaly by implementing various countermeasures. In this paper we discuss and present a powerful attack based on the vulnerability of the linker which could change the correct byte code into malicious one. During the attack, the linker interprets the instructions as tokens and are able to resolve them. Later we propose a countermeasure which scrambles the instructions of the method byte code with the Java Card Program Counter (jpc). Without the knowledge of jpc used to decrypt the byte code, an attacker cannot execute any malicious byte code. By this way we propose security interoperability for different Java Card platforms

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

“…In [18], a more memory-friendly countermeasure is presented, called field of bit; this countermeasure verifies whether a FA leads the JVM to illegally interpret bytecode operands as opcodes. An off-card encryption of the method bytecode is proposed in [17]. This bytecode encryption counteracts the security threat of jumping out of the actual method code and executing undefined data.…”

“…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].…”

A Defensive Virtual Machine Layer to Counteract Fault Attacks on Java Cards

“…In [20], the authors propose storing a countermeasure flag in a new applet component to indicate whether the method is encrypted. They perform this encryption using a secret key and the Java program counter for the bytecode of every method.…”

“…To be able to execute Java applets, the VM uses internal data structures, such as the OS or the LV, to store interim results of logical and combinatorial operations. All of these internal data structures are general objects for adversaries that attack the Java Card [4,20,24]. For every method invocation performed by the VM, a new Java frame [19] is created.…”

“…In the literature, different countermeasures, such as control-flow checks [23], double checks [4], integrity checks [8] and method encryption [20], have been proposed. Barbu [3] proposed a dynamic attack countermeasure in which the VM executes either standard bytecodes or bytecodes with additional security checks.…”