Java Server Client application Signing the client jar

[micmast]

Hello,

I'm doing some research in to Java security, and I have a question. In my line of work I find from time to time client applications written in java (so a .jar) that connects to a server, but the server will not work with a manipulated .jar. Now my question is, how does that work? After reading on the net I found that it is possible to sign a jar file with either a key or a certificate (maybe others), but nothing about how this would be checked from the serverside of the architecture.

Could somebody give me some pointers as to how it works or where I could find information?

Thx

[Frinavale]

Not sure what type of application you are implementing but it seems as simple as checking a hash code...if the hash code doesn't match then the jar has been modified.

Signing works along these lines.

-Frinny

[micmast]

Does that mean that their is not a general function in place in the Java console (the sandbox) that would allow to check the .jar independently. I'm talking from a security point of view, so if the jar is responsible for it's own signing, it would just be an open lock on a door?

[Frinavale]

I'm so sorry but I'm actually not a Java expert.
I am familiar with signing code because I use signing quite a bit...
I hope that a Java expert can jump in and help you further.

I wouldn't think that the jar is responsible for it's own signing.

I would think that your server application would store the signature/hash that it creates for the jar files based on what is in the jar...when the jar is submitted to the server later it would check to see that the signature/hash is valid to ensure that it isn't working with a modified jar file.

You might be right. There could be a Java Specific tool available to you that does this without having to rely on your code/application to do it. In fact I would be surprised if there isn't such a feature.

I still don't understand how your server is using the jar files or what your application does.

Again, I'm sorry but I'm not a Java expert...I can only help you from a conceptual point of view.

-Frinny

[micmast]

The server-client application that I'm talking about is a bit as follows:

a client has to download a java jar file that will act as a client for the application. the client will use it to enter data, modify things, login,... but the result is checked & verified by the server. but there should be some security measure in place that would prevent a malicious user from modifying the client jar file.

Already big thanks Frinavale for your input, you have helped me a lot already.

[Frinavale]

What exactly is sent to the server?
The jar file itself? Or is it some output that is the result of some calculations/operations that the client application does?

-Frinny

[micmast]

the result of some calculation, credentials,...

[Frinavale]

Wouldn't this mean that you need to validate the result, not the jar file?


-Frinny

[micmast]

that is one part of the security model, but how could you prevent a malicious attacker from modifying the content of the jar. This is under the assumption that the JAR file contains some data that will not be checked by the server and is excepted as is.

[Frinavale]

I don't think there is any way to prevent someone from un-jaring your jar file and modifying the code.

Signing the jar file certainly won't help with this.

The first thing that came to my mind would be to sign the jar file and then have the client application re-hash the currently used jar and send that signature to the server to verify the signature of the jar used to produce the output.

BUT my immediate next thought was: the malicious user would simply modify your code to have it create a hash based on your original jar....

I can't see how signing is going to help at all.

You could try taking a look at what Sun has to say on Java Security technologies.


I would recommend looking at the security design for the system as a whole.

You said that this is a server/client application....

Why not move all "sensitive" methods to the server side and leave the client side stripped of anything that could potentially leave a security hole in it.

For example, if your application requires that the user authenticates against something move this functionality to the server. Don't leave this up to the client since the client could potentially be modified to get around this authentication.

And Always do validation on the server....that' s just one of those rules that has to be implemented in order to develop a secure application.

-Frinny