A Flexible Security Model for Using Internet Content

By Nayeem Islam, Rangachari Anand,
Trent Jaeger, and Josyula R. Rao
IBM Thomas J. Watson Research Center
June 28, 1997

Java, Netscape plug-ins, and ActiveX controls have led to the popularization of a new programming paradigm: extensive downloading of executable code into applications to enhance the functionality of the desktop. However, such flexibility in the programming model leads to several security problems. Malicious downloaded content may attempt to obtain unauthorized access to the client machine. In this paper, we describe a system for downloading content over an untrusted network such as the Internet and for controlling its use on a client machine. Our system dynamically generates a protection domain for the downloaded content based on resource requirements that come with the content and based on a local policy database at the client machine. The local policy database may be administered by a user at the client machine or by a systems administrator for a particular organization. Our system dynamically enforces the protection domain using capability lists. We have modified the Java Virtual machine to implement our security model. Our implementation is freely available at http://www.alphaworks.ibm.com/alphapreview_tools/ under the title FlexxGuard.



Table of Contents


Introduction

One of the promises of the World Wide Web and the Internet is the ability to download content from arbitrary servers and then execute that content on one's machine. From the viewpoint of a user, this paradigm is powerful because it decreases the amount of software that must be stored on the machine and enables the creation of applications that can use custom components from vendors selected dynamically. From the content provider's viewpoint, it is easier to distribute content; all one has to do is put the content up on a Web page. A Web browser that downloads Java applets, Netscape plug-ins, or ActiveX controls is an example of this new computing paradigm.

A significant concern with this approach is that the downloaded software may be malicious and may damage the user's machine. The downloaded content can inflict damage on a user's machine when it has unrestricted access to the file system, network hosts, and multimedia devices on the user's machine. One solution to this problem is to regard all downloaded software as hostile and to isolate it from all the resources on the user's machine. For instance, the current Java solution is to either distrust all Java applets and disallow access to most resources on the user's machine and on the network or to completely trust the Java applet and allow it access to all local system resources and network hosts.

These two alternatives do not provide the level of flexibility required by emerging Internet applications, such as electronic commerce, groupware, workflow, and games. These applications require the ability to dynamically derive a protection domain for all downloaded content. For example, consider a workflow application that implements an activity that enables its downloading principal to generate a purchase order from the following forms: a credit check, a sales statement, and a delivery statement. Assume that only the downloading principal is authorized to read all these forms. Using Java-enabled browsers, this scenario requires that the content provider obtain encrypted versions of all these forms and provide them to the downloading principal. If the downloading principal already has these forms, then the system incurs additional cost by downloading encrypted copies of the forms. This is not only a waste of time, but it still doesn't protect the form's privacy because content run in the Java appletviewer or Java-enabled Netscape can send the plaintext form back to the content provider once it's decrypted. Therefore, current interpreters execute this activity using more overhead than required and without satisfying its application's security requirements.

Return to Table of Contents

Problem Definition

  We assume an environment where an application downloads content from a potentially untrusted server over an untrusted network. A downloading principal is the principal that receives and executes the downloaded content. Downloading principals do not typically trust content manucfacturers with all their system resources. For example, downloading principals would like to prevent content from (1) reading private files, (2) writing executable files, (3) gaining access to their system's CPU, and (4) engaging in arbitrary remote communication from their system.

Also, attackers may be present. An attacker is a powerful adversary that can read, modify, and delete any message sent between the content manufacturer and the downloading principal. Moreover, attackers can generate new messages. Therefore, it must be possible to verify the source, integrity, and freshness of downloaded content. In addition, privacy and non-repudability of content messages may be required for some applications, such as electronic commerce.

The flexible control problem is to define and enforce a limited protection domain for downloaded content that is commensurate with its resource needs and with the downloading principal's trust in the content manufacturers. There are three facets to the control of downloaded content:

  • Authentication: Verify that the security requirements of the communication have been met such that the identity of the content manufacturers and content can be determined, or assume the content is generated by an untrusted source.
  • Domain Derivation: Derive a protection domain for this content.
  • Enforcement: Enforce the content's domain throughout its execution.

Authentication is necessary to determine if the security requirements of the content message communication are fulfilled (e.g., integrity and freshness preserved). If the content message is authentic, then the sources of the downloaded content and the identity of the content can be determined. Alternatively, the content can be assumed to have been generated by an untrusted source.

Next, the protection domain for the content must be derived. For downloaded content, this domain can be dependent on (1) the trust in the actual manufacturer and raters of the content and (2) the organizational policies. Finally, the content interpreter must be able to enforce the specified domain.

