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

Introduction

This article is written to explain the JCRE functionality and behavior. More over this article explains some basic components of the JCRE such as the Javacard Applet, the Javacard Appplet firewall and JVCRE context switching mechanism.

The Java-card Runtime Environment

The Java Card runtime environment (JCRE) should be considered as the part of the platform that implements the component that does the Java Card Applet interpretation, and it is the most important part of the Java Card platform. JCRE is responsible for:

1. Smart Card resource management (e.g. Allocate Smart Card computing resources).

2. Network communication management (e.g. Card Acceptance Device sessions).

3. Applet manipulation (e.g. Applet execution).

4. Real-time on card security enforcement (e.g. Apply security policies).

The JCRE sits on top of the smart card hardware native system and represents the part of the Smart Card operating system that performs the executions , it is actually the core module of the operating system. The classes are responsible of managing the transactions between an off card entity and the on card entity (e.g. Update Applet data).

The Java Card application framework defines the Java Card API available to the programmer. The installer makes sure the Java Card Applet downloading happens in a secure and efficient manner. The software component called installer is what makes possible dynamic application management, without the installer Java Card Applets would not be capable of being installed dynamically, meaning after the Smart Card fabrication stage.

JCRE lifetime

The JCRE is initialized at the Smart Card initialization stage and remains active until the Smart Card is terminated. During initialization the JCRE creates all the necessary services (objects that implement the services) needed for the SC in order to be functional. After a Java Card Applet is downloaded and installed the JCRE creates Java Card instances and Java Card Applets create objects to store data. At this point it would be important to mention that a JCApplet can have a different AID than its own instance (see JCApplet Name Convention paragraph).

JCRE features

The JCRE component supports the Java Card language model, but also supports many other features unique to Java Card platform. Three of the most important features concerning both Smart Card functionality and security are:

1. Persistent and transient objects.

2. Atomic operations and transactions.

3. Applet firewall and sharing mechanism.

When the JCRE wants to make a JCApplet persistent [4], (all JCApplets are persistent by default) then stores a reference of the JCApplet instance object in a persistent memory type such as NVM. The term persistent is used to describe a JCApplet that sustains a cold reboots.

A JCApplet can create a transient object [4], (all JCApplets objects are transient by default, for security reasons) when it stores a reference of the object in a non-persistent memory such as RAM. The term transient is used to describe an object that does not sustain cold reboots; JCApplets are not allowed to carry data between CAD sessions.

By using the term Atomic operations/transactions [4] we refer to the ability of the JCRE to make transactions all or nothing, meaning that in order for a transaction to take effect has to be performed correctly until the end without errors or else the effect of this transaction won’t take place. The JCVM will ensure that each write operation to an object is atomic. A transaction can fail for many reasons (e.g. the card holder removes the card from the CAD before the transactions is performed).

Part of the SUN Java Card platform security requirements demands [1] was that the on-card linker and loader are needed to contribute in fulfilling these requirements. The JCVM firewall security mechanism performs a set of verifications to ensure that memory integrity is preserved.

The main role of the on-card Java Card firewall is to make sure that the runtime behavior of JCApplets converted applets (CAP files) happens in a secure and clear way, preventing objects from performing illegal access operations, performed mostly outside their Java Card packages. A package is a collection of JCApplets and objects associated with only a single application.

The main goal of the Java Card firewall is to strictly enforce Java Card generic security policies defined in the Java Card specification. The Java Card firewall provides the assurance that the access rules of Java Card Runtime Environment specification 2.1 are fulfilled [1].

Java Card Applets

Before describing in more detail the security properties of a JCApplet, we should recall in this section what makes Java Card applications different if compared to other ordinary applications. A JCApplet is restricted by: the limited resources of the Smart Card and the Java Card platform security requirements.

A normal JCApplet goes through many different phases:

1. Loading: The code of the application is downloaded from the off card entity into the on card entity, the SC.

2. Installation: An applet instance is created and registered during the JCApplet installation [3]. Several instances of the same applet can coexist with different AID, so as the JCRE can select them.

3. Personalization: A registered JCApplet (in order for a JCApplet to register first has to install) instance object is personalized only after receiving and initializing the proper data. An applet is personalized only once and only then can become operational or functional. Note however that there is no explicit support for each JCApplet in the system concerning personalization [3], which means that the programmer has to take into consideration programming that task.

