A User Centric Security Model for Tamper-Resistant Devices

7.2 Application Sharing Mechanism
7.4. We then propose two protocols for the CDAM framework in section 7.5 and 7.6. In
section 7.7, the proposed protocols are analysed for their security and performance.
7.2 Application Sharing Mechanism
In this section, we describe the application sharing mechanism implemented in Java Card
and Multos. The reason for choosing Java Card and Multos is twofold: a) they represent
two contrasting architectures to implement the rewall mechanism, and b) they are the two
most deployed smart card platforms. Furthermore, the rewall mechanisms deployed in
the ICOM are mature [28, 29, 185, 187, 188] and have been extensively studied [189][192],
which cannot be claimed for the UCOM.
7.2.1 Firewall Mechanism in Java Card
The generic architecture of a Java Card is shown in gure 7.1. The Java Card Runtime
Environment (JCRE) sits on top of the smart card hardware and manages the on-card
resources, applet execution, and applet security [28]. The JCRE has APIs (e.g. APDU, Util
and Shareable) that an application can use to access JCRE services. The JCRE also
has system classes that are integral to its functions and these classes are not visible to
applets. The rewall mechanism separates individual applications from each other and
from the JCRE. In Java Card, an application is a collection of applets grouped together
as a package for example, packages A and B in gure 7.1;
Context A
Context B
Package A
Applet A1
SIO
Package B
Applet B1
Applet A2
Applet B2
Java Card Firewall
Application Programming Interface (APIs)
System Classes
Java Card Virtual Machine (JCVM)
Java Card Runtime Environment
Smart Card Hardware
JCRE Entry Point
Objects
Native Methods
System Context
Figure 7.1: The Java Card rewall mechanism
Each instance of an applet has a unique Application Identier (AID) [28]. An instantiated
representation of an applet is termed an object. Each object is associated with a context,
159