A Flexible Security Model for Using Internet Content
`
`Rangachari Anand, Nayeem Islam, Trent Jaeger and Josyula R. Rao
`IBM Thomas J. Watson Research Center
`P.O. Box 704
`Yorktown Heights, NY 10598
`{ anand, nayeem, jaegert, jrrao} @watson.ibm.com
`
`Abstract
`
`Java applets, Netscape plug-ins and ActiveX controls
`have led to the popularization of a new paradigm: extensive
`downloading of executable code into applications to en-
`hance the functionality of the desktop. One of the problems
`with this paradigm is the need to control the access rights of
`the downloaded content. In this papel; we describe a system
`for downloading content from tlze Internet and controlling
`its actions on a client machine. Our system generates a
`protection domain for the downloaded content dynamically
`using the content’s requested domain and a policy database
`that describes the user ’s trust in the content’s manufacturer
`and type. Our system ensures that this protection domain
`is enforced throughout the execution of the content. We
`have modijed the Java Virtual Machine to implement our
`security model. Our implementation, culled Flexrguard, is
`freely available at http://www.alplzaworks. ibm.com.
`
`1. Introduction
`
`One of the promises of the World Wide Web is the ability
`of users to download content from arbitrary servers and then
`execute that content on their machines. From the viewpoint
`of a user, this paradigm is powerful because it decreases
`the amount of software that must be stored on the hidher
`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 distrib-
`ute content; all one has to do is put the content up on a
`web page. A web browser that supports the downloading of
`Java applets, Netscape plug-ins, or ActiveX controls is an
`example of this new computing paradigm.
`A signficant concern with this approach is that the down-
`loaded software may be malicious and may damage the
`user S machine. The downloaded content can inflict dam-
`age 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’s solution is to either distrust all Java applets and dis-
`allow access to most resources on the user’s machine and
`the network or 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 flex-
`ibility required by emerging Internet applications, such as
`electronic commerce, groupware, workflow and games. Not
`only would each of these applications require access to dif-
`ferent sets of resources on the user’s machine, the user would
`like to personally configure the access an application has
`to resources on hidher machine. This is a classic engi-
`neering problem of mechanism versus policy: ideally, the
`user should be provided with the infrastructure necessary to
`support the secure execution of downloaded content, while
`being free to program a specific security policy. This model
`of security would be more flexible than the ones being cur-
`rently supported by various interpreters and browsers and
`would enable a larger class of useful desktop applications.
`
`2. Problem Definition
`
`We assume an environment where an application down-
`loads content from a potentially untrusted server over an
`untrusted network. A downloading principal is the princi-
`pal that downloads, receives and executes the downloaded
`content. Downloading principals do not typically trust con-
`tent manufacturers to not tamper with the system resources
`on their machines. For example, downloading principals
`would like to prevent content from: (1) reading private files;
`( 2 ) writing executable files; (3) limit access to their system’s
`CPU; and (4) prevent arbitrary remote communication from
`their system.
`In addition to malicious content, attackers may also 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. Since an at-
`
`1060-9857/97 $10.00 0 1997 IEEE
`
`89
`
`000001
`
`Patent Owner Finjan, Inc., - Ex. 2004, p. 1
`
`

