1

I have a Java application for corporations that will be activated by a paid licence.

The application will use a public key to decrypt a license file that was encrypted with a private key. (And/or, the application will encrypt some data and submit it to a web service where it will be decrypted with the private key on the server).

Either way, the application needs to have the public key.

I'm thinking about hard-coding the contents of the public key file in a Java class and reading it from there. Also, I am using an obfuscator (Allatori) that does string encryption so the hard-coded public key string would be scrambled by the obfuscated and so won't easily readable using a decompiler, so I see that as an advantage.

But is there a good reason why I should not hard-code the public key and instead deliver it as a file in the class path?

Please give me some advice because I'm new at this and could use some advice, thanks!

AndySummers2020
  • 411
  • 1
  • 6
  • 14
  • 2
    What if you have to change the key, then you have to change the source file and ship an update of the code. While you could for example have it in a text file next to the application instead. Just one of many ideas. But having it inside the source code is indeed not the best idea, it is not source code. It is a resource. – Zabuzard Jun 28 '20 at 16:05
  • Why do you see it as advantage that the public key is not readable? It is a public key, the name says it already, it is public. If you worry about it leaking then you should not have it on the client side like that in the first place. Having it on the application like that, obfuscator or not, you have to assume that it leaked already and that any *hacker* knows about it from the first day you shipped it. – Zabuzard Jun 28 '20 at 16:07
  • Also see [Where should I store the Public Key?](https://stackoverflow.com/questions/4202672/where-should-i-store-the-public-key). – Zabuzard Jun 28 '20 at 16:10
  • @Zabuzard Great points, thanks for all the input. I saw it as an advantage because it's a little more "security through obscurity" ... that is, if I implement a design where the application decrypts a license file locally (without phoning home to a web service), the hacker's life is easier if the public key is sitting out in the open. I figure hard-coding it and then the obfuscation's string encryption is one more headache for the hacker and might be enough to get him to not bother. I know I'll never stop a skilled and determined hacker, but I figured why make it easier for them. – AndySummers2020 Jun 28 '20 at 16:18
  • @Zabuzard I was also considering writing a routine that (pre-compiler) inserts a dummy/decoy public key (and possibly dummy/decoy "http phone home" code) in every class in the application. But it's very likely I'm overthinking this. :-) – AndySummers2020 Jun 28 '20 at 16:22
  • It'll only take someone 15 minutes to find the decrypted public key, why make life difficult for yourself for no added security? – Joni Jun 28 '20 at 16:23
  • @Joni You're probably right ... but with the obfuscation, all strings (including the hard-coded public key) would be encrypted, and if I put a hard-coded dummy public key in every class in the project, it would be harder to spot. All that being said, might not be worth the trouble. All I'm really trying to do is get honest corporations to pay for the licenses. – AndySummers2020 Jun 28 '20 at 16:25
  • 1
    An adversary can attach to your program with a debugger and set a breakpoint in the cryptographic library you use. At that point they can extract the correct, decrypted key from memory. – Joni Jun 28 '20 at 16:32
  • Not even that, you can always take a look at all strings on the heap of any process. Just use common process tools and you have all of them. As said and explained in the linked SO, a public key is public. It is not desirable to hide it, nor does it add any security to it. It does not matter at all if your public key is visible or not, it is public. You could write a Facebook post and tell the whole world your public key, it is public. If you do not want it to leak then you do not want a public key but something else. – Zabuzard Jun 28 '20 at 17:00
  • 1
    @Zabuzard and Joni all very interesting insights. I'm very glad I asked. – AndySummers2020 Jun 28 '20 at 17:04
  • 2
    You will have to store it somewhere. Where the best place is to store it depends on multiple factors including how you distribute updates to your application. It is certainly OK to hard-code it in your source code. I would like to point out that "encrypting" with the private is usually the wrong terminology. That operation is more commonly called "signing", and is best performed with classes specific to signing, like the [`Signature` class](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/security/Signature.html). – President James K. Polk Jun 28 '20 at 20:53
  • @PresidentJamesK.Polk Thanks for info on signing vs encrypting ... I'll look into signing after I get encrypting done. I'm actually having a related follow-up problem, I just posted a question about it here, if you have a moment to take a look, that would be great! https://stackoverflow.com/questions/62629974/how-to-fix-error-java-security-nosuchalgorithmexception-rsa-ecb-pkcs1padding – AndySummers2020 Jun 29 '20 at 01:27

1 Answers1

0

Thanks for the great information that flowed in the comments, I got good answers to my question, and learned a lot in the process.

The original question was "is there a good reason why I should not hard-code the public key and instead deliver it as a file in the class path?"

The answer is ... yes, there are good reasons to not hard-code the public key in the Java class. Namely, the public key should be thought of as a resource, separate from the Java class, so it might not be good form from coding conventions perspective. Also, keeping the public key separate means you can update the public key later without having to recompile and deliver a new build of the Java code.

All that being said, it is technically reasonable to include the public key inside the Java class, and since it suits my purposes, I did take that approach. (Specifically, I like that the obfuscation hides the public key as an encrypted string in the Java code simply to add one more layer of obscurity around my licensing solution; it's simply one more obstacle to annoy a casual hacker.)

Thanks for the help everyone!

AndySummers2020
  • 411
  • 1
  • 6
  • 14