The ultimate control flow transfer in a Java based smart card

Bouffard, Guillaume; Lanet, Jean‐Louis

doi:10.1016/j.cose.2015.01.004

Cited by 6 publications

(6 citation statements)

References 17 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…To run a Java applet on resource-constraint devices, the adopted solution is to translate reference name to token during a step made by the Java Card converter 4 . If the class file to convert implements features that can be used by other applications, a Java Card export file is also generated.…”

Section: Java Card Security Modelmentioning

confidence: 99%

See 1 more Smart Citation

PhiAttack

Dubreuil¹,

Bouffard

2022

Smart Card Research and Advanced Applications

Self Cite

View full text Add to dashboard Cite

Compiling Java Card applets is based on the assumption that export files used to translate Java class item to Java Card CAP tokens are legitimate. Bouffard et al.[2] reversed the translation mechanism. Based on malicious Application Programming Interface (API) embedded in a target, they succeeded in making a man-in-the-middle attack where cryptographic keys can leak. In this article, we disclose that, on a pool of legitimate export files, Java Card Virtual Machine (JCVM) implementations can be confused by a CAP file verified by the Java Card Bytecode Verifier (BCV). The disclosed vulnerability leads to Java Card class hierarchy rewriting. The introduced vulnerability is exploitable up to Java Card 3.0.5. Recently, Java Card 3.1.0 provides a new export file format which prevents this vulnerability.

show abstract

Section: Java Card Security Modelmentioning

confidence: 99%

“…The Java Card platform implementation security has been thoroughly studied against software [1,3,4,5,8,9,10,12,17] attacks. Those attacks are implementation dependent and they are prevented by a BCV.…”

Section: State-of-the-art Java Card Platform Securitymentioning

confidence: 99%

PhiAttack

Dubreuil¹,

Bouffard

2022

Smart Card Research and Advanced Applications

Self Cite

View full text Add to dashboard Cite

show abstract

“…Bouffard and Lanet [13] presented a generic approach based on a Control Flow Transfer (CFT) attack to modify the Java Card program counter. The attack is based on a type confusion, it abused the BCV verification, using the couple of instructions jsr/ret.…”

Section: Fault Enabled Logical Attacksmentioning

confidence: 99%

Hiding a fault enabled virus through code construction

Hamadouche

Lanet

Mezghiche

2019

J Comput Virol Hack Tech

Self Cite

View full text Add to dashboard Cite

Smart cards are very secure devices designed to execute applications and store confidential data. Therefore, they become the target of many hardware and software attacks that aim to bypass their embedded security mechanisms in order to gain access to the sensitive stored data. Recently, a new kind of attacks called combined attacks has appeared. They aim to induce perturbations in the application's execution environment. Thus, correct and legitimate application can be dynamically modified to become a hostile one after being loaded in the card using a fault injection. In this paper, we treat the problem from another angle: how to design an innocent looking code in such a way that it becomes intentionally hostile after being activated by a fault injection? We present an original approach of backward code construction based on constraints satisfaction and a tree traversal algorithm. After that, we propose a way to optimize the search process by introducing heuristics for a faster convergence towards more realistic solutions.We implement this approach in a Trace Generator tool; thereafter evaluate its capacity to generate the required solutions while giving a proof-of-concept of the code desynchronization technique.

show abstract

“…Despite all the security features enforced by the Java Card environment, several attack paths [1,2,4,5,6,10,11,13,14,15,19,22] have been found exploitable by the Java Card security community.…”

Section: The Java Card Security Modelmentioning

confidence: 99%

Java Card Virtual Machine Compromising from a Bytecode Verified Applet

Lancia¹,

Bouffard

2016

Smart Card Research and Advanced Applications

Self Cite

View full text Add to dashboard Cite

The Byte Code Verifier (BCV) is one of the most important security element in the Java Card environment. Indeed, embedded applets must be verified prior installation to prevent ill-formed applet loading. In this article, we disclose a flaw in the Oracle BCV which affects the applet linking process and can be exploited on real world Java Card smartcards. We describe our exploitation of this flaw on a Java Card implementation that enables injecting and executing arbitrary native malicious code in the communication buffer from a verified applet. This native execution allows snapshotting the smart card memory with OS rights.

show abstract

The ultimate control flow transfer in a Java based smart card

Cited by 6 publications

References 17 publications

PhiAttack

PhiAttack

Hiding a fault enabled virus through code construction

Java Card Virtual Machine Compromising from a Bytecode Verified Applet

Contact Info

Product

Resources

About