Secure Computing with Java: Now and the

Future

Print-friendly Version

Executive Summary

Overview

The Internet is changing the landscape of modern computing. In addition to opening new

avenues of access for users, it is fundamentally altering the architecture of today's computing

systems. Software developers are no longer constrained by the monolithic, mainframe approach

to computing. Rather, they are free to take advantage of a new development paradigm:

distributed processing. This new architecture allows designers to segment applications into

components-each of which may exist and execute on different processors and in separate

locations.

The tremendous new potential offered by distributed computing also carries with it the necessity

to exercise certain security safeguards. As distributed, mobile components move among

machines, the opportunity for security breaches increases dramatically. Examples are not

difficult to find:

Viruses can invade and destroy information

on a user's disk, sometimes permanently

Unauthorized agents can steal credit card

numbers

Confidential business files can be copied or

distributed in a way that directly affects

revenues

Computer users and administrators should not be lulled into thinking that security is someone

else's problem. Anyone who uses a browser can unwittingly download a "Trojan Horse" directly

onto their system. The resultant problems can range in severity from mildly mischievous to

highly malicious.

Leading the charge into this new era of computing is Java-a development platform born of the

net. Java technology is well known for simplifying many operations for both users and

developers. Through its unique design and streamlined implementation, Java has made

distributed computing, especially on the Internet, a practical reality. As we shall examine here,

Java also provides a full complement of powerful and highly flexible security features that make

it uniquely capable in the area of the Internet and distributed computing systems.

What is Security?

Security is the practice by which individuals and organizations protect their physical and

intellectual property from all forms of attack and pillage. Although security concerns are not

new, there is revived interest in the entire area of security in computing systems. Why? Because

today's information systems have become the repositories for both personal and corporate assets.

Computers of all sizes and network configurations are providing new levels of access-and

consequently new opportunities for unauthorized interaction and possible abuse.

With respect to computing systems, there are a number of important attributes that are associated

with good security practices. These include authentication, authorization, confidentiality,

containment, auditing, and non-repudiation. Due to its inherent security architecture, the Java

development platform is particularly well-suited to implement all of these features.

Java Security

In order to combat potential security threats, users need programs they can rely on. Moreover,

developers look to a development platform that has been designed with security capabilities built

in-not added as an afterthought. This is where the Java platform comes in. Java is designed from

the ground up for network-based computing. Security measures are an integral part of Java's

design. Other distributed solutions cannot make this claim. From their inception, other

distributed solutions utilize a traditional execution model. As applications created by other

solutions migrate toward the net, developers must add security features as appliqués-without the

many benefits of the Java security model.

The business end of the Java security model is conveniently described by using the metaphor of

the Sandbox. The sandbox comprises a number of cooperating system components, ranging from

security managers that execute as part of the application, to security measures designed into the

Java Virtual Machine (JVM) and the language itself. The sandbox ensures that an untrusted-and

possibly malicious-application cannot gain access to system resources.

To implement sandboxes, the Java platform relies on three major components: the class loader,

the byte-code verifier, and the security manager. Each component plays a key role in maintaining

the integrity of the system. Broadly speaking, these components serve the following purposes:

Only the correct classes are loaded

The classes are in the correct format

Untrusted classes will not execute dangerous

instructions

Untrusted classes are not allowed to access

protected system resources

Also fundamental to the Java security model is the concept of a Java Protected Domain. Their

unique characteristics can serve to extend the Java sandbox into the file system thereby offering

a powerful and independently flexible facility. Java Protected Domains enable the use of

"permissions" by the user or can use a pre-configured default setting. This type of capability

serves to extend Java's existing fine-grained control by allowing multiple and unique permissions

for individual applications. Collectively, these and other integral features provide a highly secure

and flexible security model for the Java platform.

Summary

Effective security is not a discreet or static endeavor. It is an on-going process that requires

diligence, the use of appropriate techniques, and a watchful eye on the context in which

computing systems operate. Security measures can fail if not constantly reinforced by training

and revision to address new types of attacks.

The Java Security Model provides developers with an extremely flexible and powerful security

framework that is built-in to the Java platform. This means that developers can create fine

grained security policies and articulate independent permissions for individual applets- all while

appearing transparent to the end user. The Java Security Roadmap has laid the groundwork for

the continued delivery of refinements and new capabilities and in so doing, offers users a high

level of confidence for the future. The Java platform is more secure than any other Internet

access platform, including those that download native (binary) code, while continuing to deliver

excellent usability.

The New World of Computing

The Advent of the Internet

The world of application development is changing at a rapid pace. As the age of the monolithic,

mainframe-based application wanes, a new era of distributed computing is rapidly taking hold.

Distributed development architectures allow applications to be divided into pieces (called

components), each of which can exist in different locations. In fact, this new development

paradigm allows programs to "download" code from remote machines onto a user's local host.

Leading the charge into this brave new world is Java-a execution platform born of the net. It has

made distributed computing a practical reality, while simplifying computing and empowering

users.

One of the strongest catalysts for the Java technology evolution has been the Internet. The

Internet has changed the landscape of modern computing, and perhaps more to the point, is

changing the way we live. Because its full potential is still being realized, even the most ardent

cynic ought to agree that as we move into the 21st century, the world will be at our fingertips-

literally.

The power and potential of the Internet have not been lost on the business community. The

ability to reach consumers and conduct business via the Internet has precipitated countless new

opportunities for electronic commerce. Software organizations have also been quick to recognize

the power of the Internet. For example, customer service organizations have discovered that

