Using the EC Trust Manager to Secure Java

An White Paper

Electric Communities has designed and implemented a capability-based security infrastructure for certificates that goes far beyond simple digital signatures. Applying EC's Trust Manager to Java provides a powerful and extensible semantics that lets users specify and enforce highly complex trust relationships governing the load-time behavior of Java classes--class importing, subclassing of other classes, and package membership. Adapting the Trust Manager to Java required only a few changes to the Java runtime; for example, adding it to the standard Sun distribution requires changes to only one source file. EC's Trust Manager was customized to Java as part of the E programming language effort, but it also is a stand-alone product that can be added to any licensed Java implementation.

Java(TM), Sun Microsystems' platform-independent programming language and runtime environment, has taken the computing community by storm. Initial distributions of the language runtime allow some user control over the delegation of trust to Java classes, but developers of distributed applications have expressed the need for a more flexible and powerful security model. Javasoft, Microsoft, and other vendors have announced plans to implement digital signatures for Java classes, based on the techniques of public-key cryptography, that address part of the security picture for distributed applications.

Electric Communities' Trust Manager (ECTM) is a security framework that propagates trust through security policies composed from mutually suspicious sources. This allows the revocable delegation of domain-specific powers to trusted agencies (such as a company MIS department or network system administrator) as represented by their digital public keys. This framework is specialized by adding code defining the kinds of operations needing authorization in a given domain, and intercepting these operations so the Trust Manager can calculate whether they should be allowed.

Electric Communities has provided a Java-specific implementation of the ECTM that solves several security issues in the Java Language, including issues highlighted by the Java Security Manager and signed classes. This customized ECTM, called ECTM/J, is a tool that lets the user make and enforce assertions controlling:

This white paper outlines the differences between the initial Java security model and EC's Trust Manager for Java, presents the mechanism used by ECTM/J to enforce users' security preferences, and illustrates the power and flexibility of the ECTM security mechanism.

Security in Current Java Releases

A number of companies are pursuing the development of security enhancements to Java. In this white paper, we compare our Trust Manager only to the version of Java currently in release.

The security model for the current release of Java works as follows:

  1. Classes that can potentially damage the user's system, such as writing arbitrarily to the hard disk, are designated by their authors as "dangerous". Calling classes not designated "dangerous" is always allowed.

  2. In each dangerous method of a dangerous class, the author must include calls to Java's Security manager, asking it to check the context in which the call is made.

  3. The Security Manager examines the current execution stack and evaluates each class as "trusted" or "untrusted". In general, classes residing on the user's hard disk are regarded as trusted; classes originating from elsewhere on the network may be considered trusted or untrusted based on a user-configurable default.

    FIGURE 1. Security in the initial Java release. Classes designated dangerous know hot wo query the Java Security Manager when called. The Security Manager examines the stack for that call; if any untrusted class is in the calling stack, the call is disallowed.

  4. The Security Manager reports to the dangerous class whether any untrusted classes exist in the calling stack.

  5. If any class in the current calling stack is considered "untrusted," the call to the dangerous class is disallowed and signals an exception. If not, the call proceeds.

There are some limits to the flexibility and extensibility of this model:

Security with EC's Trust Manager for Java

Javasoft has lately been speaking of sandboxing, and this seems to have created a bit of confusion. Sandboxing is not a proposed alternative to the above mechanisms, but a description of how they expect the above mechanisms to be used.