`

`tacker can generate spurious messages, it must be possible
`to verify the source and integrity of the messages received
`by the downloading principal. In particular, the integrity of
`the messages containing the downloaded content should be
`verified. Since it is also possible for an attacker to eaves-
`drop on the communcations between the manufacturer and
`the downloading principal, privacy content messages may
`be required for some applications, such as electronic com-
`merce. Finally, there should be some means of enforcing
`non-repudiability, that is, ensuring that a manufacturer can-
`not disavow its responsibility in producing the content.
`The flexible control problem is to define and enforce a
`limited protection domain for downloaded content commen-
`surate with its resource needs and the downloading princi-
`pal’s trust in the content’s manufacturer. There are three
`facets to the control of downloaded control:
`
`Authentication: Verify the security requirements of
`the communication have been met such that the iden-
`tity of the content’s manufacturer 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 through-
`out its execution
`
`Authentication is necessary to determine if the security re-
`quirements of the content message communication are ful-
`filled (e.g., integrity 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 de-
`rived. For downloaded content, this domain can depend
`on: (1) the trust in the actual manufacturer and raters of the
`content; and (2) organizational policies. Finally, the con-
`tent interpreter must be able to enforce the specified domain
`when the content is being executed.
`
`3. 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 exe-
`cute 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 de-
`rive a protection domain dynamically for even new content;
`and (4) the ability to enforce different protection domains
`
`and resource limitations on different content executing si-
`multaneously.
`In our system, content can be delivered in encrypted
`form and with signed stumps provided by its manufacturer.
`A stamp is used to: (1) identify the manufacturer of the
`content and the principals involved in its distribution; (2)
`verify that no attacker has tampered with the content; (3)
`ensure that the manufacturer of the content cannot disavow
`hidher role in creating the content; and (4) enforce that no
`unauthorized eavesdropper can recover the content from the
`messages. We use public-key cryptography[20, 151, digital
`signatures and encryption to enforce this.
`The stamp include information about the content’s iden-
`tity, purpose (e.g., using PICS ratings), and the resources it
`needs to execute on a user’s machine. Content rating ser-
`vices can provide additional stamps that downloading prin-
`cipals can use to determine whether the content should be
`executed and the protection domain that the 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 andlor a systems administra-
`tor to configure a policy database with maximal protection
`domains for different content. Using the content identity
`information in the stamp, a maximal protection domain can
`be derived. This domain is compared to the requested do-
`main provided in the content stamp to determine the con-
`tent’s actual protection domain. A downloading principal
`may optionally change the domain through a user interface
`(within limits).
`The content’s access to the resources on the client ma-
`chine is regulated at runtime by a protection domain en-
`forcer. It determines the content associated with the access
`and authorizes the access using that content’s protection do-
`main. Some denial-of-service attacks can also be prevented
`because the enforcer can monitor resource consumption.
`
`4. Architecture
`
`We propose a novel architecture for controlling the exe-
`cution of downloaded content. In this architecture, down-
`loading principals retrieve content and content stumps 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 oper-
`ations are then restricted to the derived protection domain.
`We define the following concepts in our architecture.
`The downloading principal: the client who is down-
`loading the content and subsequently uses it.
`
`The manufacturer of the content: the principal that
`manufactured the content.
`
`90
`
`000002
`
`Patent Owner Finjan, Inc., - Ex. 2004, p. 2
`
`

`

`Manuladurer
`
`ANALYSIS
`
`MODULE
`
`DOWNLOADING
`PRINCIPAL
`
`securely obtain another principal’s public key. Next, we as-
`sume 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]. How-
`ever, we assume that the verifier enforces type-safety prop-
`erly and do not address it further. Lastly, we assume that the
`operating system can be trusted. This is necessary to build
`a secure stamped content usage system upon it.
`Our architecture solves the flexible control problem as
`follows (see Figure 4):
`
`0
`
`STAMPED CONTENT USAGE SYSTEM
`
`Figure 1. The Architecture of the System
`
`The content server: the server that delivers the content
`to the downloading principal;
`
`The certifying authority: A principal that manufac-
`tures public key certificates. These certificates bind
`the identities of principals to their public keys. The
`public key of the certifying authority is well-known.
`
`The policy distribution service: a principal that dis-
`tributes policy databases to the downloading princi-
`pal.
`
`The content rating service: a principal that rates con-
`tent.
`
`The stamped content usage system (see Figure 4):
`(1) an analysis module that authenticates content and
`creates protection domains for content; (2) a content
`interpreter that interprets the content,(3) apolicy data-
`base 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 download-
`ing principal trusts certifying authorities, content rating ser-
`vices, the policy distribution service and the stamped content
`usage system. It does not trust the content server and the net-
`work. It has a varying degree of trust in the manufacturers
`of software.
`We make the following assumptions about the environ-
`ment in which our architecture is used. First, we assume that
`principals use a key distribution service that enables them to
`
`91
`
`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 au-
`thenticate 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), and
`
`4. The protection domain enforcer enforces the content’s
`derived protection domain on any controlled opera-
`tion performed by the content,
`
`The content stamp specifies the authentication informa-
`tion and execution requirements of the content from the
`manufacturer’s and/or rating service’s viewpoint. The ar-
`chitecture is designed to utilize such information, as well
`as user input, to determine the content’s protection domain.
`The domain enforcer must determine which content is be-
`ing executed and enforce the appropriate protection domain
`upon it.
`The subsequent subsections detail how the architecture
`performs the tasks listed above.
`
`4.1. Content Stamp
`
`Manufacturers and/or content rating services may create
`a content stamp to annotate content with authentication and
`execution information (analogous to PEM[2] or BETSI[ 161
`certificates). Figure 2 shows various fields of the content
`stamp. In general, the content stamp is divided into two
`parts: ( I ) 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
`
`000003
`
`Patent Owner Finjan, Inc., - Ex. 2004, p. 3
`
`

