LaMeH@CkeR

Introduction

The purpose of this article is to describe a Java Card file verification attack by exploiting a vulnerability found in the SIO mechanism of the Java Card Virtual Machine 2.1. This article will also include a short background introduction to explain the reasons that led to the SIO vulnerability and the concepts that the SIO mechanism is based on.

Data sharing before 2.1 JCVM

Since the invention of Java Card platform, the issue of code and data sharing has been a topic of considerable interest [1,2]. The first Java Card Virtual Machines shared data between JCApplets using directly the file system, and restricting the access to that file system by applying access control lists (ACL) to the operations performed to the data.

The ACLs would determine which identities could access specific files, and what permissions each identity would be given. The identity authentication was performed through the use of key files and PIN verification procedures. This approaching method was considered to be quiet effective and powerful [1], but it did not worked well with the object oriented nature of Java Card platform. In many occasions data sharing between objects was quiet difficult to do in a clear and smooth way. The concept behind the Java Card Platform 2.1 was that all necessary data would be stored into objects, the Service Objects.

Access control through the AIDs

When the SIO mechanism is used all access control decisions taken by the Server JCApplet are based solely on the AID of the requesting Client JCApplet; no other information is available to the Server JCApplet.

This is done because only certain interfaces are to be granted to particular client JCApplets. Each AID is unique, and as already explained is used to uniquely identify JCApplets that are already registered to the JCRE. This is a very important detail because identification through the use only of AIDs could lead to serious security violations.

Java Card platform 2.1 treats data as objects. The only way for an object to gain access to the some application data is to use its own methods to access other objects containing the requested data, e.g. Service Objects hold data that make JCApplets operational. In that way a completely object oriented data approach is achieved; only objects are used to manipulate data and handle operations, the outcome of this approach is that generic data access mechanisms are used for literally all read/write procedures.

Now if the SIO mechanism is used from one JCApplet to access data in another JCApplet and only the AIDs are used for identification, this means that an ill formed JCApplets (a malicious JCApplet) could easily impersonate a legitimate JCApplet to obtain illegally data.Ill formed JCApplets can easily be loaded to the Smart Card with forged AIDs because no violation is going to be detected by the CAP file verifier.

AID impersonation

It is possible for a malicious JCApplet to forge an AID, make a valid SIO request, and gain illegitimate access to data. This is feasible only under three assumptions:

a) The ill-formed JCApplet knows the Sever JCApplet AID.

b) The ill-formed JCApplet knows the Client JCApplet AID.

c) The ill-formed JCApplet knows what interfaces the Server JCApplet implements.

Under the assumptions made above, a malicious JCApplet can be loaded to the JCRE and forward a SIO request to the JCRE using the forged AID, and then try to obtain the returned SIO. The server JCApplet want be able to deny access to the requested interface because the object identification process will not detect the AID forgery.

This is a critical security problem, and can be solved only through JCApplet downloading restrictions. Restricting JCApplet downloading reduces significantly the flexibility that Java Card platform provides; this issue should be considered as a functional problem and also as a security problem.

Why AID impersonation is a CAP file verification attack

An AID impersonation attack is a CAP file verification attack because, in order for an attacker to perform an AID impersonation first has to verify his/her malicious Java Card Applet. If the a malicious Java Card Applet, exploiting the SIO vulnerability, is verified, then his/her JCApplet is also an Ill formed JCApplet that bypasses two security mechanisms, the CAP file verifier and the Java Card Applet firewall. This form of attack happens because of two major reasons a) the runtime properties of the JCRE and b) and the CAP file verifier. Future solutions to this problem can be given only if JCRE and CAP file verifier are going to be completely redesigned.

Assumptions made for this attack

An AID impersonation attack, as already mentioned, is based in four basic and very important assumptions:

a) The Java Card application uses the SIO mechanism to share data between JCApplets.

b) The attacker has knowledge of the Server JCApplet AID.

c) The Attacker has knowledge of the Client JCApplet AID.

d) The attacker knows what interfaces the Server JCApplet implements.

Basic description of the system used to perform the attack

The system used to perform the attack consists of three JCApplets, one Client JCApplet named ClientApplet, one Client JCApplet named MClient and one Server JCApplet named ServerApplet. The legitimate Client JCApplet named ClientApplet is used to show how a normal SIO interaction is performed; the Client JCApplet named MClient is used to hack the ClientApplet interface form the Server JCApplet named ServerApplet,.

The ServerApplet will implement two interfaces, the ServerInterface that is used by the ClientApplet and the ServerMaliciousInterface that is used by the MClient. Both Clients should be capable of making a legitimate request for their SIO interface, but MClient should not be capable of requesting the ServerInterface.

All three JCApplets must be compiled, verified and loaded successfully to the Java Card platform in order for the experiment to take place, in a few words all JCApplets must be selectable during the attack.

References:

[1]Author: Michael Montgomery and Ksheerabdhi Krishna, Secure Object Sharing in Java Card, USENIX Association,May 1999 Chicago, Illinois, USA ,date retrieved: 22-06-2005

URL:http://www.usenix.org/publications/library/proceedings/smartcard99/montgomery.html

[2]Daniel Perovich and Leonardo Rodriguez, Martin Varela,A Simple Methodology of Secure Object Sharing, Instituto de Computacion Faculat de Ingeniria, October 2000,Date retrieved: 22-06-2005,

URL: http://www.fing.edu.uy/inco/grupos/mf/Proyectos/Grado/JavaCard/secsha.pdf