如何在 .NET 程序集中安全存储加密密钥

发布于 2024-08-26 23:12:02 字数 193 浏览 3 评论 0原文

为了防止有人轻易获取我的数据,我将服务中的数据缓存为加密文件(基本上是复制保护)。

但是,为了做到这一点,我必须将加密密钥存储在 .NET 程序集中,以便它能够加密和解密这些文件。

意识到像 Red Gate 的 .NET Reflector 这样的工具可以直接拔出我的钥匙,我感觉这不是一个非常安全的方法...有没有最佳实践来做到这一点?

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 this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

国际总奸 2024-09-02 23:12:02

您必须决定什么是可接受的风险水平。没有“安全”的方法可以做到这一点。

如果有人使用反射器,或者只是使用 System.Reflection.Assembly 类打开程序集并以这种方式获取资源的风险太大,那么下一步可能是在启动时从服务器下载密钥。

然后有人必须在使用您的代码时执行诸如调试之类的操作并以这种方式获取密钥。您可以使缓存的内容过期并换出密钥。您可以让每个人都拥有自己的密钥,以保护一个用户的数据免受另一用户的侵害。

您可以做很多事情,但如果您的目标是阻止某人能够解密您放在他们机器上的程序集能够解密的信息,那么您应该知道这几乎是不可能的。您真正能做的就是提高盗用密钥/数据的成本;你无法阻止它。

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.

请持续率性 2024-09-02 23:12:02

您无法防止解密,但可以防止伪造数据的重新加密:

只要您的代码在其他人可以访问的计算机上运行,​​您就无法阻止他们检查该程序。然而反编译和分析确实需要时间。正如 MaxGuernseyIII 所指出的,这完全取决于可接受的威胁级别。

在您的情况下,问题不在于黑客可以反编译您的代码,而在于他们可以更改您想要保护的数据(谁拥有许可证)。

因此,您可以使用公钥加密方法来加密数据。这样黑客可以读取,但无法重新加密。

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.

驱逐舰岛风号 2024-09-02 23:12:02

正如马克斯暗示的那样,您需要考虑威胁模型。

您担心什么样的攻击者? (关心某些人是合理的,而关心其他人则是不合法的)。典型的类别可能是“购买程序的不懂计算机的用户”、“愿意花费数小时研究解决方案的专门人员”、“知道如何在线查找裂缝的休闲用户”等。

根据您的具体情况,解决方案可能是不同的。

需要注意的一个有趣/悲伤的事情是,如果您的产品很受欢迎,那么只需要一两个专门的人坐下来打破它,然后为所有人发布补丁。我想这就是软件的本质,当你的整个应用程序在他们的机器上运行时,这是一个未解决的问题。

显然,这意味着如果您的应用程序作为网站运行,即它在您控制的计算机上运行,​​那么这不是问题。

我知道这不是一个特别有用的答案。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文