Using jar signing as a kind of license key

问题:

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!

回答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.

回答2:

Simple JAR signing won't work. JAR signing is all about the client trusting your JAR file. It doesn't prevent the client from creating a new JAR from your JAR's contents (with tweaks) and running it as an unsigned JAR.

Classes in your JAR could attempt to check that they are loaded from a suitably signed JAR, but any such class could be tweaked to disable the check. So that is a speed-bump for a determined attacker ... but certainly not an indefeasible solution.

The normal way to implement limits on simultaneous users is to implement a separate license manager / license key system; e.g. FlexLM. (And of course, that too can be defeated by tweaking your classes to skip the license check.)

The bottom line is that any license management scheme for code running on machines controlled by your client can be defeated.