using the Internet can reduce the costs associated with product support. In addition, system

designers have discovered that the Internet can provide their users with convenient and cost-

effective access to both personal productivity and mission critical applications. However, the

Internet's tremendous potential does bring with it some tradeoffs. As we'll discuss here, the price

of openness on the Internet might be peace of mind.

Distributed Computing

The continually changing landscape of today's computing systems alters our understanding of

systems architecture and application development. That is, new technologies must be harnessed

to create applications that are more efficiently developed and maintained. A few examples

follow:

Enhanced Transaction Processing - With

distributed applications, single transactions

may span multiple hosts and multiple

processes. However, applications must still

guarantee the atomic integrity of transactions

(i.e., a unit of work.)

Portable Clients and Servers - In distributed

environments, both users and their

applications can move. On the Internet, users

can access applications from just about

anywhere. Similarly, system administrators

enjoy the luxury of moving

applications/components among various

machines based on such factors as load,

hardware failure, performance, and so on.

Enhanced Data Sets - Applications no

longer deal with only simple data types.

Current technologies allow system designers

to incorporate enhanced objects such as

video, audio and multimedia into even the

most basic applications.

With the move toward distributed processing, applications must continue to appear seamless to

users. This can be very difficult because of changes to the underlying architecture. Furthermore,

distributed architectures increase this burden because they provide users easy access to a myriad

of applications.

Distributed computing is also has its attendant compromises for developers: ease of access

increases security concerns. As a result, system designers that are developing for distributed

environments benefit greatly when security is integral. Effective security cannot be added on as a

"patch".

Why Now?

Although many of the ideas expressed here are not new, the seeds of distributed computing are

only now coming to fruition. Why is distributed computing becoming a reality now? In the

recent past, system designers were unable to exploit the advantages of distributed computing

because some basic requirements were missing. Today that has changed, due to a number of

important technological advances. These include:

Better development platforms that are

specifically designed to support distributed

execution environments. Java's Write Once,

Run Anywhere capabilities address one of the

key challenges faced in distributed computing

environments.

Rapid expansion of low-cost, high bandwidth

networks.

General availability of high-performance,

low-cost CPU cycles.

Broader feature sets provided by operating

platforms.

Better development methodologies and tools.

Note that many of these features have a resonant and cascading effect. For example, reducing the

cost of CPU cycles allows systems developers to imbue operating systems with expanded feature

sets; that in turn allows other developers to implement more powerful tools that support and

enhance the efforts of application designers.

Security

Good security practices include a number of important attributes. The following sections discuss

these key attributes in detail.

Authentication

The first task of any security system is to authenticate remote users, systems, and applets.

Specifically, a system should be able to assure it users, to some reasonable extent, that who or

whatever is on the other side of the connection is who or what the user expected to be there. That

is, users should be assured that:

The host that they have connected to is the

host they "called out to" (i.e., the host is not

an "impostor").

The module they have downloaded is really

the one they expected to run. (i.e., the module

has not been replaced with a "substitute").

This is of particular concern in downloaded environments where there is a constant threat of a

"Trojan Horse".

Authorization

Given authentication, the next feature security systems should provide is authorization. Users

and/or administrators should have the ability to decide what level of access to bestow upon an

authenticated principal. Note that for this feature, granularity is an important attribute: highly

trusted resources should be granted more access than those of more dubious origin.

Confidentiality

Confidentiality is a feature that comes in many forms. For example, users should be assured that

any data they are exchanging with a remote host remains private. However, users may also want

to keep confidential the fact that they have simply connected to a particular host. If known, this

fact alone could reveal customer and/or supplier information to a competitor. In short, a secure

system should ensure that all attributes of a connection-time, frequency, data, queries, etc.-

remain confidential.

Containment

Given authentication and authorization, a security system can provide an appropriate level of

containment. That is, once the execution environment establishes an applet's bona fides, it should

ensure its continued compliance by constraining its activities-in effect, it should the applet in a

"box". The system can determine the size, shape, and boundaries of the box by the level of

authorization. As mentioned earlier, Java implements a model based on a Sandbox.

Auditing

A good security system should provide an auditing capability. Thus, if an anomaly or a breach

should occur, the audit trail should assist developers and administrators in their efforts to isolate

and remedy the problem. In a more practical sense, it also helps the business people access the

extent of the damage and decide on an appropriate course of action. Note that while auditing

cannot prevent attacks, it can alert appropriate personnel, record the extent of the breach, and

assist in the eventual repair.

Non-repudiation

Assured authentication provides another important benefit: non-repudiation. That is, parties can

no longer disavow knowledge of a transaction: the security system can "prove" they took part.

As a result, cooperating parties can now execute electronic agreements because each side can

authenticate and prove the other's participation. Thus, both sides can execute an agreement with

the assurance that other side cannot repudiate it..

Security in Practice

Given the previously mentioned attributes, and the fact that no usable system is impenetrable, the

objective of a solid security strategy is to strike a balance among the following goals:

To minimize the potential costs of a breach

To minimize the impact on users

To maximize the difficulty of potential

attacks

Note that the importance of each factor will vary with each system; thus, one would expect the

level and type of security measures employed to vary as well.

Security must therefore be viewed as a trade-off between cost and benefit. However, regardless

of the amount of money spent and effort expended, no system-no level of security-is

impenetrable. The sections that follow will discuss what system security can-and should-

reasonably achieve in practice.

Personnel

Every organization is responsible for vetting its constituents. The tools and techniques discussed