Return to Table of Contents

Solution Overview

  In this paper, we describe the design and implementation of a system that can flexibly control downloaded executable content. Flexibility is provided by (1) the ability to execute both authenticated and unauthenticated content, (2) the ability to use statements about content made by trusted third parties, such as content rating services, (3) the ability to dynamically derive a protection domain for content--even new content--and (4) the ability to enforce different protection domains and resource limitations on different contents executing simultaneously.

In our system, content can be delivered in encrypted form and with signed stamps provided by its manufacturer. A stamp is used to verify that (1) the manufacturer of the content and the principals involved in its distribution are identified, (2) no attacker has tampered with the content, (3) the manufacturer of the content cannot disavow his role in creating the content, and (4) if the content is encrypted, no eavesdropper can recover the plaintext. We use public-key cryptography[14, 19] for digital signing and encryption.

The stamp can also include information about the content's identity, purpose (e.g., using PICs ratings), and requested protection domain. Content-rating services can provide additional stamps that downloading principals can use to determine whether the content should be executed and what protection domain that content should be granted.

A difficult challenge in these systems is to derive a "least privilege" protection domain for content. In our system, we permit a downloading principal and/or a systems administrator to configure a policy database with maximal protection domains for different contents. Using the content-identity information in the stamp, a maximal protection domain can be derived. This domain is compared to the requested domain provided in the content stamp to determine the content's actual protection domain. A downloading principal may optionally change (within limits) the domain through a user interface.

The content's access to the resources on the client machine is regulated at runtime by a protection domain enforcer. It determines the content associated with the access and authorizes the access using that content's protection domain. Some denial-of-service attacks can also be prevented because the enforcer can monitor resource consumption.

Return to Table of Contents

Architecture

 

figure59

Figure 1: The Architecture of our system.

We propose a novel architecture for controlling the execution of downloaded content. In this architecture, downloading principals retrieve content and content stamps that attach descriptive information to content in a secure manner. Our architecture uses these content stamps to authenticate content and derive its protection domain. The content operations are then restricted to the derived protection domain. We define the following concepts in our architecture:

  • The downloading principal: the client who downloads the content and subsequently uses it.
  • The manufacturer of the content: the principal that manufactured the content.
  • The content server: the server that delivers the content to the downloading principal.
  • The certifying authority: a principal that manufactures public key certficates that bind principals to their public keys. The public key of the certifying authority is well-known.
  • The policy distribution service: a principal that distributes policy databases to the downloading principal.
  • The content-rating service: a principal that rates content.
  • The stamped content usage system: (1) an analysis module that authenticates content and creates protection domains for content, (2) a content interpreter that interprets the content, (3) a policy database that holds the maximal domain associated with each principal, (4) a dynamic security enforcer that enforces access to system objects at runtime, and (5) an access rights table that holds the capability lists associated with content.

The trust model of the architecture is defined from the perspective of the downloading principal. The downloading principal trusts certifying authorities, content-rating services, the policy distribution service, and the stamped content usage system. It does not trust the content server and the network. It has a variety of degrees of trust in the manufacturers of software.

We make the following assumptions about the environment in which our architecture is used. First, we assume that principals use a key distribution service that enables them to securely obtain another principal's public key. Next, we assume that all system I/O operations can be identified. This assumption depends on Java being a type-safe language. This has not been formally proven, and researchers have found errors in the verification and loading mechanisms that have enabled the type-safety to be circumvented[6]. However, we assume that the verifier enforces type-safety properly and does not address it further. Lastly, we assume that the operating system's TCB can be trusted; this trust is necessary to build a secure stamped content usage system upon it.

Our architecture solves the flexible control problem as follows (see Figure 1):

  1. The manufacturer and content-rating services upload content and/or content stamps to a content server.
  2. The analysis module uses the content stamp to authenticate the downloaded content.
  3. The analysis module uses the content stamp, the downloading principal's policy database (obtained from a policy distribution service), and perhaps some user intervention to derive the content's protection domain (set in the access rights table).
  4. The protection domain enforcer enforces the content's derived protection domain upon any controlled operation by the content interpreter.

The content stamp specifies the authentication information and execution requirements of the content from the manufacturer's and/or rating service's viewpoint. The architecture is designed to use such information, as well as user input, to determine the content's protection domain. The domain enforcer must determine which content is being executed and enforce the appropriate protection domain upon it.

The subsequent subsections detail how the architecture performs the tasks listed above.

