class library security & license technology

I asked a question regarding assembly security and someone told me few things:

You c开发者_高级运维ould invoke a licensing technology when the library was to be instantiated. What I've done in the past is include a public key as a resource to the dll, and then look for a license xml document with a cryptographic signature signed with my private key. As long as I keep close track of my private key, it's pretty difficult to defeat.

After reading this I have some questions:

1. How to invoke my licensing technology when I'm developing a class library?
2. How to add a public key as a resource to the assembly?
3. How to look for a license xml document with a cryptographic signature signed with my private key and from where & when to look?

It will be better if anyone please help me to understand the things in detail to implement the above security. Thanks a lot.

---

"Licensing technology" is basically the methods he goes into more detail about in the rest of the paragraph. A "license" is little more than proof of permission for an actor (either the user themselves, or other code being run on their behalf) to use your code. It doesn't have to be some universal standard like an SSL certificate. It just needs to be known to you, and difficult to fake by others.

As for resources, this is just something inherent in .Net. in VS Solution Explorer, go to the project you want to be able to access your restricted DLL from. The first item in its expanded contents will be a Properties folder; under that you should find an item Resources.resx. Open it up and you'll get a GUI that will allow you to reference strings, images, plain text files, etc. which can be compiled into or kept alongside the DLL when the solution is built. This is where you'd specify a string that is some encrypted, known value. Probably the most secure string to encrypt would be the strong name or GUID of the assembly, because then you could compare what you decrypt with the assembly information of the caller, preventing someone from getting the encrypted string out of one of your libraries and using it in theirs. In your restricted DLL, you can use the same feature to store the decryption key you will use to decode the string provided by calling DLLs.

There are numerous resources available for tutorials on how to use RSA encryption (the encryption method inferred here) in .NET. There is an RsaCryptoServiceProvider that will perform encryption/decryption, generate keys, etc; all you have to do is drop it in. Something that may be confusing is that in asymmetric-key algorithms like RSA, data is usually encrypted using the "public" key and decrypted using the "private" key. This is because assymmetric keys are usually used over public communication channels, and you need to give the remote party a key they can use to write messages that you will then decode. However, in this case, your restricted DLL must decrypt the data it needs to compare, and so it needs a fixed "private key". This makes the decryption key "public" to anyone with .NET Reflector or some similar disassembler. However, if you, the developer, are the only one that can provide encrypted strings to DLLs that are authorized to access your DLL, then you can keep the encryption key secret.