`

`Stamp
`
`....................
`
`Certificate List
`....................
`Content description
`
`....................
`Requested Domain
`
`Stamped Content
`
`Figure 2. Structure of stamped content
`
`was created and distributed by the principals whose creden-
`tials occur on the list; (2) verify that the content has not
`been altered after it was stamped; and (3) ensure that manu-
`facturers 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 the 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, regriesfed domain, specifies the
`protection domain that the content requests for executing
`the content. 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 appears in [ 11.
`When manufacturers create content, they may create a
`stamp for that content that binds their signature to the con-
`tent’s identity and requested domain. Downloading princi-
`pals can use this stamp to verify that manufacturer signed the
`stamp, 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/pubn;VWW/PICS/) about the content or
`revise its protection domain. The content rating services
`
`92
`
`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 services stamp needs to
`be verified if both can be obtained.
`
`4.2. Content Authentication
`
`The downloading principal requests the content by send-
`ing a message to a content server. The content server re-
`ceives the request and, if required, encrypts the stamped con-
`tent (i.e., content and stamp) using either shared symmetric
`key, if one has been obtained (e.g., using Kerberos[ 17]), or
`the downloading principal’s public key.
`If a reply is not received from the content server within a
`specified timeout period the downloading process is termi-
`nated 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 fig-
`ure 4) authenticates the content to verify its integrity and
`source. It then decrypts the encrypted stamped content us-
`ing the private key of the downloading principal. The public
`key of the manufacturer of the content or content rating ser-
`vice 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 prin-
`cipal 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. The
`identity information may also be used to verify that the con-
`tent 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.
`
`4.3. Domain Derivation
`
`Once the content has been authenticated, a protection
`domain must be computed for the content.’ The protec-
`tion 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 a defined by a set of domain rights
`and exceptioris.
`e A domain right i s a tuple <system-object,allowed-
`ops,limif> This states operations that are allowed on
`
`The system allows content that has no stamp to run in a highly restric-
`tive domain.
`
`000004
`
`Patent Owner Finjan, Inc., - Ex. 2004, p. 4
`
`

`

