Juniper Ex. 1009-p. 1
`Juniper v Finjan
`
`

`

`Juniper Ex. 1009-p. 2
`Juniper v Finjan
`
`

`

`
`
`
`
`
`
`EXHIBIT A
`
`Juniper Ex. 1009-p. 3
`Juniper v Finjan
`
`

`

`8/2/2018
`IEEE.org
`
`|
`
`
`|
`
`IEEE Xplore Digital Library
`
`
`|
`
`Mobile code security by Java bytecode instrumentation - IEEE Conference Publication
`IEEE-SA
`
`IEEE Spectrum
`
`More Sites
` Cart(0)
`
`Create Account
`|
`|
`|
`
`|
`
`
`|
`
` Personal Sign In
`
` Back to Results
`
`Related Articles
`
`Analysis of potential deadlock in Java
`multithreaded object-oriented programs
`
`A Teaching Path for Java Object
`Oriented Programming
`
`JR: flexible distributed programming in
`an extended Java
`
`View All View All
`
`Access provided by:
`IEEE Staff
`Sign Out
`
`
`
`Browse
`
`My Settings
`
`Get Help
`
`Browse Conferences > Proceedings DARPA Information...
`
`Mobile code security by Java bytecode instrumentation
`
` << Results
`
`View Document
`
`11
`Paper
`Citations
`
`18
`Patent
`Citations
`
`164
`Full
`Text Views
`
`3
`Author(s)
`
`A. Chander J.C. Mitchell I. Shin
`
` A. Chander ; J.C. Mitchell ; I. Shin
`
`View All Authors
`
`Abstract
`
`Authors
`
`Figures
`
`References
`
`Citations
`
`Keywords
`
`Abstract: Mobile code provides significant opportunities and risks. Java bytecode is used to provide executable
`content to Web pages and is the basis for dynamic service configuration in the Jini framework. While the Java
`Virtual Machine includes a bytecode verifier that checks bytecode programs before execution, and a bytecode
`interpreter that performs run-time tests, mobile code may still behave in ways that are harmful to users. We
`present techniques that insert run-time tests into Java code, illustrat... View more
`
` Metadata
`Abstract:
`Mobile code provides significant opportunities and risks. Java bytecode is used to provide executable content to
`Web pages and is the basis for dynamic service configuration in the Jini framework. While the Java Virtual
`Machine includes a bytecode verifier that checks bytecode programs before execution, and a bytecode
`interpreter that performs run-time tests, mobile code may still behave in ways that are harmful to users. We
`present techniques that insert run-time tests into Java code, illustrating them for Java applets and Jini proxy
`bytecodes. These techniques may be used to contain mobile code behavior or, potentially, insert code that is
`appropriate to profiling or other monitoring efforts. The main techniques are class modification, involving
`subclassing non-final classes, and method-level modifications that may be used when control over objects from
`final classes is desired.
`
`Published in: Proceedings DARPA Information Survivability Conference and Exposition II. DISCEX'01
`
`Date of Conference: 12-14 June 2001
`
`INSPEC Accession Number: 6991891
`
`Date Added to IEEE Xplore: 07 August 2002
`
`DOI: 10.1109/DISCEX.2001.932157
`
`Print ISBN: 0-7695-1212-7
`
`Publisher: IEEE
`
`Conference Location: Anaheim, CA, USA, USA
`
` Contents
`
` Contents
`
`
`
`Full Text
`
`https://ieeexplore.ieee.org/document/932157/
`
`1/20
`
`Juniper Ex. 1009-p. 4
`Juniper v Finjan
`
`

`

