[2043] in java-interest
Re: User machine resident data and code
daemon@ATHENA.MIT.EDU (Futplex)
Fri Sep 22 09:13:44 1995
To: java-interest@java.sun.com
Date: Fri, 22 Sep 1995 06:30:48 -0400 (EDT)
Reply-To: java-interest@java.sun.com (Java Interest Mailing List)
In-Reply-To: <199509210630.XAA29359@java.sun.com> from "owner-java-interest-digest@java.sun.com" at Sep 20, 95 11:30:07 pm
From: futplex@pseudonym.com (Futplex)
John Moore writes:
> I would like to be able to make an applet/application that is used as
> follows:
[...]
> It is basically
> behaving as a software agent with local, persistent storage.
>
> The issues here are (at least):
[...]
> -storage at the client of applet-specific data that is persistent between
> sessions. This is a important from both a security and applications
> viewpoint.
> -new security issue: a specific applet should be able to:
> (a) create it's OWN directory that no other applet can access, but
> that can be freely accessed by future instances of this applet.
[...]
> This security issue is critical for my real-world application. I want
> to be able to store, for example, credit card information on the local
> client, [...] At the same time, I don't want the user to have to
> answer authentication pop-up boxes every time the applet needs to do
> things.
> We need the concept of an authenticatable application,
> with persistent, authenticatable class cacheing, and with local persistent
> storage of data that is inextricably tied to the authenticated
> application (at least from within the Java virtual machine).
I'm not sure whether you are looking for a Java-specific way to do this, or
just a protocol. Here's a simple protocol, with at least one problem I can
see:
The server where the applet lives holds a secret key belonging to the applet.
The applet's corresponding public key is distributed in some fashion.
Servers sign applets with their secret keys. When an applet is downloaded,
the client browser checks the signature on the applet using the right public
key, to ensure that the signature matches the applet received. In addition,
the signature is compared to a signature stored on the client machine, if
the applet has previously been downloaded. Directory access is granted based
upon these checks, and the signature ID. Data written in applet directories
is encrypted with the applets' public keys.
The snag is that a server effectively can be assumed to know the secret keys
of all the applets it serves. So, they all reduce to the root password on
the server, which all too often reduces to getting an account on the server.
Can you say, "single point of failure" ? One cracked server could snoop into
the encrypted applet directories on millions of client machines, grabbing
credit card information or whatever.
All this stems from the fact that an applet agent doesn't have an
independent existence outside of public areas of a server. You want some sort
of persistent object/entity/agent that has its own private data. A human agent
can carry around a password in her head, but a software agent has a
transparent mind. I don't see a way to get around this right now.
-Futplex <futplex@pseudonym.com>
P.S. to Scott B.: nice to see more people from the firewalls list here !
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
