java - 如何创建序列 key 以保护应用程序

Question

我有一个创建序列 key 的应用程序，如下所示:

Take customername
Sign customername using privatekey and sha/dsa algorithm

然后可以通过使用公钥解码来检查许可证，并检查客户名是否匹配

这工作正常，除了生成的序列相当长。因此，客户输入序列号而不是在文件中提供序列号并不实际，这与 mist 应用程序和工作方式大不相同，并且令人困惑。

许多其他应用程序只是在用户购买时为他们提供一个 Guid

即 5bd1060b-8608-4817-93ca-207f7c828e2f

并且用户必须输入他们的电子邮件地址和 guid 才能许可他们的应用程序。

对于用户来说，这看起来像是一个更简洁的解决方案，但我不明白这样的应用程序如何从无效的 guid 中验证有效的 guid，除非它通过检查数据库中的电子邮件地址/guid 对在线完成。但我真的希望在不需要在线检查的情况下完成某种验证:

a>如果互联网连接/我的服务器出现故障，应用程序将无法运行或者b>他们可以通过禁用互联网访问来规避检查

编辑:

我对以下答案提出的理解解决方案:

用户进行购买
获取电子邮件地址 + salt
用 SHA1 加密给出 160 位散列
转换为十六进制表示法给出 20 个十六进制值，即 40 个字符
Lop 的最后 8 个字符以提供 Guid
电子邮件用户 Gui 和他们输入程序的电子邮件地址程序通过获取电子邮件地址、添加盐、加密等等来验证此配对并检查生成一个有效的 guid。

我的主要问题是我需要将 salt 存储在程序中的某个地方，因此如果黑客找到 salt 并计算出我在做什么，他们可以为任何电子邮件地址创建一个有效的许可证 key 生成器。

我目前的另一个程序的方法:

我已经生成了一对公钥/私钥
用户购买
我通过签署电子邮件地址生成许可证
BaseEncode生成的许可证
向用户发送许可证
程序通过基于公钥的解码和解密来验证许可证

我的问题是，当我签名时，电子邮件地址太长，所以我最终把它放在一个文件中，而不是用户将它输入到一个字段中，但也许问题是我使用的是 base64 编码，而不是转换为十六进制。

签名的输出可以有多长，它取决于输入的长度还是始终相同？

因为我用公钥解密 key ，所以我不能删除许可证 key 的一些字符，但如果生成 key 只有 40 个字符，我想这没问题

我认为这种方法的优点是，即使黑客知道我是如何做事的，他们也无法创建许可证生成器，因为他们没有，也无法获取私钥，因为它只存储在我的服务器上。如果他们创建了新的私钥/公钥对，他们只能生成许可证，然后如果我的应用程序本身有编码的公钥，应用程序无论如何都可以拒绝许可证。

当然，他们可以破解应用程序，但如果定期更新应用程序，这将需要大量工作。

总结一下:我是否理解正确，哪种方法最好，第二种方法会生成多少数据。

Answer 1

我认为签名方法是目前的最佳实践。顺便提一句。有许多涵盖该主题的免费库。

许可证 key 的长度至少由签名 key 长度决定——一个 1024 位的 key 产生一个 128 字节的许可证(如果没有添加其他有效负载)。

许可证文件通常包含有关许可使用本身的更多信息，如有效期、许可子模块、吞吐量... - 签名本身嵌入此结构中。这样您就可以获得灵 active ，我强烈建议您使用此解决方案，即使许可证变得更大也是如此。

要在应用程序中导入许可证，您可以采用混合方式(就像我们所做的那样)。一方面，您可以提供经典的“导入许可证文件”解决方案。另一方面，我们生成一个随机的短 ID(如您的 GUID)并将其与许可证数据相关联。注册后，用户输入短 ID，应用程序通过 HTTP 查找完整的许可证。你必须只在线一次，你仍然可以提供复杂的许可证，用户只需要一个简短的 ID。

编辑

1. 签名的长度就是 key 的长度。例如。 1024 位(或 128 字节)
2. 如果您的应用程序知道签名的数据(例如邮件)，您可以单独使用此签名
3. 您可以签署包含比邮件更多属性的“许可文件”。在这种情况下，许可证包含属性(property)和签名(因此，比只有签名长)
4. 您不需要在线连接来检查许可证。只需将许可证与应用程序一起导入并随时检查。
5. 除许可证文件导入外，您还可以使用短 ID 作为 key 在线下载许可证文件。许可证已下载并处于脱机状态。因此，您可以两全其美。