ECTM/J works by modifying the Java Class Loader which, like the Java Security Manager, is a part of the Java runtime. Restricted classes are defined by the user in policy certificates (described in the next section) that specify any restrictions on importing those classes.

  1. When an attempt is made to load a new class, the Class Loader invokes the Trust Manager.

  2. The Trust Manager examines the new class to see which classes in imports.

  3. The Trust Manager consults the policy in the TBF to see which classes are restricted.

  4. If the new class contains references to restricted classes, the Trust Manager consults the certificate database for policy statements giving the loading class permission to import the restricted class. These certificates must in turn by authorized by policy statements in the TBF concerning them, or by other certificates whose authorization then needs to be checked. This can be an iterative process; the claim is traced back to the TBF through any number of certificates found in the database or through hints leading to other URLs.

    FIGURE 2. Secrity with EC's Trust Manager for Java. The system's Trust Boot File (TBF) outlines policy specifying which classes are restricted and under what circumstances they are allowed to be imported. At load time, every class is checked by the Trust Manager for imports of any restricted classes. If there are none, the class is loaded and is free to execute. If the class does import restricted classes, certificates are then checked to see if any chain authorizes that class to import the restricted class. If not, the load of the importing class fails.

  5. If the class has been granted all the powers it needs to import the classes it needs, it is allowed to load and run. If not, the load is disallowed and an exception is signaled.

This capability infrastructure lets the outside world access restricted classes via "safe" intermediary classes that present only a subset of its functions. For example, the File class could be "wrapped" by a class that uses File only to create a single temporary file of limited length. This latter class, associated with a signed statement, can be presented freely to the outside world because there's no way an abnormal or hostile class could use it to do damage.

FIGURE 3. Wrapping a restricted class with a harmless one. The "wrapper" class PrefsFile can call the restricted class File, but only to create a single temporary file of limited length. The ability to load and call PrefsFile can then be given out freely, even to an EvilNasty class, because there's no way to use it to get at the more destructive capabilities of File.

The Structure of Policy

System policy is based on a file on the user's hard disk called the Trust Boot File (TBF). The Trust Boot File contains certificates that grant powers to classes or signature public keys. The signature public keys represent others such as a company MIS department, Java class vendor, or network system administrator, to whom the user might delegate certification authority.

Certificates make assertions of the following forms:

Certificates in the Trust Boot File are administered by the user with an interactive tool called the Policy Blesser. The Trust Boot File contains the minimum number of trusted public keys and certificates needed to bootstrap the certification process. It also contains "hints", which are URLs telling the Trust Manager where to find additional certificates on the network. For example, the TBF might contain the public key for the company's MIS department, and the URL for obtaining the company's policy certificates from the MIS department's server. These external certificates must be signed by the key contained in the TBF to be accepted as valid. Keys provided in those verified certificates can then be used in turn to locate and verify additional trusted public keys.

EC's Trust Manager for Java simplifies security concerns for the user by enabling delegation of trust. A corporate user can specify in the Trust Boot File that any certificate signed by the public key of the company's MIS department is to be trusted. The MIS department can further delegate some of that trust to the public keys of Sun, Microsoft, or other vendors of Java classes.

FIGURE 4. Backward chaining and delegation of trust.

Benefits of ECTM/J

The EC Trust Manager for Java has a number of beneficial features:

A Word About E

Electric Communities' Trust Manager for Java can be incorporated easily and cheaply into any licensed Java implementation with a minimum of modifications to the Java runtime. However, it was originally developed as part of the E programming language.

E is an object-oriented programming language designed for writing distributed applications including databases, groupware, publishing systems, multimedia, and games. E is a superset of Sun Microsystems' Java and builds upon the Java Virtual Machine. E classes are very similar to Java classes, and the two can coexist in the same program. However, an E-object responds only to messages sent by other objects, rather than using the traditional call/return semantics of Java methods. When an E-object receives a message, it executes an associated E-method that defines what to do when the class receives that message.

E provides some powerful enhancements to Java, including:

The current Developer's Release of E, including the Java Development Kit and the E version of the Trust Manager for Java, can be downloaded at no charge from our website at

Electric Communities
10101 N. De Anza Boulevard, Suite 100
Cupertino, CA 95014
408.342.9200 fax

Electric Communities and the E logo are trademarks of Electric Communities. Use of the E logo for commercial purposes without the prior written consent of Electric Communities may constitute trademark infringement and unfair competition in violation of federal and state laws.

This document is copyrighted by Electric Communities with all rights reserved worldwide. Under copyright laws, this document may not be copied, in whole or in part, without the written consent of Electric Communities. Under the law, copying includes translating into another language.

Java(TM), and HotJava(TM) are trademarks of Sun Microsystems, Inc.