bsd5tu1 wrote:
>The boss has indicated that for one of our products, since it can contact
>and obtain classes from other machines outside our local networks, he would
>like some mechanism for verifying the authenticity of the outside classes.
>We will provide the outside classes, but we want to make sure that they
>don't get hacked/modified while sitting on machines out of our control
If I understand you correctly, all you're doing is verifying that the
classes you obtain from the remote origin are identical with what you
originally put there. That is, your local code knows what to expect, and
it simply wants to confirm that it's getting what it expects. You stored
it remotely, and you want to confirm that what you retrieve is exactly what
you stored earlier.
That's a simpler problem, and doesn't require jar signing.
Your local code simply keeps hashes of all the code it placed remotely, and
calculates a hash when it retrieves a remote class. If the hash matches
what it expects, then there was no change to the remote code. If the hash
differs from what it expects, then the remote code is invalid.
If what I described is NOT what you're doing, then please describe the
exact sequence of creating the distant code, transporting it, storing it,
and later retrieving and confirming its integrity.
>What I thought would happen would be that if I copied the signed jar file
>to another machine without any cert's or keystores installed on it(in other
>words, the remote machine is oblivious to the fact that this is a signed
>program), I assumed that the when the JVM was invoked it would identify the
>file as signed, attempt to look for a cert, and then either run the program
>if the key exists or throw a security exception if it didn't.
How was the JVM invoked on the remote machine?
> Since I did
>not transfer any stores or certs to the remote machine, I anticipated that
>an attempt to execute the signed jar file would fail. What happened instead
>was that the "foreign" machine (a Red Hat Linux 9.0 w/JDK1.4.2) went ahead
>and ran the jar file without complaining about anything. It didn't care
>that the program was signed or not. Using "jar xvf KeyToolTest.jar" reveals
>that the META-INF manifest file has been modified and as anticipated the we
>now have two more files with a .DSA and a .SF extension.
>
>I realize that I can verify that the file is signed via "jarsigner -verify"
>prior to attempting to load foreign programs/classes, but I really thought
>this securtiy mechanism would be much more sophisticated and aggressive
>than this.
I think the problem is misplaced expectations.
Transferring a JAR to a remote machine, where you then execute it with the
'java' command will NOT cause signatures to be checked. The 'java' command
itself has no requirement for signed JARs. It assumes that every JAR you
tell it to use is an implicitly trustworthy JAR.
For a signed JAR to be checked, you have to use it in a Java environment
that DOES NOT assume every Jar is implicitly trustworthy. A web browser is
one such environment. A JNLP client is another. You can also write your
own Java code that requires signed code. But unless you use the jar in
such an environment, you won't be using a ClassLoader that checks
signatures, so signed or unsigned won't make any difference, since none of
the code that cares is being executed.
>Am I doing something wrong or is this really how these certificates work?
>We are not interested in paying money to Thawte or Verisign for
>certificates at this time.
From what little you've described of what you need to accomplish, I don't
think you need certificates of any kind. Keeping local (i.e. trustworthy)
hashes of the original files will suffice. If the local hashes AREN'T
trustworthy, though, that's a different kettle of fish.
-- 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
