Securely storing AES key in application binary

6502 said:
Why you think that AES key can be located with decompilation and the same cannot be done with asymmetric cryptography? The cracker may simply replace your public key with his public key and then generate license or do something of this kind.
Click to expand...

It doesn't work that way. The public key would be used in this context only to validate the license's signature. The private key would only sign the license.

There's no need to encrypt anything in this context if there's no real need for confidentiality, only authentication.
 
Consider security-in-depth. You can't stop it but you can make it very inconvenient. This keeps the honest people honest.
  • As discussed, public key to validate license and capabilities.
  • Static linking to prevent swapping out shared libraries.
  • Code signing as an attempt to catch tampering of the binaries.
  • Frequent updates to force user to reapply any hacks they've discovered.
  • A USB "dongle" eg. Yubikey.
  • Conditionally compile out the features not purchased.
Checking signatures - of the code and license file - can happen in multiple places - which changes with each release. Figuring out where to patch the code the first time took effort. Having to start over on each release is further deterrent.

I've seen some crazy copy protection schemes over the years. Never rely on just one trick.

Most companies have gone to SaaS or software as a service. You log in to their servers to get the functionality you need.
 
Beware; if you make your application too inconvenient to use (eg. with a hardware dongle) a number of possible customers will skip it and use a different application instead.
 
6502 said:
Why you think that AES key can be located with decompilation and the same cannot be done with asymmetric cryptography?
Click to expand...
I don't think anybody claimed that. :-/

6502 said:
The cracker may simply replace your public key with his public key and then generate license or do something of this kind.
Click to expand...
Sure. Still that's a more complicated "crack" (involving actual manipulations of the binary) than just grabbing a key and using it.

I tried to explain that earlier: Short of some locked down (hardware) platform (that reliably won't execute anything manipulated for example), all attempts to enforce your licensing are only about complicating cracks as much as possible.

To decide which technical measures you should implement, some risk assessment should be done. If your software deals with some specific domain only needed by business customers, it's already unlikely any company would even think about using it unlicensed (at least in our part of the world). Then, the solution with a license file that's encrypted and verified using asymmetric crypto is probably already more than enough. I still wouldn't suggest anything simpler ... the crypto functions necessary are readily available, so implementing that won't cost you much.
 
I just had an idea this morning.
When your app has more than one file, you can run md5sum or something over the whole pile at startup and collect the results (including your binary). You the take all these sums inside your code and hash them together (minus the one for the licence, you may sum that last and do off-by-one array access to not add it here) giving you the key with which your licence is to be encrypted.
So you change any file in the application, things won't work any more. And you can also report that as "Some files have changed, integrety damaged. Not starting". Depending on the area of usage, this is good practice anyway. Just look at medical software. You would not want to change the cuda library in an MRT application for one that was not tested and that may have bugs. I once heard a rant from some image processing folks about software written in javascript for this which updated all heck on itself. You will never get an approval for this.
 
The application is just a single file plus the licence file.

We just want to ensure no one can copy it and run it on other machines.
 
Besides talking about implementation details:
You probably don't want that the license file simply can be copied and used on a lot of (offline) installations.
So some data like e.g. customer company name should be encoded into the license file. To activate the license, the customer has to enter his company name in the software.
That is not a huge improvement security-wise, the logic for decoding the company name also is contained in the application binary. Anyhow it requires more criminal energy: a user has to enter a wrong company name making it clear that this is a stolen license.
 
elgrande said:
You probably don't want that the license file simply can be copied and used on a lot of (offline) installations.
Click to expand...
This won't work since the licence file contains an id which can only be generated on the machine being subject to the licence.

The application generates the id on every start and compares it to the id in the file.

eternal_noob said:
The customer generates a unique id on the server our app should run on.

Then he submits this id to us and we generate a file with some info and this id.

We encrypt the resulting file with AES and give it to the client.

The app requires this file otherwise it won't start.

If the file is present, the app decrypts it, generates the unique id again and compares that to the id stored in the file.

If the app runs on another server, the id generated upon start will be different and the app refuses to start.

If they match, all is good and the app runs.
Click to expand...
 
unitrunker said:
I've seen CPUID, ethernet and bluetooth MAC addresses, hard drive IDs, and the system's own UUID used to fingerprint a system.
Click to expand...
If you don't want your fingerprinting to be easily fooled by VMs, you have to include one factor depending on physical hardware (only the cpu-id comes to mind) and one factor depending on environment (e.g. MAC addresses of active network interfaces must be different at least on the same subnet). Of course, a VM running on the same host will have the same cpu-id, and it could have the same MAC as well when put in a different subnet... therefore, just add "more stuff" to make a fingerprint collission less likely....

Yes, this whole concept depends on how unique your fingerprints are, I'd say that's the harder part than applying suitable crypto.

It's also the part where annoying your customer could start, unfortunately. What if the host (or VM host) where you installed your software dies? You have to negotiate getting a new "license file" from your software vendor. In the case described here (offline operation possible), the vendor won't even have a way to know whether the old license file is still used, so there will be some potential for conflicts.

Enforcing licenses (aka "copy protection") is always some shady area, unless done by the platform itself (including hardware).
 
Short update.

I listened to you guys and convinced my boss that the AES encryption of our licenses is rather pointless and potentially dangerous.

I implemented a new mechanism that uses public-key cryptography as suggested here.

We now sign our licenses with RSA-PSS and validate the signature in our products.

Thank you again for the constructive answers!
 
You must log in or register to reply here.
Back
Top