Guillaume Bouffard

Combined software and hardware attacks on the java card control flow

The Java Card uses two components to ensure the security of its model. On the one hand, the byte code verifier (BCV) checks, during an applet installation, if the Java Card security model is ensured. This mechanism may not be present in the card. On the other hand, the firewall dynamically checks if there is no illegal access. This paper describes two attacks to modify the Java Card control flow and to execute our own malicious byte code. In the first attack, we use a card without embedded security verifier and we show how it is simple to change the return address of a current function. In the second attack, we consider the hypothesis that the card embeds a partial implementation of a BCV. With the help of a laser beam, we are able to change the execution flow.

A friendly framework for hidding fault enabled virus for Java based smartcard

Smart cards are the safer device to execute cryptographic algorithms. Applications are verified before being loaded into the card. Recently, the idea of combined attacks to bypass byte code verification has emerged. Indeed, correct and legitimate Java Card applications can be dynamically modified on-card using a laser beam to become mutant applications or fault enabled viruses. We propose a framework for manipulating binary applications to design viruses for smart cards. We present development, experimentation and an example of this kind of virus.

Reversing the operating system of a Java based smart card

Attacks on smart cards can only be based on a black box approach where the code of cryptographic primitives and operating system are not accessible. To perform hardware or software attacks, a white box approach providing access to the binary code is more efficient. In this paper, we propose a methodology to discover the romized code whose access is protected by the virtual machine. It uses a hooked code in an indirection table. We gained access to the real processor, thus allowing us to run a shell code written in 8051 assembly language. As a result, this code has been able to dump completely the ROM of a Java Card operating system. One of the issues is the possibility to reverse the cryptographic algorithm and all the embedded countermeasures. Finally, our attack is evaluated on different cards from distinct manufacturers.

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

Off 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.

Type Classification against Fault Enabled Mutant in Java Based Smart Card

Smart card are often the target of software or hardware attacks. For instance the most recent attacks are based on fault injection which can modify the behavior of applications loaded in the card, changing them as mutant application. In this paper, we propose a new protection mechanism which makes application to be less prone to mutant generation. This countermeasure requires a transformation of the original program byte codes which remains semantically equivalent. It requires a modification of the Java Virtual Machine which remains backward compatible and a dedicated framework to deploy the applications. Hence, our proposition improves the ability of the platform to resist to Fault Enabled Mutant.

Memory Forensics of a Java Card Dump

Nowadays several papers have shown the ability to dump the EEPROM area of several Java Cards leading to the disclosure of already loaded applet and data structure of the card. Such a reverse engineering process is costly and prone to errors. Currently there are no tools available to help the process. We propose here an approach to find in the raw data obtained after a dump, the area containing the code and the data. Then, once the code area has been identified, we propose to rebuilt the original binary Cap file in order to be able to obtain the source code of the applet stored in the card.

Evaluation of the ability to transform SIM applications into hostile applications

The ability of Java Cards to withstand attacks is based on software and hardware countermeasures, and on the ability of the Java platform to check the correct behavior of Java code (by using byte code verification). Recently, the idea of combining logical attacks with a physical attack in order to bypass byte code verification has emerged. For instance, correct and legitimate Java Card applications can be dynamically modified on-card using a laser beam. Such applications become mutant applications, with a different control flow from the original expected behaviour. This internal change could lead to bypass controls and protections and thus offer illegal access to secret data and operations inside the chip. This paper presents an evaluation of the application ability to become mutant and a new countermeasure based on the runtime checks of the application control flow to detect the deviant mutations.

Mitigating Type Confusion on Java Card

One 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.

The ultimate control flow transfer in a Java based smart card

Recently, researchers published several attacks on smart cards. Among these, software attacks are the most affordable, they do not require specific hardware (laser, EM probe, etc.). Such attacks succeed to modify a sensitive system element which offers access to the smart card assets. To prevent that, smart card manufacturers embed dedicated countermeasures that aim to protect the sensitive system elements. We present a generic approach based on a Control Flow Transfer (CFT) attack to modify the Java Card program counter. This attack is built on a type confusion using the couple of instructions jsr/ret. Evaluated on different Java Cards, this new attack is a generic CFT exploitation that succeeds on each attacked cards. We present several countermeasures proposed by the literature or implemented by smart card designers and for all of them we explain how to bypass them. Then, we propose to use Attack Countermeasure Tree to develop an effective and affordable countermeasure for this attack.

Accessing secure information using export file fraudulence

Java Card specification allows to load applications after the post-issuance. Each application to be installed into the card is verified by a Byte Code Verifier which ensures that the application is in compliance with the Java security rules.