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.
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
|
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
|
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
|

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):
- The manufacturer and content-rating services upload content and/or content stamps to a content server.
- The analysis module uses the content stamp to authenticate the downloaded content.
- 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).
- 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
|
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
|
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
|
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:
- The requested domain (from the content stamp)
- The maximal domain (from the policy database)
- 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
|
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.
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 as the protection domain
of a downloading principal, its policy database represents the
following relationships among maximal domains: .
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
. 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
|
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
|
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
|
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 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, , and (3) the public key certifcate of the manufacturer
M, , that maps the desription of the
manufacturer, , to its public key, , and is signed
by a certifying authority (CA). The message 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 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 is sent
to the content server. The message may optionally be encrypted using
the content server's public key.
|
Return to Table of Contents
|
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
(e.g., obtained using Kerberos) or the downloading
principal's public key . Using the public key, the message
is sent to the downloading principal.
|
Return to Table of Contents
|
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 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
|
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
|
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
|
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 [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 (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 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
|
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 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
|
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 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 [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
|
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
|
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
|
|