4. Processing: When a registered, operational JCApplet is selected, it can receive several C-APDU commands and responds back with R-APDU, and afterwards it can be deselected. This can be repeated many times until the transaction is performed.

Java Card Applet Name Conventions

Each JCApplet instance is identified by a pre-selected application identifier (AID). The same thing happens for the JCApplet, actually before any JCApplet can run first has to have the corresponding package already installed.

If the JCApplet instances are registered with the default AID (meaning the JCApplet owner AID) then the register function is called without parameters. If the JCApplet instances are installed with other AID then the parameters that initialized the register method are provided from the install function and the instance becomes operational. An AID is literary speaking a byte array used as a selection identifier. Each AID that complies with the ISO 78164 consists of a RID and PIX. The RID is a 5-byte value called resource identifier and PIX is a 0 to 11-byte value, called proprietary identifier extension. The PIX value works as a company identifier and the PIX is used as an application identifier within the same company.

Java Card Applet Categories

The Java Card platform supports three different kinds of JCApplets, the ROM JCApplet, the Pre-issuance JCApplets and the Post-issuance JCApplets.

The ROM JCApplets are simply a JCApplets written into Smart Card ROM memory space, which means that it must be burned into the ROM during the Smart Card fabrication stage. Because ROM JCApplets are owned by the issuer the Java Card platform treats them as a trusted peace of software and allows this kind of JCApplets to make native calls, e.g. using the C/C++ programming languages.

Pre-issuance JCApplets are simply JCApplets written into an NVM memory, which means that the procedure takes place after the Smart Card fabrication stage. Because Pre-issuance JCApplets are also owned by the issuer the Java Card platform treats them as a semi-trusted peace of software and does not allow making native calls.

Post-issuance JCApplets are simply JCApplets written into the Smart Card NVM memory, which means that the procedure takes place after the Smart Card fabrication stage. Actually post-issuance JCApplets are installed to the smart card after the card is launched to the field. Because Post-issuance JCApplets are not owned by the issuer the Java Card platform treats them as an un-trusted peace of software and does not allow making native calls.

Java Card Applet life cycle

In order for a JCApplet to be functional or operational first has to go through a few procedures that reside inside the smart card platform. After the packages defining a JCApplet have been loaded and linked correctly, inside the SC, the JCApplet can start operating normally. A JCApplet first has to be installed, then has to register and then if selected can start performing useful tasks by using the process function to process C-APDU commands. Now because JCRE is a single threaded environment only one JCApplet can run each time, a JCApplet becomes selected only when explicitly requested by an application host. The term selected refers to a procedure performed when an off-card entity wishes to interact with a specific JCApplet that resides into the SC. A regular JCApplet goes through lots of phases during its life time and before it terminates.

The following functions that are used to manipulate JCApplets are well formed procedures defined at the Java Card platform specification:

1. JCApplet install: Is the method called by the JCRE during a JCApplet installation in order to create a JCApplet instance. The install method is similar to functionality with the Java main function, when this method is called then three things happen: a. a service object is created on behalf of the JCApplet, b. the service object is initialized to provide the specific services, c. the service object is registered with the JCRE. Service Object (SO) is the term that refers to an object created by a post-issuance or pre-issuance JCApplet in order to become operational.

2. JCApplet registration: Is the function called by the JCRE used to do two things: a. to store the JCApplet reference to the JCRE (so as the JCApplet can become selectable) and b. to assign a valid AID to the instance, the default AID is the same of the JCApplet.

3. JCApplet process: Is the function used by the JCApplet instance to process the incoming C-APDU and produce the outgoing R-APDU.

After a JCApplet is selected, it can get deselected and selected again many times until the JCRE decides to dispose the JCApplet permanently from the smart card (e.g. delete the JCApplet). A JCApplet remains in suspended state until it gets selected by the JCRE. The SELECT APDU command is the only C-APDU command standardized on the Java Card platform [4], providing that way interoperable JCApplet selection in various Java Card implementations.

Before new JCApplet gets selected by the JCRE (the JCRE is single threaded) must first deactivate the previously selected JCApplet, unless the previously selected JCApplet is the one that has to be selected now. If the JCRE receives an APDU SELECT command about a JCApplet, then if the JCApplet is installed and registered to the JCRE then it will get selected and capable of interacting with the host application through the JCRE.

JCApplet firewall