Return to Table of Contents

Content Stamp

 

figure74
Figure 2: Structure of stamped content

Manufacturers and/or content-rating services may create a content stamp to annotate content with authentication and execution information (analogous to PEM[5] or BETSI[15] certificates). Figure 2 shows various fields of the content stamp. In general, the content stamp is divided into two parts: (1) the authenticator, which provides information for authenticating the stamp and the content, and (2) the tag which provides descriptive information used to determine how to execute the content.

The authenticator consists of two fields. The first field, security credentials list, includes a hash of the content, a list of stamp signers, and their signatures of the stamp. These credentials are used to (1) verify that the content was created and distributed by the principals whose credentials occur on the list, (2) verify that the content has not been altered after it was stamped, and (3) ensure that manufacturers cannot disavow the content that they have created. The separate content hash permits stamps to be downloaded separately from the content itself, if necessary.

The next field, certificate list, of the stamp contains a list of public key certificates (e.g., X.509) of the signer(s) of the stamp. For example, a stamp may be signed by a manufacturer and one or more content-rating services. A public key certificate binds the identity of certificate's principal to its public key. A certifying authority signs such certificates.

The tag also consists of two fields. The first field, content description, contains information that describes identity of the content, such as the name and version number of the software, the manufacturer's name, and the target execution platform. The second field, requested domain, specifies the protection domain that the content requests before executing. Content may need access to the following types of resources: the file system, memory, CPU, remote principals, and the downloading principal's display. Details of the protection domain specification syntax appear in [1].

When manufacturers create content, they may create a stamp for that content that binds their signature to the content's identity and its requested domain. Downloading principals can use this stamp to verify that that manufacturer signed the stamp, that the content is unmodified, and that the manufacturer is the principal that vouched for the content and its requested domain (if the signature and hash verifications succeed).