here can do little to protect an organization from the untrustworthy actions of individuals. An

organization must involve every one of its members in security practices-at all levels. These

practices must be established by edict, and reinforced through training. Whether through attack

or apathy, the cost of a security breach is just as great. This is not a new concern, and most

organizations have established vetting practices commensurate with the risk.

System Security

Let's begin by stating the obvious: The only truly secure system is the one that contains no

external access capabilities and remains locked and guarded in a sealed vault. Such a system

would be of extremely limited value to its potential users. Thus, security boils down to a risk

analysis, weighing the benefits of external access versus the costs of a breach.

What Price Security?

Deciding how much to spend on security is a major concern. For example, the security

requirements for a company publishing an on-line catalogue would be much less stringent than

those of a multi-billion dollar bank engaging in nightly fund transfers; and the security needs of

both of these organizations would be less than a governmental agency involved in national

security. In short, the cost of security should remain commensurate with the need. Figure 1,

below, depicts this relationship.

Figure 1

The Price of Security

Usability

As alluded to previously, one typical characteristic of computing systems is that security

corresponds inversely to usability. To the extent possible and practical, security should not

impede users. Systems must remain accessible to those people with authorization to use them.

Indeed, overly restrictive measures can greatly reduce personnel productivity. In extreme cases,

users will often deliberately circumvent security measures when under pressure to "get the job

done at any cost".

Accordingly, different security models afford different levels usability. Because the Java security

model incorporates security features as part of its foundation, it can continue to deliver excellent

usability while enabling security options. By comparison, binary security models must sacrifice

significant usability in order to implement even modest levels of security.

Figure 2

Security vs. Usability

It can be difficult to strike an appropriate balance between security and usability. However,

because of its flexible security model, Java provides many features that allow for "transparent

security". That is, Java environments can provide a high-degree of security without unduly

encumbering the user. While at once, offering the system manager the ability to articulate finely

grained security policies.

False Expectations

In most organizations, a manager's job includes the management of as one of their primary

responsibilities. Surprisingly, many professionals have an elevated expectation involving

computer system security. To understand the risks properly, managers must understand what

security can and cannot provide.

No Risk at All (or, If you can't see it, it doesn't exist)

This is likely the greatest misconception of all. There is no such thing as an impenetrable or

invulnerable system. In fact, this status is unattainable. However, that is not to say that one

should not strive for perfection-only that one should not reasonably expect to achieve it. Security

issues are only one facet of the business jewel: Every dollar spent on security is a dollar not spent

on marketing, research and development, employee training, customer support, etc. Because

security contributes to business overhead, it should be regarded as an important cost of doing

business, just as with other "business overhead" items such as rent, utilities and insurance.

Organizations must weigh the cost of security measures in context with the other needs of the

business.

Narrow Focus

Modern computing networks and architectures can be very complex. Often, security breaches

result from a compartmentalized view of the world, particularly in organizations that divide

security responsibilities among multiple departments. Security breaches occur all too frequently

at the seams between components and systems. Therefore, security policies should encompass a

broader vision that spans department, system, and network boundaries.

One Size Fits All

When a security breach does occur, organizations quickly assemble their "damage control" teams

to quell the attack. This is especially true when deploying new technology: all hands are on alert

and quick to pounce at the slightest indication of a problem. Despite such preparedness, many

organizations lack consistency and follow-through. Security breaches usually occur when you

least expect them. When a break is discovered and repaired in one area, there may be no follow-

up investigation to determine whether a similar problem exists in other areas. Each breach should

be treated as a puzzle: once discovered, the security team should reconstruct the reasons for its

occurrence and eradicate all traces of its signature.

Diligence

Just because the security door is locked today, does not mean that a new attack will not be

fashioned tomorrow. Hackers are an inventive lot with time their side: they have to succeed only

once. Security administrators have to be prepared for intrusions around the clock, and only one

failure might not be considered an acceptable condition.

The Importance of Security

Unfortunately, the convenient, cost-effective network access described previously is also a

troubling concern. This is one of the great ironies the new age of technology: in order to use the

Internet securely-a technology whose raison d'être is to open new vistas-users have to continually

find new ways to implement safeguards. Consequently, everyone who surfs the net must remain

cautious.

Downloading Code

Adding to the welter of concern is the age of remote access. Millions of individuals are

downloading unseen programs, from unknown Web sites, allowing them unquestioned access to

their systems. The power of this architecture is undeniable, but so are the attendant security

concerns. Here are two examples:

A hacker managed to make a downloaded

module appear as if it was a local piece of

code. Once running, the module had access to

the user's disk drive. It was then comparative

child's play for the module to open a socket to

a private host and transfer proprietary data.

In another example, another hacker managed

to get a "Trojan Horse" loaded onto an

unsuspecting user's machine. Once executed,

the module attacked the user's banking

software to transfer funds into the hacker

account.

The precise details of each attack have been omitted (for obvious reasons). The sophistication of

the attacks is of primary concern, and there are plenty of hackers who would like nothing better

to do than to breach a system and get into some malicious mischief.

The Problem with Binary Security

Security problems can be exacerbated in environments that download binary code. That is, the

downloaded code is in the native computing mode of the local host. The reason this is such a

concern is simple: binary code is not as easy to inspect, review, and restrict as is an interpreted

language like Java. Moreover, once executing, the host system can exercise only limited control

on binary modules. This can lead to serious security breaches. (The examples cited above

occurred in binary environments.) To drive home the point, experts in the anti-virus industry

