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:
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!
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.