开发简单的序列号生成器/验证器的好方法是什么？

Question

我正在开发一款我想在某天销售的应用程序 - 越早越好！我想开发一个相当简单的序列号方案来保护它。

• 简单的数字/字母组合，长度不超过 25-30 个字母数字字符（想想 Microsoft 产品密钥）
• 不要求用户在验证过程中输入任何个人信息（如电子邮件地址）

我一直在考虑这个问题（很少），我认为公钥密码学是一个很好的起点。我可以生成一个标识许可证的字符串（如 SKU + 普通 ole' 整数序列号），对其进行散列、加密，并将序列号 + 标识符编码为 25 位（左右）字母数字密钥。然后，应用程序会将密钥解码为序列号和“签名”，生成标识符散列，使用相应的公钥解密“签名”并将其与生成的标识符散列进行比较。

基本上，产品密钥包含两个数据：用户声称拥有的序列号以及程序可用于验证该声明的各种签名。我不知道 25 个字母数字字符（每个编码 5 位，实际总共 120 位）是否足以满足所有这些要求。但是，它不必是加密安全的，只要代码不易被猜到就足够了。我可以接受短密钥长度和短哈希。

就实现而言，该应用是用 Objective-C 为 Mac OS X 编写的，但考虑到将代码注入 Cocoa 应用是多么容易，我可能会直接用 C 编写验证代码。

Answer 1

我不会使用任何强密码，因为无论如何你都必须在程序中对其进行解密，这使得密钥生成器或至少破解变得容易。

我会执行以下操作 - 比如说，25 位数字。现在添加一些规则，例如： - 数字必须能被 31 整除 - 它必须以最后一个字母开头和结尾 ...

始终使用这些规则生成密钥。使用 20 条或更多规则（越多越好）。部署应用程序时，使用较少数量的规则，例如10 检查密钥是否有效。 然后这些规则将被反汇编并用于创建 keygen。

在每次更新时启用您以前未使用的规则之一。如果规则选择正确，您将禁用大部分由 keygens 生成的密钥。

Answer 2

我喜欢@bh213 的方法，但是它不会阻止在您更新序列号规则时修复密钥生成器。

就个人喜好而言，我更喜欢基于规则集方法的密钥生成器，因为如果黑客必须修补二进制文件，那么由于黑客修补程序不好以及随之而来的战斗，您可能会对您的软件进行差评在你和黑客之间。

我的偏好基于一个普遍的软件真理：如果软件足够流行，它就会被黑客入侵，没有任何计划，没有巧妙的方法可以防止这种情况发生。这场战斗是在资源有限、时间有限的开发者与手头无限时间的黑客群体之间展开的。

您的密钥生成方案实际上只是为了让诚实的客户保持诚实 - 从应付帐款中获得支票比让安全部门在密钥生成器上签字更容易。

Answer 3

由于 Redbeard 0x0A 是正确的，CD-Keys 是为了让诚实的客户保持诚实。购买您的产品只需要比找到一个注册机更容易。

如果您在网上销售您的产品，那么最好的方法是给他们一个包含序列号的文件。这样，连续剧可以长到您想要的长度，并且您的付费客户不必浪费时间输入连续剧。

串行方案可以非常简单：

1. 有很大的序列空间（25 个字母数字大约是 10⁴⁴，但只需使用序列文件并为 10²³¹¹的键空间执行 80 字符 x 16 行>)
2. 选择一些规则，将有效序列号空间减少到您认为您在最疯狂的梦想中会卖出的数量的 100 倍

如果您的产品具有在线组件（例如游戏如何拥有多人在线），您可以使用加密强随机数生成器进一步减少有效序列号（要选择基于规则的密钥的子集，产品使用规则来检查序列号，服务器使用最终的真实序列列表）。当您的产品向您的服务器请求服务时，服务器可以检查序列号。

Answer 4

所有规则，无论是定制开发的还是基于加密的，都可以被发现和破解。考虑一下您正在为谁构建应用程序。我的许多产品都是为企业服务的，所以他们要么会购买，要么不会。他们通常不会在他们的网络上运行被黑的版本。无论如何，寻找注册机的人都不太可能购买您的产品。您只是想确保您不会惹恼您的客户，以至于他们不再想购买您的应用。

话虽如此，我已经为这种东西编写了一个库，以便在基于 AES 加密的应用程序中使用。我以 25 美元的价格出售它，它使用密码和盐来使您的序列号独一无二。如果您有兴趣，可以在这里找到：http://simpleserials.com

Answer 5

sigpipe.macromates.com 上有一篇博客文章解释了如何使用私钥/公钥加密来检查序列号。它可以验证用户和序列号是否匹配。 （签名/验证）。我可能会加一些盐，只是为了确定。

由于这篇文章是 2004 年发布的，您应该考虑推荐的密钥长度 keylength.com。