Reputation: 33
We are distributing some Java jar files which are key assets of our business to the customers. We can do obfuscation to make it harder to do revere-engineering but we also don't want the jar files being used outside of our application. Are there any good solutions?
We are considering a solution of passing an access token (with a short expiration) and its signature at run-time from our application, and validating the token within the jar each time a public interface being called. The token and signature are generated from a web server and encrypted by a private key while the jars use the hard-coded public key to verify the signature. Will this work?
Upvotes: 0
Views: 176
Reputation: 2490
Whatever the amount of obfuscation you add to you binary file, it is always possible to reverse engineering it. It just require more work.
With the solution you propose, I see major issues : - legitimate users will be penalized if the web service distributing tokens is down - illegitimate users will easily patch the java class to skip token verification. Hence having a better service than legitimate users.
The main problem you have is that your added value is in the jar. If you release it, it can be used by anyone.
One solution, now widely used on the web, is to keep your algorithm in premises side and propose an on-line web service. The client submit a request, the server in your premises compute the answer en serve it to the client.
But it is a very different business model which require highly available infrastructure. Main cloud provider can help for that.
Upvotes: 1
Reputation: 73
you can define an algorithm in the jar and return the output as encrypted. you can also have the same algorithm in the webserver which also encrypted. on comparing both outputs you can decide to go forward.
some elements in the algorithm should be uinque and cannot be replicated. by this, both he functions in jar and the webserver and independent and nothing is shared in public.
Hope this helps
Upvotes: 0