Advancing Technology
`for Humanity
`
`DECLARATION OF GERARD P. GRENIER
`
`I, Gerard P. Grenier, am over twenty-one (21) years of age. I have never been convicted
`of a felony, and I am fully competent to make this declaration. I declare the following to be true
`to the best of my knowledge, information and belief:
`
`1.
`
`I am Senior Director of Publishing Technologies of the Institute of Electrical and
`Electronics Engineers, Inc. ("IEEE").
`
`2.
`
`IEEE is a neutral third party in this dispute.
`
`3. Neither I f\Or IEEE itself is being compensated for this declaration.
`
`4. Among my responsibilities as Senior Director of Publishing Technologies, I act as a
`custodian of certain records for IEEE.
`
`5.
`
`I make this declaration based on my personal knowledge, information contained in
`the business records of IEEE, or confirmation with other responsible IEEE personnel
`with such knowledge.
`
`6. As part of its ordinary course of business IEEE publishes and makes available
`technical articles and standards. These publications are made available for public
`download through the IEEE digital library, IEEE Xplore.
`
`7.
`
`It is the regular practice ofiEEE to publish articles and other writings including
`article abstracts and make them available to the public through IEEE Xplore. IEEE
`maintains copies of publications in the ordinary course of its regularly conducted
`activities.
`
`8. The article below, along with its abstract, has been attached as Exhibits A & B,
`respectively, to this declaration:
`
`A. Abstract - "Poison Java [data security]" Chen, E. , IEEE Spectrum, Vol. 36,
`Issue 8, 1999.
`B. "Poison Java [data security]" Chen, E., IEEE Spectrum, Vol. 36, Issue 8,
`1999.
`
`9.
`
`I obtained copies of each of the attached Exhibits through IEEE Xplore, whereJhey
`were maintained in the ordinary course ofiEEE's business. Each Exhibit is a true
`and correct copy ofthe Exhibit as it existed on or about September 10,2015 .
`
`10. The article abstract from IEEE Xplore shows the date of publication. IEEE Xplore
`populates this information using the metadata associated with the publication.
`
`445 Hoes Lane Piscataway, NJ 08854
`
`Blue Coat Systems - Exhibit 1005
`
`0001
`
`

`
`11. "Poison Java [data security]" by E. Chen was published by IEEE as part of Volume
`36, Issue 8 of IEEE Spectrum. The article abstract states that Volume 36, Issue 8 of
`IEEE Spectrum was published in August 1999. This publication happened no later
`than the last day of this month. The article is currently available for public download
`from the IEEE digital library, IEEE Xplore
`
`I declare under penalty of perjury that the foregoing statements ar
`J
`(11'
`.
`'l
`i /)
`Executed on: ;U · ..::OLJA · 'cxr!l )
`
`\
`
`0002
`
`

`
`
`
`EXHIBIT A
`
`EXHIBIT A
`
`
`
`
`
`0003
`
`0003
`
`

`
`IEEE Xplore Abstract - Poison Java [data security]
`
`
` IEEE.org IEEE Xplore Digital Library
`|
`
`
`|
`
`
`IEEE-SA
`
`
`
`|
`
`
`
` IEEE Spectrum
`
`|
`
`More Sites
`
`
`
`
` Cart (0) Create Account
`|
`
`
`
`|
`
`Personal Sign In
`
`Institutional Sign In
`
`BROWSE
`
`MY SETTINGS
`
`GET HELP
`
`WHAT CAN I ACCESS?
`
`SUBSCRIBE
`
`
`
`
`
`Search
`
`Basic Search
`
`Author Search
`
`Publication Search
`
`Advanced Search
`
`Other Search Options
`
`Browse Journals & Magazines > Spectrum, IEEE ...> Volume:36 Issue:8
`
`Back to Results
`
` Poison Java [data security]
`
`Full Text
`Sign-In or Purchase
`
`1
`
` Author(s)
`
` Chen, E. ; Trend Micro Inc., Tokyo,
` Japan
`
`Abstract
`
`Authors
`
`References
`
`Cited By
`
`Keywords
`
`Metrics
`
`Similar
`
`In this paper, the author argues that antidotes to malicious code are required above and beyond
` Java's own antigens if the programming language is to be immunized against security breaches
`
`Published in:
` Spectrum, IEEE (Volume:36 , Issue: 8 )
`
`Page(s):
` 38 - 43
`
`ISSN :
` 0018-9235
`
`INSPEC Accession Number:
` 6342111
`
`DOI:
`10.1109/6.780997
`
`Date of Publication :
` Aug 1999
`
`Date of Current Version :
` Tue Aug 06 00:00:00 EDT 2002
`
`Issue Date :
` Aug 1999
`
`Sponsored by :
`IEEE
`
`Publisher:
` IEEE
`
`http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=780997&newsearch=true&queryText=Poison%20Java[9/10/2015 3:54:26 PM]
`
`0004
`
`

