如何创建序列密钥以保护应用程序

Question

我有一个创建串行密钥的应用程序，如下所示：

Take customername
Sign customername using privatekey and sha/dsa algorithm

然后可以通过使用公钥解码来检查许可证，并检查cuastomername匹配

除了生成的序列相当长外，这没关系。因此，客户输入序列密钥并不是真正实用，而是必须在文件中提供序列，这与薄雾应用程序和工作方式有很大不同，并且令人困惑。

许多其他应用程序仅在用户进行购买时向其提供Guid

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

并且用户必须输入他们的电子邮件地址和guid来许可他们的申请。

这看起来像是一个更简洁的用户解决方案，但我不明白这样的应用程序如何验证来自无效guid的有效guid，除非它通过检查数据库上的emailaddress / guid对在线完成。但我真的希望在不需要在线检查的情况下进行某种验证：

a＆gt;如果互联网连接/我的服务器关闭，应用程序将无法运行 要么 b＆gt;他们可以通过禁用互联网访问来规避检查

修改

我的理解解决方案如下面的答案所示：

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

我的主要问题是我需要将盐存储在某个地方的程序中，因此如果黑客找到了盐并找出了我正在做的事情，他们可以为任何电子邮件地址创建有效的许可证密钥生成器。

我目前使用其他程序的方法：

我已生成公钥/私钥对
用户进行购买 我通过签署电子邮件地址来生成许可证 BaseEncode生成的许可证
向用户发送许可证
程序通过basedecoding和使用公钥解密来验证许可证

我的问题是，当我签署电子邮件地址太长时，我最终把它放在一个文件而不是用户将其输入到字段中，但可能问题是我是base64encoding而不是转换为Hex。

签名输出可以有多长时间，取决于输入的长度还是总是相同？

因为我使用公钥解密密钥，所以我可以删除许可密钥的一些字符，但如果生成密钥只有40个字符，我想这没关系

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

当然他们可以破解应用程序，但如果应用程序定期更新，这将会有很多努力。

总结如此： 我是否正确理解了这种方法，哪种方法最好，以及为第二种方法生成了多少数据。

Answer 1

我认为签名方法目前是最佳做法。顺便说一句。有很多免费的文库可以涵盖这个主题。

许可证密钥的长度至少由签名密钥长度决定 - 1024位密钥产生128字节许可证（如果没有添加其他有效负载）。

许可证文件通常包含有关许可使用本身的更多信息，例如有效期，许可子模块，吞吐量...... - 签名本身嵌入在此结构中。通过这种方式，您可以获得灵活性，并且我强烈建议您使用此解决方案，即使许可证变得更大。

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

修改

1. 签名的长度是密钥的长度。例如。 1024位（或128字节）
2. 如果您的应用程序知道签名的数据（例如邮件）
，您可以单独使用此签名
3. 您可以签署“许可证文档”，其中包含的内容不仅仅是邮件。在这种情况下，许可证包含属性和签名（因此，仅比签名更长）
4. 您不需要在线连接进行许可检查。只需随应用程序导入许可证，并随时查看。
5. 除了许可证文件导入之外，您还可以使用短ID作为密钥在线下载许可证文件。许可证已下载并脱机。所以你们两全其美。

Answer 2

您可以只是哈希用＆＃34;秘密＆＃34;连接的用户信息。 salt然后截断哈希。

黑客 - 如果他们对您的程序感兴趣 - 将通过对源代码进行逆向工程来破解它：他们将找到哈希算法和秘密盐。

但是这也会发生在您的签名和验证解决方案中：他们可以绕过检查，使其返回true。

因此，标志和验证解决方案更复杂但不安全。