Content-rating services may sign manufacturer's stamps or create their own to annotate or revise the information in the manufacturer's stamp. For example, the content-rating service may provide PICs rating information (see http://www.w3.org/pub/WWW/PICS/) about the content or revise its protection domain. The content-rating services sign their stamps as well. Multiple content-rating services may create stamps for the same content. For example, one may provide values for different rating attributes than the other. A content-rating service is essentially a certifying authority (i.e., it is trusted by the downloading principal), so the content-rating service's stamp with the same fields can be used to prove the same facts as a manufacturer's stamp. Therefore, only the content-rating service's stamp needs to be verified if both can be obtained.

Return to Table of Contents

Content Authentication

The downloading principal authenticates the content to verify its integrity and source. The downloading principal requests the content by sending a message to a content server. The content server receives the request and, if required, encrypts the stamped content (i.e., content and stamp) using either a shared symmetric key, if one has been obtained (e.g., using Kerberos[16]), or the downloading principal's public key.

If a reply is not received from the content server within a specified time-out period, the downloading process is terminated by the analysis module. Once the encrypted, stamped content has been received by the downloading principal, the stamped content usage system's analysis module (see figure 1) decrypts the encrypted stamped content using the private key of the downloading principal. The public key of the manufacturer of the content or of the content-rating service can be extracted from the public key certificate included in the stamp's certificate list, or it can be obtained using the assumed key distribution service. The downloading principal uses the public key to verify that the stamp has not been modified. The analysis module computes a hash of the downloaded content and compares it to the hash in the stamp to verify that the content has not been modified. Also, identity information may also be used to verify that the content has the expected content name, version, platform, etc. If a stamp is provided, but cannot be verified, the associated content is not executed. Content that does not have a stamp is assumed to be from an untrusted principal.

Once the stamp is verified, the information in the stamp can be used. For example, domain derivation is based on the manufacturer's name, content name, PICs ratings, etc. Since multiple content-rating services may provide stamps, there is a possibility that contradictory values for the same attribute may be provided. In general, the application must know the semantics of the attributes to determine the meaning of such contradictions (e.g., union, cancel, intersection, etc.). As a default, we invalidate any attributes whose values differ in multiple, valid stamps (i.e., set equal to any value).

Return to Table of Contents

Domain Derivation

  Once the content has been authenticated, a protection domain must be computed for the content. The protection domain determines the access rights the content has on the downloading principal's machine. We define protection domains using the following access control model:

  • Access rights of a principal are defined by a set of domain rights and exceptions.
  • A domain right is a tuple <system-object, allowed-ops,limit>. This domain right states operations that are allowed on an object, and it states the limit on the number of such objects the operations are permitted upon.
  • An exception is a tuple < system-object,disallowed-ops>. This exception specifies operations that are not allowed on a system object.

A protection domain for principal is authorized to perform an operation on an object if (1) at least one domain right permits the operation, (2) no exception exists that precludes the operation, and (3) the limit for the number of operations has not been exceeded.

The following inputs are used to derive content protection domains:

  1. The requested domain (from the content stamp)
  2. The maximal domain (from the policy database)
  3. User dialogue

The following procedure is used to derive a content protection domain. An access right in the requested domain of the stamped content is added to the content's protection domain if it is within the maximal domain for the content as specified in the policy database. Other access rights may be approved by the downloading principal using a graphical interface. The protection domain in which the downloading principal may approve access rights for content may be restricted as well. The downloading principal may make these changes permanent by updating the policy database.

Return to Table of Contents

Policy Database

  A policy database processes queries of the following type: Find the maximal domain for a downloading principal to execute a specific content. The content is described by a set of attribute-value pairs. The result of this query defines the maximal set of rights that the content may be granted automatically. As mentioned above, downloading principals may modify their policy database to grant more or fewer rights (within limits).

Each downloading principal (or perhaps a role covering a group of principals) has policy database entries that store mappings between sets of content attribute-value pairs and maximal domains. For example, content from manufacturer IBM that is of type games can be associated with a specific protection domain. If a value is not specified for an attribute, it is assumed that the unspecified attribute can take any value. For example, the maximal domain above would apply to any IBM game.

figure110
Figure 3: An example policy database hierarchy

If the attributes are totally ordered, a hierarchy of mapping nodes results. For example, we use a three-level hierarchy for our policy database (see Figure 3): (1) general, (2) manufacturer name, and (3) content type. Given tex2html_wrap_inline582 as the protection domain of a downloading principal, its policy database represents the following relationships among maximal domains: tex2html_wrap_inline584 . That is, each child node's maximal domain is a superset of its parent's maximal domain. For example, the maximal domain of content that only has its manufacturer specified (IBM) is always a subset of the maximal domain for content that has its manufacturer and type specified (IBM game).

In the example policy database for the downloading principal nayeem, all content can read and write to the /tmp directory. Content from IBM can connect to any machine on the Internet and can write to the /tmp directory. System administrator content from IBM has access to all files and can connect to any file on the Internet, but IBM games and word processors are limited to application-specific directories. A video-enabled content browser application from Netscape Corporation has access to a video server named video.net.com in addition to the /tmp directory. However, the interactive cookbook from GoodEarth can use the display on the downloading principal's machine.

Our architecture supports the definition of specialized policy classes to interpret a policy database. A policy class includes a traverse method and a combine method. The traverse method defines how the hierarchy is traversed. The combine method defines how the current maximal domain is modified by each node that is reached in the traversal. In our policy, we traverse the hierarchy from the root following the closest match for the attributes examined thus far. The combine method unites the current node's domain with the current maximal domain. Thus, IBM game's maximal domain is tex2html_wrap_inline586 . The resultant maximal domain is File:/u/nayeem/games, File:/tmp and Net: any.

Policy classes enable tremendous flexibility in the specification and use of policy databases. Alternative traversals are bottom-up (from best-match to weakest) or solely for attribute-value matches (no hierarchy). Combine methods may override the current value and need to provide some conflict resolution (for exceptions and domain rights that conflict).

Return to Table of Contents

Policy Distribution Service

Centralized policy administration is useful for organizations that wish to maintain a uniform policy for downloaded content. In this approach, system administrators maintain a policy distribution service that stores the policy database and policy class. Updates to the class and database are controlled by the policy distribution service as specified by the system administrators. We assume that the stamped content usage system on the downloading principal's machine and policy distribution service can establish a secure channel (e.g., using Kerberos) to enable authenticated download of policy.

Downloading principals obtain their policy database upon login or upon ``pushes'' from the policy distribution service. When a downloading principal logs in, it picks up a policy database and class from the policy distribution service and stores them in the stamped content usage system. Subsequently, the policy distribution service can change the policy by "pushing" the policy database and/or class.

A centralized policy distribution service can control modifications to the policy database. Downloading principals can only modify their own policy database (perhaps within some system administrator-defined limits). The policy distribution service achieves this by marking certain entries in the policy database as modifiable and defining a domain in which rights may be granted. For example, a downloading principal may grant only read and write access to files in its directory subtree.

Return to Table of Contents

Dynamic Domain Enforcement

  When the stamped content is executed on the client machine, all operations on system objects are mediated by the protection domain enforcer. The protection domain enforcer authorizes such operations using the content's protection domain and monitors the resources consumed by the stamped content.

The protection domain enforcer stores the protection domain and resources consumed for all content in an access rights table. The access rights table has an entry for each stamped content that maps its execution identifier (e.g., thread ID) to a tuple containing the content identifier attributes, signers, capability list, and runtime resource consumption (for limits). The identifier attributes and signers are used to recover the content identity. The capability list stores the access rights entries that comprise the content protection domain. The runtime resources consumed contain the results of monitoring the content.

A content operation is authorized by first locating its access rights table entry. The content's capability list is stored in this entry. The object and operation are used to find the appropriate entries in the capability list and the runtime resources consumed. If a domain rights entry grants permission, if no exception precludes the operation, and if the runtime resource consumption has not exceeded the limit, then the operation is authorized. If the authorization fails, the protection domain enforcer can take remedial action. Examples of remedial action include terminating the execution of the content and asking the downloading principal for guidance.

Because the protection domain enforcer mediates the use of system operations, it can also keep track of the use of system resources. After an operation is authorized, any associated runtime resource consumption entries are updated. For example, on a file open for reading, the runtime resource consumption entries that were checked in authorization are incremented.

Return to Table of Contents

Details of Cryptographic Operations

  In this section, we describe the cryptographic operations performed by the manufacturers, the content-rating services, the content server, and the stamped content usage system.

Return to Table of Contents

Manufacturer

Manufacturer M creates a stamp for content C consisting of a tag T and the following cryptographic information: (1) a hash of the content C made using a collision-free, one-way hash function (e.g., SHA-1, MD5), H(C), (2) the manufacturer's signature of the tag T and the hash H(C) using the manufacturer's private key, tex2html_wrap_inline604, and (3) the public key certifcate of the manufacturer M, tex2html_wrap_inline608 , that maps the desription of the manufacturer, tex2html_wrap_inline610 , to its public key, tex2html_wrap_inline612 , and is signed by a certifying authority (CA). The message tex2html_wrap_inline614 is sent to the content server. The message may optionally be encrypted using the content server's public key.

Multiple signers are supported by nested signatures of the tag and content hash. The public key certificate field may contain multiple certificates.

Return to Table of Contents

Content-Rating Service

Content-rating service R may also provide stamps for content C. Its tag T and content C are included in the stamp in a similar manner to the manufacturer, except that R signs the tag and content hash and R's public key certificate is included. The message tex2html_wrap_inline628 is sent to the content server. The message may optionally be encrypted using the content server's public key.

Return to Table of Contents

Content Server

The content server S may encrypt the stamped content (content and its stamp) prior to forwarding it to the downloading principal. Encryption can be performed using either a shared symmetric key tex2html_wrap_inline632 (e.g., obtained using Kerberos) or the downloading principal's public key tex2html_wrap_inline634 . Using the public key, the message tex2html_wrap_inline636 is sent to the downloading principal.

Return to Table of Contents

Stamped Content Usage System

The stamped content usage system first decrypts the content server message (using the shared symmetric key or the downloading principal's private key). Next, it verifies that the CA's signature of the public key certificate is valid. If so, it extracts the public key of the signer from the message's public key certificate. Otherwise, the message is invalid. Next, it verifies that the signature of tex2html_wrap_inline638 is valid using the extracted public key (recall that there may be multiple signatures, in general). If so, then T and H(C)'s integrity is preserved and the signer is authenticated. Otherwise, the tag and content hash are not valid. A hash of C is compared to H(C) to verify that the content's integrity is preserved.

Return to Table of Contents

Java Implementation

  We have implemented our security model in the context of the Java Development Kit (JDK) version 1.1. All the Java classes listed below have been modified to support our security model.

A key feature of our implementation is that it can handle both stamped and unstamped applets. Unstamped applets are handled according to the standard Java applet policy; that is, the applet is not allowed to access files on the client machine, and no TCP connections are allowed to machines other than the host from which the applet was downloaded.

Each stamped applet is given its own protection domain. All threads created by the stamped applet are associated with the same protection domain. Hence, all threads belonging to a stamped applet have the same capability list associated with them.

We use SecurityTokens to map threads to protection domains. When an applet starts executing, it is assigned a unique, unmodifiable, unforgeable SecurityToken. Any threads created by the applet inherit the SecurityToken. In Java, system threads execute applet code, so when applet code is run, the system temporarily assigns the associated applet's SecurityToken to the thread (from the AppletPanel and AWT objects). The applet selected depends on the identity of the applet being loaded or on the applet that created the AWT object.

The Java AppletClassLoader object is responsible for downloading applets from the server. Stamped applets are stored on the server in the JAR (Java Archive) format. In addition to the usual Java object files, a stamped applet JAR also contains files which specify the requested domain for the stamped applet.

For stamped applets, the AppletClassLoader checks the requested protection domain of the applet against the downloading principal's policy database. The downloading principal's policy database associates protection domains with applet attributes (manufacturer name and applet name). The protocol described in Section 4.3.1 is used to derive the applet's protection domain. The policy database is stored in disk files that must be protected from access by other principals and applets. If the user decides to continue with the execution of the applet, an AppletSecurity object stores a mapping of the applet's protection domain's capability list and the applet's SecurityToken.

The AppletSecurity object uses the SecurityToken of the thread that invokes it to determine whether or not to allow an access to a system resource. Using the Securitytoken, AppletSecurity retrieves the associated capability list. The capability list is used to authorize the operation. If the authorization fails, a security exception is thrown. Any calls to AppletSecurity that originated from an unstamped applet will be authorized using the default Java applet security policy. System threads (i.e., threads with the System token) are allowed full access to the system.

Return to Table of Contents

Performance

  We have measured the overhead of providing our security features for downloaded applets and for enforcing the access rights of applets on JDK 1.02. For our experiments, the server was an RS/6000 Model 320 running NCSA httpd, and the client was a Pentium 150 running Windows 95. The results are presented for two applets: a software download application (SW) and a Telnet application. The size of the main (first) file for the software download applet was 24 Kbytes, and the size of the main file telnet applet was 22 Kbytes. The one-way hash algorithm used was MD5 and the encryption algorithm used was DESX.

The results show that the additional overheads of our scheme are just over 2 seconds for both applets that we tested. The dynamic access rights checks are approximately one millisecond. These overheads are relatively low and do not affect the performance as perceived by the user.

  

Return to Table of Contents

Related Work

  There have been several proposals for achieving security on the Internet. We review work related to our work in the following sections.

Return to Table of Contents

Janus

Janus [8] is a system that allows Internet programs, such as the Netscape browser, to use untrusted helper applications. Janus restricts the system calls a helper application can use. Janus runs on Solaris and uses the Solaris operating system's /proc process tracing facility to trace individual system calls of an application. Policy modules are used to specify per user, application, or site security policy. The Janus system is weak in the policies that can be implemented because it does not verify the source of helper applications and because it does not take into consideration what resources a helper application will actually need to perform its work.

Return to Table of Contents

Cryptolopes

Cryptolopes (or Cryptographic envelopes) are IBM's solution to the problem of distribution, sale, and use of information (or content) on the Internet. The principals involved in such a transaction are a document server, a user, and a buy server. Cryptolopes containing encrypted content are released and distributed over the Internet by document servers. A user negotiates access to the content of a cryptolope with a buy server. If the negotiation is successful, the user obtains information to decrypt the cryptolope and access the contents. The cryptolopes technology addresses the issue of managing distribution and controlling access to content in the Internet. It protects the content. It complements our work. We address the issues of protecting the client machine from downloaded content. More information on cryptolopes can be found

at http://www.cryptolope.ibm.com/.

Return to Table of Contents

Microsoft's Proposal for Code-Signing

Microsoft has presented a proposal for code-signing to the W3C that they intend to use for downloading ActiveX controls. The proposal requires software manufacturers to digitally sign their code. Signing code requires the manufacturer to encrypt a one-way hash of the code using its private key. The encrypted hash, the certificate of the ISV (which includes the name of the manufacturer and its public key), and the name of the one-way hash algorithm are called the signature block. The signature block is inserted into the portable, executable file format. This is then distributed over the Internet.

When a user downloads code, the downloading application calls the WinVerifyTrust API. The system extracts the signature, determines the certifying authority that authenticated the manufacturer's certificate, and obtains the public key of the manufacturer. The public key is used to decrypt the encrypted hash. This is compared to the output obtained by running the same one-way hash algorithm on the code again. If the code has not been modified since it was signed, the new and the old digests must match. In both cases, a warning is issued to the user. The user determines whether or not to let the code run. But if the user chooses to let the code execute, no further dynamic checks are performed by the system. There is no notion of a dynamic security enforcer. Nor do they allow manufacturers to stamp the code with resource specifications regarding the downloaded code. More information can be found at http://www.microsoft.com.

Return to Table of Contents

Telescript

The Telescript system provides a mechanism for authenticating downloaded content [18]. It proposes permits for content that specify restrictions on content usage such as age, size, and process priority. Permits do not have the scope of resource specifications that we provide. In particular, permits say nothing about the capabilities of a downloaded process. In addition, it is not clear how permits are created and how they are transmitted securely from the manufacturer of the content.

Return to Table of Contents

Safe-Tcl

Safe-Tcl is an extension to the interpreted language Tcl[12]. The Tcl interpreter has a "wrapper" interface to the underlying system's resources. In the Safe-tcl model two interpreters run side by side: a regular interpreter that has all the interfaces to access resources of the underlying client machine and a restricted interpreter that does not have these interfaces. The intent is to run trusted code in the regular interpreter and untrusted code in the restricted interpreter. In addition, there is a procedure call that allows parts of a downloaded script to be run in the trusted interpreter from within the untrusted interpreter.

Return to Table of Contents

Other Extensions to Tcl

Jaeger[10] describes a system for assigning rights to downloadable executable content. These rights allow content to access system resources in a controlled manner. Jaeger also describes an architecture to authenticate sources of content, to determine access rights for content based on its source and on the application that is downloading the content, and to enforce these rights at runtime.

Jaeger's model determines the access rights of content using the predefined rights of four principals: downloading principals, remote principals, application developers, and system administrators. It uses the notion of application groups to achieve compactness in the description of security requirements of content. Jaeger implemented his prototype on Tcl version 7.5[11]. In this version of Tcl, a hierarchy of trusted and untrusted interpreters can be built. Also, untrusted interpreters can execute commands in a trusted interpreter by using an aliased command. This prototype uses aliases heavily to enable trusted interpreters to execute controlled commands on behalf of untrusted interpreters.

Jaeger addresses some of the same issues we address, but the mechanisms he employs are quite different. Jaeger uses application groups for deriving rights, whereas our approach uses user input, a local policy database, and a stamp. Our implementation on Java overloads classes in Java and implements our model in one interpreter.

Return to Table of Contents

PEM: Privacy-Enhanced Mail

PEM provides confidentiality, authentication and message integrity. In particular, it supports both public key and symmetric key cryptosystems. PEM also specifies a certificate management system that is a superset of X.509. PEM is similar to our approach in the methodology it uses for signing and encrypting messages as well as in certificate management, because it provides a degree of flexibility in the schemes one can choose. Our approach differs in that it focuses on securing the client machine from the content. This is not directly addressed by PEM.

Return to Table of Contents

SSL, S-HTTP, and IPSec

SSL [9] is the secure sockets layer protocol, and s-HTTP [13] is a secure version of the http protocol. They use different approaches to security on the Web. SSL executes a negotiation protocol to establish a secure socket level connection between two parties. The SSL security services are transparent to the user and the application. S-HTTP protocols are integrated with http. The security is negotiated through the headers and the attributes are attached to the page. It is more transparent to applications.

IPSec refers to a protocol that allow entities communicating through IP [2, 3] to authenticate each other and to allow encryption of IP datagrams. The big advantage of IPsec is that encryption is down at the lowest levels of the operating system, allowing IP headers to be encrypted.

These three protocols provide security features for two partities exchanging data. Techniques incorporated in them could be used to securely transfer content from a server to a client. These protocols do not provide a mechanism for authenticating the content and for controlling its execution on a client machine.

Return to Table of Contents

The E Programming Language

Electric Communities has developed an extension of Java, called E, for writing distributed applications. E's security model is based on a capability model which allows objects to communicate with each other in a distributed system. Such capabilities are granted to E objects at load time. A cryptographic signature and a set of capability requirements are attached to every E object. Based on the trustedness of the signature, the set of capabilities is granted or refused. For instance, one can create a trusted object that implements limited capabilities. By giving an untrusted application the ability to send messages to this trusted object, one can obtain more interesting functionality from the untrusted code without compromising security. More information about electronic communities can be found at http://www.communities.com/e.html.

Return to Table of Contents

Role-Based Access Control

  Recent systems that permit dynamic restriction of rights (e.g., based on Role-Based Access Control (RBAC) models [4, 7, 17]) require that these limited domains be pre-specified, which can result in larger domains than desired for a single content execution. For example, a RBAC domain for an application would have to encompass all rights that any individual use of the application would ever need.

Return to Table of Contents

Conclusions

  We have described a mechanism for controlling executable content for client machines. Our solution uses information associated with the content to create protection domains and dynamically enforces these protection domains. Our solution is flexible in that a client or a system administrator can configure a database to change the protection domains granted to downloaded content. One very attractive feature of our design is that it allows system administrators to control the protection domains for client machines such that a consistent policy can be implemented in an organization.



References

1
Rangachari Anand, Nayeem Islam, and J.R. Rao. "A Capability-based Security Model for Using Internet Content." Technical Report 20664, IBM Research, 1996. http://www.alphaworks.ibm.com.

2
R. Atkinson. IP Authentication Header. Internet Draft. Aug 1995, 1995.

3
R. Atkinson. IP Encapsulation Security Payload (ESP). Internet Draft. Aug 1995, 1995.

4
L. Badger, D. F. Sterne, D. L. Sherman, K. M. Walker, and S. A. Haghighat. "Practical domain and type enforcement for UNIX." IEEE Symposium on Security and Privacy, pages 66-77, 1995.

5
D. Balenson. "Privacy enhancement for Internet electronic mail: Part III: algorithms, modes, and identifiers." Internet RFC 1423, February, 1993.

6
D. Dean, E. Felten, and D. Wallach. "Java security: From HotJava to Netscape and beyond." Proceedings of the IEEE Symposium on Security and Privacy, 1996.

7
M. Gasser and E. McDermott. "An architecture for practical delegation in a distributed system." IEEE Symposium on Security and Privacy, pages 20-30, 1990.

8
Ian Goldberg, David Wagner, Randi Thomas, and Eric Brewer. "A secure environment for untrusted helper applications." Proceedings of the 6th USENIX Security Symposium, pages 1-13, July 1996.

9
Hickman and Elgamal. The SSL Protocol. Internet Draft. June 1995, 1995.

10
T. Jaeger, A. Rubin, and A. Prakash. "Building systems that flexibly control downloaded executable content." Proceedings of the 6th USENIX Security Symposium, pages 131-148, July 1996.

11
J. Levy and J. Ousterhout. "Safe Tcl: A toolbox for constructing electronic meeting places." The First USENIX Workshop on Electronic Commerce, pages 133-135, 1995.

12
John Ousterhout. Tcl and the TK Toolkit. Addison Wesley Publishing Co, 1994.

13
Rescorla and Schiffman. The Secure HyperText Transfer Protocol. Internet Draft. July 1995, 1995.

14
Ronald Rivest, Adi Shamir, and L. Adleman. "On digital signatures and public key crytosystems." Communications of the ACM, 1978.

15
A. D. Rubin. "Trusted distribution of software over the internet." Proceedings of the Internet Society Symposium on Network and Distributed System Security, 1995.

16
J. Steiner, Neuman, and Schiller. "Kerberos: an authentication system for open network systems." USENIX Conference Proceedings. Proceedings of the USENIX Conference, 1988.

17
S. T. Vinter. "Extended discretionary access controls." IEEE Symposium on Security and Privacy, pages 39-49, 1988.

18
J. E. White. Telescript Language Reference Manual. General Magic, Inc., October 1995.

19
Phil Zimmerman. PGP source code and internals. MIT Press, 1995.



About the Authors:

Nayeem Islam is a manager at IBM's T.J. Watson research center in Hawthorne, NY where he directs several projects on secure Web operating systems and resource management for servers. He has built a commercial windowing system, an object-oriented operating system and extensions to Java to provide a security model for the Java virtual machine.

Islam has also authored a book Distributed Objects: Methodologies for Customizing Systems Software that is used in graduate courses at several universities. Islam holds a Ph.D. from the University Illinois Urbana Champaign, an M.S. from Stanford University and a B.S.E. from Princeton University, all in Computer Science. His e-mail address is nayeem@watson.ibm.com.

Josyula R. Rao is a Research Staff Member in the Java Technology and Applications group at IBM's Thomas J. Watson Research Center and is an adjunct faculty member in the Department of Computer Sciences at New York University. His research interests are in programming methodology, distributed systems, operating systems and computer security. He is a member of IFIP's Working Group 2.3 (Programming Methodology).

JR received his doctoral degree from the University of Texas at Austin and his masters degree from the State University of New York at Stony Brook. He can be reached at jrrao@watson.ibm.com.




JavaTM is a trademark of Sun Microsystems, Inc.
Other companies, products, and service names may be trademarks or service marks of others.

Copyright    Trademark



  Java Feature Java Education Java Home  
IBM HomeOrderEmployment