predict that the next major virus barrage will be delivered through ActiveX Controls.

Nonetheless, given that downloading has become commonplace in Internet life, the important

questions one should ask are:

What constitutes good security?

How much can one rely on the execution

environments themselves?

What is the cost of adequate security?

These issues will be explored in more detail throughout the remainder of this paper.

Java Security

The sections that follow address the integral security features of the Java development platform.

However, before we can describe these features in detail, we need to describe some important

features of Java.

The Java Platform

In order to realize the benefits of distributed computing, developers require both design and

implementation tools. Java contains features that enhance the ability of developers to create

sophisticated, distributed applications. Indeed, Java's meteoric success is readily apparent by the

use of an important new term in the computer science lexicon: applet.

Write Once, Run Anywhere

As a rule, applications are tied to their development platforms and cannot easily "port" to other

execution environments. Porting applications across multiple platforms increases the costs of

software development and maintenance. With Java, developers gain the advantage of its Write

Once, Run Anywhere application. Developers can implement the application on their platform of

choice, and users can execute it on theirs.

The Java Virtual Machine

Java achieves Write Once, Run Anywhere capability through Java's architecture. As depicted in

Figure 3, all Java applications run atop the Java Virtual Machine (JVM). The JVM resides on the

host operating system and buffers Java programs and applets from system variances. In effect, it

creates a virtual machine that remains constant across systems. Initially accessible only in

browsers, the JVM is now widely available across a host of systems.

Figure 3

Java's Execution Environment

So, What's an Applet?

Though revolutionary in their own right, static Web pages (such as those written in HTML) can

be quite limited in what they can offer in terms of graphics and interactivity. One of the most

powerful features of Java are applets. An applet is a small executable program embedded in

(Java-aware) Web pages that are downloaded and executed locally by the browser. Thus, Web

publishers can provide sophisticated, dynamic, interactive applications as part of their pages. For

example, instead of displaying static information about a stock, a brokerage house can simulate a

"live ticker" as part of its display.

Other Important Java Features

Architecture Neutrality: Java is designed to

support applications deployed across a wide-

range of platforms.

Network Support: Java provides integral

support for most networking requirements.

Additional Libraries: Java has numerous

ancillary libraries that support the many needs

of distributed applications.

Performance: Java is efficient (especially for

an interpreted language)

Extensibility: Java can interoperate with

many other programming environments.

Multi-threading: Java browsers can generate

more interesting Web pages by allowing

multi-threaded processing.

Based on its initial acceptance, Java will likely become the lingua franca of the Internet. Many

industry observers think it already has.

The Java Security Model

Java's security model differs greatly from traditional approaches. First, most operating systems

permit applications broad access to system resources. Administrators must rely on the users to

ensure that resources are adequately protected (e.g., permissions are set correctly). Second, it is

usually incumbent upon users to verify a program's veracity before executing it (e.g., performing

a virus scan). This approach has two obvious drawbacks: it relies on the user to perform the

verification, and it relies on the accuracy of the verification software itself. As we will see, Java

takes a much more pro-active approach.

The Java Sandbox

Java allows users to download and execute untrusted applications without undue risk by

restricting such code to its own sandbox. Applets may wreak havoc in their own sandbox, but

they cannot disrupt or affect any other sandboxes. Furthermore, restrictions may be placed on

what the application can do within their own sandboxes. Thus, the jvm can allow untrusted

applications to execute in a trusted environment, without fear of corruption or subterfuge.

The Java sandbox comprises a number of cooperating system components, ranging from security

managers that execute as part of the application, to security measures designed into the JVM and

the language itself. The sections that follow describe in detail how Java's security model

constructs the sandbox. In addition, they examine the ways in which Java allows users to extend

the model.

The Class Loader

As mentioned previously, applets are executed (transparently) as part of a Web page. To load the

applet, the browser invokes the Java Applet Class Loader. This forms the first line of defense in

the Java security model: the class loader determines how (and when) applets can load classes

(code). The following briefly describes its major functions:

It fetches the applet's code from the remote

machine.

It creates and enforces a namespace (see

below) hierarchy. One of its more important

functions is to ensure that running applets do

not replace system-level components within

the runtime environment. In particular, it

prevents applets from creating their own class

loader.

It prevents applets from invoking methods

that are part of the system's class loader.

An executing Java environment (i.e., a running JVM), permits multiple Class Loaders-each with

its own namespace-to be active simultaneously. As depicted in Figure 4, namespaces allow the

JVM to group classes based on where they originated (e.g., local or remote). This delineates and

controls what other portions of the runtime environment the applet can access and modify. In

addition, by placing restrictions on the namespace, the class loader prevents untrusted applets

from accessing other machine resources (e.g., local files). In effect, namespaces serve as the

outer wall of the sandbox.

Figure 4

Java Namespaces.

By design, class loaders load all applets and their corresponding classes. When an applet is

executed, the browser invokes the Applet Class Loader, which fetches the applet and instantiates

it as a class. Normally, applets may not install new class loaders; thus, the applet class loader

remains in control of the environment.

The applet class loader creates a new namespace for each applet. Therefore, applets can access

only its own classes, and classes belonging to the standard Java library API. However, they do

not have access to any classes belonging to any other applets. This provide two important

advantages:

Distinct namespaces make it very difficult for

applets to pool their resources in an effort to

form a concerted attack.

Applet developers need not be overly

concerned about collisions: names need only

be unique within a namespace.

There are two important caveats that should be noted:

In browser environments, the class loader is

typically supplied by the system vendor.

