We developed an application which is running on a micro computer with a Debian distribution of Linux. The application is written in Java so it is not compiled as an executable file. (means java files can be easily opened to see the code)

The micro computer is always built in an external case but if someone cracks this case he can steal the external storage and has our application (and source code). We want to protect our application from this situation.

I did some research, but I could only find that we can obfuscate our code. This is not enough actually, so I'm looking for other (more secure) ways to protect our code from people who are able to get the storage medium.

We already thought about an encrypted folder where the code is standing in but I'm not sure if this is possible and if this is a good approach. Is there anyone who can help me on a solution or explain to me the best practice to secure java code on Linux?

| improve this question | | | | |
  • 2
    You don't need to keep the source code with the application, you only need the .class files. – Stephen Kitt Feb 27 '17 at 8:52
  • @StephenKitt Disassembled unobfuscated .class files are almost identical to the source files. The comments are missing, of course. – Johan Myréen Feb 27 '17 at 9:29
  • 1
    @JohanMyréen To a large extent, yes, but there's still a fundamental misunderstanding in the question. (You also lose local variable names, and in most cases parameter names too.) – Stephen Kitt Feb 27 '17 at 9:39
  • Java is always compiled as byte code or native code and there's no reason to ship it as source code. Java has nothing to do with node.js, either. Are you confusing Java and Javascript? – Gilles 'SO- stop being evil' Feb 28 '17 at 0:09

If people have physical access to the computer that is running your code, then they have access to your code. If you don't want people to have access to your code, then don't give them access.

Encrypting the code is not useful in the scenario you describe. The computer has to decrypt the code to run it. If the computer can decrypt the code then it must have the decryption key somewhere, and anyone with physical access can also decrypt the code.

The exception to this is if the computer offers a secure execution environment which is physically protected. Smartcards offer such an environment and are fairly cheap, but they have very limited computational power. (Note that a smartcard just to store the key for encrypted code that's on a bigger computer won't help you, since the bigger computer will be the target of the attack, not the smartcard.) Hardware security modules also offer such an environment and are roughly as powerful as a low-end PC, but they're very expensive. Some computers with a protected environment based on Intel SGX or ARM TrustZone offer an intermediate level of protection, against “casual” physical attacks only (open the case but not try to crack the chips).

But realistically, the cost of reverse engineering a binary is not so trivial, and the cost of maintaining source code is very high. If your application is useful then it's extremely rare for additional security measures to be commercially worthwhile: what you're really selling is support.

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.