The primary goal (as already mentioned earlier) of the on-card JCApplet firewall is to execute Java Card byte-code in a secure manner, preventing objects from illegally accessing memory parts outside their Java Card packages [1]. Even though Java Card platform is multi-application platform Java Card Applications isolation is not always true! Access between two or more packages is possible and can be controlled by the firewall. At this point Java Card platform could be considered as a hybrid of multi-application platforms and multi-function platforms.

Java Card Application firewall provides the assurance that the access rules of Java Card Runtime Environment specification 2.1 are fulfilled [2,1]. The firewall can not stop ill formed Java Card Applets that behave maliciously. Actually the confidentiality of a Java Card Application will not be preserved by the firewall if such applications provide a sharable interface associated with confidential data and fail to properly manage that data (for Sharable Interface see relevant paragraph that follows), because any other application may legally obtain the data references and gain access to the data (see more about sharable on article Object Sharing paragraph).

The Java Card firewall takes into account the following aspects:

1. The currently selected JCApplet.

2. Object access rights.

3. Context switching between objects.

4. Access across different group contexts.

Any attempt to go through the firewall raises a SecuirtyException (Java Card Exceptions and Exception Handling are beyond the scope of this report) [19].

JCApplet firewall features

The single threaded JCRE uses the Java Card Application firewall to prevent objects from being illegally accessed by JCApplets that do not have the ownership. The context notion, of the context the object is contained, enforces the proper access requirements. Each CAP file loaded in the card is associated with a specific runtime context under the following rules [1]:

1. Every Java Card Application is represented by only one package.

2. One Java Card package defines only a single runtime context.

3. All JCApplets that belong to the same package use one runtime context also called group context.

4. Objects created during a specific runtime context belong to that context.

5. All methods and objects that belong to the system JCApplets (entry-points and arrays, see relevant paragraph that follows) belong to a particular context along with the JCRE context, also called system context.

7. JCRE entry points, objects and global arrays are within the JCRE package and can be accessed from any context [1].

As a consequence, Java Card Applications are securely isolated from other contexts; this is a security requirement for all multi-application platforms. One of the responsibilities the linker has is to resolve object references. A method cannot directly refer to objects if they are not objects of the system or if they are outside its package [1].

[1]St?©phanie Motr?©, Formal Model and Implementation of the Java Card Dynamic Security Policy, 2000, date retrieved: 22-06-2005

URL:http://66.102.9.104/search?q=cache:PHaFaHXJeIAJ:www-lsr.imag.fr/afadl2000/Programme/Articles/motre.doc

+java-card+CAP+verification+attacks+&hl=en&start=31&ie=UTF-8&client=firefox-a

[2]Sun Microsystems, Inc, Java Card(TM) Specification, Version 2.2.1, October 29 2003, date retrieved: 01-07-2005
URL: http://java.sun.com/products/javacard/specs.html

[3]Renaud Marlet, Daniel Le M??etayer (Trusted Logic), Security Properties and Java Card Specificities to Be Studied In the SecSafe Project, Version 1.0, 2001/08/23, Date retrieved: 01-08-2005

[4]Zhiqun Chen, Java Card ^TM Technology for Smart Cards, June 2000, Sun Microsystems Inc.

Introduction

The purpose of this article is to provide the theoretical background, about some of the most important Java Card platform security features and explain why Javacard is an excellent programming language for smartcards.

Java security inheritance

Java was the fist programming language that took seriously into consideration secure programming. Java as a desktop programming language has many security features that help to protect the integrity of the system by preventing several common attacks found in other programming languages such as C++, C and FORTRAN. The following security features made Java popular among many other languages:

Security through being well-defined: The Java language is strictly defined:

• Primitive data types have predefined memory size.
• Operations are defined to be performed in a specific order [1].

Security through the lack of pointers: The Java language does not support pointers, so pointer forgery can not happen.

Security through memory management: Garbage collection [1] makes Java programs more secure and robust because:

• Failure to free memory once it is no longer needed is done by the JRE.
• Accidentally freeing the same piece of memory twice is also avoided by the JRE.

Security through strict compile-time checking: The extensive, stringent compile time checking occurs so that compile errors can be detected. The Java language is strongly typed [1], that is:

• Objects cannot be cast to a subclass without an explicit runtime check.
• All references to methods and variables are checked to make sure that the objects are of the same type.

Java-card is strictly defined as a Java subset