`8/2/2018
`
`Mobile code security by Java bytecode instrumentation - IEEE Conference Publication
`
` Download
`PDF
`
` Download PDF
`
` Download Citation
`
`View References
`
` Email
`
` Print
`
` Request Permissions
`
` Alerts
`
` Download Citation
`
`View References
`
` Email
`
` Print
`
` Request
`
`Permissions
`
` Alerts
`
`Authors
`
`References
`
`Citations
`
`Keywords
`
`Related Articles
`
`Footnotes
`
`Back to Top
`
`SECTION 1.
`Introduction
`
`Since its early beginnings in the Green project, the Java
`language [26] has come a long way in its applicability and
`prevalence. While its initial adoption was fuelled by the ability
`to add “active content” to web pages, Java has also become a
`predominant system and application development language,
`providing useful capabilities over and above the language
`features through an extensive set of application programming
`interfaces (APIs). The APIs' simplify programming by
`providing a rich set of domain-dependent libraries, as well as
`enabling new programmatic and computational paradigms. As
`an example, the Java Cryptography API makes it possible for
`applications to easily implement security protocols for their
`own needs, while the Jini API provides a specification for Java
`bytecode based distributed programming. One of the keys to
`Java's success and appeal is its platform independence,
`achieved by compilation of source code to a common
`intermediate format, namely Java Virtual Machine (JVM)
`bytecode, which can then be interpreted by various platforms.
`The ability to transport byte code between JVMs is most
`commonly encountered while browsing the net, and Java's
`platform independence ensures a client-independent
`experience.
`
`Although previous language implementations, such as Pascal
`and Smalltalk systems, have used intermediate byte code, the
`use of bytecode as a medium of exchange places Java bytecode
`in a new light. A networked computer can import and execute
`Java bytecode in ways that are invisible or partly invisible to
`the user. For example, a user (or his browser) may execute a
`Java applet embedded within a page as part of the HTIP
`protocol, or a client may execute a lookup service proxy as it
`prepares to join a Jini community. To protect against execution
`of erroneous or intentionally malicious code, the JVM verifies
`bytecode properties before execution and performs additional
`checks at run time. However, these checks only enforce some
`type correctness conditions and basic resource access control.
`For example, these tests will not protect against large classes of
`undesirable run-time behavior, including denial-of-service,
`compromise of integrity, and loss of sensitive information from
`password or credit card information files, say. The introduction
`of new security architectures [8] for Java has allowed for digital
`signature verification and resource access control through the
`
`https://ieeexplore.ieee.org/document/932157/
`
`2/20
`
` Export to
`
`Collabratec
`
` Export to Collabratec
`
`Juniper Ex. 1009-p. 5
`Juniper v Finjan
`
`

`

`8/2/2018
`
`Mobile code security by Java bytecode instrumentation - IEEE Conference Publication
`
`Permissions framework, but suffers from lack of specificity. A
`more expressive and fine-grained mechanism which can be
`customized to a user's security needs and is flexible enough to
`respond to security holes as they are discovered, is needed.
`
`The goal of our work is to develop methods for enforcing
`foreign bytecode properties, in a manner that may be
`customized easily. In this paper, we propose a technique, called
`bytecode instrumentation, through which we impose
`restrictions on bytecode by inserting additional instructions
`that will perform the necessary run-time tests. These additional
`instructions may monitor and control resource usage as well as
`limit code functionality. This. approach is essentially a form of
`software fault isolation [24], tailored to the file structure and
`commands of the Java language. Our technique falls into two
`parts: class-level modification and method-level modification.
`Class-level modification involves substituting references to a
`class by another class subclassed from it. As this method
`employs inheritance, it. can not be applied to final classes and
`interfaces. In these cases, method-levelmodification; which-
`may be applied on a method-by-method basis without regard to
`class hierarchy restrictions, enforces the ‘safe behavior that we.
`hope from foreign code.
`
`We have implemented these techniques within two contexts,
`each of which has a different bytecode delivery path. - For the
`case of Java applets transported via the HTTP protocol,
`instrumentation is done by a network proxy, which:in addition
`can also function as a Gl. Il-customizable firewall to specific
`sites, Java classes, and tagged advertisements, For Jini service
`proxies, for which there are only transport _ interfaces but no
`specific transport. mechanisms; we chose to modify the
`bytecode at the client's ClassLoader end, before its execution.
`Figures 5 and 6 summarize the system architecture for these
`two cases.
`
`The rest of the paper is. organized as follows. Section 2 gives
`examples of mobile code risks which cannot be checked within
`the scope of the current Java verifier and security model, and
`discusses. the extent of our technique. The bytecode
`instrumentation technique itself is presented in Section 3.
`Section 4 explains. how the mobile code transport frameworks
`for Java applets and Jini proxies are augmented to instrument
`the component bytecodes. Section 5 presents examples of the
`techniques presented, in Section 3, with one illustrative
`example for each of class-level and method-level modification.
`We make comparisons with existing work in Section 6, and
`conclude in Section 7.
`
`SECTION 2.
`Mobile Code Risks
`
`We preface our techniques for enforcing Java bytecode
`properties by examples of harmful behavior to illustrate the
`risk associated with untrusted mobile code. While these attacks
`have been around for a while, recent interest in peer to peer
`computing has added value to individual machine cycles,. and
`one may presume, incentive to deploying mobile code attacks.
`
`https://ieeexplore.ieee.org/document/932157/
`
`3/20
`
`Juniper Ex. 1009-p. 6
`Juniper v Finjan
`
`

`

