3

我正在尝试使用 Microsoft 的 LicenseProvider 找到可靠的许可方案。我的想法是通过 RSA（具有 2048 位密钥的 RSACryptoServiceProvider）的方式使用异步加密。我发现这很容易，但我不确定这个机制到底有多安全。这不是为了好玩，需要对美国的许多产品（我们说的是大约 100 次安装）进行复制保护。不需要截止日期。

现在，我使用私钥来加密许可证文件 (.lic)。在客户的计算机上，许可证管理器将在运行时将计算机的唯一 ID 与 .lic 文件中存储的唯一 ID 进行核对。由于产品将具有相应的公钥，因此它可以解密文件。如果 ID 匹配，则许可证有效并且程序启动。

（顺便说一句，计算机 ID 是：MAC 地址 + CPU 序列号 + 硬盘驱动器序列号的组合。因此，如果其中一项发生更改，则需要更新许可证）

就这么简单？如我所见，即使您可以解密 .lic 文件，也永远无法再次加密它，因为您没有所需的私钥。

现在，除了购买昂贵的第 3 方解决方案、破解和规避许可 DLL 之外，您认为使用 RSA+computerID 的想法有多安全？

（是的，我们正在研究混淆代码以使其更好）

感谢您的反馈！

4

3 回答 3

3

不管你是否混淆了代码，关键是你的技术不安全，可能会被打败。您的产品的许可方案只会与您的混淆一样安全。

与其使用 RSA 来加密唯一 ID 或许可证文件，不如考虑使用 RSA 来加密具有基本核心组件或某些关键功能的模块、程序集或类库，而您只希望在购买的完整版本中提供这些功能。这样，如果没有适当的许可，完整版本的功能或应用程序的核心逻辑根本不存在，而不是您的所有辛勤工作都被 JMP 指令窃取到完整版本“许可”软件的入口点。

从根本上说，这个概念的最基本实现是制作您在购买后收到的“许可证”，并且必须将公钥粘贴到程序中以解密加密的模块/组件。但是，您不希望这样做，因为一个人可以购买“许可证”，然后将其分发给他的所有人或将其发布在他的博客上。至少，解密完整版本功能的密钥应该使用另一个密钥加密，并包含在软件的每个副本中。然后，“许可证”将是解密受保护软件解密的真实密钥的公钥。这样，您可以拥有多个版本的许可证，或者如果一个版本发布在所有流行的连续剧网站上，则可以对其进行更改。

更进一步，加密许可证的“许可证”将简单地使用计算机“唯一 ID”进行散列或对称加密，该 ID 在支付处理期间的某个时间提供给服务器。这样，只有那台计算机可以生成正确的“密码短语”，如果你愿意，它可以恢复密钥以解密密钥以解密程序/dll/whathaveyou。

理想情况下，您会将模块解密到其他应用程序无法读取且不会分页到磁盘的受保护内存空间中，然后从内存中运行并在完成后立即被覆盖。当然，这种技术不是万无一失的，一个坚定的逆向工程师可能会获得一个解密的模块以进行重新分发，但即使发生这种情况，也必须有人从你那里购买合法许可证。

其他想法包括将核心功能或关键数据结构存储为编译的机器语言或中间语言，加密，并在某处的服务器上，必须通过验证才能在每次需要执行该功能时从服务器检索该信息，并被解密直接进入受保护的内存，从中执行它，但这种复杂程度几乎没有必要，并且不会为所涉及的复杂程度提供大量额外的安全性。

我希望我给了你一些思考的东西。请记住，如果整个内容已解密并且可供用户复制，则无法控制用户制作的副本数量，因此我建议在应用程序未执行时对某些组件进行加密。

于 2013-01-16T00:03:53.010 回答
1

我有相同类型的解决方案。但是，我只是想指出，混淆代码并不能阻止逆向工程和黑客攻击，它只会使理解逆向工程代码的工作变得更加困难。混淆是这​​个过程中的一个重要步骤，因为没有它，对代码进行逆向工程，定位安全方法，并使其返回成功结果（即无需花费数月时间试图破解加密密钥，黑客只会绕过它）。

于 2010-07-02T06:44:18.630 回答
1

只是为了澄清起见，（您可能已经提到过）您应该使用 [provider].SignData([params]) 对数据进行签名，并使用 [provider].VerifyData([params]) 来验证许可证。也不要忘记从您创建的密钥对中删除私钥。

于 2010-07-07T11:46:55.747 回答