★ wanayoo — archive 1999 http://java.sun.com/javaone/javaone97/java1-97-security.htmlNouvelle recherche | Portail wanayoo
   

Securing the Future of Java

JavaSoft builds on its inherent security advantages with more APIs

By Gregory S. Smith, JavaWorld

San Francisco (April 7, 1997) -- Last week Sun unveiled enhanced security for Java at the JavaOne conference in San Francisco. The new approach is supposed to keep hackers from wreaking havoc over the Internet, according to Sun, while allowing users of Java applications to print, read, and write to their local machines, none of which were possible under the first version of Java.

The news came amid charges from Microsoft that Sun's security limits the usefulness of Java applications. Sun retorted that Microsoft's ActiveX is inherently insecure and that the company is trying to convince the public that its security holes are actually application features.

Both companies are taking a similar approach, using digital signatures and authentication to verify the source of code coming from public networks and ensure that it hasn't been tampered with. However, Sun goes a step further by sandboxing unknown code in one place on a user's machine where it can do no harm.

The new security features in JDK 1.1.1 can be summed up in one phrase: code signing. Granted, code signing is an important step forward and well-timed given Microsoft's Authenticode push, but solves few of the problems that most developers and implementers face in deploying secure applications.

Brian Thomason, who develops custom groupware solutions, points out that "our customers aren't worried about our code, they're worried about secure connections or securing documents."

The new JDK allows application publishers to package their code in a single Jar (Java Archive) file in the same way that Zip archives combine and compress a collection of files. Jar files also include a manifest that lists a hash value for each file in the Jar. This hash value is a fingerprint of the actual file, like a checksum only stronger. Once the manifest is complete, publishers can append a digital signature of the manifest. This process allows any user to verify that the manifest file has not been tampered with since the publisher signed it. In turn, if the contents of the Jar file generate the same hash values as the signed manifest, you know that what you received has not been altered and you know, with some confidence, who published the application.

If you're inclined to trust the publisher, you can designate that the contents of properly signed Jars can run outside the sandbox. But the new runtime environment supports only this simple choice. If you trust an application's publisher, applets from that publisher run without any security restrictions beyond the type-restrictions and similar inherent features of Java.

This binary decision, however, serves only limited needs. Imagine downloading an applet from a reasonably trustworthy source. Do you really want it reading and writing to directories that contain your operating system? "Of course not," replies Beth Garber, who manages systems at CPT Services. "We'll keep [all external code] in the sandbox until there's an alternative to unrestricted access."

Increasingly, third parties are offering solutions to different parts of this security puzzle. One of the most interesting is a pair of products from Finjan software. SurfinShield scans content as it arrives on a client machine. If an ActiveX control includes code that would access certain files, for example, it will discard the program before it reaches your browser. The product also detects unresolved file or network references and allows users to take appropriate action. A companion product, SurfinGate, provides similar content inspection at a network gateway and can prevent the questionable code from entering the network. Ron Moritz, Technical Director at Finjan, points to their content inspection technology as added value over increased control that JavaSoft promises in the next twelve months.

More Permissive Play Promised
In order to support code signing in its current form, JavaSoft added several APIs, many of which the company will extend to address these concerns. You'll find implementations of an access control list (ACL), message digest (hashing), public and private keys, and, of course, digital signatures. JavaSoft will release a more complete security solution this summer that builds on these APIs and introduces some new ones, including encryption.

Perhaps the most significant of the core class upgrades will be much finer control over access to your system. Through access control lists, end-users can create domains that identify applications based on where they came from (codebase) and who signed them. Users can then assign very specific permissions to each domain, such as the ability to read and write only in a specified directory or to connect to particular hosts on a given range of ports. These domains will apply to local applications as well.

How to manage these ACLs is an implementation decision for the various platform OEMs, but Li Gong, Java Security Architect, indicated that the hooks will soon be in place to allow network administrators to centrally manage ACLs and push edits down their clients.

In the same release, JavaSoft will unveil a more complete API that abstracts most of the components of cryptography. The abstractions take place at a level that is common to all public-key cryptography systems: key-pairs, encryption streams, and X.509v3 certificates. By writing to these APIs, developers can ignore most of the specifics of different cryptography systems. For developers who want more control, like generating a DSA key pair in a certain key family, subclasses of the generic abstract will expose more details.

Run Anywhere (in the U.S.)
While you'll find APIs for all of basic cryptography, you won't find a cryptography engine. There are a host of issues that make cryptography engines incompatible with the JDK. The most obvious is that any strong cryptographic engine written in the U.S. cannot be exported. At the JavaOne security session, Gong fielded a host of questions from participants wanting to know how JavaSoft could solve the problem. Short of convincing the State Department to remove cryptographic algorithms from the list of export- controlled munitions, there isn't much the company can do. Early this summer, JavaSoft will release a set of Java Cryptography Extensions that will allow developers in the U.S. to use JavaSoft's cryptography engine. Also expect JavaSoft or other developers to create middleware that maps the Java APIs to other engines like Microsoft's CAPI or even BSAFE.

Notably lacking from this summer's release is support for secure sessions through SSL, SKIP, and related protocols. JavaSoft promises to deliver this last core piece of cryptography by year's end. JavaSoft has a separate SSL package that it is using in the Java Web Server, HotJava Browser, Java Wallet, and other products, but it is not part of that summer release. JavaSoft also is working on a certificate server, written entirely in Java, for delivery in 1998, although you should be able to use existing X.509 servers available from other platforms.

Who Are You?
With all the developments in improving security, you may have noticed one missing service that we've come to expect from any enterprise-ready environment. Java currently doesn't have any infrastructure for authenticating users. Though there are few details available yet, JavaSoft plans to implement authentication next year.

JavaOne Today show coverage is provided by JavaWorld (www.javaone.com), IDG's monthly Web-only publication for the Java developer community.

April 4, 1997 Complete Contents