Although it is usually based on templates

supplied by Sun, consumers must nonetheless

rely on the vendor's expertise. However, if the

system vendor relies on Sun's templates, users

should not experience any problems.

Java applications are free to create their own

class loaders. In fact, the Java Developer Kit

(JDK) provides a template for a class loader

to facilitate customization. As already noted,

a breach in this area could allow an untrusted

applet to define its own namespace and

breach security. Thus, when designing

custom class loaders, developers should take

care to follow all of the guidelines put forth in

the JDK documentation. If they do, they

should experience minimal difficulties.

Security Feature Summary

Security is an integral feature of the Java platform. The Java security model offers a variety of

ways to inspect, review, and restrict the execution of applications. In contrast, the binary security

model offers only a small fraction of Java's capabilities, and in some instances, offers no security

at all. To illustrate this point, Figures 5 and 6 depict the process flow of code in both binary and

Java models from a security perspective. Note that in the Java model, both untrusted and local

code must pass through the byte-code verifier.

Figure 5

Binary Security Process Flow.

Figure 6

Java Security Process Flow.

The Byte-Code Verifier

Recall that Java source code is compiled into platform-independent byte-codes. Before a class

loader may permit a given applet to execute, its code must be verified by the Byte-code Verifier.

The verifier ensures that the applet's code-which may not have been generated by a Java

compiler-adheres to all of the rules of the language. In fact, the verifier assumes that all code is

meant to crash or penetrate the system's security measures.

The verifier performs several types of validations. At a base level, it ensures that the code

conforms to language specifications. On a more complex level, the verifier applies a built-in

theorem prover against the code. This ensures that the applet does not (among other things) forge

pointers, circumvent access restrictions, or access objects through an illegal cast. The byte-code

verifier, in conjunction with security features built directly into the language (see below), ensures

that:

Compiled code is formatted correctly.

Internal stacks will not overflow or

underflow. (When either of these events

occurs, systems are unstable and hackers can

"play in the confusion.") Historically, this

type of attack has led the way to some of the

most infamous security breaches.

No "illegal" data conversions will occur (i.e.,

the verifier will not allow integers to serve as

pointers). This ensures that variables will not

be granted access to restricted memory areas.

Byte-code instructions will have

appropriately-typed parameters (for the same

reason as described in the previous bullet).

All class member accesses are "legal". That

is, an object's private data remains just that:

private.

Using a byte-code verifier means that Java validates all untrusted code before it permits it to

execute within a namespace. Thus, namespaces ensure that one applet cannot affect the rest of

the runtime environment; code verification ensures that an applet cannot violate its namespace.

Ultimately, the JVM will only execute code that has passed muster with the verifier.

The Security Manager

The third and most important component of Java's security model is the Security Manager. Its

task is to perform run-time verification of all so-called "dangerous methods"-that is, methods that

request file I/O, network access, or those that want to define a new Class Loader. In all such

cases, the Security Manager may exercise veto power over any request. For example, if applet

invokes a "read" method, the JVM consults the security manager. If the applet is trusted (among

myriad other considerations), the request will be permitted; if it is not, the request will be denied.

(Obviously, built-in classes are granted more license than downloaded, untrusted applets.) In

effect, the job of the Security Manager is to police the boundaries between the sandboxes.

Some of the Security Manager's duties include:

Managing all socket operations.

Guarding access to protected resources

including files, personal data, etc.

Controlling the creation of, and all access to,

operating system programs and processes.

Preventing the installation of new Class

Loaders.

Maintaining thread integrity. (There are some

security concerns in this area; this topic is

explored in detail later in the paper.)

Controlling access to Java packages (i.e.,

groups of classes).

To ensure compliance, all methods that are part of the basic Java libraries (i.e., those supplied by

Sun) consult the Security Manager prior to executing any dangerous operations.

Another point to note is that the Security Manager is customizable. This is different that most

binary models: if binary code is trusted, it can do anything; with Java, users can customize the

level of security for each module. For example, the JDK program, appletviewer, reads a

configuration file to set some tunable security options. (Future releases of the JDK will simplify

Security Manager customization even further.)

Type Safety

The Java language itself is designed to enforce security in the form of type safety. This means

the compiler ensures that methods and programs do not access memory in ways that are

inappropriate (i.e., dangerous). In effect, this is the most essential part of the Java security model

in that it fundamentally protects the integrity of the memory map.

To understand how type safety plays a fundamental role, consider the following example.

Imagine a banal class called MyClass, that has a member function called doIt(). Now assume that

doIt() did nothing more that set a Boolean variable to True-but that variable happened to reside at

byte offset 64 in the object. At this point, it all seems rather mundane. Now, let's make it more

interesting and assume there is also a JDK-supplied class call SecurityManager, and at byte

offset 64 resides a flag that, when set to True, allows applets to access the local hard drive. It

does not take a deceitful mind to realize that if you can get a pointer of type MyClass to point to

an object of type SecurityManager, you can invoke the doIt() method and have your untrusted

applet gain access to the local file system.

This type of attack is a major concern in binary models. If a malicious piece of code can gain

access to a protected part of memory, the results could be disastrous.

The JavaSecurity API

One of the core APIs that ships with the JDK is called JavaSecurity. Built as part of the

java.security package, this API will provide for digital signatures, message digests, key

management, and access control lists. A portion of this API contains the Digital Signature

classes. This component will provide tangible classes called Certificate, Key, Signature as well

as extensible classes such as Provider and Algorithm. The latter two represent a specific

JavaSecurity vendor and a specific algorithm, respectively. The JDK ships replete with a default

provider called SunSecurity (located in sun.security). This package also includes an

implementation of the NIST DSA algorithm, the MD5 and SHA message digest algorithms, and

support for X.509 certificates. The access control list package (sun.security.acl) allows users to

define read/write permissions based on users and groups.

Sun defines a vendor that supplies a complete implementation of the JavaSecurity API as a

Security Package Provider (ssp). The important point is that users can rely on the default

package, or purchase and/or create one of their own. Thus, an organization can select a security

level commensurate with their risk tolerance. If you plan to develop an SSP of your own, you

must ensure that your algorithm is secure and that it is bug-free. One error in design or

implementation could render you signatures forgeable or your encryption algorithm breachable.

Digital Signatures and JAR files

There is a type of attack to which all network-based systems might be vulnerable. Called the

man-in-the-middle or middleman, this type of breach is particularly insidious. It proceeds as

follows: a client application requests some service from a legitimate server. Unknown to both

client and server, an attacker application observes this request and waits for the server to

respond. When it does, the attacker intercepts the server's response and replaces it with one of its

own-one that the client may assume came from the original server. To appreciate how

treacherous this type of attack can be, consider that the client might expect to treat this response

as an applet.

The way to thwart this type of attack is to ship code contained within a digital shrink-wrap.

When purchasing software that is delivered on physical media, consumers tend to trust the

product if its from a known supplier and the external packing does not show any signs of

tampering. Java environments can achieve similar results using "signed applets". To do this, a

supplier bundles Java code (and any related files) into a JAR (a Java Archive). The supplier then

"signs" the applet using a digital signature. The client can verify the authenticity of the supplier

by verifying the signature.

Key Management

Key encryption is based on two equally important components: an algorithm and a key. Both the

key and the function are crucial to the encryption -- the same key used in two different

encryption functions will produce two different results, and two keys used with the same

function also produce two different results. The Security API provides support for integrated key

management in Java programs and applets.

Message Digests

Using public-key encryption algorithms to encrypt messages can be quite slow. As a result,

cryptographers have developed a way to generate a short, unique representation of your message-

called a message digest-that can be encrypted and then used as your digital signature.

Access Control Lists

The Security API also provides support for Access Control Lists, which are used to restrict

access to systems and services. The Java Security API provides code that simplifies the effort

required for programs to maintain and access these lists.

JAR files also provide another benefit: increased performance. Current web technology transmits

files serially. Using JAR files, a Web page can download everything it needs in a single request.

Additional Security Considerations

Java Application Security

Java programs come in two main flavors: applications and applets. Java applications are

developed, purchased, and installed just like other types of commercial software. Because such

applications reside locally, they are usually not subject to the stringent security measures applied

to applets. In effect, they execute as "trusted" applications-security is achieved by maintaining

physical control of the local environment.

One caveat: Users should scan all application files for viruses before invoking any newly

acquired programs. This is particularly true for applications delivered via the net. To encourage

this practice, organizations should maintain, and invite the use of, isolated virus scanning

stations. In addition, users and administrators should be encouraged to scan their systems for

viruses regularly.

Java Applet Security

In what is now considered traditional networking infrastructure, organizations safeguard their

environments by restricting access to data, software, and networks. It is true that by merely

accessing Web pages, users may download code onto their local machines that might be obtained

from untrusted party. More importantly, unless otherwise restricted, this code can execute in an

unrestricted manner on the local machine. Thus, code that is downloaded from a remote source

has the potential of becoming the software equivalent of a "Trojan Horse".

Java reduces the likelihood of such an attack by placing rigid, enforceable processing restrictions

on applets.

Untrusted applets cannot read or write

from/to local disk drives-this severely limits

the disruption that an applet can create.

All stand-alone windows created by applets

are labeled as such. Thus, users are

forewarned when entering data into such

screens.

Untrusted applets cannot establish network

connections to other hosts on the network.

This prevents malicious behavior behind the

firewall.

However, this level of applet security is the "default". Consider that the security features

described in previous sections allow users to "trust" applets downloaded from the net. Thus, if

desired, this type of trusted applet can enjoy the same level of security as purchased or "home

grown" applications. That is, if permitted by the user, the JVM can let users '"extend the

sandbox" and establish fine-grained security policies to address almost every need. For example,

a user could establish the policy that applets from site A may read files, whereas applets from

site B may read and write files. The level of granularity can be applied to any system resource:

files, devices, ports, communication channels, etc.

Browser Security

Currently, both major browser products-Netscape's Navigator (versions 2.02 and later), and

Microsoft's Internet Explorer (versions 3.0 and later)-are Java enabled. Moreover, as of this

writing, both browsers' security policies are identical-and rather strict at that. The following

summarizes the applet security conventions adopted by both vendors:

Applets may not read or write files

Applets may only establish network

connections to their original hosts

Applets have access to a limited number

(nine) of system properties

If a local applet is loaded, and its class file

does not reside in a directory specified in the

classpath, it is loaded using the Applet Class

Loader (i.e., it is considered untrusted).

Java Security: The Future

Java Protected Domains

A fundamental element to the evolving Java security model is the Java Protected Domain. This is

a Java security component that has its scope defined by a set of objects that are accessible by a

principal. A principal is any entity in the computer system that has accountability-that is, any

entity to which authorizations may be granted or revoked. The Java Sandbox is an example of a

Java Protected Domain.

By default, Java Protected Domains must remain distinct from each other. Interaction among