`
`IEEE Xplore Abstract - Poison Java [data security]
`
`IEEE Account
`
` Purchase Details
`
` Profile Information
`
` Need Help?
`
`» Change Username/Password
`» Update Address
`
`» Payment Options
`» Order History
`» View Purchased Documents
`
`» Communications Preferences
`» Profession and Education
`» Technical Interests
`
`» US & Canada: +1 800 678 4333
`» Worldwide: +1 732 981 0060
`» Contact & Support
`
`
` Personal Sign In Create Account
`|
`
`
`About IEEE Xplore Contact Us
`|
`
`
`
`|
`
`Help
`
`
`|
`
`Terms of Use
`
`
`|
`
`Nondiscrimination Policy
`
`
`
`|
`
`Sitemap
`
`
`
`|
`
`Privacy & Opting Out of Cookies
`
` A not-for-profit organization, IEEE is the world's largest professional association for the advancement of technology.
`© Copyright 2015 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.
`
`http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=780997&newsearch=true&queryText=Poison%20Java[9/10/2015 3:54:26 PM]
`
`0005
`
`

`
`0006
`
`
`
`EXHIBIT B
`
`EXHIBIT B
`
`0006
`
`

`
`BE IMMUNIZED AGAINST
`
`SECURITY BREACHES
`
`EVA CHEN
`Trend Micro Inc.
`
`38
`
`00t8-9235/99/$to.oo©l999 IEEE
`
`IEEE SPECTRUM AUGUST 1999
`
`0007
`
`

`
`softvvare
`
`I N JUST FOUR YEARS, Java has taken the net(cid:173)
`
`worked world by storm. The rate of adoption of the
`programming language has broken all records, to the
`undoubted delight of its originator, Sun Micro(cid:173)
`systems Inc., Mountain View, Calif. Today there are
`hundreds of thousands of Java developers worldwide.
`In a recent study, Forrester Research Inc., Cambridge, Mass.,
`found that out of those Fortune I 000 companies who
`responded to the study's survey, 72 percent are planning to
`use Java as part of their software development.
`This avid interest is more than justified. Java does what
`no programming language has done before. It combines pow(cid:173)
`erful, object-oriented programming with the ability to run
`on any computer platform-Macintosh, Windows/lntel,
`Linux, and Solaris machines, as well as many others-with(cid:173)
`out the need for recompiling or translating. One result of its
`platform independence is that a scrap of code called a Java
`applet can be embedded in a World Wide Web page. When
`a user comes across a page while browsing the Web, the
`applet downloads with the page and automatically executes,
`regardless of the type of computer being used.
`The appeal is obvious. Web page designers who use]ava
`applets can produce a multiplicity of animated effects, adding
`movement and dimensionality to previously static pages.
`The stock prices that scroll across the bottom of a screen
`at some Web sites may owe their motion to Java. Less obvi(cid:173)
`ously, Java promises to play a yet more fundamental role in
`the future of on-line computing, including electronic com(cid:173)
`merce, for it can make powerful applications easy for anyone
`anywhere to access and use. It owes this facility to its ability
`to hop from computer to computer, for which reason it is also
`referred to as active content or mobile code.
`Nonetheless, programmers of all sorts-from the nefar(cid:173)
`ious hackers of the Chaos Computer Club in Hamburg,
`Germany, to serious software researchers at Princeton
`University in New Jersey-have demonstrated a dark side
`to Java. Malicious Java code has the power to delete or cor(cid:173)
`rupt files, monopolize system memory, and even forge e(cid:173)
`mail messages and send them out, if it is released in the wild
`(meaning not in the laboratory, but in the real world). And
`compared to other software with an evil bent, it can be much
`more surreptitious, entering the user's machine and activat(cid:173)
`ing itself without warning.
`
`A malicious taxonomy
`Computer viruses currently plaguing the corporate world
`are classified as a subset of the more generic class: malicious
`code. By definition, a virus is any code that not only has some
`unwanted effect on information resources (as does all mali(cid:173)
`cious code), but can also propagate by replicating itself. Self(cid:173)
`replication, the distinguishing characteristic of viruses, is what
`makes them so dangerous; without it, they would quickly
`die out. But because they can copy themselves into any com(cid:173)
`patible software-environment "host" with which they come
`in contact, they proliferate at an alarming rate.
`In a 1998 survey of the prevalence of computer viruses,
`the independent industry watchdog organization, Inter(cid:173)
`national Computer Security Association (ICSA) Inc., Reston,
`Va., found they had infected over 99 percent of large and
`mid-sized North American corporations. For the most part,
`those infections are due not to malicious Java applets but to
`
`macro viruses-viruses implemented using macro commands.
`Most often, the cause was a macro virus embedded in a Micro(cid:173)
`soft Word or Excel file attached to e-mail. The earlier macro
`viruses did not harm files but merely caused inconvenience
`(like locking up their prey's machine and so forcing a restart),
`but the latest variety can seriously damage systems.
`Self-replication is no longer the only way to prolifer(cid:173)
`ate. Every time someone accesses a Web page with Java code,
`the code is automatically downloaded and run. So now the
`Web can serve to propagate malicious code. The fact that
`malicious Java code is not yet rampant is no reason to ignore
`it, for history tells us it will start sacking and looting. The
`evolution of the virus threat has mirrored the evolution of
`people's computing habits: as the desktop computer evolved
`from a computing into a communication tool, the means
`of spreading malicious code shifted, too [Fig. 1].
`
`Promise and threat
`To repeat, the power of Java lies in its platform indepen(cid:173)
`dence. Any possessor of a Java-enabled Web browser, such as
`Internet Explorer or Netscape Navigator, can indulge in Java
`applets, regardless of the computer hardware or operating
`system to hand. Platform independence brings with it the
`capacity for a high degree of customization, since users can
`interactively tailor the software to meet their specific needs.
`But interactivity can work both ways. A Java program res(cid:173)
`ident on a Web server can run on a user's computer and access
`whatever information about the setup will enable it to per(cid:173)
`form its job efficiently and without any action on the part of
`the user. HouseCall, a Java-based virus checking service that
`can be accessed free of charge from Trend Micro Inc.'s Web
`site (http://housecall.antivirus.corn!), illustrates such capability.
`HouseCall is able to remotely scan and remove any viruses
`present on the workstation of someone visiting the site. When
`the workstation user selects the scan option on the Web page,
`the server downloads a Java applet that accesses whatever
`workstation computing resources (central processor, memory,
`operating system, hard disk, network connections, or other
`system assets) it needs to complete its task.
`While Java is the most prominent language for develop(cid:173)
`ing such active content, or mobile code, it is not unique.
`Microsoft ActiveX controls [see "Another option in mobile
`code," p. 41] and Netscape JavaScript are also widely used.
`Lesser-known active code languages include Safe-Tel, Tele(cid:173)
`script, Word macros, and Excel macros.
`Active code is highly attractive to businesses. Huge produc(cid:173)
`tivity gains can be realized from the powerful, highly cus(cid:173)
`tomized business system applications based on active con(cid:173)
`tent now being developed and deployed. Today, businesses
`are using active content to host secure on-line banking, secu(cid:173)
`rities trading, and electronic shopping, as well as collabo(cid:173)
`rations on inter-company projects. Active content applica(cid:173)
`tions are starting to streamline transactions and collaborations
`between business partners and their diverse customers.
`Businesses are using the public Internet, private intranets,
`and private, secure extranets for these tasks.
`But active content, with its ability to make free use of a
`computer system's resources over the Internet, can be a
`double-edged sword. To perform any useful local process(cid:173)
`ing, active content must reach deep into local computers.
`There, it can perpetrate such "crimes" as erasing data stored
`
`39
`
`0008
`
`

`
`on hard disks or surreptitiously copying and
`transmitting data to eavesdropping third
`parties, just as readily as it can facilitate pro(cid:173)
`ductive collaboration or transactions.
`Security managers at large companies,
`while aware of the dangers implicit in Java
`[Fig. 2], for the most part are doing little
`about it. They allow Java applets to enter
`their network unchecked, and do not even
`use software to alert them to the applets'
`entry into their domain. Nor has the release
`of Java 2 last December, with its highly
`touted security model, done much to quell
`such security concerns because of the com(cid:173)
`plexity of implementing it.
`Even though malicious applets are as yet
`few and far between, prudent managers will
`take action now. Recent history has shown
`that tardiness in responding to new secu(cid:173)
`rity threats is costly. Firms unprotected
`against the most recent macro virus infec(cid:173)
`tions have incurred major costs in recover(cid:173)
`ing from an attack and from reduced
`employee productivity.
`Stephen Cobb, director of special pro(cid:173)
`jects for the ICSA, said, 'The situation is
`scary. Enterprise IT [information technol(cid:173)
`ogy] managers ... have to set up policy now
`to prevent users from downloading malicious
`applets and viruses." Most analysts agree that
`malicious code will become a widespread
`
`[1] Back in the seventies, before the surge
`in Internet use, viruses were passed
`around by floppy diskettes.
`Next, as programs (that is, executable
`code) became ever more available online
`for downloading, viruses spread by repre(cid:173)
`senting themselves as legitimate software.
`Then, along with increased use of
`e-mail came viruses attached to e-mail
`messages as supposedly nonexecutable
`files, such as Microsoft Word files.
`With the rise of Java, Web sites and
`Web pages attached to e-mail are becom(cid:173)
`ing the way to spread malicious code.
`
`Changing modes of
`malicious code transmission
`
`problem, although they disagree on when
`this will occur. On the other hand, most
`security consultants do, like Cobb, recom(cid:173)
`mend implementing supplemental Java secu(cid:173)
`rity sooner rather than later.
`
`Attack categories
`The attacks Java applets could facilitate
`fall into four categories, namely, those that:
`• Modify the system.
`• Invade a user's privacy.
`• Deny legitimate use of the machine by
`hogging resources.
`• Antagonize a user.
`Of these, system modification is the most
`damaging. This class of attack includes sur(cid:173)
`reptitious alteration of financial records
`(which can lead to financial loss) or tam(cid:173)
`peringwith medical records (which can lead
`to fatally incorrect treatment). As yet,
`though, the Java-based variety of this attack
`has not been seen outside the laboratory.
`In contrast, examples of the other three
`classes of malicious applets are readily avail(cid:173)
`able. In fact, a large collection of them, com(cid:173)
`plete with source code, is posted on a cer(cid:173)
`tain Web site; in July 1998, malicious applets
`from this site were used to launch a real
`attack that could affect anyone using
`Netscape browser versions 4.04 and 4.05.
`(Note that IEEE Spectrum chooses not to list
`the name or universal resource locator of
`sites that contain malicious applets.)
`Perhaps the most disturbing malicious
`applets in the wild are those that forge
`mail-a form of privacy invasion. The
`applets can actually compose an e-mail mes(cid:173)
`sage and send it to everyone on someone's
`address list, posing as that individual.
`Clearly, this could expose that person to a
`wide range of risks, depending on the con(cid:173)
`tent of the e-mail. For example, sending e(cid:173)
`mail to the White House threatening the
`life of the President is a felony, yet it is well
`within the powers of a relatively simple
`malicious applet.
`Forging such e-mail is neither particularly
`
`complex nor hard to do. A knowledge of
`e-mail protocols is the sole requirement. By
`allowing users to state their identity any way
`they like and omitting to authenticate an
`identity, browsers make forgery even easier.
`Defense against e-mail forgery is quite dif(cid:173)
`ficult in Java, while an even greater peril, as
`more people use systems for commerce and
`personal information, is the theft of private
`personal and corporate information.
`Denial of service is the most usual of Java
`applet crimes. It encompasses everything that
`ties up computing resources, preventing vic(cid:173)
`tims from doing what they want to do. Like
`e-mail forgery, denying service is little trou(cid:173)
`ble to implement in an applet, but is a lot of
`trouble to prevent. Applets of this kind
`posted on the Web include code that swal(cid:173)
`lows up all a machine's memory, or opens
`numerous windows, or consumes processor
`power, so that a Web browser shuts down.
`Finally, applets that antagonize the Web
`user are basically annoyances, whether the
`playing of incessant sounds or the display of
`pornography. One humorous applet now in
`the wild displays a dialog box that says, "April
`Fools." When its recipient attempts to re(cid:173)
`move it by clicking on the OK button, the
`box jumps around the screen, evading the
`mouse cursor. (Exiting the browser is the sim(cid:173)
`plest way to close this dialog box.) Several
`other applets in this category are posted on
`the Web on, for instance, Mark LaDue's
`Hostile Applets Home Page (http://www.
`rstcorp.comlhostileappletslindex.html).
`
`Java security
`Most industry experts agree that threats
`from malicious code cannot be prevented
`by traditional security measures, such as fire(cid:173)
`walls and data encryption. A certain amount
`of security is inherent in Java, but two prob(cid:173)
`lems remain.
`To begin with, there is the problem of
`getting security holes patched. The various
`Web browsers (Netscape Navigator, Net(cid:173)
`scape Communicator, and Internet Explorer,
`
`Web pages in e-mail A_ .. · } Malicious
`
`W
`Java applets
`andother
`active code
`
`Web browsing
`
`•
`
`E-mail
`
`Macro viruses
`-in e-mail
`attachments
`
`1975
`
`'80
`
`'85
`
`'90
`
`'95
`
`2000
`
`40
`
`IEEE SPECTRUM AUGUST t 999
`
`0009
`
`

`
`Another option in mobile code
`
`W hile Java is by far the most popular Web-based mobile
`
`code or active content, there are others, and each
`poses its own challenges. Most often mentioned after
`Java are Microsoft's ActiveX controls, which have similar capa(cid:173)
`bilities to Java applets but a distinctly more limited security
`model. In fact, security professionals have criticized ActiveX for
`its weak approach to this matter.
`ActiveX relies solely on the trust-based approach of digital
`code signing, using Microsoft Authenticode. Al~hough each mod(cid:173)
`ification to an ActiveX control in the wild must be re-certified
`with Authenticode, no checking or testing for malicious coding
`is done in any of the certification processes. Hence, the certifi(cid:173)
`cation is not an endorsement of the code's function or intent.
`It all boils down to clients choosing whom they trust to produce
`virus-free programs, that is, ActiveX controls.
`
`This determination is a rough one to make, and varies
`from individual to individual within a company. Many
`users, already accustomed to clicking "continue" on
`every warning message they receive on the Web, simply accept
`all controls regardless of the consequences.
`What's more, compared to malicious Java applets, malicious
`ActiveX controls are perceptibly the greater threat because of
`how ActiveX is designed. When an ActiveX control passes
`through a list of acceptable digital signature sources, it does so
`unfettered by the sandbox that Java imposes on its applets.
`Nonetheless, one way of warding off malicious ActiveX con(cid:173)
`trols is to use software that checks the controls' certificates and
`compares them with the list of recognized certificates in the
`Microsoft Internet Explorer database. All unsigned controls and
`controls not carrying recognized certificates can then be
`blocked. As Internet Explorer's default certificate database is
`modifiable, it frees administrators to selectively accept or reject
`any ActiveX controls
`-E. C.
`
`among others) implement Java in different
`ways. Accordingly, different security flaws
`have been identified in the specific versions
`of these browsers. Browser makers typically
`hurry to fix security bugs and make updated
`browsers or patches available to users on their
`Web sites. Unfortunately, many Web users
`fail to download these fixes, thus becoming
`vulnerable to malicious code, which may
`even determine the type of browser they are
`using and tailor its attack to that type.
`The second problem is that implement(cid:173)
`ing a coherent security policy on malicious
`applets is an obstacle-ridden and time-con(cid:173)
`suming task. This is true even for the most
`recent release, Java 2. Many companies
`
`therefore relegate policy management to
`users, leaving it to them to determine, say,
`which kinds of applets should be allowed.
`Inevitably, implementation of security pol(cid:173)
`icy then becomes inconsistent.
`The reason why setting up policy for Java
`is complex is that Java security evolved in a
`complex fashion. Security issues raised by
`active code can be addressed by system ad(cid:173)
`ministration with so-called sandboxes and
`with digital signatures. As Java evolved, both
`approaches made their way into its security
`model, so that today, Java security is a hyb(cid:173)
`rid of these techniques [Fig. 3].
`A sandbox is a software "box" where code
`of unknown origin (untrusted code) can be
`
`Are you concerned about Java
`and ActiveX security?
`
`Do you allow Java or ActiveX
`to enter your network?
`
`No-8%
`
`No-28%
`
`Yes-92%
`
`Yes-72%
`
`Where do you scan Java and ActiveX code?
`
`56%
`
`31%
`
`6%
`
`8%
`
`Application
`server
`
`Desktop
`computer
`
`Firewall
`
`Don't scan
`
`Source: Forrester Research Inc.
`
`CHEN- POISON JAVA
`
`run. Untrusted code may be all code that
`comes from outside a company, which con(cid:173)
`siders only code from its internal Web server
`trustworthy, or it may also freely allow code
`from the Web sites of companies with excel(cid:173)
`lent security reputations.
`The sandbox places tight controls on what
`the code may do. One component of the
`sandbox security model in Java 1.0.2 is the
`security-manager code module, which is very
`strict about access to local files, including file
`operations such as read, write, and delete. But
`constraining the access of each and every
`Java applet, with no provision for exceptions,
`would cause a problem. A user may want
`some trusted applets to have more access to
`system resources than is allowed in the sand(cid:173)
`box so that they may benefit the system, per(cid:173)
`haps by searching a hard disk for viruses and
`removing any they find.
`Java 1.1, released in the early spring of
`1997, attempted to address this limitation
`by incorporating the digital signature meth(cid:173)
`od into its security model. Digital signatures
`are a form of encryption where binary files
`are encoded with a digital code, or signa(cid:173)
`ture, unique to a developer, distributor, or
`certifier. Because a digital signature has spe(cid:173)
`cial mathematical properties, it is next to
`impossible to decipher and, hence, to forge.
`Using this technology, a Java applet can be
`digitally signed [see "Digital signing," p. 42].
`The idea is that the user decides whom to
`trust. For example, a company may opt to
`
`[2) While all but a few of the Fortune 1000
`security managers responding to a 1998 survey
`by Forrester Research Inc., Cambridge, Mass.,
`were concerned about the threat to security
`from Java and ActiveX code [top, left,] less
`than a third are blocking such software from
`entering their networks [top, right). Few com(cid:173)
`panies even look for such code, and those that
`do merely use a firewall to check only if the
`applet has a valid digital signature [bottom).
`
`41
`
`0010
`
`

