How to safely store encryption key in a .NET assembly

In order to prevent somebody from grabbing my data easily, I cache data from my service as encrypted files (copy protection, basically).

However, in order to do this, I must store the encryption key within the .NET assembly so it is able to encrypt and decrypt these files.

Being aware of tools like Red Gate's .NET Reflector which can pull my key right out, I get a feeling that this is not a very safe way of doing it... are there any best practices to doing 开发者_StackOverflow中文版this?

You have to decide what is an acceptable level of risk. There is no "safe" way of doing this.

If the risk of someone using reflector, or just opening up the assembly using the System.Reflection.Assembly class and grabbing the resource that way, is too great, then your next step is probably to download the key from the server when you start up.

Then someone will have to do something like debug while using your code and grab the key that way. You can expire stuff that is cached and swap out the keys. You can make it so that individuals each have their own keys to protect one user's data from another user.

You can do a lot of stuff but if your goal is to keep someone from being able to decrypt information that an assembly you are putting on their machine has the ability to decrypt, you should know it's pretty much impossible. All you can really do is elevate the cost of pirating your keys/data; you can't stop it.

You cannot prevent decription, but you can prevent re-encryption of falsified data:

As long as your code runs on a computer accessible by others, there is no way you can prevent them from examining the program. Decompiling and Analysis does cost time however. As MaxGuernseyIII points out, it is all about acceptable threat levels.

In your case the problem is not so much that that a hacker can decompile your code, but much more that they can change the data you want to protect (who owns the license).

So you can use a public key cryptography method to encrypt the data. That way the hacker can read, but he cannot re-encrypt.

As Max hints at, you need to consider a threat model.

What sort of attackers are you worried about? (It's legitimate to be concerned about some, and not so legitimate to be concerned about others). Typical categories could be "non-computer savvy user who purchased program", "dedicated person willing to spend hours on a solution", "casual user who knows how to find cracks online", etc.

Depending on your exact scenario, solutions may be different.

One interesting/sad item to note, is that if your product is popular, then it takes only one or two dedicated people to sit down and break it and then release the patch for all. This is the nature of software, I suppose, and it's an unsolved problem when your entire application runs on their machine.

Clearly, the implication is that it isn't an issue if your application runs as a website - i.e. it's on a machine of your control.

I know this isn't a particularly useful answer.