Security provided by applets
Web applets have popularized the idea of downloading and executing untrusted compiled code on
the personal computer running the Web browser, without user’s approval or intervention. Obviously,
this raises major security issues: without appropriate security measures, a malicious applet
could mount a variety of attacks against the local computer, such as destroying data (e.g. reformatting
the disk), modifying sensitive data (e.g. registering a bank transfer via a home-banking
software [5]), divulging personal information over the network, or modifying other programs (Trojan
attacks).
Beyond Web services, the applet model is now being transferred to high-security embedded
devices such as smart cards: the Java Card architecture [6] allows for post-issuance downloading of
applets on smart cards. Smart cards are used as security tokens in sensitive application areas such
as payment, mobile telephony, and authentication. This makes the security issues with applets
even more acute.
The solution put forward by the Java programming environment is to execute the applets in a
so-called “sandbox”, which is an insulation layer preventing direct access to the hardware resources
and implementing a suitable access control policy [18, 54, 34]. The security of the sandbox model
relies on the following three components:
1. Applets are not compiled down to machine executable code, but rather to bytecode for a
virtual machine. The virtual machine manipulates higher-level, more secure abstractions of
data than the hardware processor, such as object references instead of memory addresses.
2. Applets are not given direct access to hardware resources such as the serial port, but only
to a carefully designed set of API classes and methods that perform suitable access control
before performing interactions with the outside world on behalf of the applet.