Java Card technology preserves the object-oriented nature of the Java programming language thus it can be represented by UML (Unified Model Language) diagrams. Java Card subset includes some features that are very useful for writing and deploying programs on smart cards. The unsupported features are omitted from the Java Card programming language.

Introduction to the Java-card Security

Java Card virtual machine is split into two parts: one that runs off-card, and is deployed into the terminal, and one that runs on-card, within the smart card chip. Processing procedures with high CPU consumption are constrained because smart cards have limited computing resources and some procedures are not needed during runtime execution, the complexity of the system also reduces, which makes it easier to avoid system errors. Java Card security features are applied by the divided JCVM (the off-card part and the on-card part). Many security procedures of the JCVM occur in the off-card JCVM entity, because of the increased processing power and complexity.

Four different security properties related to Java Card are the most important and should be discussed in this article:

1. CAP/Class files verification.

2. Dynamic Applet downloading.

3. Security context partitioning through the firewall mechanism.

4. Transaction atomicity

3.1 CAP/Export file

The CAP file (Converted Applet) is a binary extract of the original Java code that is suitable to be executed from the JCRE, which is embedded into the smart card operating system. That is the reason why some of the inherent Java security is lost. That is also the reason why the CAP file is always verified before it?€™s downloaded to the smart card. The CAP file verifier checks the CAP file?€™s internal and external consistency (references to other CAP files). CAP file verification is a process usually performed off-card just before Applet downloading. The term external CAP file refers to the export files. The export file contains prototypes of the imported classes and their methods; this file is produced during the CAP file generation, an export file is similar to a C header file.

Java Card loading and linking

Java Card enabled devices are also capable of effectively enforcing on-card security policies that are based on three different processes. The loader process and the linker process and the CAP file verifier. The term loader refers to the procedure of dynamic Applet downloading and term linker refers to the procedure of liking the export file with the CAP file, in a secure manner. The loader optionally performs a file authentication while the linker makes reference resolution, in order to resolve the referencing done by the CAP file [2] to other class files. These two procedures can only guarantee none dynamic security properties as they do not predict applet?€™s behavior during execution. As a consequence, JCRE enforces additional runtime security requirements which result in specific features in the JCVM [2].

The linking and the loading characteristics [3]:

1. The linking and loading procedures are package based processes and not class based as in Java (see Figure 16).

2. CAP files contain considerable redundant information for optimizing the loading, linking and applet installation.

3. The information from a class file is represented in two different files, the cap file and the export file.

4. Binary compatibility in the Java Card specification is a based on a subset of Java’s binary compatibility rules.

CAP file verification

The byte-code verifier performs static checks on the byte-codes of the methods of a CAP file. Byte-code verification is a key feature of the Java Card security: applet isolation [4], for instance, depends on the file satisfying the properties a verifier checks to hold. A method of a CAP file that has been verified shall not contain, for instance, an instruction that allows forging a memory address or an instruction that makes improper use of a return address as if it were an object reference. In other words, byte-codes are verified to hold up to the intended use to which they are defined [4]. This report considers that static byte-code verification may be performed either on the host application (off-card verification) or on the smart card (on-card verification), but prior to the installation of the file on the card in any case.

References:

[1] Author: Vijay Sureshkumar, 14. Java Security, 1996, date retrieved: 01-09-2005

URL: http://ei.cs.vt.edu/~wwwbtb/book/chap14/lf.html

[2] St?©phanie Motr?©, Formal Model and Implementation of the Java Card Dynamic Security Policy, 2000, date retrieved: 22-06-2005

URL: http://66.102.9.104/search?q=cache:PHaFaHXJeIAJ:www-lsr.imag.fr/afadl2000/Programme/Articles/motre.doc+java-card+CAP+verification+attacks+&hl=en&start=31&ie=UTF-8&client=firefox-a

[3]Author: Pieter H. Hartel, Eduard de Jong, A programming and a modeling perspective on the evaluation of Java Card implementations*, August 17 2000, date retrieved: 01-09-2005

URL: http://www-sop.inria.fr/oasis/JCW/HARTEL.pdf

[4]Trusted Logic on behalf of Sun Microsystems, Inc, Java Card System Profile Protection (Version 10b), SUN Microsoft System, Inc, August: 2003, date retrieved: 07-09-2005

URL: http://www.ssi.gouv.fr/site_documents/PP/JCSPPC.pdf

[10]? Zhiqun Chen, Java Card TM Technology for Smart Cards, June 2000, Sun Microsystems Inc.

?

?