views:

149

answers:

4

I've been reading a little about encryption recently and am interested in protecting a licence file from tampering. Now this may not be the best way to do it, in which case I'm open to suggestions. But one way I was thinking of protecting it is to simply encrypt it.

However if I were to use encryption I'd need to use symmetric key, but this raises the question. If I store a key in the source code, with such tools as reflector, is it really worth it? It seems a fairly trivial task to obtain the initalization vector, salt, key etc and therefore break the encryption. Is there a way to protect a key in source? Or is this the completely wrong approach?

+1  A: 

Anything on the client side of the system can be compromised.

If you encrypt your file you must also somehow place the decryption key in your program. Anyone with a hex editor will be able to step through your code to find this key and then decrypt your license file and also create keys for your system.

Internet activation would be a good way to go, but I would see if you can find third parties to do this for you as they will have been down these roads before.

That said running your license file through some AES 256 encryption can't hurt :).

Spence
Thanks, I thought this might be the case.
Ian
+1  A: 

if you are speaking about MS/.NET environment, i recommend you the DPAPI. It is an API used to store your data protected by a password. Then you can ask me "but then i have the same problem", the answer is no, because in this scenario you use a user password to protect your data. So what you have to do, to access your data, is run your application under a certain credentials. In MS environment, its the the best solution.

from the documentation:

DPAPI is focused on providing data protection for users. Since it requires a password to provide protection, the logical step is for DPAPI to use a user's logon password, which it does, in a way. DPAPI actually uses the user's logon credential. In a typical system, in which the user logs on with a password, the logon credential is simply a hash of the user's password. In a system in which the user logs on with a smart card, however, the credential would be different. To keep matters simple, we'll use the terms user password, logon password, or just password to refer to this credential.

VP
+7  A: 

If you want to prevent tampering, you want signing/hashing, not encryption. Similar theory - but it means you can validate the file with the public key in the app, without requiring the private key that you keep on your server (and use to issue licenses).

Search for cryptographic hashing / signing.

Marc Gravell
Digital signing verifies against a trusted public certificate. If someone is starting up the reflector to pull keys out of the program, they can just as easily exchange the trusted public key.
Thanks Marc, I did briefly think hashing might be another way. Something I don't really know much about. I actually thought this might suffer from a similar problem, reflect and find out the how the file is hashed so someone can makes changes at will. If it works like encryption though, an assymetric approach is probably just what I need. I'll take a look into it. Thanks
Ian
+1  A: 

What you're attempting is DRM; there is no 100% way to do this on current PC hardware. There are many measures you can take to obfuscate parts of your program. It's a tradeoff between how much you want to obfuscate and how many hurdles you want to make your paying customers go through.

Thanks for the answer, I did think that obfuscation might help, however it's probably a fairly easy part of a program to isolate even with obfuscation in place.
Ian