domains will be permitted only through trusted system code, or when explicitly permitted by

both interacting domains. This unique characteristic of Java Protected Domains can serve to

extend the Java sandbox into the file system-a powerful yet flexible facility. For example, two

different applets might be allowed to write to a specific part of the file system while each one

was protected from the other. These conditions could be set up as permissions by the user or

enabled through a pre-configured default setting. This type of facility serves to extend Java's

existing fine-grained control by allowing multiple and unique permissions for individual

applications.

Broadly speaking, protection domains fall into two distinct classes: system and application. By

design, all system resources (e.g., files, network connections, screen, keyboard, etc.) are

accessible only through system domains. This architecture is depicted in Figure 7.

Figure 7

Java Protected Domains.

Conceptually, each jvm needs only one system domain. However, for increased security, the jvm

can instantiate multiple system domains, each responsible for a single class of resource. This

greatly reduces the risks and consequences arising from coding errors or security flaws. The

result is that errors and breaches are more likely to be confined within a domain. All Java

Protected Domains (system and application) may also impose additional restrictions on their

internal resources. Thus, developers can extend integral security services to provide support for

custom resources. For example, a brokerage application can define a domain that will protect

such objects as customers, bonds, equities, etc.

Note that a given thread of execution (which may span multiple threads) is not limited to a single

protected domain; indeed, it may span several. For example, a program that wishes to print the

contents of a file will need to interact with the domains responsible for the file system and the

printer. Obviously, the jvm must ensure that the application does not acquire less-restrictive

permissions when it invokes services within one of the system domains. The converse is also

true. If code within a system domain invokes a method within an application domain-such as

when the awt library invokes an application's paint() method-the effective permissions must be

only those enabled in the application domain. There is one important exception to this rule:

surrogate code, or trusted code that executes on behalf of an application. For example,

applications may not access password files directly. However, a trusted utility can change a

password on behalf of a user.

Architectural Directions

The Java Security Roadmap has been carefully constructed to meet the demands of rapidly

expanding distributed systems. The following guidelines will help to shape and update the

roadmap:

easy use for both users and developers

fine-grained control

unique policies for different sources

the ability to manage all system resources

flexibility to support emerging technologies

portable across all platforms

The following section describes some of the new security features for Java that are already in the

pipeline.

Table-based Configuration

Currently, the flexible and fine-grained security policies previously mentioned are available only

at the programming level. Therefore, in order to take advantage of these policies, an organization

must purchase or develop custom code (e.g., extending the security classes). Future versions of

Java will be designed to allow users an enriched ability to establish such policies using a simple,

table-based interface.

Secure Communication

As illustrated by the middleman attack, a conversation is only as secure as the medium itself.

Sun's Simple Key Management Internet Protocol (SKIP) technology allows conversing parties to

agree on an encryption scheme that ensures private communications. The Java Encryption

Extension is a plug-in module that provides an easy way for developers and system

administrators to apply advanced encryption technologies to Java programs. The plug-in is

algorithm and implementation independent thereby offering developers complete flexibility in

choosing from a variety of third party encryption schemes. DES and triple-DES encryption

methods are slated for inclusion in the Java Security model.

Auditing

An important aspect of any security system is auditing-the ability for the system to provide a

journal of events. If security administrators observe or suspect a breach, auditing would offer a

history of the events that will help them determine what happened.

Currently, Java does not define a set of auditing standards. Efforts are now underway to define a

set of standard auditing features that vendors must provide as a standard part of the deliverable.

Domain IDs

One of the problems users might face when using protection domains is cross-machine

authentication. That is, how can code running in a domain on a remote machine gain access to

resources on a local machine-assuming it was "entitled" to them. The local machine would likely

view the remote code as "untrusted", and therefore deny it access to its local resources. To

overcome this limitation, protection domains can be assigned "IDs" that would allow the local

host in this example to authenticate the remote host and allow its code to execute in a local

domain.

Certificate Support

Currently, the use of certificates requires a considerable amount of custom development. To

simplify the use of certificates, Java will supply apis to allow uniform access to third-party

certificate code including X.509v3 and provide a on-line Certificate Authority (ca) server.

Summary

With the rapid expansion of the Internet and the proliferation of distributed computing, new

interest is now focused on the security aspects of both personal and enterprise computing

systems, and with good reason. Millions of computer users are downloading files and

applications of unknown origin every day-directly onto their PCs and workstations. Due largely

to its Write Once, Run Anywhere capabilities, Java has become the de facto development

platform distributed applications, while at once offering the most powerful and flexible security

model available for web-centric environments.

The table below, summarizes the important security attributes discussed in this paper and the

Java platform features that implement them.

Security Attribute Java Platform Feature

Authentication Digital Signatures, Certificates

Authorization Security Manager, Java Protected Domains

Confidentiality Encryption, SKIP Technology

Containment Class Loader, Sandbox, Java Protected Domains, Byte Code Verifier

Auditing Limited, Security Manager, Future enhancements pending

Non-repudiation Digital Signatures, Message Digest

Table 1

Java Security Features

The Java Security Model includes several facilities that are inherent to the Java architecture and

helps to promote a secure operating environment while offering selective permissions to users

and machines. Unlike some binary security models that patch on security features as an

afterthought, the Java Security Model has security built into its foundation. The end result of

Java's security architecture is that it can offer intelligent and selective access to system resources

and information. When compared to "all or nothing" binary methods, the Java development

platform offers superior protection and flexibility.

Appendix A: Security Guidelines

Overview