`an object and the limit on the number of such objects
`the operations are permitted upon,
`
`e
`
`An exception is a tuple <system-ohject,disallowed-
`ups>. This specifies operations are not allowed on a
`system object.
`
`protection domain for principal is authorized to per-
`A
`form an operation on an object i f ( I ) at least one domain
`right permits the operation; (2) no exception exists that pre-
`cludes the operation; and ( 3 ) the limit for the number of
`operations has not been exceeded.
`The following inputs are used to derive content protec-
`tion domains: (1) The requested domain (from the content
`stamp) (2) The maximal domain (from the policy database),
`and (3) User dialogue.
`The following procedure is used to derive a content pro-
`tection 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 re-
`stricted as well. The downloading principal may make these
`changes permanent by updating the policy database.
`
`4.4 Policy Database
`
`The policy database stores the mappings of content de-
`scriptions to default maximal protection domains. The
`analysis module can retrieve the default maximal protection
`domain for any content by supplying its description to the
`policy database. The policy database is organized to support
`partial matches of content descriptions to database entries,
`so default maximal protection domains can be retrieved for
`incompletely specified content and new content.
`As Figure 3 shows, we use a three-level hierarchy for our
`policy database: general, manufacturer name, and content
`type. The general entry applies to all content. A manu-
`facturer name entry applies to all content from the same
`manufacturer. A content type entry applies to all content of
`the same type from the same manufacturer or any manufac-
`turer. Given DUser as the user’s protection domain, the pol-
`icy database represents the following relationships among
`protection domains: DuSer 2 D t y p e 2 Dmanufacturer 2
`Dgeneral. Additional levels, such as content name, can be
`added to extend the policy database. Also, different hierar-
`chies can be specified for different users.
`A default maximal protection domain is the union of the
`database entries whose key matches the content description.
`For example, the default maximal protection domain for
`ZBM Games content is the union of the protection domains
`specified for the general, IBM, and IBM G a m s entries.
`
`93
`
`file: Rmp
`I
`
`General
`
`......................
`
`File:lulnayeemldocumentJ
`
`I
`
`File: any
`
`Figure 3. An example policy database hierar-
`chy
`
`However, the default maximal protection domain for IBM
`Financial Services content would be the union of the general
`and IBM entries only. Therefore, default maximal protec-
`tion domains can be derived even for new content. Users
`can then extend the domain of the new content interactively.
`A policy distribution service is defined to enable central-
`ized management of security policy by system administra-
`tors. The service stores the policy database and responds to
`queries for default maximal protection domains and database
`modifications by users. We envision the policy distribution
`service being run on a secure machine. A secure channel is
`required to prevent unauthorized modification of the data-
`base. Access control to the policy database is enforced by
`associating ACLs with each database entry that specify who
`can perform read, write, delete, and specialize (i.e., create a
`child entry) operations.
`When the stamped content is executed on the client ma-
`chine, all operations on system objects are mediated by the
`protection domain enforcer. The protection domain enforcer
`authorizes such operations using the content’s protection do-
`main and monitors the resources consumed by the stamped
`content.
`The protection domain enforcer stores the protection do-
`main and resources consumed for all content in an accen
`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 at-
`tributes, signers, capability list, and runtime resource con-
`sumption (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 pro-
`tection domain. The runtime resources consumed contains
`
`000005
`
`Patent Owner Finjan, Inc., - Ex. 2004, p. 5
`
`

