Question

Related to this question, can / should I use jar signing to create a tamper proof jar with information embedded for run-time enforcement of the number of users allowed to use the application? My idea is this:

1. Create jar with single class containing static field holding the right number of users
2. Sign the jar and place in Grails war lib folder so on classpath
3. (Assumption, is this correct?) I can access the the static field in the class in the signed jar file from my grails application safely knowing that the jar has not been tampered with (otherwise an exception will be thrown), and also without any extra work required like “accepting” the signature.

Is my step 3 assumption correct? Is this a good approach for what I am trying to do? If not, what is standard practice?

Thanks!

Answer 1

It’s only ‘tamper proof’ if the user has to run it in some environment that insists that the signature is present and functional. If you hand a jar to an ordinary person who can run it in an ordinary JVM (not as an applet, not as a webstart), they are free to remove the signature altogether. If you want to try to stop this, you’d have to write code to call Class.getSigners and explode if you didn’t see yourself. So, they’d need to fire up asm to write that check out of existence, and they’d be good to go.

Java code signing allows some container to verify that a jar file maintains integrity from its source. It does not give you a means of creating a tamper-proof package.