Security By Design

This page discusses some of the security concerns for license management on the Java Virtual Machine which are addressed by TrueLicense. The information provided on this page is not exhaustive however, so if you need more details or if you would like to discuss another security concern, then please contact the user mailing list - your feedback is welcome! If you would like to verify the propositions on this page, then please consider checking out the source code or reading it online.


First, there is no such thing as a 100% secure licensing schema: Any software running on the Java Virtual Machine is subject to debugging, tracing and even instrumentation. These features are big advantages of any system running managed code, but at the same time they are an impediment to protect your intellectual property and enforce copyright because they can be used by attackers to reverse engineer your code and break its licensing schema.

Security Objectives

So why should you even consider defining a licensing schema if it seems to be a futile endeavour anyway? A reasonable objective is to make it more expensive to break your licensing schema than to buy a license key for your software product.

For example if you sell license keys for your software product for one Bitcoin, but it would cost any attackers ten Bitcoins to break it, then your licensing schema should be considered fine (your mileage may vary). Obviously, this reasoning fails for attackers who aren’t working on a budget, e.g. who try to break the licensing system for sports, no matter how long it will take. But then again, as long as they can’t use their findings to forge license keys for other users, your licensing schema should still be considered fine.

Security Level

TrueLicense obeys the Kerckhoffs Principle, that is, even if attackers know in advance that your software product is using TrueLicense and how it’s working, this knowledge alone doesn’t help them to break the licensing schema of your software product. The cheapest way to break it still requires reverse engineering and modifying your software product so that it doesn’t use any licensing schema at all.

To establish trust in this proposition, TrueLicense is commercial open source software. It is covered by the terms of the GNU AFFERO GENERAL PUBLIC LICENSE, Version 3. Commercial licensing for use with closed source software is available upon request. For ordering please contact sales AT schlichtherle DOT de.

Cryptographic Algorithms

TrueLicense uses the Java Cryptography Architecture (JCA) to perform cryptographic tasks:

  • License keys are digitally signed in order to protect your intellectual property and enforce copyright. The digital signature algorithm is configurable, e.g. SHA1withDSA for compatibility with applications using the legacy V1 license key format or SHA256withRSA for applications using the new V2/* license key formats. If you use the TrueLicense Maven Archetype to generate a project, then key stores are created and set-up so that no private keys are leaked to users.
  • License keys are encrypted in order to protect the privacy of your customers. The password based encryption algorithm is configurable, e.g. PBEWithMD5AndDES for compatibility with applications using the legacy V1 license key format or PBEWithSHA1AndDESede for applications using the new V2/* license key formats.

String and Code Obfuscation

You need to obfuscate constant string values plus the byte code of your software product in order to protect it against reverse engineering with popular tools like javap, JAD, ASMifier etc. Again, this a general concern for any closed source software.

When obfuscating your software product, don’t forget to include TrueLicense in the process. Otherwise attackers could simply substitute the TrueLicense classes on the class path with custom created mocks.

You can use the TrueLicense Maven Archetype to generate a project which uses the TrueLicense Maven Plugin and ProGuard in order to obfuscate the generated license consumer application.