bsd5tu1 wrote:
>The jar files we put on the remote machines are NOT to be executed on the
>remote machines, but rather on the local machine. The local machine
>accesses these jar files by loading them via a URLClassLoader.
As a result, the local machine is trusting that the remote machine will
supply a jar file containing trustworthy (i.e. uncompromised) code.
What's unclear is why the remote machine is supplying any executable code
to the local machine at all.
>These are not applets, they're applications.I believe it's sort of similar
>in principal to what WebStart does, but the fact is the jar files CAN be
>generated dynamically on the remote machines, and they can contain embedded
>data specific to that particular machine.
If the jars can contain embedded data generated remotely, then by
definition the jar-files WILL BE "tampered with". That is, what was put
there initially IS NOT what is eventually retrieved.
For the altered jar to be trustworthy, the remote machine must be
trustworthy in all actions that could affect the jar. There's no way of
avoiding that condition, because it's a fundamental part of the trust
relationship.
Analyze the trust relationships first. You'll have a bunch of statements like:
X trusts Y to do Z.
You'll also have some statements like:
X doesn't need to trust Y to do Z.
Those are the "don't care" relationships.
Without a clear and complete list of the trust relationships, you can't do
a good security analysis.
>What I'm looking for is a means to determine whether or not the jar file on
>the remote machine has been tampered with. We feel it's difficult for
>someone to actually hack into the process that generates the jar file, but
>the generated jar file in turn is placed in the directory structure of an
>Apache web server, which we can then access via the URLClassLoader, and
>then execute locally. The problem, of course, is the verification of the
>jar files validity.... in other words, someone could hack the web site and
>then modify the jar file and introduce bogus embedded data.
In that case, the remote machine is no longer trustworthy, and anything it
can possibly build or write is untrustworthy. That extends to signing the
jar file, which is what you'd be doing remotely.
A signed jar must be signed using a private key. But if the private key is
available for signing, it's also available for being hacked. It may be
harder to hack, or it may not, but if you're worried about it being
compromised, then that's a clear statement that you don't trust the
production procedure. But if you don't trust the production procedure,
what purpose does it serve to sign anything?
In any case, it's clear that you can't tell remotely whether or not the
machine was hacked and used to sign bogus data. Everything the remote
machine can possibly do is untrustworthy, so having it sign files in a jar
is pointless. You don't know whether the signing key was compromised or
not, so you may as well omit the signing and just use unsigned files.
Since the machine can't be trusted, you have no other options. You can't
possibly accomplish what you hoped for when you set out. If you change the
trust relationships, you'll get different consequences, but from what
you've stated are the requirements, cryptography changes nothing, and you
can't succeed.
If I were you, I'd just use unsigned jar-files, and NOT put classes in
them. If the local app never executes code loaded from ANY remote jar,
then the code-integrity problem disappears. Just put your remotely
generated data-files in the jar and don't sign any of it, because it's not
really buying you anything on an untrustworthy machine.
Another possibility is to sign all the code in the remote jars, but keep
the private key (the signing key) ONLY on the local machine, NOT on the
remote machine. Or better yet, keep the private key on an altogether
different local machine or removable storage media.
It's unclear to me why the remote jars have any class-files in them at all.
It seems pointless given your description of the situation.
If you were deploying jars for remote execution, then the included classes
might represent data-gathering plugins used to create the host-dependent
data. But you said you're NOT executing the classes remotely. So any
classes that COULD be in the remote jars are ones you originally put there,
on the local machine. But if you put them there originally, you can just
as well put them in your local app's jar and omit them in the remote jar.
Then you don't have to sign any code, because it's never loaded from an
untrustworthy origin, i.e. a remote host.
With unsigned data-only jars, you at least have to validate the data in the
remote jar for well-formedness, which you should do in any case. You may
also filter the data for bogosity, based on prior knowledge of the host it
was obtained from. Since you haven't described what this data is, I have
no other suggestions for validating it or ensuring its authenticity.
If I've misunderstood something, then the above analysis could be
completely off. The pivotal point, though, is still this:
Why are you putting any classes at all in the remote jar?
In this case, the less you rely on getting from the remote host, the better.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