`8/2/2018
`
`Mobile code security by Java bytecode instrumentation - IEEE Conference Publication
`
`The categorisations' below should be taken only as indicative,
`and not exhaustive. We situate the extent of our techniques
`w.r.t, the various kinds of attack threats posed by mobile code;
`Section 5 presents more detail for specific examples.
`
`2.1. Denial of Service
`The current Java security model provides a Permissions
`framework to specify the host resources that mobile code may
`access. However, the extent of use is not monitored, and code
`which has legitimate use for a certain resource, say the screen,
`or the audio driver, may abuse this privilege. The system may
`be rendered useless by greedy techniques: monopolizing and
`stealing CPU time, grabbing all available system memory, or
`starving other threads and system processes. Many variants on
`this' theme exist, a common scheme is for the foreign code to
`spawn ‘a “resource consuming” thread. The runaway thread
`redefines its stop method to execute a loop and effects an
`“infinite access” to the resource, which may result in annoying
`to crippling behavior, for example through screen flooding.
`Often a complete browser or system shutdown becomes the
`only viable, option.
`
`Since the safety of Java runtime system may be threatened by
`inordinate system resource use, it is useful to have some
`mechanism to monitor and control resource ‘usage.
`
`2.2. Information Leaks
`
`An applet may subvert its constrained channels of information
`flow through various means. A possible third-party channel is
`available with the URL redirect feature. Normally, an applet
`may instruct the browser to load any page on the web. An
`attacker's server could record the URL as a message, then
`redirect the browser to the original destination [5]. Another
`scenario exploits the ability of an applet to send out email
`messages [10]. If the web server is running an SMTP mail
`daemon, a hostile applet may forge email after connecting to
`port 25.
`
`Time-delayed access to files also can be used as a covert
`channel [19]. Specifically, if mobile code fragment
`, with
`access to private information is prohibited from accessing the
`net, information can still be sent out by another, mobile code
`fragment
`, which shares a file with
`. Inter code
`communication via storage channels may be detected by
`system logs, but these are hard to analyze in real time.
`
`It is generally accepted that theoretically feasible covert
`channels like refreshing a page at uneven time intervals to
`transmit a sequence of bits, are hard to detect. We ignore such
`arbitrary and unpredictable information channels, while using
`our techniques to plug more tractable pathways as in the case
`of email forgery.
`
`2.3. Spoofing
`
`In a spoofing attack, an attacker creates a misleading context in
`order to trick a user into making an inappropriate security-
`relevant decision [7]. For example, some applets display URLs
`as the mouse navigates over various components of a web page,
`like a graphic or a link. By convention, the URL is shown in a
`specific position on the status line. If an applet displays a fake
`URL the user may be misled into connecting to a potentially
`
`https://ieeexplore.ieee.org/document/932157/
`
`4/20
`
`Juniper Ex. 1009-p. 7
`Juniper v Finjan
`
`A
`B
`A
`

