Is Java the only secure approach?
ActiveX is trying to address security concerns by moving in a certain direction. Interesting, JavaSoft is also moving in the same direction, but for different reasons.
December 1996
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
|
Is Java the only secure approach?ActiveX is trying to address security concerns by moving in a certain direction. Interesting, JavaSoft is also moving in the same direction, but for different reasons.
|
December 1996
|
While the security war has been waged on the basis of the sandbox model versus ActiveX's security model, the new reality is that users want functionality only available outside of the sandbox. Java is moving to make that happen in a secured fashion. At the same time, Microsoft is responding to the need to tighten security for its ActiveX controls. In short, both sides have seen the middle ground and are now doing everything they can to win supporters. Here we examine the evolution of the security models in JavaSoft and Microsoft products. (2,000 words)
 Mail this article to a friend |
There is a heated battle in the Internet wars over the issue of security. Java supporters cry out that ActiveX is fatally flawed and should be shunned because of the security issues. ActiveX supporters rally behind the need for open access to system functions and the use of other security models to tighten up systems. Is either side really better than the other? Security is ranked high on the list of priorities of many users as greater access to information is afforded through the Internet and LAN environments. But what type of security is the issue? Often this question gets muddled as people talk about their concerns. Consider the apprehension of consumers regarding electronic commerce, where it is the transmission of credit card information that makes the headlines. Corporations on the other hand are suspicious of confidential data passing through the 'net without protection. While these types of security are being addressed with technologies like SSL (Secure Socket Layer) and PCT (Private Communications Technology), the attack of the killer applet has come to the forefront, and everyone is beginning to get nervous about all of those nifty applets just waiting to be downloaded to improve your system. This type of security issue is distinctly different from the first two issues. At first sight it appears that there are two distinct models of security being delivered to the market. The Java sandbox model seeks to lock all applets into a tight security framework that prevents numerous types of attacks to the operating system by constricting the access points to functions outside of the sandbox. Seemingly on the other side of the fence is the ActiveX model, where everything relies on trust placed in the developer of the applet. Over the decades that programs have been available in the commercial marketplace, a trust has developed between the buyer and seller based on prudent practices. Those few developers who violated that trust have been punished by the market. The trust model, as it turns out, is central to almost everything we do in computer technology.
Security foundation
A truly secure system is one that is severed from the world. No network
connections, no user interfaces, and no input ability will secure a system
effectively. But it also renders the system minimally or completely
non-functional. Obviously, this is not an alternative, so the next step is
to introduce sufficient security barriers to tighten up the system without
making the system too difficult to use. This balance is hard to find -- and
there are inevitable holes in the model that scare people when the holes
are exposed.
Ultimately, all systems are based on trust. There is trust in the Java
sandbox because users believe that JavaSoft acts in the public interest,
creating code that is designed to minimize possible harm to the host
system. Implementing any browser on the market today entails trust again.
For example, Microsoft implemented the Java Virtual Machine (VM), including
support for the sandbox model within Internet Explorer. Developers could
implement the Java VM in a browser with a backdoor to allow destructive
actions at a later date (like the fictional Gatekeeper software in the
movie "The Net"). In today's market, such an act of treason would be met
with sharp retaliation on the part of the users and rejection of the
developer from future activities in the market.
The true foundation for security comes from the decisions about the
level of security desired balanced with the cost and effort to implement
that security. For example, if the concern is an attack from a hostile
applet, the Java sandbox provides an excellent choice for limiting its
reach. But this same benefit becomes limiting in an environment that is
known to be safe because additional functions that land clearly outside the
Java sandbox, such as access to the local hard drive or other network
servers, are simply not permitted in an applet. In an intranet environment,
this limitation may become overly stringent and force the developer to go
outside the sandbox.
|
|
|
|
|
Stepping outside the sandbox
ActiveX started outside the Java sandbox. Its strength comes from the vast
number of controls that exist in the market today to support Windows-based
systems that can be invoked through the ActiveX control and Java
technologies. Recognition by JavaSoft that stepping outside the sandbox is
a necessary and beneficial function has led to the ability to create Java
applications that no longer fall subject to the security benefits or
limitations of the sandbox. In this new realm, trust is again the basis of
security.
Within the next two releases of Java, digital signatures will assist
users in identifying the source of the applet or application, letting users
make informed decisions about allowing application code to be loaded and
run on the local machine. This development parallels the strategy chosen by
Microsoft. JavaSoft argues that starting with the sandbox tightens the
security model, while migrating to the digital signature model it
provides a tighter control over the degree of freedom and function you
would grant to a new applet or application. The Microsoft counterpoint is
that the JavaSoft strategy merely moves to the same model Microsoft began
with and both will provide the necessary tradeoff between security desires
and operational reality.
The Java digital signature model represents a higher degree of control
over the code file's content being downloaded through the Internet.
Through the Java Archive process, the entire file set for the applet (and
other file sets) is encapsulated and digitally signed by the author. If the
file is tampered with after this point, the integrity of the digital
signature will be violated, warning the user that the archive is unsafe.
More flexible security
Additionally, JavaSoft is moving to allow the ability to assign access and
security rights to individual applets. This model relies on the trust
model, again allowing the user to define all applets from a developer as
trusted, speeding the process of downloading and using applets and
applications from known sources. With this model, users can define which
capabilities are permissible from a developer, such as data collection from
the local workstation, access to the hard drive, or access to other network
servers other than the originating server for the applet.
Microsoft has also adopted this model and is implementing, in the
Internet Explorer 3.01 and 4.0 releases, the same type of granularity in
security control. Code signature revocation is available today in Internet
Explorer 3.01. A good example of the value of this feature is the infamous
Exploder control attack on ActiveX. In that situation, the developer of the
control applied and received a personal digital signature from Verisign.
The control was then posted on the Internet and downloaded by users to
demonstrate that ActiveX controls could be signed and still cause damage.
Shortly after the control was posted, Verisign notified the author that
he had violated the agreement with Verisign by using the digital signature
to post malicious code. The code was removed from the Internet and the
author's digital certificate with Verisign was revoked. Now Internet
Explorer can be commanded to check the status of certificates and remove
those that have been revoked, disabling those ActiveX controls that are
signed by that revoked author.
The next release of Internet Explorer will allow you to make this
revocation check automatic. There will also be features to assist in site
administration to ease the effort of enabling this level of security across
multiple browsers.
Into the domain
Microsoft has relied on the power of the Windows NT security system to
create security models that span the domain. This model is more
complicated, but affords an organization the ability to assign rights down
to the file and user level. JavaSoft has recognized that this model is
appropriate for some organizations and is opening up its product to
encompass domain-level security in 1997.
Domain-level security requires client operating systems that allow for
the implementation of the security policies at both the servers and
clients. In today's operating system world, this immediately eliminates all
of the millions of personal computers running DOS, Windows 3.x, Windows 95,
and Macintosh System 7.x. All of these operating systems lack the file
system capabilities to manage security at the level that Unix and Windows
NT affords. As such, domain-level security will remain an enterprise model
for organizations that have committed to these more extensive operating
systems.
Final message
Security is tenuous at best. No system is totally secure, especially in the
world of computers. The tradeoffs can be dangerous, but the physical and
psychological costs of security have to be factored into any model you
implement. Users demand the highest level of security possible that doesn't
get in the way of a product's ease of use.
The good news is that both JavaSoft and Microsoft are headed in that
direction. For Internet novices, the JavaSoft sandbox is an ideal model
for security. Applets can be downloaded with a high sense of trust that the
code will be benign in its function. For the more advanced users, the next
level of controls, allowing the use of trusted controls, brings added
functionality combined with ease of use.
In the longer term, the ability to control program functionality down to
the level of disk access, opens up very robust security models for
organizations and individuals. Rounding out future models is the
incorporation of domain security models that can manage entire classes of
users and code in one single keystroke.
All of this points to more flexible security models that will allow you
as much functionality and risk as you are willing assume. In the intranet,
the risk of invasion will come from the external programs, but the
internally developed applets and applications can be readily deployed with
ease. For the Internet, finding and enabling trusted applet developers
will again ease the acquisition of new functionality with a higher sense of
security. All of this coupled with tighter restrictions over what
individual applets or controls will be allowed means security is
approaching the best of all models.
|
|
Resources
About the author
Robert E. Lee is a technology consultant, speaker, columnist, and author who has been in the computer industry for 20 years. He specializes in networking, Internet strategies, systems analysis and design activities, and has participated in the Windows NT and Internet betas since the start of those products.
Reach Robert at rob.lee@sunworld.com.
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright96.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-12-1996/swol-12-javasec.html
Last modified: