班级图书馆安全与许可技术
我问了一个有关装配安全的问题，有人告诉了我一些事情：
当要实例化库时，您可以调用许可技术。我过去所做的是将公钥作为 dll 的资源，然后查找带有用我的私钥签名的加密签名的许可证 xml 文档。只要我密切关注我的私钥，就很难被击败。
读完本文后我有一些问题：
- 当我开发类库时如何调用我的许可技术？
- 如何将公钥作为资源添加到程序集中？
- 如何查找带有用我的私钥签名的加密签名的许可证 xml 文档以及来自何处&什么时候看？
如果有人能帮助我详细了解实现上述安全性的事情，那就更好了。多谢。
I asked a question regarding assembly security and someone told me few things:
You could 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:
- How to invoke my licensing technology when I'm developing a class library?
- How to add a public key as a resource to the assembly?
- 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
“许可技术”基本上是他在本段其余部分详细介绍的方法。 “许可证”只不过是参与者（用户本身或代表他们运行的其他代码）使用您的代码的许可证明。它不必是像 SSL 证书这样的通用标准。它只需要你自己知道，而其他人很难伪造。
至于资源，这只是.Net 固有的东西。在 VS 解决方案资源管理器中，转到您希望能够从中访问受限 DLL 的项目。其扩展内容中的第一项将是 Properties 文件夹；在其下您应该找到一个项目 Resources.resx。打开它，您将获得一个 GUI，允许您引用字符串、图像、纯文本文件等。在构建解决方案时，这些文件可以编译到 DLL 中或与 DLL 一起保存。您可以在此处指定一个字符串，该字符串是一些加密的已知值。最安全的加密字符串可能是程序集的强名称或 GUID，因为这样您就可以将解密内容与调用者的程序集信息进行比较，从而防止有人从您的库之一获取加密字符串并使用它在他们的。在受限 DLL 中，您可以使用相同的功能来存储解密密钥，您将使用该解密密钥对调用 DLL 提供的字符串进行解码。
有大量资源可提供有关如何在 .NET 中使用 RSA 加密（此处推断的加密方法）的教程。有一个 RsaCryptoServiceProvider 将执行加密/解密、生成密钥等操作；可能令人困惑的是，在 RSA 这样的非对称密钥算法中，数据通常使用“公共”密钥进行加密，并使用“私有”密钥进行解密。这是因为非对称密钥通常在公共通信通道上使用，并且您需要向远程方提供一个密钥，他们可以使用该密钥来写入您随后将解码的消息。然而，在这种情况下，您的受限 DLL 必须解密它需要比较的数据，因此它需要一个固定的“私钥”。这使得解密密钥对任何使用 .NET Reflector 或类似反汇编程序的人都是“公开的”。但是，如果您（开发人员）是唯一可以向有权访问您的 DLL 的 DLL 提供加密字符串的人，那么您可以对加密密钥保密。
"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.