[1401] in java-interest
Re: questions after Java talk at Computer Literacy
daemon@ATHENA.MIT.EDU (Chuck McManis)
Thu Aug 31 19:54:47 1995
Date: Thu, 31 Aug 1995 13:54:46 -0700
From: cmcmanis@scndprsn.Eng.Sun.COM (Chuck McManis)
To: java-interest@java.Eng.Sun.COM, noams@clark.net
> The fellow giving the talk (Harry Foxwell?) talked about a method of
> "certifying" java byte codes retrieved over the net using RSA. I have
> seen hints of this mechanism in the various documents on the Java web
> server as well. Some questions come to mind:
> - Is this mechanism in place?
No it is not.
> - If so, where can I take a look, or if not, can you expand upon the
> nature of this facility?
I've prototyped the system using optional class file attributes as the
storage mechanism for the signature data. The prototype also requires
either a framework of cryptographic classes upon which to build the
mechanism or to have that framework built into the runtime. There are
export issues associated with both approaches, however if the run time
is left untouched we have the advantage of shipping one runtime and
potentially two sets of crypto classes. (one exportable and one not)
Finally, to be really useful the mechanism could use a certificate
authority from which to get public keys. Sun is working with several
people in setting up such a CA but that effort is not yet ready for
"prime time" as it were. There are CAs being set up in the US (the
Post Office, Verisign, etc) that can also be used.
Most importantly you have to understand that signing classes gives you
a mechanism upon which to build a model of trust, it does not guarantee
that the classes are not malicious. This caused some confusion internally
for a while. I can explain the difference with an example:
Let's say you run the class "FooBar" and this class keeps track of
your hot list and maybe orgainizes it in a useful way. After using
this class for a while you begin to trust it and wish to allow it
access to the hotlist file without having to click on a
confirmation dialog every time. But you don't want to do that for
every class, just the FooBar class.
For a single class, one could design a scheme whereby you computed
a hashing function over the FooBar bytecodes and stored that locally.
Now when you accessed the class, its hash could be compared against
the hash stored for the same name and if they matched one could
imagine giving that class "free" access to the hotlist file.
In this case you have developed a certain amount of trust in the
implementation of the FooBar class. Enough that you are willing to
risk you hotlist file to it. Unfortunately, when the author updates
the FooBar class you can't tell the difference between this and a
bad guy trying to damage your hotlist. Thus any class, regardless
of author, who claims to be a FooBar but does not have the same
message hash, cannot be trusted.
Now if we introduce the notion that a class can be "signed" this
signature could contain the name of the class, the hash function,
the author's name, and be encrypted with the private portion of
the author's RSA key pair. This signature is not forgable without
access to the author's private key. We can presume you have access
to the author's public key. Either she sent it with the class,
published it on her web page, or had it distributed via email it
does not matter.
Now you run the class "FooBar" and it is signed by Alice.
After using this class for a while you begin to trust it
and wish to allow it access to the hotlist file without having
to click on a confirmation dialog every time. But you don't
want to do that for every class, just the FooBar class.
Now you design a scheme whereby you put the name of the class,
the author, and the author's public key into a local store.
When you encounter the class on a web page you check to see
that it is signed, and that it is signed by Alice, before you
trust it to access your hotlist file.
Now Alice can update the FooBar class and fix bugs or add features
and your environment will be able to trust all of her versions because
they are all signed by her. The trust model has been expanded to
include the notion of the author of a class in addition to the class
itself.
Using this kind of information one can exercise quite a bit of
latitude in deciding to trust classes. The trust can be to a
specific implementation of a class (hash functions match) or
to a specific class name and author (class signature match).
You could also extend it to all classes by an author (class
is signed by known public key) or by a trusted third party
(such as your system administrator).
> - What are the implictions of using RSA on the free distribution of Java?
There are two:
a) Within the U.S. you have to have a license for the patent from
the patent license holder (currently RSA Data Security Inc)
b) If you wish to export it then access to code that does encryption
has to be restricted to uses of authentication only. (This is an
authentication problem BTW, we're just authenticating classes)
Can't comment on a) although there are freely redistributable RSA libraries
around (rsaref comes to mind).
For b) the trick seems to be in either burying the crypto in a very un-OO
way underneath some class or coming up with some mechanism whereby the
classes that actually do the crypto are only usable by the system.
> The idea of a browser asking a server for code to implement a new content
> type or protocol that the browser doesn't uderstand was mentioned in the
> talk and is also discussed on your web page. The presenter at the talk
> indicated there was a requirement of some server-side support for this
> mechanism - is this really the case?
This is not the case, the code is loaded with the HTTP protocol.
> ... Can you provide more information
> about how this (second request to get code to implement new features)
> mechanism works?
Well it was a bit fuzzy in alpha because we weren't sure whether we
wanted to document/support it or not. This should be much cleaner in
beta (and have better documentation)
> In working on my own applet, I find a need to present the user with a
> listing of a directory (but the FileDialog doesn't do the trick).
> Is there a directory object somewhere that I'm missing? If not, is one
> planned or do I need to write a native method to handle this?
In beta it will be possible to construct a file accessor dialog box
in an applet. However, be aware that applets are only allowed access
to very few files. If you use a native method your applet will not be
downloadable across the network.
> Finally, I see alot of talk about how Java produces portable code. This
> is true provided there is a Java runtime available on the target system.
> (This doesn't seem different from any other system that requires runtime
> support.)
Yes, and it is different. Unlike many other languages the way a piece of
Java code executes is the _same_ for every runtime. That way an applet
can load into any browser and do the same thing, regardless of the
hardware platform the browser is running on. This is not the same as
having for example a BASIC interpreter on every platform.
> As a developer, I am wondering how long it will be before "Industrial
> Strength" Java runtimes are available on the wide variety of platforms
> I'd like to target (i.e. SunOS (4.x in addition to Solaris), Dec Unix,
> AIX, HPUX, MacOS, SCO, MS*DO[W]S, OS/2) - when will the market for Java
> apps reach critical mass?
Well OSF has announced they are doing several ports, and the java-porting
alias has been very busy. I don't think this will take too long.
> I know Netscape claims that they will have Java support in Q4 - does anyone
> know if thats calendar or fiscal year? Will this be across all supported
> platforms?
Have you asked them?
> I have read OSF's announcement. It seems they are only committed to an
> assessment of the technology. Does anyone have any information about firm
> plans from vendors like DEC, IBM, SGI, HP or SCO?
Again, these guys all have mail addresses and mailing lists of their own.
I would suggest that you ask them yourselves. Everyone in the industry
has expressed an interest in Java and HotJava technology and to the extent
that their customers are asking for it, it will encourage them to support
it in their base product. There are also many efforts underway to port it
to various platforms and I suspect there might even be some business
opportunities to provide support for Java on many niche platforms.
--Chuck
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