`

`8/2/2018
`
`Mobile code security by Java bytecode instrumentation - IEEE Conference Publication
`URL, the user may be misled into connecting to a potentially
`hazardous website. It is also possible to abuse weaknesses in
`mobile code-fetch conventions to spoof the real place of origin
`of a code fragment, laying client-side security policies
`regarding network connections to naught.
`
`Bytecode instrumentation is an effective technique against
`well-specified attacks, which include denial of service and
`information leaks via specific pathways. In this sense, its scope
`is monotonic; newly discovered attack specifications can be
`added to a client's policy files and any additional bytecodes that
`match them can be instrumented to enforce safety properties.
`The reader may like to think of this in virus checking terms,
`where the safety net widens with addition of new entries in the
`virus signature files. Byte code instrumentation thus allows for
`content-based protection, since the modification is a function
`of the bytecode and the client's safety policy.
`
`We now move on to the technical details of our scheme.
`
`SECTION 3.
`Bytecode Instrumentation
`
`Our goal is to design a safety mechanism for Java byte code
`that extends the signature based security manager with user-
`controlled content-based control. The basic idea is to restrict
`bytecode by the insertion of sentinel code. In the examples we
`have implemented and tested, sentinel code may monitor and
`control resource usage as well as limit functionality. This
`approach is a form of software fault isolation [24], adapted to
`the specific structure and representation of Java bytecode
`programs.
`
`Our safety mechanism substitutes one executable entity, such
`as a class or a method, with a related executable entity that
`performs additional run-time tests. For instance, a class such
`as Window can be replaced with a more restrictive class
`Safe$Window that performs additional security and sanity
`checks. This replacement must occur before the transported
`bytecode is loaded within the JVM of the client, and we achieve
`this at different points in the transport path in our experiments
`with Java applets and Jini proxies (see Section 4). Note that we
`will use the prefix SafeS to indicate a safe class.
`
`The following sections explain how modified executable entities
`are inserted in Java bytecode. The modifications may be
`performed at the level of the class or the method, by modifying
`the constant pool to replace references to substituted entities
`by their safe substitutes.
`
`3.1. Class-level Modification
`
`A class such as Window can be replaced with a subclass of
`Window (say Safe
`
`constructor can limit the number of windows that can be open
`at one time, by calling Window's constructor, and raising an
`exception when the number of windows opened currently
`(stored as a private variable in the method) exceeds the limit.
`Since Safe$Window is defined to be a subclass of Window, the
`
`https://ieeexplore.ieee.org/document/932157/
`
`5/20
`
`Juniper Ex. 1009-p. 8
`Juniper v Finjan
`
`W indow)thatrestrictsresourceusageandf unctionality. F orexam
`

`

`8/2/2018
`
`Mobile code security by Java bytecode instrumentation - IEEE Conference Publication
`
`applet should not notice the change, unless it attempts to create
`windows exceeding the limit.
`
`This class substitution is done by merely substitut-.ing
`references to class Window with references to class Safe
`Window is a subtype of Window, type
`Safe$Window can be used anywhere type Window is expected.
`
`In Java, all references to strings, classes, fields, and methods
`are through indices into the constant pool of the class file [16].
`Therefore, it is the constant pool that should be modified in a
`Java class file. More specifically, two entries are used to
`represent a class in the constant pool. A constant pool entry
`tagged as CONSTANT_Class represents a class while
`referencing a CONSTANT _Uft8 entry for a UTF-8 string
`representing a fully qualified name of the class, as in figure 1.
`
`If we replace a class name of a CONSTANT. Uft8 entry,
`Window, with a new class name, Safe
`
`as shown in figure 2.
`
`Substituting a class requires just one modification of a constant
`pool entry representing a class name string. This is
`straightforward since a subclass may appear anywhere a
`superclass is used without any modifications to the program.
`However, this approach cannot be applied to a final class or an
`interface class.
`
`3.2. Method-level Modification
`In class-level modification, the basic idea is to substitute a
`potentially harmful method (for example, those that provide
`direct access to system resources) with a safer version that
`provides for customized control. Unlike class-level
`modification, however, there is no relationship between the two
`methods. This provides more flexibility in that it can be used
`even when the method is final or is accessed through an
`interface, but requires more modifications than a simple
`substitution of methods.
`
`Figure 1. Class references in the constant pool
`
`Figure 2. Modfying class references
`
`https://ieeexplore.ieee.org/document/932157/
`
`Before getting into the general mechanism, let us consider a
`fi ld
`d
`h d d
`i
`i hi
`h
`l
`fil
`f
`
`6/20
`
`Juniper Ex. 1009-p. 9
`Juniper v Finjan
`
`W indow. W henS af e
`W indow, theCON S T AN lassentrywillrepresentthenewclass, S
`T
`C
`

`

`8/2/2018
`
`Mobile code security by Java bytecode instrumentation - IEEE Conference Publication
`field and a method descriptor within the Java class file format.
`The field descriptor represents the type of a class or instance
`variable. For example, the descriptor of an int instance variable
`is simply I. Table 1 shows the meaning of some field
`descriptors.
`
`Table 1. The meaning of the field & method descriptors
`
`The Method descriptor represents the parameters that the
`method takes and the value that it returns. A parameter
`descriptor represents zero or more field types, and a return
`descriptor a field type or v. The character V indicates that the
`method returns no value(void). For example, the method
`descriptor for the method
`
`is
`
`We will describe an instance method in the form <ClassName.
`MethodNameAndType> and an class(static) method in the
`form <ClassName: MethodNameAndType>, to distinguish
`them, though they are not distinguished in the constant pool.
`
`A method such as Thread.setPrioritY(I)V can be replaced with
`a safer version, say Safe
`
`The new safeguarding method takes priority of type integer as
`one of the arguments, and compares it with its upper limit. If
`the argument is higher, the argument is set to the upper limit.
`Eventually, the new method invokes Thread.setPrioritY(I) V
`with the verified argument. Since the new method invokes an
`instance method mentioned before, a reference to an instance
`of class Thread should be passed to the new method.
`
`3.2.1 Method Reference Modification
`It is more difficult to represent a method than a class;
`consequently the bytecode: modification procedure for
`methods is more involved. A constant pool entry tagged as
`CONSTANT. Methodref represents a method of a class(a static
`method) or of a class instance(an instance method). The
`CONSTANT_Class entry representing the class of which the
`method is a member and the CONSTANT _NameAndType
`entry representing the name and descriptor of the method are
`referenced by CONSTANT. Methodref, In our example, the
`CON-STANT_Class entry and the CONSTANT. NameAnd'Iype
`entry reference the CONSTANT Uft8 entries representing
`java/lang/Thread.setPriorityand(I) V, re-spectively.
`
`https://ieeexplore.ieee.org/document/932157/
`
`7/20
`
`Juniper Ex. 1009-p. 10
`Juniper v Finjan
`
`T hread : −setP riority(Ljava/lang/T hread; I )V , whichdoesnota
`

`

`8/2/2018
`
`Mobile code security by Java bytecode instrumentation - IEEE Conference Publication
`
`Since a new class appears, we should add a new CONSTANT
`_Uft8 entry representing a new classname string, Safe
`
`setPriority (Lj a-lang/Thread; I) V, as shown in figure 3.
`
`3.2.2 Method Invocation Modification
`Among various Java Virtual Machine instructions
`implementing method invocations, we are interested in
`invokevirtual for an instance method invocation and
`invokestatic for a class(static) method invocation. Both
`instructions require an index to a CONSTANT. Methodref
`constant pool entry, but they require slightly different
`environments. The instance method invocation is set up by first
`pushing a reference, to the instance which the method belongs
`to, onto the operand stack. The method invocation's arguments
`are then pushed onto the stack. The contents of the stack at this
`point (the environment), which include the reference to the
`method and the operand stack of the call to Thread.
`setPriority(I) V, is shown in Figure 4(a). The class method
`invocation requires an environment much like that of the
`instance method invocation, except that a reference to the
`instance is not pushed onto the operand stack. The
`environment of a call to Safe$Thread: setPriority (Ljaval
`lang/Thread; I) V is shown in Figure 4(b).
`
`A visual comparison of the two method invocation
`environments in figure 4 makes the modification required very
`clear. The contents of the operand stacks are the same, though
`an instruction for method invocation changes from
`invokevirtual to invokestatic.
`
`The distinct nature of methods and classes, and their distinct
`representation in bytecode thus leads to different mechanisms
`for their respective modification. Method-level modification
`requires a change in bytecodes in addition to some
`modifications in the constant pool, whereas class level
`modification requires only one change in the constant pool.
`The difference in the costs of these operations is made up by
`the difference in the applicability of the schemes; method-level
`modifications provide finer-grained control, and are the only
`choice for final classes and interfaces.
`
`SECTION 4.
`Application Frameworks
`
`Our experiments with bytecode transfer and untrusted code
`execution were carried out in the context of Java applets and
`Jini service proxies. While the same instrumentation
`mechanisms apply in both cases (and, in general, for arbitrary
`bytecode), the transport mechanism is modified at different
`points. In the following, we refer to the code which carries out
`the bytecode instrumentation as the byte code filter.
`
`4.1. Java Applets
`
`The ubiquity of Java applets and their usefulness comes at the
`price of an increased security risk owing to unintentional
`execution of malicious mobile code during web browsing.
`
`https://ieeexplore.ieee.org/document/932157/
`
`8/20
`
`Juniper Ex. 1009-p. 11
`Juniper v Finjan
`
`T hread, andanothernewCON S T AN T . C lassentryref erencingth
`

`

`8/2/2018
`
`Mobile code security by Java bytecode instrumentation - IEEE Conference Publication
`
`There are two obvious ways of inserting a Java bytecode filter
`into the network and browser architecture. One approach
`would be to modify the class loader of the Java virtual machine
`used by the browser. The other is to capture and modify Java
`bytecode before it enters the browser. The latter provides an
`easier experimental framework, since a user can easily
`configure his or her browser to obtain web content through a
`piece of software called a network proxy. This can be done by a
`simple modification to a standard browser dialog box. In
`contrast, modifying the class loader of the Java virtual machine
`requires installation of special purpose code in every browser.
`Moreover, using a standard proxy interface allows us to install
`a Java-based “security tuner” interface in every browser, which
`allows the user to specify their security constraints. Thus a
`proxy interface provides a simple, customizable and flexible
`framework for developing and testing Java bytecode filters.
`
`The basic architecture of our system is shown in Figure 5.
`When the web browser requests a web page or applet, this
`request goes through the network proxy. The proxy forwards
`the request to the web server and receives the desired display
`or executable content. When the web server sends a Java
`applet, the proxy will pass the applet code to the byte code
`filter. The bytecode filter will examine the bytecode for
`potential risks and modify the bytecode before sending the
`code for execution to the web browser. In this way, the web
`browser only receives bytecode that has been screened. The
`proxy also has access to a repository of Java classes, including
`secure safe classes that can be substituted for standard library
`classes and implementations of user-interface methods. The
`user interface, written in Java and run as an applet under
`control of the browser, allows the user to customize the security
`checks performed by the proxy and filter during a web session,
`without stopping or restarting the browser or Java virtual
`machine running under control of the browser.
`
`Figure 3. Modifying method reference
`
`https://ieeexplore.ieee.org/document/932157/
`
`9/20
`
`Juniper Ex. 1009-p. 12
`Juniper v Finjan
`
`

`

`8/2/2018
`
`Mobile code security by Java bytecode instrumentation - IEEE Conference Publication
`
`Figure 4. Modifying environments of method invocations
`
`4.2. Jini Proxies
`
`The Jini architecture and application program interfaces
`provide a convenient and relatively general framework for
`dynamic discovery and configuration of distributed ser-vices.
`Although Jini is designed to support dynamic federation, the
`security aspects of Jini are extremely limited. The proliferation
`of networked small devices and the availability of lean JVMs
`makes Jini an obvious target for attacks in such a distributed
`system. We describe the basic Jini mechanisms below, and
`demonstrate the use of our techniques to ensure safety in this
`framework.
`
`4.2.1 Protocols
`The Jini API extends the Java environment from a single
`virtual machine to a network of machines. In general, a Jini
`system contains a set of services each of which offers some
`functionality to any member of a federation. The initial
`handshake between the clients and the services is facilitated by
`lookup services. The location and installation of services via
`this lookup mechanism involves network transfer of Java
`bytecode. Specifically, if a process on machine A wishes to
`communicate with a process on machine B, then machine A
`installs a surrogate stub object that communicates with a
`corresponding object on machine B through remote method
`invocation. This surrogate stub object is called a proxy. If the
`object on machine B provides a lookup service, then the stub
`object installed on machine A is called a lookup proxy. If the
`object on machine B provides a general distributed service,
`then the stub object installed on machine A is called a service
`proxy.
`
`A Jini client obtains a lookup proxy and a service proxy
`through the following steps:
`
`Discovery The client broadcasts a request for a lookup
`service. The lookup service responds with a lookup proxy.
`This stub object (proxy) allows the client to make further
`queries of the lookup service.
`
`Query The client queries the lookup service for a service
`with specific attributes. The lookup service responds with
`a list of services and supplies a list of attributes
`associated with each service. v
`
`https://ieeexplore.ieee.org/document/932157/
`
`10/20
`
`Juniper Ex. 1009-p. 13
`Juniper v Finjan
`
`

`

`8/2/2018
`
`Mobile code security by Java bytecode instrumentation - IEEE Conference Publication
`
`Selection The client requests and receives a service
`proxy for a specific service. The result of selection may be
`a signed or unsigned jar (java archive) file.
`
`The first phase, used in discovery, involves communication
`with a subnet or multicast group, in order to locate a lookup
`service. In the second phase, which includes query and
`selection, the agent communicates with the lookup service
`through a lookup proxy that was obtained in the discovery
`phase. While standard Jini uses remote method invocation,
`other forms of communication could conceivably be
`substituted. Since the agent must install and execute a lookup
`proxy (interface or driver), the agent is susceptible to errors or
`attacks resulting from corrupted or malicious proxy code. In
`the third phase, the agent interfaces with the installed service
`through a service proxy. Again, standard Jini relies on remote
`method invocation, but if the service is distributed, then other
`communication mechanisms could be appropriate. As with
`installation of the lookup proxy, the agent is again subject to
`risks associated with execution of service proxy code received
`over the network.
`
`Figure 5. Architecture for instrumenting Java applets
`
`https://ieeexplore.ieee.org/document/932157/
`
`11/20
`
`Juniper Ex. 1009-p. 14
`Juniper v Finjan
`
`

`

`8/2/2018
`
`Mobile code security by Java bytecode instrumentation - IEEE Conference Publication
`
`Figure 6. Architecture for instrumenting Jini proxies
`
`4.2.2 Security
`The current Jini security model is simply the Java security
`model. The final jar file received as the result of selection may
`be signed. The client Java security manager may be configured
`to provide each lookup proxy or service proxy with specific
`access rights, according to the signing key used in creation of
`the Jar file. This provides some protection, but suffers from the
`familiar shortcomings of signature-based security. Specifically,
`authenticated code may have unintentional safety loopholes,
`which are only adequately addressed by a content-based
`protection mechanism. Instrumenting the proxy bytecode at
`the client's end, before it is loaded by the class loader for
`execution, provides for client-specified safe behavior.
`
`Figure 6 illustrates the augmented Jini architecture. Note that
`specific kinds of bytecode filtering may be appropriate for Jini.
`For example, if Jini service proxies (consisting of java
`bytecode) are not expected to contain loops, then filtering can
`be used to detect this and prevent looping. Another desirable
`property might be that the proxy only engages in secure
`authenticated network connections with the service it came
`from, and the code may be filtered to require this. Other client
`and service specific tests may be performed by instrumenting
`the proxy with sentinel code, which performs the required code
`analysis prior to execution of the original code. Jini-specific
`filtering can be achieved either by writing appropriate
`configuration files for our existing filter, or extending the filter
`implementation.
`
`The second piece of the augmented Jini infrastructure is an
`interception mechanism for proxy bytecode. As described
`above, for Java applets this was achieved by using a network
`proxy that intercepted http communication. For Jini, this must
`now be done using a network proxy or some other mechanism
`that has access to arguments and return values of Java RMI
`calls.
`
`4.2.3 Bytecode Interception
`The Jini specification only requires the protocols described
`above to be based on TCP and UDP transport and object
`serialization, and implementations are free to choose a
`communication mechanism. In particular, the specification
`makes no particular reference to the RMI registry or wire
`protocols. The only requirement is that Jini interfaces preserve
`the RMI remote interface semantics, which means that they
`need to only declare RemoteException on its methods. This
`makes the job of identifying a well known, constant path of
`remote-class delivery rather difficult. We note though that
`most Jini communities of services and clients actually use RMI,
`on account of it being used in Sun's default implementation.
`
`We focus on the relevant parts of the Jini discovery protocol.
`After the lookup server is found, it sends to the client an object
`implementing the net.jini.-core. lookup. ServiceRegistrar
`interface. This is done in the last phase of the discovery
`protocol, via a java.rni.MarshalledObject. This ServiceRegistrar
`object is the lookup proxy, and will receive all service proxies
`on the clients behalf. Accordingly, there are three places where
`one could intercept the service proxy bytecode:
`
`https://ieeexplore.ieee.org/document/932157/
`
`12/20
`
`Juniper Ex. 1009-p. 15
`Juniper v Finjan
`
`

`

`8/2/2018
`
`Mobile code security by Java bytecode instrumentation - IEEE Conference Publication
`
`during transport from the lookup server to the lookup
`service proxy,
`
`within the ServiceRegistrar before the serialized object is
`reconstructed, and
`
`within the ServiceRegistrar after