`

`the results of monitoring the content.
`A content operation is authorized by first locating its ac-
`cess 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 permis-
`sion, no exception precludes the operation, and the runtime
`resource consumption has not exceeded the limit, then the
`operation is authorized. If the authorization fails, the pro-
`tection 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 as-
`sociated 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.
`
`performed either using a shared symmetric key KS-D
`(e.g., obtained using Kerberos) or the downloading prin-
`cipal’s public key KA. Using the public key, the mes-
`sage K;{C,T, H ( C ) , K&{T, H(C)}, K,,{DMM, K&})
`is sent to the downloading principal.
`
`Stamped Content Usage System The stamped content
`usage system first decrypts the content server message (us-
`ing the shared symmetric key or the downloading principal’s
`private key). Next, verify that the CA’s signature of the pub-
`lic key certificate is valid. If so, extract the public key of the
`signer from the message’s public key certificate. Otherwise,
`the message is invalid. Next, verify that the signature of
`{T, H ( C ) } is valid using the extracted public key (recall
`that their 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.
`
`5. Details of Cryptographic Operations
`
`6. Java Implementation
`
`In this section, we describe the cryptographic operations
`performed by the manufacturers, the content rating services,
`content server, and the stamped content usage system.
`
`Manufacturer Manufacturer M creates a stamp for con-
`tent C consisting of a tag T and the following crypto-
`graphic information: (1) a hash of the content C made
`using a collision-free, one-way hash function (e.g., SHA-
`I, MD5), H ( C ) ; ( 2 ) the manufacturer’s signature of the
`tag T and the hash H ( C ) using the manufacturer’s private
`key, K&{T, H ( C ) } ; and ( 3 ) the public key certificate of
`the manufacturer M , K&(DMK$}, that maps the de-
`scription of the manufacturer, D M , to its public key, K L ,
`and is signed by a certifying authority (CA). The message
`{C,T, H(C), K&(T, H ( C ) } , K C A { D ~ , K L } } is sent to
`the content server. The message may optionally be en-
`crypted using the content servers public key.
`Multiple signers are supported by nested signatures of
`the tag and content hash. The public key certificate field
`may contain multiple certificates.
`
`Content Rating Service Content rating service R may
`also provide stamps for content C. Its tag T and content C is
`included in the stamp in asimilar manner to the manufacturer
`except R signs the tag and content hash and R’s public key
`certificate is included.
`
`Content Server The content server S may encrypt the
`stamped content (content and its stamp) prior to forward-
`ing it to the downloading principal. Encryption can be
`
`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.
`Our modified appletviewer can handle both stamped and
`unstamped applets. Unstamped applets are handled accord-
`ing to the standard Java applet policy, that is, the applet is
`not allowed to access files on the user’s 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 do-
`mains. When an applet starts executing, it is assigned
`a unique, unmodifiable, unforgeable SecurityToken. Any
`threads created by the applet inherit the SecnrityToken. In
`Java, system threads can execute applet code, so when applet
`code is run, the system temporarily assigns the associated
`applet’s SecurihToken to the thread (from the AppletPanel
`and AWT objects). The applet selected depends on the iden-
`tity of the applet being loaded or the applet that created the
`AWT object.
`The Java sun.applet.AppletClassLoader (subclass of
`jaLa.lang. ClassLoarler) is responsible for downloading ap-
`plets from the server. The Java AppletClassLoader ob-
`ject 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,
`
`94
`
`000006
`
`Patent Owner Finjan, Inc., - Ex. 2004, p. 6
`
`

`

`a stamped applet JAR also contains files which specify the
`requested domain for the stamped applet.
`For stamped applets, our modified AppletClassLoader
`checks the requested protection domain of the applet against
`the downloading principal’s policy database. The down-
`loading principal’s policy database associates protection do-
`mains with applet attributes (manufacturer name and applet
`name). The protocol described in Section 4.4 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 con-
`tinue with the execution of the applet, an AppletSecurity
`object stores a mapping of the applet’s SecurityToken and
`the applet’s protection domain’s capability list.
`Our modified sun.applet.App1etSecurity (subclass of
`java. ZangSecurityManager) 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 Securityto-
`ken, AppZetSecurity 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 pol-
`icy. System threads (i.e., threads with the System token) are
`allowed full access to the system.
`
`7. Specifying access rights
`
`Domain rights are specified using a simple BNF syntax
`that is covered in detail in [I]. We briefly illustrate the use
`of our language in this section. Note this syntax is used for
`the policy database as well as the request domain tag in the
`stamped content.
`Our mechanisms allows one to specify limits on disk
`space, window system, CPU usage, file access and network
`access. Table 1 summarizes some of the resource limits and
`access rights that can be specified.
`
`8. Performance
`
`We have measured the overhead of providingour security
`features for downloaded applets and for enforcing the access
`rights of applets on JDK 1.02. Table 2 shows the results of
`our security mechanism. 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
`(app 1) and a Telnet application (app 2). The size of the
`main (first) file for the software download applet was 24
`Kbytes and the size of the main file for the telnet applet was
`22 Kbytes. The one way hash algorithm used was MD5 and
`the encryption algorithm used as DESX.
`
`95
`
`The results show that the additional overheads of our
`scheme are just over 2 seconds for both applets. The dy-
`namic access rights checks are approximately one millisec-
`ond. These overheads are relatively low and do not affect
`the performance as perceived by the user.
`I Overhead
`I seconds I seconds I
`Application
`Download initial .class file
`Download stamped .class stamp
`Decrypt and verify hashes
`Extract stamp
`Dynamic Enforcement
`
`0.50
`,
`1 0.001
`Table 2. The performance overheads of our
`security scheme
`
`0.22
`0.50
`
`I 0.001
`
`9. Related Work
`
`There is now a fairly large body of work on restricted
`execution environments for downloaded content. Early sys-
`tems restricted downloaded conten