`
`accept only applets signed by someone on
`a specific list it develops. All applets signed
`by someone not on the list (and unsigned
`applets) will not be allowed to run freely and
`relegated to the sandbox. This is the essence
`of Java 1.1 security.
`Many security administrators are skepti(cid:173)
`cal that a digital signature capability alone
`can implement a security policy for Java.
`Recent Forrester research showed that only
`20 percent of survey respondents felt that
`code signing would fully safeguard their sys(cid:173)
`tems. What seems to be missing is access
`control capabilities. Java 1.1 can either accept
`code or relegate it to the sandbox based on
`who signed it; but finer control over what
`each applet can access is needed to provide
`the flexibility administrators are demanding.
`Released last December, Java 2 is Sun
`Microsystems' response to these needs. Java
`2 's fine-grained access control allows code
`with proper permissions to gradually step
`outside the sandbox's constraints, with the
`system administrator granting different
`degrees of privilege to different programs.
`
`Digital signing
`
`Public-key cryptography is the basis
`
`for the digital signatures used in
`Java code. In this method, the
`developer of the code runs a special
`algorithm to generate two large num(cid:173)
`bers-a private key and a public key.
`The developer uses the secret private
`key to digitally sign code, that is,
`encrypt it, and everyone else uses the
`public key to verify this signature.
`Since the private key is kept secret,
`only the developer can use it to put a
`signature on code. Conversely, since
`everyone knows the developer's public
`key, everyone can verify that the signa(cid:173)
`ture on an applet is the developer's.
`More specifically, everyone's browser
`can compare the developer's registered
`public key to the signed applet,
`enabling the browser to reject the
`applet if it is not from the developer.
`Further, an independent third-party
`company whose reputation for hon(cid:173)
`esty has been established is used to cer(cid:173)
`tify that developers are who they say
`they are. The certification authority
`(CA), as the company is called, prevents
`the forgery of digital signatures on
`applets. The CA first verifies a devel(cid:173)
`oper's identity in person and issues that
`person an electronic credential. The
`developer then attaches a copy of this
`credential to each signed applet. As a
`result, the recipient of an applet can
`first electronically check the devel(cid:173)
`oper's credential and then check the
`digital signature.
`-E. C.
`
`42
`
`With such access control, theoretically,
`administrators could implement security
`policies under which certain applets may
`take certain actions that will be beneficial.
`For example, an administrator could set up
`a configuration allowing a certain applet to
`read and write files in a particular directory
`and connect to any host in a given domain.
`But Java 2 security has an Achilles' heel.
`According to Gary McGraw and Edward
`W. Felten in Securing Java, Getting Down to
`Business with Mobile Code [see To Probe Further,
`p. 43], the idea of Java 2 security may be
`simple, but in practice creating a coherent
`policy is quite difficult. They assert that "set(cid:173)
`ting up a coherent policy [using Java 2] at
`a fine-grained level takes experience and se(cid:173)
`curity expertise. Today's harried system ad(cid:173)
`ministrators are not likely to enjoy this
`added responsibility. On the other hand,
`if policy management is left up to users, mis(cid:173)
`takes are bound to be made." In other words,
`some sort of tool is needed to ease the task
`of configuring servers to enforce a com(cid:173)
`pany's Java security policy.
`
`Client- versus server-side security
`So what actions do security managers
`need to take? Not one measure but a com(cid:173)
`bination is needed to reduce the risk that
`Java applets will breach security.
`Defenses against the security threat of
`Java applets run the gamut of client-side and
`server-side options. The most obvious client(cid:173)
`side solution-and most draconian-is to
`disable Java altogether at each workstation.
`With Netscape Navigator, for example, users
`need only select Security Preferences from
`the Options menu and click on the Disable
`Java box. But this wholesale approach frus(cid:173)
`trates users grown accustomed to the added
`dimensionality of Java applets. As the applets
`move more and more to center stage on
`Web pages, disabling them eliminates some
`applications of value to users.
`Client-side solutions include the Safe(cid:173)
`Agent program from the unusually named
`Security-7 (software) Ltd., Woburn, Mass.
`They plug into the Web browser at the work(cid:173)
`station and do various sorts of screening and
`applet signature checking. That takes both
`the load off the server and the brakes off the
`Internet traffic. At the same time, client-side
`protection often provides real-time moni(cid:173)
`toring, of the kind offered by SurfinShield
`Xtra from Fin jan Inc., San Jose, Calif.
`From the system administrator's view(cid:173)
`point, client-side solutions have limitations.
`Requirements that Java be disabled by var(cid:173)
`ious users are hard to enforce companywide,
`and they carry more management overhead.
`Also, dumping difficult decisions on secu(cid:173)
`rity issues in the client's lap results in secu(cid:173)
`rity becoming inconsistent.
`These drawbacks are addressed by the
`alternative to client-based solutions: server(cid:173)
`based security. Analyst Ira Machefsky of
`
`Giga Information Group Inc., Cambridge,
`Mass., stated in a 1996 report that he be(cid:173)
`lieves sites should move to server-based
`security mechanisms whenever possible, be(cid:173)
`cause the latter can save on system overhead
`and enhance the quality and auditworthi(cid:173)
`ness of an active-component security policy.
`Indeed, server-based solutions are single(cid:173)
`point implementations of a security policy
`that users cannot subvert at their desktop.
`For example, at the gateway to a protected
`network, Fin jan's SurfinGate inspects Java
`code using a process that emulates the code's
`likely actions. The process assigns a unique
`ID and applet profile to the code, noting
`any possible security breaches, according
`to Finjan.
`This type of protection, while readily
`deployed and managed, can also place a
`heavy load on the server and can slow
`Internet traffic. And while an emulation
`process like this one can model many likely
`applet actions, it cannot model all of them.
`That loophole may set an applet at liberty
`to undertake unmodeled and potentially
`malicious actions.
`
`Hybrid help
`A hybrid solution to supplementing Java
`security was recently released by the author's
`company, Trend Microsystems Inc. Called
`lnterScan AppletTrap, the software integ(cid:173)
`rates elements of both client- and server(cid:173)
`based solutions [Fig. 4]. It employs a proxy
`server, one that acts as an agent for the
`server to prevent an attack on the security
`software. Using the proxy, AppletTrap first
`weeds out unwanted applets as HTML
`pages are downloaded, checking to see
`whether the applet is on a list of those to be
`blocked out. To check the applet, the pro(cid:173)
`gram uses the 32-bit MD5 message-digest
`algorithm (created by Ronald L. Rivest of
`the Massachusetts Institute of Technology,
`best known as a co-inventor of the RSA
`public-key cryptography system) to create
`a hash code of the applet, which it compares
`to those on its list. Any applets found on the
`list are at once discarded. Next, the software
`runs a certificate check on the applets and
`blocks any that are unsigned, signed by an
`unrecognized certificate authority [see "Digi(cid:173)
`tal signing," this page], or signed with a sig(cid:173)
`nature that does not match its content.
`After this prefiltering, applets with calls
`to system resources are prepared for more
`thorough examination. The preparation pro(cid:173)
`cess is referred to as instrumentation. During
`it, AppletTrap wraps monitoring code around
`the applet and attaches the security policy
`that determines what system resources it can
`access. Depending on how AppletTrap is
`configured, this security policy can vary from
`one intended recipient to another.