The few problems experienced by Java users to date can be classified as implementation defects,

rather than inherent flaws in the security model itself. Nonetheless, users and system

administrators should adhere to the following guidelines to enhance their Internet experience:

Use the most current version of all

networking software-particularly browser

programs. Newer versions include fixes for

known security problems of the past.

Employ draconian measures as appropriate-

don't even consider connecting enterprise

systems directly to the Internet. Use firewalls

as appropriate.

Remain vigilant and investigate even the

smallest anomalies. A "missing file" might

really be the result of "a hack".

Be cautious of the web sites you visit-you

never know what you might be downloading.

CERT

Users and administrators should become familiar with CERT (http://www.cert.org). This

organization-funded by DARPA-provides assistance to individuals and organizations that are

experiencing security attacks. In addition to providing assistance to those besieged by attacks,

the organization also issues "alerts" that announce potential and actual security breaches.

Sun's FAQ's

Another way to keep current on security issues is to visit Sun's Java Security Frequently Asked

Questions (FAQ) page. You can find it at: http://java.sun.com/sfaq. The FAQs contain timely

information concerning the details of potential and actual breaches. Additional information on

general security issues can be found at: http://java.sun.com/security.

Appendix B: Security Holes

Types of Breaches

Overview

In theory, there are several types of attacks to which systems using applets might be vulnerable.

They are listed in order of their severity:

Attacks that modify or alter a system or its

resources

Attacks that deny legitimate use of machine

resources

Attacks on an individual's privacy

Attack aimed at merely annoying users

Table 2 below summarizes the types of attacks and Java's ability to defend against them; each is

then discussed in more detail in subsequent sections.

Class Severity Defense

System Modification Most severe Strong

Invasion of Privacy Severe Strong

Denial of Service Moderate Weak

Antagonistic Irksome Weak

Table 2

Classes of Attacks.

System Modification

This is the most serious type of attack-its consequences most severe. By definition, such a breach

implies loss of service, proprietary data, or damage to system resources. This type of attack is

especially important to defend against due to Java's ability to run on many different platforms.

However, although such attacks are theoretically possible, it is extremely difficult to achieve in a

practical sense in most Java environments.

Invasion of Privacy

Examples of this type of attack include the reading of email, modifying messages, and displaying

intrusive (and often rude) messages. Although not as severe as the former, it can have drastic

consequences. Again, Java environments are not easily subject to such attacks.

Denial of Service

This class of attack renders system services unusable. Applets can accomplish this "feat" in any

number of ways:

Exhausting a file system

Allocating all available file pointers

Allocating all available memory

Creating thousands of windows

Consuming CPU cycles

Denial-of-service attacks are, by far, the most prevalent security concern. This is because Java

engineers cannot adequately protect users from such attacks-programs have to run to do anything

useful. Though a real concern, there is usually no material loss (as compared with the prior

classes of breaches) and recovery is usually as simple as re-booting the systems. Nonetheless,

repeated attacks of this type can affect business operations and individual productivity.

Antagonistic Attacks

Less odious, though just as troublesome, antagonistic attacks are meant to annoy users. Examples

include playing unwanted sound files and displaying obscene images on the screen. As with the

prior class of breaches, Java environments can have a difficult time defending against such

attacks. However, losses are usually negligible and recovery is simple.

Security Flaws

The following sections describe some serious security flaws that have been discovered within

Java execution environments. They have all been rectified.

Jumping the Firewall

Most organizations protect their internal networks by using a firewall. A firewall protects the

local environment by acting as a gate: all access to/from the Internet must pass through, and be

approved by, the firewall. When using firewalls, many organizations feel they can relax their

internal security levels. Thus, if hackers can breach the firewall, they might achieve unrestricted

access to the rest of the local network.

In one instance, a hacker managed to use Java to jump a firewall. To accomplish this breach, the

hacker exploited a weakness in Java's DNS translation processing. That is, the hacker managed

to "fool" the runtime environment into believing that his system was a "trusted host". Once that

was accomplished, the JVM allowed a network connection that breached the victim's firewall.

The solution for this breach was to change the criteria used by the Security Manager when

deciding whether a network connection is permissible. This fix has already beenincorporated into

the latest browser releases.

A Question of Locality

In another attack, a hacker managed to make an applet appear as if it was a local, and therefore

trusted, piece of code. This breach required two "slights of hand". First, taking advantage of a

common browser feature called file caching, the hacker managed to store a malicious applet in a

file on the user's local disk. He then "fooled" the browser into loading the applet as a local,

trusted piece of code. The fix for this problem is simple, and has been incorporated into the

current versions of all the popular browsers.

Type Confusion

In a type confusion attack, a malicious applet coerces two pointers of different types to reference

the same object. Thus, the applet can use one pointer to access (read) private information from

the object, and use the other to modify (write into) the object. The result is an applet that can

undermine, or bypass, security restrictions. This problem was fixed in release 3.0 of Netscape's

Navigator.

CERT Alerts

At the time of this writing, CERT has issued two alerts for Java: CA

96.05.java_applet_security_manager and CA-96.07.java_bytecode_verifier. The first deals with

the firewall breach discussed previously; the second concerns a breach in the class loader. Both

have been rectified with updates made by the major browser vendors.

Portions of the White Paper were derived from Java Security: Hostile Applets, Holes, and Antidotes, by Gary

McGraw and Edward W. Felten. Copyright © 1997 by Gary McGraw and Edward Felten. Published by

John Wiley & Sons, Inc., New York, NY. Used herein by permission.